App Store Bit Rot

With Xcode 4.5 reportedly dropping support for armv6 binaries (iPhone Classic and iPhone 3G) and therefore deployment targets below iOS 4.3, actually continuing to use these devices gets increasingly harder.

Apple has half-baked measures in place that could alleviate this issue, but it appears to be broken.

Let’s say I’m using my iPhone Classic on iOS 3, and GreatApp 1.0 supports this hardware.

The developer decides to support iOS 6 and iPhone 5 using Xcode 4.5 and therefore has to drop armv6 support with GreatApp 2.0.

The device will not install the update because it’s incompatible. But iTunes on Mac/PC will download the update and replace the 1.0 .ipa on disk.

Now the device needs a restore from a backup. iTunes lost the 1.0 ipa. And the device is unable to get the older version from the App Store, because only the latest version is listed.

In iTunes Connect, there is an option to “indicate a legal issue with this version“. According to the wording on the page, this should make this version unavailable to redownload. This would also imply there was some way to access those old versions. But there is none.

Even when accessing the old purchase directly (viewSoftwareRedownload URL), the store seems to present only the latest version to the user, even if it’s incompatible.

With an ever-increasing number of older devices floating around, Apple should make sure customers have a way of restoring those devices to a somewhat usable state even when apps get their unevitable updates and drop explicit support for old devices.

The App Store should enable old devices to actually download the last compatible version of an app through the iTunes in the Cloud / iCloud mechanism, a.k.a. App Store / Updates / Purchased.

Developers should have a clear way of indicating which old versions should stay available. The “legal issue” indication is there already, but worded confusingly and apparently quite useless.

About APNs tokens and duplicate UDIDs

David Schuetz found the source of the leaked UDIDs by tracking the duplicate UDIDs in the file. Great find!

While the result was confirmed by BlueToad, his intermediary assumption about the APNs tokens is not correct.

Interesting. Just noticed there are UDID duplicates in that data dump, with multiple APNS tokens. Different app providers, or multiple regs?

UDID duplicates do not come from multiple app providers or multiple apps. Any production app on a single device will get the same token. E.g. Facebook and WhatsApp will get the same token on the same device at the same time.

Tokens change when

  • the user switches devices, regardless of restored backups
  • the user restores a device to factory settings and does not restore his old backup
  • (possibly some Apple certificate expires, maybe once every year or two, maybe at major iOS updates)

Tokens appear to be derived from some device specific data (maybe the UDID), a key applied at device activation, and possibly Apple’s certificate.

So the duplicates likely stem from development devices being restored to new OS versions, as is apparent from some of the device names as well. “iPad 4.2″ vs “iPad 4.3.1″ on the same UDID.

Another way of one device having multiple tokens at the same time is production vs sandbox environment. But at any one time, a device will not have more than those two tokens (in the App Store context, MDM may be another story).

Another interesting data point are identical APNs tokens on differing UDIDs in the data set. By all accounts, this should be impossible, as confirmed by Apple (iOS Dev Membership required).