Category: iOS

Flutter Initial Impression

Flutter has been getting a lot of positive press in my social media feeds. I listened to an episode of Engineering Daily which interviewed Eric Seidel, one of the founders of Flutter.

I was extremely disappointed that they chose not to implement any hardware interfaces, like accelerometer, GPS, etc. Flutter really just cares about the UI. They are letting “the community” build plug-ins for all the hardware interactions because those vary by and sometimes within a platform. So now Flutter apps will be like PhoneGap and WordPress. Soon (if not already) there will be a dozen GPS plugins, all with slightly different feature sets, wildly different degrees of quality, and patchy support for different devices within a platform (think of the camera in Android devices). Judging between these plugins will be difficult, and in many cases plugins are unable to be used by certain types of clients, like the federal government, due to security concerns and vetting processes. So in those cases you will just write your own. The cost of a cross-platform app is not going to be lessened by using Flutter. At this point I’d say it’s OK for CRUD or brochureware, but not much else. If your app doesn’t interact with the hardware, why not just build a web site?

I’ll still write some code with it, but I’m disappointed with the reach of the platform into the devices it runs on.

Be Consistent Not Uniform

Android UI is not iPhone UI

A common shortcut often taken is to make one UI work on multiple platforms, and I find myself fighting this misconception often. My thoughts on this were spurred by an article Mobile First, Desktop Worst, which basically takes on mobile first and responsive design as being flawed. I think many of the arguments presented in that article were also relevant to building mobile UIs for an app that exists on both iOS and Android.

UI development is the most time consuming aspect of developing mobile apps. As the app owner you may want your app to be the same on all platforms to try and minimize the work, but this thinking is wrong. Individual users don’t use your app on multiple platforms and expect a common experience, they use your app on their chosen platform and expect it to act like other apps on their chosen platform. An application which does not adopt the UI conventions of the target platform will have diminished success. Users now expect applications to match their platform experience, especially millennials or users who don’t have experience in other platforms.

Each platform has controls, widgets and interaction paradigms that do not exist on other platforms. One UI that works across all platforms will not take advantage of the unique features of each platform, becoming a compromised design that does not meet user’s expectations. The differences in each platform are typically what makes a quality user experience for that platform. The least-common-denominator approach of the sameness across platforms reduces the potential for adoption and success of an app on any given platform. Mobile usability and a fabulous UX are now expected, and your app won’t achieve that goal unless it exploits the platform and device features.

Many of the cross-platform tools make this mistake out of the gate and promise a two-for-one outcome, which is fallacious thinking. Don’t fall into this trap.

Resources – Apps Users Want to Use


I am presenting this talk at DetroitDevDay on November 12th. It’s a look into some differing views on psychology and app composition and how it affects users of software. As a mobile developer, this kind of work had come to the forefront as the bar for mobile apps continues to rise.




First Time Jenkins iOS Build Stalls

We’ve been adding some Cordova-based builds into our system, and the first iOS build kept stalling during the build. After some troubleshooting and Googling I came across this fantastic article: Automating Cordova Workflow: xcodebuild Hangs During iOS Build. What Simon describes is exactly the effect we were observing, and his solution solved the problem. What is happening is Cordova is not creating the Xcode project correctly, it’s missing the schemes. Opening Xcode on the server fixes this, as does the scripted solution presented by Simon.

But even better than fixing our current problem with Cordova, one of the commenters solved another mystery which I’ve encountered for a long time in Jenkins iOS builds. The first time a project is built using Jenkins, it never seems to work. But if you remote into the server and just open the project using Xcode, it magically starts working after that. Turns out the schemes are stored in xcuserdata, which we are keeping out of source control with .gitignore. Opening the IDE on the server causes the schemes to be created. The real solution is to set the schemes to shared in Xcode. Open the Product menu in Xcode, choose Scheme then Edit Scheme:

Xcode Edit Scheme Window with Shared checked
Click the Shared checkbox then check in the project. The schemes will now be part of the build and it won’t hang mysteriously any more.