Every year, millions of phones update overnight and some apps wake up broken. A login screen that won’t load, notifications that stop arriving, a layout that slides under the camera notch. None of this is bad luck. Apple and Google publish their plans months in advance, and the teams that read them and test early rarely get caught out on release day.
Know the yearly calendar
The rhythm is predictable. Apple announces the next iOS at its developer conference in June, runs public betas over the summer and releases in September alongside new iPhones. Google now ships major Android versions earlier in the year, with betas starting months before, and then sets a deadline each August by which app updates on Google Play must target a recent API level.
Exact dates move a little each year, so put a reminder in your team calendar to check Apple’s developer news and the Google Play Console policy page every quarter. Missing the Play target API deadline doesn’t remove your existing app, but it blocks you from publishing updates until you comply, which is painful if you need an urgent fix.
Apple’s minimum SDK rule
Apple works differently. Rather than a target API deadline, it periodically announces that new submissions must be built with a recent version of Xcode and the matching iOS SDK, usually from around April. Existing apps stay on the store, but your next update can’t be submitted until your project builds cleanly with the new tools, which can mean upgrading your framework and plugins too.
What usually breaks
Major releases rarely break your core business logic. They break the edges, where your app talks to the operating system, the hardware or other companies’ code. Over the years, these are the areas that have caused most of the late-night release-week fixes we see:
- Permissions — location, photos, contacts and notifications keep getting finer-grained, and old request flows can fail silently.
- Background work such as delivery tracking or syncing, which both platforms restrict further to save battery.
- Screen layout — Android’s edge-to-edge default and new iPhone screen shapes can push buttons under system bars.
- Privacy declarations like Apple’s privacy manifests, which third-party SDKs must now include.
- Third-party SDKs for payments, analytics or maps that need their own update before yours can ship.
That last point matters more than people expect. If your app uses a payment SDK for Tabby, Tamara or a card gateway, a chat widget, or Firebase, you are dependent on those vendors updating in time. Check their changelogs early in the beta period and raise issues with them before September, not after.
Remember the variety of devices your users actually carry. In the UAE and the wider Gulf, a large share of Android users are on Samsung, Xiaomi, Oppo and other brands that add their own battery savers and permission screens on top of Android. Some Huawei devices ship without Google services at all, which affects maps, push notifications and sign-in.
Test early on the betas
Keep at least one spare iPhone and one Pixel on the beta channel. They don’t need to be new devices. Run through your critical journeys every couple of weeks: sign-up, login including UAE PASS or social login, search, checkout, notifications and any background feature. Record what breaks and fix the serious issues while the betas are still changing, not on the final build.
Don’t forget the oldest devices you still support. Each new OS version drops some older phones, and your analytics will show how many of your users are on them. Raising your minimum supported version once a year, after checking those numbers, reduces testing effort and lets you use newer platform features without endless workarounds.
If you build with Flutter or React Native, the framework itself also needs to support the new OS. The framework teams are usually quick, but upgrading the framework can mean upgrading many plugins too. Leave room in the plan for that. A framework jump that slips by two weeks is fine in July and stressful in September.
Testing by hand only goes so far. Automated tests on your critical flows, run on cloud device farms such as Firebase Test Lab or BrowserStack, catch regressions across many devices and OS versions in minutes. Pair them with crash reporting through Crashlytics or Sentry, so that if something slips through, you see it within hours rather than in your store reviews.
Release day should be boring. If it’s exciting, you started testing too late.
A practical release checklist
- Raise the target SDK and minimum OS versions, and drop very old versions you no longer test on.
- Update the framework, plugins and third-party SDKs, then fix deprecation warnings rather than ignoring them.
- Review store requirements such as privacy labels, in-app account deletion and data safety forms.
- Test Arabic right-to-left layouts and large text sizes on the new OS, as these often regress.
- Submit a build a week or two before the public release, allowing for store review delays.
When the update goes out, release it gradually. Apple’s phased release spreads an update over seven days, and Google Play lets you roll out to a small percentage of users first. Watch crash rates and key metrics such as logins and payments at each stage, and pause the rollout if anything looks wrong.
The bottom line
For a typical business app, yearly OS readiness takes somewhere between one and four weeks of work, depending on how many SDKs you use and how long it has been since the last update. That is far cheaper than an emergency fix with one-star reviews piling up. Plan it, test it on the betas, and keep your dependencies current all year.
If your team is small or your original developers have moved on, a maintenance retainer with a partner who does this every year can be the simplest option. Either way, write the yearly OS work into your product budget now, so it competes fairly with new features instead of becoming an unplanned emergency.
