Recently I have been heavily involved in Apple platform development -- specifically of the mobile variety. This has involved launching and maintaining a prominent e-book reader (with a user base of 500k+) alongside my personal projects' apps (puush and osu!stream). While I generally try to see the best of any situation, developing for iOS has fueled stress and anger that I am not used to, and even made me consider at times that changing profession wouldn't be such a bad thing.
And don't get me wrong, I love coding. I live for code. So something must be drastically out of balance here, right? While some of the issues I have are specific to my own workflow and methodology, I think most of you will be able to agree on some level that things could definitely be greener in the Apple ecosystem. I'm going to touch on a few specific areas of iOS app development over the last couple of years which have hampered my productivity. Hopefully it will serve as a light warning to those looking at entering this arena.
Apple always has the last say
Since releasing our e-book reader, we have had to remove over half the functionality in order to keep it live on the store. After Apple decided to enter the e-book market, it was initially unclear as to how we would be affected; I knew there would be a drop in sales as Apple leverages their App Store and OS strongholds to promote their new app and store, but they did not stop at just that.
In a manner that I would personally say is many times worse than the age-old Microsoft anti-trust case, Apple gradually changed their policies to lock competitor e-book providers out of their system. It is obvious that they were not happy having customers using their devices to purchase books via other providers (even though all fulfillment was done via an external web link), and gave us a deadline to make the transition to In-App Purchases. This would mean giving a 30% revenue margin to Apple.
While reluctant to take this approach, we did end up attempting to embrace Apple's restrictions. Sadly, the publishing industry is a very complex one, and payments and pricing could simply not be moulded into Apple's tier-based pricing system. This would not allow for regional pricing, state-based tax, 100k+ product listings and rapid price changes, to name a few problematic points. Of course, Apple would have understood this from the beginning -- having to abide to the same contractual terms with publishers themselves when distributing via iBooks -- and pushed the deadline forward further while they planned the road forward for their competitors.
Then, along with Amazon and other key e-book providers, we were given an ultimatum: remove the store completely from the app. "Okay", we said, and replaced the in-app store with a link to our website. This was not enough to please apple; within a day our app submission was rejected, and what followed were a few months of back-and-forward build rejections. The end result wasthe removal of every UIWebView from our application, along with every external link. Yes, we could no longer provide even a web link taking customers to our company's own web site (not even a "forgotten password" link!).
The end result is a thin-client reader which can do not a lot more than read and sync books purchased outside the iOS environment. Potential customers cannot make a purchase unless they manually make the connection via our app and our website.
Too late to apologise
When I initially made osu!stream available, I ran into some licensing complications with the music I was using, resulting in the need to quickly pull the app (of my own accord) and replace the songs. A month later, I submitted an update to the app, which amongst many other improvements, mapped the previous song packs to newer ones. This was a way of ensuring users which bought the initial song packs didn't feel cheated after they were made inaccessible.
To reach the maximum amount of users possible with instructions on how to retrieve the new content (and providing a brief explanation of the events that took place), I wrote up release notes which had a paragraph dedicated to the licensing issues. In this paragraph, I apologised for what happened. This update got rejected on basis that release notes were "not related to the changes in the app".
When Apple reject an update, they generally do not give any specific instructions, instead only quoting the relevant sections from the Terms of Service passage and leaving the rest to you to figure out. I had a hunch that the word "sorry" triggered alarm bells, so changed only that sentence; accordingly, it was approved one day later (n.b. they did actually check each localisation, so it took two shots!).
While this might not seem like a huge deal, it is just another example of the kind of randomly exerted control they have over the approval process.
As agile as a snail
One of the more apparent downsides of iOS development is the compulsory approval process associated with deploying an app to the App Store. Depending on seasonal demand, this approval process can take anywhere between 6 hours and 14 days (based on my experiences to date). The lower end of the scale is generally only seen when it is in Apple's interest to get it live quickly.
I usually work with a very rapid release cycle, usually aiming for daily releases -- pushing features and fixes the moment they are mature enough. At times this means relying on the end-user to do the "testing", but I find this to be the most productive release method. Keeping things fresh generally keeps people happy and coming back for more. Maybe I am designing for myself here, but if I was a user, I would enjoy seeing my feedback rapidly incorporated in a product.
Being limited by external forces to an average of weekly releases -- with no rapid user feedback in the interim -- makes development very staggered and unproductive for me. This is likely amplified due to the way I work, so I would be interested to hear other people's experiences with the imposed time-between-release limitation.
You might say "but you can deploy to testers as often as you want via a rapid deployment process (testflight is awesome)!", to which I would answer that I am definitely aware of this and actively deploying regular builds using these methods. The main problem here is that each developer account is limited to 100 registered devices for device provisioning, and while this may sound like a large number, I found that a month or two after accepting testers over 80% of them were inactive. You are only given one opportunity each year to remove a number of devices (at the anniversary of your account registration), which is both cumbersome and sub-optimal.
There are also many documented examples of extreme cases where apps get stuck in a pending state with absolutely no response from Apple. 2Do is one current example, who seem to be stepping in dangerous territory due to their iCloud's CalDAV sync. I have had some personal experience in trying to get a response from Apple's chain-of-command via phone and email and can attest that it is not so easy. Lack of control over your own product's release cycle -- and a communication blackout from those in control -- is indeed quite a scary concept.
Think Different, or Don't Think at all?
The final straw (which actually triggered the writing of this article) was having my app rejected today for storing downloadable content in the application's "Documents" folder. Since the introduction of iCloud, the guidelines have been changed to only allow "user-created" documents to be stored in this specific folder. This wouldn't be such a bad thing if it wasn't the only non-volatile storage area available to developers.
In short, this means that if myself and other developers in a similar predicament are to abide with the new terms, iOS can choose to delete all downloaded content in any app it sees fit to free up memory. Users are not given the option to disable this behaviour -- let alone warned about it when it happens. This is a support nightmare for app developers, who users are going to obliviously blame for the loss of their files.
The new "cleaning" behaviour (more details in this article) is going to surprise many users over the coming months as their files disappear at iOS' whim. In osu!'s case, this means all purchased songs would disappear, requiring special support at an application level to track when files have disappeared, alert users and trigger a fresh (and still quite awkward) in-app purchase process to re-retrieve the content. With a bit of luck, the user will have an internet connection available at this point, but what happens if they are in the middle of a long flight, or in an area without coverage?
I have been following this behavioural issue since it was discovered earlier this month, but didn't think I would be affected -- after all I am only storing around 10mb (at most) to the Documents folder. It would seem that for whatever reason, Apple is not only actively enforcing this new clause, but cracking down on it hard.
Waiting a week for approval to only be rejected is quite a bad feeling (especially when you have other coinciding release details planned), but when the rejection is due to this kind of issue it really makes you wonder if Apple know what they are doing. And makes me ask myself whether I really want to continue developing for a platform this unstable.
--
Hopefully this didn't come out as too much of a rant -- I do always try to look at things from a neutral perspective. I won't be stopping iOS development, but may take a few days off to regain some motivation :). I am not changing my app's behaviour to meet the new clause requirements and have instead filed an appeal with Apple. I hope there is enough velocity from my appeal, along with other affected developers/users' voices to change the way things work.
