Supporting iPhones we don’t own
Our team carries new iPhones. Our users don’t. Plenty of the people who open one of our apps on any given day are using a device that’s three, four, sometimes five years old. If we only tested on what we have in our pockets, we’d be shipping for the wrong audience.
This is easy to forget in a small studio. When you develop on fast hardware all day, fast becomes normal, and anything that’s merely fine on an older phone stops registering as a problem. The only reliable fix we’ve found is to put the older phone in front of us, physically, every time.
Our reference fleet
We keep a small physical set of devices — one iPhone from each of the last five years, plus the cheapest iPad currently sold. Every build goes through that fleet before it leaves QA, not just the latest hardware sitting on the engineers’ desks. The five-year-old phone catches problems no simulator will.
The routine is unglamorous. Install the build, cold launch it, scroll the longest list in the app, open the heaviest screen, rotate the device, background the app and come back. On the iPad we also check split view, because a cheap iPad running two apps side by side is a very different machine from a new one running one. None of this takes long, and it’s the part of release week we’re least willing to skip.
The same thinking applies beyond the iPhone. Our Android apps get tested on modest hardware, not just flagship phones, and our iPhone and iPad apps also run on Apple-silicon Macs, where a layout that looked fine on a phone can suddenly sit in a resizable window.
What we’ve learned
Animations that feel snappy on the newest chip feel mushy two generations behind. Image-decoding choices invisible on a Pro Max can stall the main thread on a base SE. Memory budgets that are generous on 8 GB devices are tight on 4 GB. None of these surface as bugs — they surface as a quiet sense that the app feels worse on cheaper phones, which is exactly the impression we don’t want to leave.
What we got wrong early was treating the old phone as a final check rather than a design input. We’d build a screen, polish it on new hardware, and only then discover that it stuttered on the older device — at which point the fix meant reworking something we’d already called finished. Now the older phone is in the loop from the first prototype. If an animation or a list can’t hold up there, we change the design, not just the code.
There are trade-offs. Some effects simply aren’t worth it if they only look good on the latest hardware, so we leave them out. That occasionally makes an app look a little plainer in a screenshot than a competitor’s. We’re comfortable with that.
Our minimum
Two major iOS versions back across every Zydeno app. Apple’s deprecation pace is fast enough that going further makes the codebase painful to maintain, but two versions back is the difference between serving most of our users well and serving only the ones on the newest software.
Holding that line means occasionally waiting before we adopt a new system feature, or building it so the app still works without it. That’s a real cost in engineering time. We’d rather pay it than tell someone their phone, which works perfectly well, is no longer good enough for us.
The cheap phone is the honest critic. We keep it on the desk for a reason.