“Grab The Nearest Device” Design

When designing Yet Another Wifi App (YAWA), I subconsciously had a design principle in mind that eventually was coded into the development process: the version numbers were kept in sync and all platforms had the same feature set.

I now call this “Grab The Nearest Device” design, because when I want to do something, I want to grab the nearest device. What’s the point of having an iPhone app if I can’t do the thing I just grabbed the device to do? I personally think that’s worse than not having an iPhone app because it makes me spend time trying to do something I then find I cannot. For example, say I want to add a new account at my bank. I pick up the iPhone (or run the app on my iPad), and search around for the “add account” feature. Can’t find it. Now I have to go get the computer and do it on the web site, whereas without the option of an app, I would have just gone to the computer in the first place. Next time, if I’m smart, I’ll skip the app and go to the web site – which is exactly what I find myself doing (frequently deleting the app in the process).

So, from a practical standpoint, here’s my development approach:

  • Need to reach multiple platforms? Do a mobile-first responsive-design web app (that’s how YAWA started). My app must work, completely, on a phone, and must not have a separate “mobile site”, because those always break (and it means maintaining two code bases instead of one).
  • Want device interaction on a solid platform? Carefully launch an app on iOS and keep the feature set 100% in sync with the web app (you *can* cheat and wrap the non-device-interactive features to the web app, but be very careful about your user experience when doing this as it can get you bad reviews really fast – remember, they already can go to your web site).
    • While you’re at it, do a Mac app – with a bit of work you can share most of the code. I recommend keeping all the code in one repository/Xcode project with a different target for the MacOS and iOS versions. Keep the version numbers in sync except, possibly, for minor version numbers if you need to push a bug fix. Oh, and always always include release notes. 😉
  • Need device interaction on more users? Carefully launch an app on Android, again keeping the feature set 100% in sync with the web and iOS apps. I personally haven’t done an Android app as the plethora of devices makes testing and putting out a reliable app more difficult – I’ve stuck with iOS because Apple’s done a pretty good job of making stable development possible.
  • Consider a Universal Windows Platform app (again, keep the feature set in sync before releasing)

You might think “that’s a lot of catch up for the second platform and beyond”. Design your app so that the core functionality is in a RESTful API. The web/iOS/Android/Mac/Windows apps should be clients. Then it’s easy to catch up.

Published by

Grant Grueninger

Grant's been in Software Development and computer-related consulting for over 20 years. He also studied music composition at UC Berkeley and USC. Having learned programming in Silicon Valley in the shadow of Lockheed, he's passionate about good, bug-free software development. He also enjoys quality music composition, but defines "quality" using the criteria of well-produced recordings and well-crafted pieces. As such many pop songs, especially those produced by Max Martin and his associates, match the definition. He maintains this blog in his spare time, using it to share information that either he cares about or thinks others will care about, hoping that those two criteria will at some point meet and garner mutual interest.

Leave a Reply