The Mac and iOS developer community is perhaps the most brilliant single group of technologists in the business. Which is why it’s so damn painful to watch web development run circles around what used to be the most advanced platform on the planet. Here are seven ways that Apple fails to do its developers justice.
The explosion of high-quality web apps is changing users (and developers’) expectations for how software evolves. In the early days of Facebook (which I’ll use as an example of a prevalent web app) users were outraged when the layout and functionality changed. Now Facebook alters the look and function of dozens of features every month, and not only have users learned to roll with the punches, but they’ve come to expect this as a natural part of improving the Facebook product. The idea that Apple has to install more code on your phone through a software update just to extend its abilities is becoming tiresome.
Want examples? Look at this excellent laundry list of iOS, Mac OS, and iCloud complaints from FanGirls. Almost all of these complaints will have to wait for an OS update to be remedied, and even a minor OS update is a major hassle in iOS and Mac OS X, causing users to stop what they’re doing, download the update, and leave their device functionless for a little while while it fixes itself. The web has made us realize that these updates should be pushed in the background without hassling the user. Sure, this isn’t Apple’s fault–the nature of C languages is that you have to add code to add functionality. But there are ways around that: Read on.
Because Apple can’t push remote updates, they can’t do A/B testing the way web developers can. As a result, features take months or years of internal testing to improve, where some data-driven testing would probably speed the process exponentially. What’s the big deal, you ask? Well, at least one company–Philadelphia-based Artisan Software–is working on a framework that lets iOS developers push changes to their native apps without software updates. The ramifications of that will be huge as Artisan (and presumably, some competitors) bring native Mac/iOS app development cycles up to web-like velocity. The OS itself, and Apple’s own apps, will start to seem dinosaur slow when the third-party apps on their own platform are blowing by them in project velocity.
An ancillary problem is automated testing, something that web developers have benefitted from for years now. Mac and iOS developers are just figuring out ways to hack together automated testing, as this tutorial from Brooklyn-based startup HowAboutWe demonstrates.
There’s no reason to couple the release of developer tools and endpoints with consumer-facing products. Developer tools need to evolve faster, yet Apple has gotten in the habit of tying improvements in its platform along with product events. This is frustrating, but especially so for developers who have worked on the web, where discovering and fixing a problem in the platform often happens the same day the problem is reported. As Gus Mueller reports on his blog:
This was the very first thing that set off alarms in my head when Apple introduced the iCloud APIs. It’s baked into Foundation. Not “at the foundation of the OS” marketing talk, but the APIs are exposed to us via Foundation.h. This is a very, very bad code smell. Things on the web and in sync land move fast, and if we have to wait 12-18 months for something to be fixed or updated, why in the world would a developer adopt it? Oh, you say it’s all fixed on 10.9? That’s great. How about all those users who aren’t updating to that OS for whatever reason? Oh, they are screwed? Great. That’s what I wanted to hear… .Mac syncing sucked- but it had a downloadable SDK and it was the sane way to do things. You could download an update which fixed bugs and it was possible for Apple to add new APIs without having to do it in sync with the OS. Just because an idea had a bad implementation doesn’t mean the idea is wrong.
Sure, Facebook sort of blew it when it tried to make an OS–even forgetting the app dock until last week. But you can’t blame them, because developing a product in secret makes testing that much harder; you have to really know how to dogfood your product correctly. But one thing that Facebook deserves credit for, and which future OS-makers will no doubt be expected to replicate, is its reliance on its own well-documented APIs to build its products. Gus Mueller again, on his blog:
When Apple’s consumer apps use the exact same APIs we are given, it might be time to seriously look into using iCloud for doc syncing. When iCloud was introduced, Pages on iOS certainly wasn’t using the same APIs Apple gave us for syncing. Why not? I guess because it was broken and/or unreliable. Something third party developers had to find out on their own.
The stuff you store on Macs and iOS devices today are hopelessly fragmented across apps, local drives, and tiny, expensive cloud repositories. From FanGirls again:
Okay this is a huge debate with the geek crowd. That crew is heavy into the idea that iOS needs to have a ‘Finder’. But I disagree. I don’t think that users need to see into the core system in such a way. But what is needed is a single system where all data lives. Doesn’t mean that every app can use everything. But at least have common file types in a place where every app that can use it has a single copy to play with. Say like PDFs. Sucks that if I want to see it in iBooks, PDF pen and GoodReader that means I have 3 copies of the file filling up space. And then there’s that clunky ‘Save to’/’Open from’ file sharing system.
Apple has chosen to make software products for certain applications in their OSes, which causes third-party developers to eschew competition there–particularly where Apple is using undocumented APIs and has an unfair advantage. As a result, the Apple apps which suck (and there are a few) leave a gaping hole in the platform where innovation should be happening. One example is Contacts, which could use a huge organizational and social-networking overhaul–but you have to have guts (looking at you, Brewster) to compete here, so a lot of developers go where they know Apple most likely won’t–categories like Games, which is arguably the only one where Apple acts like a trustworthy platform. As Ben Thompson says on his blog:
An app can afford to be prescriptive about the user experience and means of interaction; in fact, the best apps have a point of view on how the user ought to use their service. Platforms, on the other hand, are just that: a stage for actors (i.e., apps) of the user’s choosing to create a wholly unique experience that is particular for every individual user.
Apple needs to figure out where it’s a platform and where it’s an app developer, draw the line, and rarely (if ever) move it. Otherwise, developers will always live in fear of solving problems for users which are too close to Apple’s interests, and where they might be shut down or trod over by a new Apple product.
What used to be a scrappy event for a tight-knit community has become an exclusive gala event. The glad-handing might be enough to satisfy prominent developers, but the rest of us are stuck needing to form our own unofficial WWDC just to feel included. Surely Apple could find a way to make their tent a little bigger. We’re tracking AltWWDC with interest–it’s a free and open Apple developer conference happening this week in San Francisco, concurrent with the official event.
[Image: Flickr user Boston Public Library]