App Rejections Are a Lousy Way to Communicate Policy Changes

Following Twitter reports from earlier in the week, MacRumors and TechCrunch now report that Apple is rejecting apps that use the unique device identifier (UDID), by means of the -[UIDevice uniqueIdentifier] call.

This in itself is not surprising: iOS 5 deprecates the method, adding “Special Considerations” that advise developers to create a one-off CFUUID to identify a single install of the app on a single device.

So far, so good. I even had a section of my talk at last week’s CocoaConf Chicago that talked about CFUUIDs and the need to migrate any UDID dependencies to them now.

The problem is the timing. Apple’s established pattern has been to deprecate a function or method in one major version and, at the speediest, remove the call in the next major version. Many developers, myself included, expected that we had until iOS 6 to get off of the UDID.

But instead, without warning, the app review process is being used as an immediate death-penalty for the uniqueIdentifier call.

This is a problem because we’ve all had about six months to get off of UDID, and while that’s surely enough to get a simple app migrated — indeed, I have cases where switching it out is a 5-line fix — it is not necessarily the case that everyone can be expected to have already done this.

The real problem isn’t with developers; it’s with whom we develop apps for. Our clients don’t know or care what a UDID is, nor are they aware of a single line in Apple’s documentation saying “stop using this”. Sure, it’s our job to be on top of it. But let’s imagine apps with long development cycles — big apps, or academic apps that rev for the new school year in the Fall and are largely dormant the rest of the year. It’s entirely plausible and reasonable that developers of these apps have “get off UDID” as a high-priority item in their bug trackers, but are waiting for budget and approval to start working. And what if it’s not a simple process? What if an app has some deep dependency on access to the UDID, both in the app and on a server somewhere, meaning that two different teams are going to need to deal with losing access to uniqueIdentifier, and will need to come up with a plan to migrate user records over to a new id scheme?

Well, they just lost their chance.

Captain Hindsight is in full effect in the MacRumors forums, loudly asserting that developers should have known this was coming, have had plenty of time, etc. I get that it’s the natural defensiveness about Apple, but it gets worse… because this isn’t the only case of Apple using app rejections to carry out policy changes.

Thanks perhaps to my many posts about in-app purchase, I recently heard from a group of developers who’d gotten a galling rejection. They have an app with a subscription model, and used the new “auto-renewing subscription” product. This product is far superior to the original subscriptions that I have repeatedly described as broken, as they cannot restore between a user’s devices, and do not carry state to indicate what was subscribed to and when. Auto-renewing subscriptions fix these problems, and the In-App Purchase and iTunes Connect guides had (seemingly until a couple weeks ago), clearly disparaged use of the old subscriptions in favor of the new auto-renewing subscriptions.

So imagine the surprise of my colleagues when their app was rejected for using auto-renewing subscriptions. The reason given was that they were using it for a different business plan like a data-plan model, and auto-renewing subscriptions are, according to the reviewer, reserved only for content subscriptions like Newsstand magazines. I have never seen anything to this effect in any Apple I-AP documentation. Nevertheless, the developers had to switch to the shitty, broken, old subscriptions.

In both of these cases, we see Apple breaking with their own documentation or with long-established practice with no warning, and instead using app rejections as a tool to communicate and carry out new policies. This is wretched for developers, who get caught scrambling to fix problems they didn’t know they had (or didn’t expect just yet).

It’s also terrible for Apple, because the aggrieved developers initially control the message as they flock to blogs and Twitter, leaving it to loyalist commenters and bloggers like Gruber and the Macalope to mount a rear-guard gainsaying defense. To see Apple — of all companies! — not controlling the message is astounding.

All it takes is clarity. If they’re going to make such a major change, they’ve already got our attention via e-mails, the developer portal, and many other channels. They could and should clearly state the what, why, when, and how of policy changes. “We’re getting rid of UDIDs, because they constitute a privacy risk. We’ll reject any app that calls -[UIDevice uniqueIdentifier] as of March 23, 2012.” Not that hard. They’ve done it before: a few years back, Apple required streaming media apps to use HTTP Live Streaming if they streamed more than 10MB of data — this was communicated via announcements on the developer portal a month or so before its implementation, and nobody got caught by surprise, nobody complained.

Apple has developed a reputation for capriciousness in its app review process, and a cavalier attitude towards its developer partners. It’s not undeserved. As Erica Sadun once cleverly put it, “Apple is our abusive boyfriend.”

