Mobile is actually pretty hard.

A manifesto aimed at the haters

Subscribe to Jacob’s Tech Tavern for free to get ludicrously in-depth articles on iOS, Swift, tech, & indie projects in your inbox every two weeks.

Paid subscribers unlock Quick Hacks, my advanced tips series, and enjoy exclusive early access to my long-form articles.

You might picture mobile engineers as blissfully unaware drones, making castles in the sandbox provided to us by our favoured tech giant, tongues lolling and eyes glazing over while we wait 30 minutes for Xcode to build.

Perhaps you’re picturing a colleague right now.

Mobile devs aren't exactly up to our eyeballs in container orchestration conundrums, battling the distributed computing basilisk, or untangling hours-long JOIN operations in billion-row DBs.

But hold onto your FitBits, naysayers. I’m about to shatter the illusion that mobile development is a walk in the (Apple) Park.

The OS is constantly trying to kill you

The iOS and Android operating systems are a microcosm of the fickle gods we serve - Apple and Google. Picture Jobs or Page standing behind your app with piano wire, just waiting for it to step out of line.

Perhaps you've used a smidgen too much memory or CPU.

Or, more likely, you’ve kicked off a background task to download a file, and your user got bored and TikTok started hogging all your system resources.

Too bad. Garotted.

Capricious overlords & prod incident purgatory

I’ve been building production mobile apps for 7 years, and my blood still runs cold every time an incident wriggles out of the woodwork. I can usually fix it within hours, but the fix won’t get released until Apple or Google deign my little app worthy of their attention.

In my darkest days, I was once on the hook in App Review for over 50 days while a SEV-2 smouldered in the background. Fortunately, we could finesse some hacks on the backend to work around it, but if we were less lucky our company could have been killed dead by Apple’s machinations.

The closest a backend or web engineer might get to this terror is if they are a customer of CircleCI, when you could have your prod fix ready to deploy in minutes, but are blocked for several hours while CircleCI fixes their own incident.

CircleCI, please sponsor my Substack

Diligent feature flagging isn’t just for A/B testing here - it’s a matter of survival. Fortunately, like any good benevolent dictators, Apple and Google have deemed us worthy of basic tools like phased releases to prevent outright revolt.

The ecosystem is like that movie Evolution

I appreciate I’m profoundly dating myself with this reference, but I hope you see what I’m getting at - when the scientists visit the impact crater of a meteorite:

• First, it just contains a rock covered in bacterial slime.

• A few days later, the cave floor in which it landed is covered in flatworms.

• A couple weeks after, it’s a tiny jungle ecosystem full of alien flora and fauna.

The mobile tech ecosystem is the same. In the last few years, both platforms have experienced seismic shifts where a large chunk of domain knowledge is deprecated.

2017: Kotlin first supported on Android. 2 years later, Google announces it as the preferred language, and a decade of legacy Java code is re-written.

2018: Kotlin finally releases Coroutines, a sensible concurrency language feature

2019: Swift 5 achieves ABI stability, putting to rest all arguments about it being “production-ready,” though there are still Objective-C devs today wondering why they can’t hire anyone.

2019: Apple finally releases Combine, a sensible concurrency framework

2020: SwiftUI 2.0 released. (The less said about SwiftUI 1.0 the better). UIKit rapidly falls out of favour as SwiftUI devs run circles around them.

2021: Google releases Jetpack Compose 1.0, immediately making Fragments and XML look dusty and lame. Let’s hope Google doesn’t kill it.

2021 (again): Swift finally releases async/await, a sensible concurrency language feature… and stops talking about Combine

The damn users keep moving away from WiFi

I know it sounds a tad whiny to gripe about our apps being "mobile," but constantly factoring in global state like network connectivity and permissions dials up the complexity in the apps we build.

Users often expect a seamless offline mode, requiring reactive data pipelines that bind our UI to a local DB, which syncs up with the network whenever it graces us with its presence.

Even worse, users with spotty or intermittent WiFi might appear to have some connectivity, but never actually be able to load anything. And do not get me started on Captive Portals.

Fragmentation up the wazoo

Our comrades on the web probably understand this pain - particularly the OGs who dealt with IE6.

In the age of Docker and container orchestration, it’s almost quaint to talk about fragmentation across devices, OSs, and versions.

In mobile, you get to deal with more than just these 3!

Each device might have its own screen size, resolution, and hardware limitations.

This fragmentation makes it tough to ensure a consistent user experience across all devices, and fully comprehensive upgrade testing is out of reach even for behemoths like Meta and Uber.

Resource management like Factorio

In the age of the Snapdragon 8 and A16 bionic chips this is less of a big deal, but back in the day, resource constraints and CPU power was a pretty big deal - you had to be sure that any device could render each frame within 16ms.

If you want to know how jittery scroll animations used to be on a basic feed UI, just try using a Flutter or React Native app today 🖐️🎤