I've lost track of how many developers I've talked to that have some major grievance with the way Apple runs the App Store. From rejecting Apps that include some SDK, to using the rejection process as a means to set new policy, Apple has made a lot of developers very nervous. Some of these guys are trying to make a living selling their apps. They have a deep fear of the often mysterious and cryptic rejections. No one dares speak out though! There has already been one developer who had his app removed for criticizing the App Store. Most sites won't go after Apple either because they want early access, or simply to avoid a life-time ban like Leo Laporte. I'm even a bit hesitant. They could revoke my Linkshare referral account, and the 60% of you that come here on Mac's could label me a "hater", but fuck it... This week's Too Much Information Tim is going to look at a real problem for one dev.

Om nom nom nom!

I've been talking with a guy who, for several reasons, needs to stay anonymous. He's a somewhat-high-profile guy in the tech industry and he had an idea for an app. This app is processor intensive though and he wanted to make sure people wouldn't accidentally buy it on older devices. Being the conscientious geek that he is, he spent a lot of time thinking about how to make sure he didn't screw over customers. Developers can't say, "Don't install on iPhone 3G and earlier, just iPhone 3GS and later."

You have to get tricky!

Many iPad 1 owners will know that the way a lot of people have been blocking iPad 1 installs is to require the front facing camera, available only on iPad 2s and 3s. This gets really complicated on iPhones and even more so with Universal apps. Don't get too fancy with your hardware requirements; you probably won't be able to change them after the app is released!

Artist Rendering of Anonymous Developer.Shamed and photographed by Apple.

This is a serious challenge for many developers. They want to make great apps that take advantage of the new hardware that Apple is selling, but Apple won't allow devs to prohibit the obsolete devices. In this specific case the dev knows that iPod Touches simply don't have the horsepower. Just to be safe, he wants to keep the iPhone 3GS out as well so that those users won't give him 1 Star reviews on iTunes, if they encounter any performance issues.

This should be as simple as sending Apple a list of hardware saying:

Disallow

Instead, Apple gives developers a compatiblity matrix of features. It's up to the developer to find some combination of features that only exist on the targeted devices. For this example, all of following are not available on iPod Touches, so let's see if we can use any of these on a Universal app to exclude iPhones prior to iPhone 4:

• Telephony: Would also exclude non-3G iPads.
• SMS: Would also exclude non-3G iPads.
• GPS: Would also exclude non-3G iPads.
• Magnetometer: Works, but you would need something else to exclude iPhone 3GS.
• Gyroscope: Requirement to exclude iPhone 3GS, although this also excludes iPad 1.
• Auto-focus-camera: iPhone 3GS has this, it would also exclude iPad 2.
• Camera-flash: This would exclude 3GS, but would exclude all iPads.
• Bluetooth-le: Would also exclude iPhone 4.

This is crazy, and it will only get worse as more and more iDevices come out. For this case you could go with requiring Magnetometer and Gyroscope. Unfortunately for this developer, he chose the GPS requirement, which completely eliminates iPads that don't have 3G! A fact he didn't realize until after the app went live.

What hoops are developers going to be jumping through, in just a couple of years, when they want to block iPad 3s? I praise apps that can maintain backward compatibility with older devices, but damn it Apple, you're the one that has made a business model out of annual obsolesce! Stop making developers the ones to deal with it.

Reader Comments 6

excellent post, Tim! this is indeed a problem and needs addressing, much in the manner that you propose. we're in complete agreement that the system and these "compatibility games" that devs must play is archaic and needs a serious overhaul.

however, don't forget that it's also possible to download apps through iTunes on your Mac or PC, so these installation requirements still won't prevent someone from downloading an app that they won't be able to install on their iOS device.

a solution to this potential issue could be for iTunes to quickly check to see which devices have been synced and/or associated with said user's account, and at the very least, pop-up a warning before the purchase goes through that the app may only be installed on XXX devices, etc.

Yes, Google has a similar thing in place already. I have a really cheap Galaxy Prevail, it can't run some newer apps, and Google Play tells me so. It won't even let me buy stuff on the computer, because it knows that I only have that phone associated to my account. If you have multiple Android devices it will show you which are compatible and which aren't.

You'd think their infamous hardware fragmentation would make managing app incompatibilities a nightmare, but it has never been an issue. To be fair, I don't know of a lot of apps that are really pushing the hardware in the same ways some people are on iOS. The deprecation model is basically when the manufacturer stops updating the OS firmware for the device. The OS version becomes the primary requirement for an app, but this also works out in a "If it ain't broke, don't fix it" sense; the phone never really gets broken by any future OS updates or apps (*cough*iPhone 3G*cough*). If it works for you, you can just keep using it as is.

Try-before-you-buy would fix a lot of things. As a developer, I'd love to let people beat on the app for a day or two before forking over the cash -- this would take care of getting an app that doesn't work as expected or on the hardware they have. Reviews would be allowed only if the app is paid for, so there would be fewer "yer app iz da sux" reviews, when someone buys Auria, but was expecting Angry Birds.

With all due respect, that thing is NOT competition for iOS, as it's a completely different beast. It's way more competition for something like the Teenage Engineering OP-1 or other similar hardware than anything in the App Store. It's a neat idea, but probably destined to not succeed, at least in any meaningful way. How much does that baby cost, anyway? Look at the conclusion Lemur came to about being in the dedicated hardware business in the age of the iPad.

The Polysix emulation looks awesome, though (is Korg going to unleash that on iPad sooner than later?) but the biggest problem with a touchscreen laptop-esque setup is that you'll eventually suffer from fatigue, commonly known as "gorilla arm"-- it's much more difficult than it would seem to accurately use a touchscreen laptop, you'll get real tired real quick having your arm outstretched like that for long periods of time, and that's no fun, is it?

Now, the Minimoog had a control panel at a similar angle, but that worked because of actual physical controls that you could grab and sort of "hang off of" if you liked without doing any damage and still accurately controlling your sound. I'm afraid with this set-up, it wouldn't be anything close to the same experience.

Not to keep harping on the design of this little guy, but that two octave keyboard sans mod/pitch wheels looks pretty useless, too. I imagine that I would be wanting to use the MIDI ports on it to connect a different controller, and at that point, well, what's the point exactly?

was merely pointing out that android is a proven viable alternative platform for consumers...and developers.the device itself is likely only a proof of concept/prototype at this point but, if korg and yamahaare willing to commit resources, it may succeed as a musical alternative to plugging an ipad into anakai or line 6 peripheral keyboard. admittedly, korg and yamaha have less limited (though equally valuable)resources, compared to indie developers. apple are world class risk managers (or so $117B in free cash would suggest) but, in the case of tim's rant,they seem to be alienating developers by pushing too much of that risk on to their (the dev's.) shoulders.it would seem to be a self-limiting process, ie., if developers jump ship, consumers are likely to follow, in orderto satisfy their own needs. thus, competition, in the free market (such as it is), may ultimately force them toaddress the dev's. concerns.