Comments (27)

  1. Checking the versioning of Apple’s messaging to developers about I-AP subscription purchase types, the current version (7.3) of the iTunes Connect Developer’s Guide still discourages use of the old, broken subscriptions:

    Non- renewing subscriptions can still be offered, but auto-renewable subscriptions are now preferred for the following reasons[…]

    There is no guidance in the product types section (p. 140) that indicates that auto-renewable subscriptions are only allowed for magazines. In fact, both types of subscriptions are described with a newspaper/magazine example.

    7.3 does not include an entry for itself in the revision history, so it’s unclear when this version came out or what it changed.


    Thanks Chris for this article. We’ve actually been porting all our apps over to the latest Flurry Analytics in fear this was coming soon, looks like it hit sooner than expected.

    I think where the ‘abusive boyfriend’ analogy falls flat is that there AREN’T plenty of other good fish in the sea. In fact, our abusive boyfriend treats us better than anyone else can at the moment and that’s probably why they can and will continue to do this to us.

    My question to you is: How can we change this? Our gripes about the gaps and inconsistencies with Apple’s developer processes seems to go continually unheard. I would say I’m desensitized to trying to provoke change and, as a result, focus only on my personal development and understanding the iTunes Store /Marketing aspects where I know I can affect results.

  3. mattand

    Came to this article via Daring Fireball. You know Apple has a problem when even Jon Gruber is critical of them.

  4. mattand: I know! Especially given how I rather pissily predicted that Gruber would defend it.

  5. Icouldseeitcoming

    Really? You couldn’t see this coming from the before you started using those IDs? Really? In an age when people are getting fed up with businesses asking for the phone numbers at the register, spamming them incessantly, and otherwise lying to people and invading their privacy on a regular basis, you REALLY couldn’t see this coming???

    There are no words.

  6. Icouldseeitcoming: Really? You could see this coming all along? Then where were you in 2008 when -[UIDevice uniqueIdentifier] debuted in the iPhone SDK 2.0? Were you telling everyone how this was an obvious privacy violation that would be snatched away at some arbitrary date in the future? If so, then you’re obviously smarter than me, than Flurry, than HockeyApp, and thousands of other developers. Yay, you. Now tell us what else in the iOS SDK we should be careful not to depend on.

  7. mattand


    It’s not an issue of seeing something coming. It’s an issue of communicating honestly and clearly with developers of your platform, something that isn’t Apple’s strong suit at times.

  8. Icouldseeitcoming

    No, the issue is that no one should have thought it was ok to use information that could identify or otherwise compromise another person’s privacy. It should have been obvious that once this got out Apple would need to do something about it. It should have been obvious that you should not have been doing it at all.

  9. mattand

    If Apple was that concerned about using that data, they’d have forbidden it from the very first SDK. Which they didn’t. So once can conclude they were perfectly fine with collecting data that may compromise privacy.

    Apple is a company that has rejected apps with little or no explanation. This makes a developer’s job infinitely more difficult.

    Quite frankly, only an idiot or a fool would base their app development around what Apple may or may not do.

  10. Icouldseeitcoming

    I don’t care if Apple was ok with it, and no one outside of the developer community does either. If Apple was ok with it, they were wrong. If they simply overlooked it, they were wrong. If you used it then you were wrong too. Don’t go whining that Apple did something about it once they were called out on it.

  11. mattand

    Did you even read the post?

    “The problem is the timing. Apple’s established pattern has been to deprecate a function or method in one major version and, at the speediest, remove the call in the next major version. Many developers, myself included, expected that we had until iOS 6 to get off of the UDID.

    But instead, without warning, the app review process is being used as an immediate death-penalty for the uniqueIdentifier call.”

    Apple failed to communicate in a timely manner that they were going to do this, screwing over everyone in the process. If they’re going to deprecate something, give people fair warning first.

    It’s really not that hard to understand. Even self-proclaimed psychics who can see things coming should be able to grasp this concept.

  12. @icouldseeitcoming: OK, Captain Hindsight, are you done yet? Or do we need to commemorate an “Only Person Who Gets It” plaque in your honor?

  13. mattand: You’re mostly right. Apple did deprecate it, in iOS 5. But they’ve never rejected apps for using deprecated APIs (lots of apps probably still use -[UITableViewCell initwithFrame:reuseIdentifier:]), and actual removal of deprecated APIs has occurred in full-point versions (and is rare anyways). So there was a deprecation, but the follow-up behavior was unprecedented and obviously a surprise to many of us.

  14. mattand

    @cadamson: Appreciate the info. I’m not a developer, but do follow Apple and its wacky adventures fairly closely. Always good to learn something new.

  15. Icouldseeitcoming

    Yeah, you guys are right. How could anyone have expected that something called a “unique device identifier” might be used to track people. Plus, it’s obviously much more important that Apple not step on the toes of developers who used this than protect their actual customers. They should have given out multiple warnings over a span of six months or a year. So what if customers were being violated during that time? Who cares about end users anyway?

    Apple screwed up by allowing it in the first place. Thankfully, they’ve corrected the problem. If you’re a developer and you disagree, please post a link to your apps so that I can be sure not to buy one.

  16. Icouldseeitcoming

    Ugh! WordPress removed my [sarcasm] tags. 🙁

  17. Saying that UDIDs are bad because they might be used to track people is oversimplifying the issue. Like many things, UDIDs could be used in ways that are not in the best interest of the user. However, the UDID is a brilliantly simple mechanism to allow an app to access assets and data files on a server, without forcing the user to go through the tedious task of creating yet another app account. And that’s just one non-tracking use. Are there other ways to do it? Of course! Just as there are other ways to do tracking.
    The problem here is that we can’t overreact every time someone abuses the system. Apple knows who these entities are, and instead of punishing all developers with new restrictions, Apple should just revoke certificates and take it up with each developer individually. Another example is the Address Book. It is incredibly useful to be able to access entries in the Address Book from an app, in order to make the user’s life easier. It is too bad that some apps decided to “steal” the Address Book’s contents, but when Apple finds out about egregious behavior like this, instead of banning all developer access to the address book, they really should punish one developer and make it known that Apple takes its users’ privacy seriously.
    But the point @mattand is making is that the lines of communication between Apple and the developers are there. In fact, most to the time, that channel is an echo chamber. Apple needs to utilize this channel better and give developers timely notices of what is going to be enforced, and when, or what is changing and why. I hate having to think of app submission as being a shot in the dark, not knowing what you could do to make your app be approved on the first pass.

  18. thomas

    One strange aspect about this, for me, is that Apple appears to be applying this policy non-uniformly. I develop an SDK that I put in a test app that I’ve had in the app store for several years. My SDK uses -[UIDevice uniqueIdentifier] like it has for many years, but a submission last week was just accepted today. It appears that Apple appears to not be checking my app like they do other apps. Once I mistakenly used a private API in my SDK. Apple accepted my app, but they rejected an app using my SDK submitted by a third-party.

  19. Thanks for getting back on topic, bitsonthego and thomas.

    I’ve followed up with a much more detailed post about the UDID itself over at Times Change, People Change, Hairstyles Change… Security Changes. Let’s please take the discussion of the specifics of UDID and its deprecation over there, and leave this comment thread for the original topic of how the move was handled. Thanks.

  20. Icouldseeitcoming

    So your response is: Apple should have handled this on a case by case basis, regardless of the fact that there are over half a million cases and counting? And yet you complain that you need to modify a small portion of your code because of the change? Wow. How many man hours do you think Apple would need to spend examining each application? How many will the average app developer need to spend? And how long would it take before users could reasonably feel that some semblance of privacy had been restored?

    Remember that most app developers didn’t use the id and many who had been could have and should have made changes last year when its use was deprecated BECAUSE OF PRIVACY CONCERNS. Honestly, if it had been deprecated because it was outdated then I could understand if a developer was taken by surprise at the way Apple acted. As it is, I’m surprised that Apple took so long — and I’m a little disappointed in them for doing so.

  21. Icouldseeitcoming: Please read my detailed history and analysis of the UDID at Times Change, People Change, Hairstyles Change… Security Changes and reply there. Your ignorance and belligerence is getting very annoying.

  22. uniqueflower

    Frustratingly, when uniqueIdentifier was listed as deprecated, I changed my app’s code to check availability before making the call:

    UIDevice *curDevice = [UIDevice currentDevice];
    if ([curDevice respondsToSelector:@selector(uniqueIdentifier)])
    NSString *deviceIDString = [curDevice uniqueIdentifier];
    // … code that uses UDID if available…
    // …. Fallback code that uses random numbers

    …because that’s what you *do* with deprecated methods. When Apple releases a future OS version that simply doesn’t include the deprecated call anymore, this code would continue to work fine.

    Also: To Icouldseeitcoming, who is clearly trolling, I will now counter-troll. UDIDs and browser cookies both track you, in very much the same way. If you plan to make sure you don’t use apps that access your UDID, you should also not use websites that store and use cookies. The privacy reasoning is the same in both cases.

    As a side note, this very blog uses cookies. You need to not post here, so that you won’t get tracked.

  23. […] about the iOS App Store it was a little unclear, vague and open to interpretation. Many developers assumed that they would have at least until the release of iOS 6 to clear things up, but that turned out to […]

  24. […] about the iOS App Store it was a little unclear, vague and open to interpretation. Many developers assumed that they would have at least until the release of iOS 6 to clear things up, but that turned out to […]

  25. […] is a problem,” developer Chris Adamson wrote in a blog post, “because we’ve all had about 6 months to get off of UDID, as well as whilst […]

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.