Keeping an app healthy after launch
New operating systems arrive every year. A little planning keeps them from becoming emergencies.
Launch day is the start of an app’s life, not the end of the project. Phones, operating systems and store rules keep moving, and an app that stands still slowly stops working well. A simple routine prevents most of the trouble.
Plan around the yearly cycle
Apple and Google each release a major operating system version every year, with betas a few months before. Use the beta period: install the app on a test device running the new version, look for broken layouts and permission changes, and fix them before the public release.
Keep up with store requirements
Both stores raise their minimum requirements over time. Google Play requires apps to target a recent Android API level to stay available, and Apple periodically requires apps to be built with a newer version of its tools before updates are accepted. Missing a deadline can stop you shipping a fix when you most need to, so keep a calendar of them.
Update dependencies on a schedule
Every app is built on libraries and services that change. Update them a little at a time, every month or so, rather than all at once every two years. Small updates are easy to test. Big ones turn into rebuilds.
Security fixes are the exception: apply those as soon as they’re published.
Watch what users see
Crash reports and store reviews tell you what’s going wrong before most people bother to write in. Look at them weekly. A crash that affects one percent of sessions can still mean many unhappy people.
Keep the boring parts current
Certificates, domain names, API keys and payment accounts all expire or need renewing. Write down when each one does, and who is responsible. Many app outages aren’t code problems at all.
A routine that fits on one page
Monthly: dependency updates, crash and review check. Yearly: test the OS betas, check store requirements, renew what’s expiring. That’s most of it, and it’s far cheaper than an emergency.