Google is Winning the Developers; How Apple Can Win Them Back in an Instant
Google I/O went very well this morning. While I’m predominantly an iOS developer, I also write Android apps and, boy, was I blown away by Google’s intoxicating love for developers like me. Starting with the recent ability to reply to your Android app reviews (OMG), the announcements today were just as aweesome.
Google Play Services that also support iOS! WHOA!
Android Studio! OHMIGOD!!!
Integrated analytics, revenue graphs, alpha and beta testing on Play Store! SWEET!!!
Localization Services! YES! …that aren’t free and you still have to wait a week. WAIT, WTF?
That last dud aside, I’m pretty stoked. The crowd was stoked. The cheers were loud and authentic. Don’t mistake it for fanboys, these are exciting announcements!
These last couple years, conversely, Apple hasn’t really gotten my juices flowing. Following in the footsteps of Nintendo, who last peaked with the announcement of their glass-free 3DS technology, Apple has been about new laptops and new iPhones that aren’t much different from their predecessor. They’re a hardware company. If anything, the lightning cable has made life more annoying as evidenced by the older plug that sticks out of all the exercise equipment in my apartment’s gym. Doh! Better bring your adapter with you!
Google is winning the developers. The tools are outpacing Apple’s XCode which still suffers from excruciatingly long wait times to get the most obvious, and obnoxious, bugs fixed up. Storyboards are a duplication of XIB’s without replacing them. Autolayout is an unmitigated disaster. The App Review process is as frustrating as ever, providing no clear indication when a review will occur and providing plenty of inconsistent examples of what’s good and what’s bad. It famously drove Joe Hewitt away completely. Given all that, Apple can still win the day, and the cheer, with one simple announcement:
“We will no longer subject our developers to app reviews. When you submit the app to the App Store, it will process immediately.”
Some may say Apple would never do this, but why not? Of their rejections, what percentage of them are for functionality? Very few. Let’s be honest, they don’t test the apps very much. So why can’t they conduct the testing for copyright violations and other bullshit (yes, bullshit) on a more passive basis? Let’s say every day they test out 5,000 apps, looking for their usual violations. Should they find an offense, they report it to the developer who has 1 week to submit a fix. What’s wrong with that?
Also, think about the waste. On a recent project, we would have a new update lined up every week. In fact, we had to WAIT for Apple to review the previous app before submitting the new app. Why? Because if we re-submitted a new binary, we’d go back on the waiting list. Apple had to review the first app, then we’d re-submit, and a week later review the next version. They wated their time! By reviewing on a passive basis, they can skip interim updates and even prioritize their efforts on new apps rather than update after update. On top of that, it pisses off developers to no end that companies like Twitter and Facebook (and whoever else has a buddy at Apple) get precedence when there’s a glaring error.
In terms of an app that crashes, Apple rarely runs into that. So what if they let developers update apps immediately? Well, if the app crashes, guess what…THEY CAN UPLOAD A FIX IMMEDIATELY. I guarantee you Apple catches far, far less than 50% of the app crashes…so why punish developers by making them wait a week for an update to process while they helplessly watch their app reviews drill down to 1 star?
(No, I won’t get into the urgent update process, which is hardly ever worth doing considering the long-term effects.)
This one announcement would get the WWDC crowd to its feet, set the social networks on fire, and re-energize a devoted developer base that has watched the other side get all the good Christmas presents while we’re still trying to figure out how to get iCloud to work correctly.
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)