Mobile SDK & API Version Upgrades

Google Play and the App Store both raise their minimum requirements on a fixed schedule. Every year a new Android API level becomes mandatory for updates, and every iOS release removes or restricts something that used to work. An app that shipped two years ago still opens on a user's phone, so nothing looks broken from the outside. The trouble only becomes visible when you try to ship something new, or when a store email arrives with a date on it.

Version work is the part of mobile development that nobody gets credit for until it is missing. It keeps the app installable, reviewable, and fixable on the platforms people actually use, and it is far cheaper when it runs on a yearly rhythm than when it lands as an emergency.

What platform version work covers

Apple ships a new iOS version each autumn, and Google publishes a new Android API level every year with a target SDK requirement attached to Play Store submissions. Third-party libraries release breaking changes on their own timelines. Permission prompts change wording and timing. APIs that worked on the previous version get marked deprecated, then removed.

A version upgrade project brings your app back into line with all of it. The code compiles against current SDKs, the target API level meets the store requirement, deprecated calls are replaced, permission flows match the current model, and your dependencies sit on versions that are still maintained.

This is different from a rebuild. The product stays what it is. We keep the design, the data, and the user flows, and we touch the parts the platform has moved past.

Why apps fall behind

Most teams do not decide to skip upgrades. The work gets postponed because nothing catches fire on the day a new OS ships. Then a store message arrives with a deadline, or a release stops because Play Console refuses an upload below the required target API.

The cost of that delay lands in a few places. A single bump turns into a backlog, because two or three skipped versions stack up and each deprecated path has its own replacement. Libraries drift, so a dependency you pinned two years ago may now require a different major version of another library, and the whole chain has to be resolved at once. Device behaviour has moved on too: permission handling, background execution limits, and battery rules changed across the versions you skipped, so testing uncovers more than anyone expected. The people who wrote the original code may not be the people available now.

The bill finally arrives as a compressed deadline, with the app live and users on it.

Where the project starts

We take version upgrade work from three states, and the approach changes with each.

A plain idea means there is no app yet, or only a design. Version compliance becomes a build decision from the first commit. We set the target SDK, choose dependencies that are actively maintained, and leave the project on a schedule that survives annual platform releases.

An existing conventional codebase is a working app built with normal practices that has fallen behind. We audit the dependencies, find the deprecated calls, and plan the bump in stages so the app keeps shipping while the upgrade is prepared.

An AI or vibe-coded prototype is an app assembled quickly with AI coding tools where nobody has tracked SDK versions, dependency pins, or store requirements. The idea is worth keeping and the code needs review. We inventory what is actually there, then bring it to a state that compiles, passes review, and supports future work.

What we deliver

The deliverable is a working app on current SDKs, together with the audit and plan that explain what changed. The scope usually includes:

• A dependency and API audit listing what is deprecated, what is unsupported, and what has a breaking change ahead.
• The upgrade itself: target API level raised, SDK versions updated, deprecated APIs replaced, and permission and privacy flows aligned with current platform rules.
• Library upgrades, including the awkward ones where a major version changed its interface and the calling code has to follow.
• Regression testing on real devices. Permission prompts, camera and microphone access, background behaviour, and network conditions behave differently on hardware than in a simulator.
• Store submission support for the requirements that arrive with a target SDK change, handled alongside our App Store and Google Play publishing work.
• Notes on what the next platform cycle will need, so the schedule is planned in advance.

How the engagement runs

We start with the audit, because the scope depends on how far behind the app is and how much of the dependency tree has moved. From there the work runs in stages.

1. Audit and plan. We read the codebase, run it, list the deprecated surface, and give you a staged plan with effort estimates at our hourly rate.
2. Upgrade in a branch. The app keeps working on its current live release while the upgrade is prepared and tested.
3. Device testing. We run the app through its main flows on real hardware and fix what the new platform behaviour breaks.
4. Release. We handle the store submission, watch the review, and support the rollout.
5. Handover. You get the updated repository, the notes on remaining risk, and a view of the next cycle.

For apps already under a support arrangement, this work fits into our mobile app maintenance and support retainer. Where the upgrade uncovers structural problems, we combine it with mobile app refactoring and migration.

What it costs

Version upgrade work is billed at our flat rate of $39 per hour, or through a monthly capacity plan from $2,699 when there is enough recurring work to justify it. The pricing page sets out both models and what each one suits.

A single target SDK bump on a healthy app is usually a small piece of work measured in days. An app that has skipped two or three cycles is closer to a short project, and if the audit shows the app should be rebuilt on a current foundation, the effort reaches the mobile MVP typical order of $4,800 to $8,500 across four to six weeks. We give the estimate after the audit, once the size of the backlog is known, because guessing at it is how deadlines get missed.

Proof

Voice VPN is our own Flutter VPN product with native integrations on both platforms, including Android Services and iOS NetworkExtension. Background execution, network entitlements, and permission rules shift between OS releases, and this project proves we keep an app working across those changes rather than rebuilding it each time.

Calculator Lock is an Android app on the Play Store with biometric unlock, an intruder photo feature, and encrypted file storage. Camera, storage, and fingerprint permissions all follow the Android permission model, which has changed more than once, so this shows how a target SDK bump can change app behaviour on top of the build configuration.

Camera Filters is a native iOS photo editor with real-time previews and adjustment controls. Camera and photo library access is one of the most tightly reviewed permission areas on iOS, and the project proves we work on exactly the screens that each iOS release touches.

Related services

• Mobile apps development for the full range of iOS, Android, and Flutter work we do
• Mobile app refactoring and migration when an upgrade uncovers structural problems worth fixing properly
• Mobile app maintenance and support for a retainer that keeps the upgrade cycle on a planned schedule
• App Store and Google Play publishing for submissions, review handling, and store policy changes
• API development and integration when the upgrade also involves a backend contract that has moved

Next step

If your store listing is close to a target API deadline, or the upgrade has been sitting on the list for a while, send us the app and the platform you are targeting. We will say how much work is actually in front of you.

Contact us with the details, or run the version and dependency situation through the Vasilkoff.info estimator for an initial scope and cost range.