The Hardest Problems in Mobile Engineering.
10 reasons why your life sucks
I try to avoid gushing on this blog, it’s not my brand, but the iPhone keynote in 2007 was probably the best corporate presentation of all time.
Jobs introduced the iPhone featuring multi-touch, multi-tasking, networking, power management, security features, graphics frameworks, motion sensors, a camera, and “desktop-class” email & web browsing.
“iPhone runs OS X” was regarded as a historic technical achievement (and a very handy marketing shortcut). In a decade defined by miniaturisation of technology products, Apple found a way to run computer-grade software into tiny battery-powered devices, converting Blackberries into antiques in one fell swoop.
How far we’ve come since 2007.
AI labs are busy invoking the machine god, while I, a moderately prolific mobile engineer, am having daily heated arguments about how to launch quickly or how to scroll without hitting an out-of-memory exception.
Uh. Anyway.
If you work in mobile, here’s 10 reasons why your life sucks:
This post is quite long, so your email client may cut it off. Read on my website for the best experience.
1. Modular Architecture (that isn’t spaghetti) 🍝
I always find it delightfully droll when people argue about screen-level architecture.
It’s not hard guys.
Pick an architecture, keep it consistent, bada-bing, bada-boom. Now anyone can onboard to your codebase without getting disoriented between screens. It’s a dull argument, and I’m tired.*
*That VIPER thought, amirite?
The architecture that matters, the one where you actually need to make interesting choices, is laying out your modules in the wider dependency graph of your project. And keeping it tidy.
Your modular architecture really solves an organisational problem: how can lots of people work on this project without stepping all over each other? Modules make it trivial to carve out ownership boundaries.
Smaller teams will probably still want to modularise. With tools like SPM or Tuist, it’s extremely easy to do so these days. Thoughtfully splitting your app into modules brings build time improvements and, more importantly, sparks joy when you look at your lovely unidirectional dependency graph.
When designing Granola’s modular architecture, I took a lot of inspiration from Tuist’s TMA (The Modular Architecture) and RevenueCat’s layered SDK.
As we ascend the agentic engineering abstraction ladder and get further from the code, keeping on top of system design is more and more critical.
2. Oh, you want to release?
Apple saw what happened to Microsoft in the 2000s.
Slowly, the impenetrable walled garden of their OS monopoly cracked and leaked as developers flooded to the freedom of the open web. Google ate their lunch across the successive tech cycles of web and mobile. Apple said, not I.
Distribution is everything. It’s the core reason Jobs pivoted from “HTML5 web apps are great for building on iOS!” in 2007 to the App Store in 2008. Devs who want to ship apps can’t get around Apple (except our friends at NSO Group), they need to ask permission every time they release.
App Review is ostensibly there for consumer protection: keeping a wash of slop off the Store. But we know it’s there to remind us who’s boss. We live and work under the imperious thumb of the ghost of god-emperor Steve Jobs. Or perhaps his middle finger.
This is why mobile teams usually skew a little older. We’re not really. We’re 30. We just lost all our hair because of App Review stress. Oh, to be able to ship in 30 seconds like our friends on the web. I hope you remembered feature flags.
Fun last-minute update to this section: this week I got possibly the most infuriating app rejection ever for my new drink-tracking app, “The Damage”
Instead of appreciating my genius custom tab bar for what it is, I got summarily rejected under “Spam” for building “primarily a drinking game app”, and they suggested I build a WEB APP instead 🤦♂️
Unfortunately, Apple failed to understand how autistic I get when I go on a warpath: I responded with a 3-pronged attack of replying, appealing to the App Review Board, and emailing a couple of my friends in DevRel to help correct the injustice. I got approved.
Oh, and this wasn't even close to my worst run-in with App Review: it nearly got me fired back in 2023. I worked for a startup building a consent-oriented data ingestion pipeline, where we got stonewalled and blocked from releasing for over 6 months.
3. Architecture Astronauts & Sync Engines
There comes a day in the life of every architecture astronaut where he (and yes it usually is a he) wakes up in a cold sweat: “OUR DATA. IT’S NOT ROBUST ENOUGH!”
Rapidly followed by a 16-hour Monster Energy Mango Loco™ binge, and subsequent 12,000 line PR (before it was cool), which lands without review and single-handedly introduces a jobs program to rival the New Deal, except the deal is that you fix a shitload of weird concurrency queue and database edge cases.
The subsequent 7-and-a-half reasons are behind a paywall (and intentionally slightly obscure contents headers). If you want 75ish% more value from my blog, you know what to do.
Paid members get lots of treats to help forget the pain of mobile engineering:
⚓️ Access my full library of 50 paywalled articles (including this one)
🚀 Read free articles a month before anyone else
🧵 Master concurrency with my full course and advanced training
🧑🚀 Get a free copy of my new eBook, “Land your iOS Tech Job”
❤️🩹 Support independent, sometimes funny, tech writing
