Upward Mobility: The Hidden Cost of iOS7

It's much easier to change an iPhone's case design than to retool an entire ecosystem of apps

As with every Apple iOS release, iOS7 started to become a serious item for developers at the WWDC held the summer before the release, when all the ins and outs of the new capabilities start to be made available to the development community under NDA. In most cases, the technologies that are announced fall into two broad categories: new toys and better ways to do existing things.

New toys are always seen as a positive, because they don’t tend to require anyone to change anything in existing code unless they want to, or need to take advantage of the new capabilities. Examples of this have included Storyboards and Autolayout. If you wanted to use ‘em, you could. If you liked things the way they are, no problem either.

The other type of thing that developers would see at WWDC is Apple fixing items that had been sore spots, such as bringing in the Automatic Reference Count compiler. But even there, with a fundamental change being made to the way that the underlying memory management of iOS was being coded to, you could add one compiler flag and continue to retain and release to your heart’s content.

The golden rule for iOS seemed to be, First Do No Harm. If you had a happy, stable iOS application, an iOS upgrade would never ever break it. This is the big change that iOS 7 brought along.

It’s easy to see the skewmorphism banishment as cosmetic, and not understand how thoroughly Apple complicated the lives of iOS developers with the new release. The reality is that without major changes to the UI design of applications, most of them would look awful or even become non-functional under iOS7, and converting apps has taken many companies the larger part of the summer to accomplish.

It’s not even a matter of choosing whether or not to move to the new look and feel.  As soon as developers upgraded their XCode installations to the latest version, newly compiled apps automatically began to act like iOS7 apps when installed onto an iOS7 device. For most apps, this means awfully. Beautifully crafted buttons turned into ugly little links, page alignments went all askew, and tab bars could become unreadable. The only temporary workaround was to install the old SDK into the new XCode, a solution that was both unsupported and led to unexpected behaviors occasionally.

I’m not arguing whether the new anti-skewmorphic iOS7 philosophy is good or bad. To be honest, I have no strong opinion and have gotten used to it by now. But Apple, for the first time since I became an iOS developer, has pulled a “flag day” on the entire community, and I suspect that the rush to get apps in good shape for iOS7 derailed a lot of useful feature development over the summer. When Jony Ive decides that the new iPhone should have a plutonium cover, a few thousand engineers at Apple get to scramble. When he fundamentally changes the whole iOS user interface paradigm, the whole world of iPhone developers takes the hit. Jony, can you go back to playing with your CNC machines and let us code for a while?

Related

Sign up for the O'Reilly Programming Newsletter to get weekly insight from industry insiders.
topic: Programming
  • One of many injured developers

    The way Apple treats its developers is not like would be, e.g., a business partner. The last time I’d criticize Apple, on 2012′s 4th July (remember the issues with updates generated but not assumed by Apple), and complained about the delay to analyze our apps, they created a great sort of issues on our app in order to reject it, after 2 resubmits, with new issues pointed by them my company gave up it app.
    Now, one of our apps that was working normally till iOS 6.1 suddenly presents a lot of issues, on iOS7. Obviously we didn’t complain or criticize the “All Might Apple”, but we lost almost a month to correct “what was already right”.
    Because of this I support the “campaign” “Jony Go Home, to your CNC machines and let us code in peace”.