“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.

No Release Notes – Take 3

I’ve seen a couple of apps now start adding release notes again. But then, I also saw one company decide to stop adding release notes. My latest procedure, if I can’t delete the app yet, is to write release notes for them in the review.

Here’s my review of one company’s product – “Word”:

Since they don’t include release notes any more, let me tell you what they added in this version:
– Deletes all your files on login
– Spies on your family
– Detects cookie jars in your kitchen and eats all your cookies

If these aren’t the features they added, perhaps they’ll add release notes next time and prove me wrong.

I strongly encourage you to do the same. If they don’t get the hint, at least the reviews will be entertaining.