App Store or Google Play says an update is required: what to do (2026)

An Apple or Google “update required” notice can mean a code change, a store-form update, or both. First confirm which app and build it covers, the exact deadline and current status. Then map the notice to the smallest safe fix and verify the actual signed release candidate. A deadline is a planning constraint, not proof that every app needs a rebuild.

Read the exact notice in the console

Open the notice in the developer account that owns the app. Record:

• The app, platform, affected track, and exact version or build.
• The required action, deadline, current status, and what changes if the date passes.
• Whether it concerns a new submission, existing-app visibility, a store form, or the binary.

Do not confuse the SDK numbers

On Android, target API sets the behavior level your app agrees to; the compile or build SDK is the toolchain and API surface used to compile it; min SDK defines the oldest Android version it can install on. On Apple platforms, the Xcode and iOS SDK required for upload are separate from the deployment target, the app’s minimum supported iOS. A higher target or upload SDK does not automatically raise the minimum OS. Changing one number also cannot make an incompatible dependency, permission flow, manifest, or SDK behavior safe.

Find the real change

Consider a fictional Android app whose Play Console notice asks for target API 36. Before editing, its owner confirms the named app, affected release, deadline, and status in the console. The team checks whether each plugin and embedded SDK builds and behaves correctly at that target, then reviews platform behavior changes, permissions, and manifest declarations. A version bump alone might compile while a library still breaks sign-in or push delivery.

• Check dependencies and privacy-related SDKs; update or replace incompatible components.
• Review manifest entries, runtime permissions, and matching store disclosures.
• Check account-deletion instructions and age-rating answers when relevant; these examples do not apply to every app.
• Confirm whether the notice permits a metadata or form correction, or requires a new binary.

Keep the release controlled

Make changes on a maintained release branch, preserve the last approved source and build, and record the versions changed. A metadata-only correction can stay in the console if the notice permits it; code, SDK, or manifest changes need a new signed binary.

1. Build the release candidate with the required toolchain and signing setup. Keep the candidate tied to the maintained release branch.
2. Install that signed build on supported physical devices. A development build alone does not verify the release candidate.
3. Retest the app’s real user paths. Check login, purchase and restore, push notifications, and deep links where the app uses them.
4. Upload to an internal or closed testing track. Confirm the app, version, permissions, and launch behavior in the installed build.

Testing, review, and ownership are separate

Uploading a test build does not authorize a public release. External TestFlight testing may need beta review. Agree each testing, review and release step with the account owner. The client retains the store accounts, source and signing access. Scope ongoing maintenance, ASO and app maintenance or modernization separately. Our review timing guide covers scheduling.

1. Triage the notice
2. Make the scoped change
3. Verify the signed build
4. Owner approves next step

Testing, review submission, and public release remain separate decisions.

Checked 4 November 2026: Google Play requires API 36 for ordinary phone-app submissions; existing-app visibility has separate rules. Apple’s current upload requirements include Xcode 26 and the iOS 26 SDK. Announced 2027 requirements are future changes. Confirm the deadline and scope in your own app’s console notice.