State of the Union: Mobile Development
Beyond iOS vs. Android
This was originally posted on Medium in January 2014.
I’m fascinated by, and concerned for, the state of the mobile software development community and ecosystem in 2014. We’re growing so fast it’s easy not to step back and consider the greater trajectory of how we’re shipping. Whenever the development process is considered holistically, it’s generally to bemoan the fragmentation between iOS and Android, or to pick a side and do some good old American bipartisan battling. There’s greater, and more dangerous fragmentation we should consider.
While pointing out the sorry state of client-side engineering recently, Tim Bray said:
“I’m going to skip the differences between Android and iOS here because they’re just not that significant in engineering terms.”
There are plenty of differences between iOS and Android: big and small, syntactic and ideological, distribution and revenue, discovery and deep linking. But in the greater arc of mobile software engineering, they’re just not that significant.
Joe’s not impressed
Managing Talent, Teams and Products
The obvious impact to engineering management is in talent. The software industry is starved for mobile development skills. We’re splitting a pre-existing supply-side deficit into even smaller pools. Leading the engineering and product development process becomes artificially more difficult, too. Getting to market takes longer. Architecting two functional back-ends while maintaing feature parity and consistent, usable experiences across OS front ends isn’t trivial (or easily done lean). Attempting to measure engagement with parity can also be ugly, like simulating iOS foreground and background events with Android approximations. The visual and interaction design languages are differ, too.
Fundamentals and Progress
Software development fundamentals are losing big. Machine/deep learning, data engineering, neural systems/genetic algorithms and many more disciplines are making unbelievable strides right now. Server-side engineers are finding ways to introduce fresh concepts like human-fault tolerance to make more robust systems than were imaginable ten years ago. Designers are re-inventing what it means to create experiences and foster interaction, putting us on the brink of a new set of HCI paradigms. Meanwhile, in mobile client land, we are arguing about interaction fashion and syntax.
I believe the mobile client engineering issues Tim Bray raised are mostly correct. The fragmentation is inefficient for making software, managing talent, distributing product, etc. We are investing engineering time in mastering the in’s and out’s of Google and Apple sandboxes, where the rules can arbitrarily change on short notice. Distribution dynamics are opaque and developer relations are poor. There are very few companies in the business of producing developer platforms that ignore their users with such candor.
That being said, Apple and Google are fueling the mobile revolution. That took a big investment and plenty of hard, innovative work from teams at both companies. The growth is amazing and it is painfully obvious that mobile is the future of software. So we put up with this, and we become experts in Apple-variant Objective C and Android-variant Java. But if themajority of consumer computing products run mobile software in the future, this ecosystem doesn’t seem sustainable. Inconsistencies and artifical limits on functionality can’t last, major user interface features that make consistent experiences difficult can’t last, and difficult app discovery can’t last (Android trying to fix this by indexing app contents but doesn’t have much to show for it so far).
But, most importantly, it’s about the software development process. Right now it’s brutally inefficient. As an industry we could be innovating on product faster if the system were more open.
I’m not just talking about the fragmentation between iOS and Android, but the general control on the entire mobile software dev-to-consumer pipeline and ownership of the OS. I can FTP an entire web app to a server and have it live for the world to see easily. I can experiment with richer interaction, richer data embeds, new API’s and web hooks. While the hardware has innumerable advantages in mobile, I’m left to exploring new ways to abuse Android and iOS class methods to innovate on functionality. If I find a great way to juice the grey area of their dev terms, the industry will follow suit, and it will be made illegal or inaccessible in future versions.
Finding the forest for the trees
Google continues to suck core Android functionality behind their private services wall, and Apple seeks to deepen their moat and increase platform lock-in (iBeacon/Airdrop: proprietary, closed versions of previously open protocol BLE). Mobile needs to open up, and Google and Apple need to encourage more experimentation around functionality and true leverage of distributed networks. Mobile engineers should be able to maximize time spent on novel applications of widely adopted mobile network computing, and less time learning how to implement platform-dictated specific rules for App/Play Store compliance.
The space for computer scientists to experiment has never been more fascinating or encouraging looking forward at the rate of Moore’s Law, consumer adoption and new interface technologies. I hope the 2014 mobile dev community is more vocal about this, and escapes the pettier debates that consumed too much time last year.
I hope we can raise the upper-bound of growth and discovery beyond the artificially-imposed commercial terms of Android and iOS developer documentation rules. Let mobile be “the great leveler” it has the potential to be.