Sound familiar?
- Google Play warned your app will stop being shown to new users
- The developer who built the app has gone quiet
- The app still works, but nobody can produce a new build
- Crash reports and one-star reviews have crept up since the last iOS release
- You do not know who holds the signing keys or store logins
- A library in the app has a security advisory and no fix in sight
Key facts
- Apple required builds from Xcode 26 and the iOS 26 SDK from 28 April 2026
- Google Play requires new apps and updates to target API level 36 from 31 August 2026
- Apps not updated drop out of Google Play for new users on newer devices
- Crash and error monitoring with Firebase Crashlytics or Sentry
- We take over Flutter, React Native, Swift and Kotlin apps built by others
- Phased releases on the App Store and staged rollouts on Google Play
Why apps need regular work
A website you leave alone usually keeps working. An app does not, because Apple and Google move the ground under it every year. Each September brings a new iOS version; each summer, Google raises the minimum target API level. Google's target SDK page says that from 31 August 2026, new apps and updates must target Android 16 (API level 36), and existing apps below API level 35 stop being offered to new users on newer devices. Apple's upcoming requirements page says uploads from 28 April 2026 must be built with Xcode 26 using the iOS 26 SDK.
Miss these and the app does not vanish overnight, but you lose the ability to ship even a one-line fix until the whole toolchain is upgraded, which is always more expensive under pressure.
What maintenance covers
- Platform updates. Testing on each new iOS and Android release during the beta period, fixing layout, permission and behaviour changes before users hit them.
- Framework upgrades. Keeping Flutter, React Native, Swift or Kotlin versions current in planned steps rather than giant leaps.
- Library hygiene. Updating packages, replacing abandoned ones and acting on security advisories.
- Store compliance. Updating App Store privacy labels, privacy manifests and the Google Play Data safety form when SDKs or policies change, and responding to policy emails.
- Monitoring. Firebase Crashlytics or Sentry crash reporting, with alerts when a release raises the crash rate.
- Back end. Keeping the API behind the app patched and its integrations working.
Taking over an app someone else built
Many of the apps we look after were not built by us. The first job is a handover audit, the app equivalent of a code audit. We check that we have the full source code, that it builds from a clean machine, who holds the Apple Developer and Google Play Console accounts, where the signing keys are, and whether Google Play App Signing is enabled. We also check push notification keys, analytics, crash tools and any third-party services with your card on them.
Lost keys are the classic trap. If an Android upload key is lost but Play App Signing is on, Google can reset it. If an iOS distribution certificate expires, it is replaced without affecting users. We document every credential in your name so this never becomes an emergency again. If the app is beyond saving, we will say so and quote a rebuild through our software rescue work.
Releasing safely
Every release goes through automated tests, a TestFlight and Play internal test build, then a gradual rollout. The App Store's phased release spreads an update over seven days for users with automatic updates on, and Google Play's staged rollout lets us release to a small percentage first. If Crashlytics shows a spike, we pause, fix and resume, rather than pushing a broken build to every customer at once.
Accounts and renewals nobody remembers
Some app failures have nothing to do with code. If the Apple Developer Program membership lapses, the app is removed from sale until it is renewed. Push notification certificates and some third-party SDK keys expire on a schedule. Domains used for deep links and the privacy policy URL in your listing must keep working, or review can fail. We keep a renewal calendar for every account and credential the app depends on, held in your company's name, and warn you well before anything expires.
We also review the store dashboards each month: Android vitals for crash and ANR rates, App Store Connect for crashes and review trends, and any policy notices from either store, so a warning email does not sit unread in a former employee's inbox.
How it is arranged
We agree a scope: which apps, how many platform updates a year, how quickly urgent faults get a response and what counts as new feature work. You then get a fixed-price quote for that scope after a free chat. Feature changes are quoted separately. For websites and hosted systems alongside the app, our sister site dijitul support covers IT and website support. See also software maintenance, or get in touch.
What we deliver
- A handover audit: code, build, keys, accounts and store status
- Annual platform updates for each new iOS and Android release
- Target API and Xcode SDK upgrades ahead of store deadlines
- Dependency and framework upgrades with tests
- Crash monitoring, triage and fix releases
- Store compliance: privacy labels, Data safety form, policy changes
- An agreed response process for urgent faults
How it works and what it costs
Every project gets a fixed-price quote after a free initial chat and a short scoping stage. You own the code and the data.
Free chat
Tell us the problem in plain English: what you do now, what goes wrong and what "better" looks like. No charge, no obligation.
Scoping
We map the processes, systems and data involved, agree what is in and out, and write it down so there are no surprises.
Fixed-price quote
You get a fixed price for the agreed scope, or a phased plan for bigger builds, so you can start small and prove it works.
Build and test
We build in short stages you can see and try, test against real data, then go live carefully with a rollback plan.
Hand over and look after
You own the code and the data. We can host it, support it and keep improving it, or hand it to your own team.
Frequently asked questions
Why does an app need maintenance if it works?
Apple and Google raise their requirements every year. An app that is not updated eventually cannot ship even a small fix, and Google Play stops offering apps with an old target API level to new users on newer devices. dijitul keeps apps current before deadlines hit.
Can you maintain an app another developer built?
Yes. dijitul starts with a handover audit: source code, build setup, store accounts, signing keys and third-party services. We then fix anything blocking a release and put the app on a regular update cycle.
What if we have lost the signing keys?
It is often recoverable. If Google Play App Signing is enabled, Google can reset a lost upload key. Expired iOS distribution certificates can be replaced without affecting users. dijitul checks your setup and records every credential in your company's name.
How do you stop a bad update reaching everyone?
dijitul uses the App Store's phased release and Google Play's staged rollouts, watching crash reports in Firebase Crashlytics or Sentry as each stage goes out. If the crash rate rises, we pause the rollout and ship a fix.
Is maintenance priced per hour?
No. dijitul agrees a scope covering platform updates, response times and monitoring, then gives a fixed-price quote after a free chat. New features are quoted separately so there are no surprises.
Related
Tell us what you need to build
Free chat, clear scope, fixed-price quote. You own everything we build.