What keeping an app alive really involves
The yearly calendar nobody tells you about
Apple previews its next iOS around the middle of the year and ships it a few months later. Google runs its own cycle of previews, betas and a public Android release. Each version changes something that apps rely on: how permissions are requested, what may run in the background, how screens are laid out around system bars. Separately, both stores set a minimum SDK or target level for new submissions and raise it on a schedule. An app left untouched for a couple of years often cannot ship even a one-line fix until it has been brought up to date. We test your app on the betas, fix what changed and plan the target update before the deadline, when it is routine work and not an emergency.
Dependencies age faster than your code
A typical app pulls in dozens of third-party packages for networking, storage, payments, analytics, maps and sign-in. Each has its own release cycle, and vendors retire old SDK versions with little ceremony. Skipping updates feels safe until several major versions have to be crossed at once. We upgrade little and often: framework and build tools first, then libraries, one group at a time on a branch with the test suite and a manual pass on real devices. Packages that have lost their maintainers are replaced early.
Monitoring that someone reads
Crash reporting is only useful if a person looks at it. We connect Crashlytics or Sentry, upload symbol files so stack traces are readable, tag each release and set alerts for new crash types and for a falling crash-free rate. Alongside that we watch Android vitals in the Play Console and the metrics in App Store Connect, since Google Play can reduce the visibility of apps with poor stability. Issues are ranked by how many users they hit, so effort goes to the crash affecting thousands before the one that is merely interesting.
Taking over an app from another team
Before agreeing to maintain an app we ask five questions. Is the full source code available, and does it build from a clean checkout? Who owns the Apple Developer and Google Play accounts? Where are the Android signing keystore and the iOS certificates? Who controls the Firebase project, push keys and other third-party services? Is there any documentation for the API? Missing items are usually recoverable. Store accounts can add new users, apps can be transferred between accounts, and an upload key enrolled in Play App Signing can be reset through Google. A lost keystore without that enrollment is the hard case, and we tell you where you stand before any work is quoted. If the backend needs attention too, our app API integration team picks that up.
What a plan looks like month to month
Plans are sized to the app. A stable app needs a little time each month for monitoring and upgrades, plus a larger block around OS release season. An active product uses more, mostly on small features. You get a monthly report of what the time went on, and we say so when a month needs less.