Your Old App Can’t Ship an Update? Let’s Modernize It and Get It Published.

Is this your situation?

• Play Console shows “Your app must target Android 16 (API level 36)” or the release is rejected at upload with an API-level message.
• Play Console warns that the app uses a deprecated version of the Play Billing Library.
• Play Console flags 16 KB page size compatibility for one or more native libraries.
• App Store Connect refuses the upload because the build was not made with Xcode 26 / the iOS 26 SDK, or emails ITMS warnings about privacy manifests or required-reason APIs.
• The project no longer builds at all: an old Flutter, React Native, Unity, Cordova or Xamarin version, a Gradle/AGP that the current Android Studio rejects, CocoaPods specs that have moved, or plugins that were abandoned.

If the message you received names a specific policy (privacy, permissions, metadata, minimum functionality), that is a different problem — start from the Google Play or App Store rejection guides instead.

The requirements that block old apps right now

The full dated list, with sources, lives on the app publishing deadlines page. For the Android half of that table you can get a first answer in a minute: paste the project’s build file into the update readiness checker and it reports which of these requirements the configuration already fails, which it cannot judge from text alone, and which guide covers each one.

Why “change one line” rarely ends there

Raising targetSdk to 36 is a one-line change. What follows is not. Android 16 enforces edge-to-edge layouts and drops the opt-out, changes how large-screen orientation and resizability are handled, tightens background execution and notification behaviour, and many older libraries (analytics, ads, payments, maps) simply do not compile against the new toolchain. On the Apple side, moving to Xcode 26 usually forces a newer minimum deployment target, updated Swift language mode, migrated CocoaPods or Swift Package Manager dependencies, and privacy manifests for any SDK on Apple’s list. Each of those is a small task; together they are a modernization project.

What the work looks like, by framework

Flutter

• Upgrade the Flutter SDK in steps (large jumps break plugins), then flutter pub upgrade --major-versions and replace abandoned plugins.
• Android: migrate to the Gradle Kotlin DSL / plugin DSL if still on the legacy apply plugin form, raise AGP and Gradle, set targetSdk 36, rebuild native plugins (16 KB alignment comes from the plugin versions, not from Dart code).
• iOS: Xcode 26 build, minimum iOS version raised where required by plugins, PrivacyInfo.xcprivacy for the app and for plugins that ship one.
• Billing: in_app_purchase must be on a version that wraps Play Billing Library 8; older versions embed PBL 5–6.

React Native

• Upgrade through the React Native Upgrade Helper diff, one minor version at a time; the New Architecture is now the default and some native modules need replacements.
• Android: AGP / Gradle / Kotlin versions move together; targetSdkVersion 36; Hermes and native modules need 16 KB-aligned builds.
• iOS: Xcode 26, CocoaPods or the newer dependency setup, privacy manifests for listed pods, deployment target changes.
• Billing: react-native-iap (or RevenueCat’s SDK) at a Play Billing Library 8 release.

Unity

• Move to a Unity LTS that produces 16 KB-aligned native libraries (Unity’s own guidance for Android page sizes) and supports the current Android SDK target.
• Replace Unity IAP versions built on old Play Billing Library releases; re-import Google Play plugins.
• iOS: export with Xcode 26; review any third-party native plugins for privacy manifests.

Native Android and iOS

• Android: AGP 8.5.1+ (16 KB zip alignment), NDK r28+ for own native code, updated dependencies, behaviour-change audit for API 36.
• iOS: Xcode 26 warnings audit, deprecated API replacements, SwiftPM migration where pods are unmaintained.

Cordova, Ionic, Xamarin and other discontinued stacks

These can often be carried one more release, but every requirement above eventually lands on a toolchain nobody maintains. The honest advice is usually a planned rewrite in Flutter or React Native while the old app is kept compliant just long enough. We say so in the initial review when that is the case.

Play SDK Console warnings and outdated dependencies

Play Console can also flag individual SDK versions that violate a policy or have a known issue, and can block releases that include them. The fix is the same as above — move the dependency to a compliant version — but it often cascades: the newer SDK needs a newer Kotlin, which needs a newer AGP, which needs a newer Gradle. We resolve the chain rather than the symptom.

How the update review works

1. Inventory. We read the warning or upload error, the build configuration you share (build.gradle, pubspec.yaml, package.json, Podfile.lock) and the framework versions. No source code is needed for this step.
2. Blocking list. You get the requirements that block the release today, the ones that will block it within months, and the side-effects we expect (layout, permissions, billing flows, push).
3. Scoped plan. If you want us to do the work, the modernization is quoted as a fixed piece of work with a test plan on real devices and a release checklist — including an extension request in Play Console where that buys time.

Pre-release checklist for a modernized app

• targetSdk 36 with the Android 16 behaviour changes tested (edge-to-edge, orientation on large screens, background limits, notifications)
• Play Billing Library 8+ in every purchase path, including Unity/Flutter/React Native wrappers
• Every .so in the bundle 16 KB aligned (own code and SDKs), verified with zipalign -c -P 16
• iOS build from Xcode 26 with privacy manifests and required-reason API declarations in place
• Deprecated SDK versions replaced; Play Console policy status clean
• Upload key and Play App Signing confirmed before the release build — see lost keystore / upload key
• Data safety form and App Store privacy details re-checked against the new SDK set