developer tease

Don’t tease the developers

Does your platform just show and tell?

Dion Almaer
3 min readSep 18, 2013

--

Man, some iOS software development teams were giddy as they learned that old devices were able to install the last known working application.

This is an area of the AppStore experience that has been weak in the Apple eco-system. As a developer, I should be able to give the right version of an application to my user. For that decision, the type of device / version of the OS should be a factor.

This functionality (and others like it) change the way developers can think about new platforms. Without this ability, you can easily feel teased when WWDC comes around and shows you new sexy jewels, some of which have you gnashing your teeth. How many didn’t jump on the autoLayout bandwagon when it was first announced in iOS6 because they had to deal with iOS5 users? (How many didn’t think the tools were baked yet?).

Some are wary though:

“The likelihood of any complex app, especially anything API driven, working after several years of neglect are slim. Those that do work may be incredibly unreliable and buggy”

I don’t understand this. The point isn’t that apps will work forever. If the backend changes then the app may not work and THEN WHAT!

That being said, Apple has been very quiet about the details here. If there is a bug in an application, can the developer get a fix into the older version? How does that all work?

How about planning for that?

I always have a configuration service that my applications speak to and shake hands with when they come online. This allows a nice match of config, A/B testing, and analytics. The three legs of the stool.

Since the application passes up info such as the version of the app, OS, etc, the configuration service can then be smart enough to know if the app “should no longer work”. You can then put in a nag attack:

“Hey, you are really missing out. If you upgrade to v+1 you will get feature X, Y, and Z!”

And if you really get to a point where you can’t keep the application working, then you can use the nuclear option and force the user to upgrade to keep on going. You don’t want to do this to your users as a matter of course. In fact, I have never yet had to use it… but that doesn’t mean you shouldn’t plan for it. It is the kind of core functionality that you shouldn’t punt on, as you can’t go back into the past to fix it.

Native platforms such as iOS aren’t the only teasers. If you are beholden to any platforms out of your control (read: client side and more) then you are used to the tease.

The Web has the benefit of not being locked into an app model. You don’t have to wait for the user to update, you can basically force it. However, don’t get too smug. To be a Web developer is to be teased. How often do you see a great new feature in the platform that you can’t use because “I need to freaking support IE8 still :/” Hell.

We have seen amazing progress with the modern browsers which upgrade in short order, but I still wish that we could have gotten our cake and eaten it too by separating the app runtime from the browser shell.

I would give so much to be able to say “I require version ~5.4.x” and be able to map my application to capabilities.

--

--