Game studios should audit their upload toolchain, Android native libraries, publisher registration, and media permissions before scheduling another release. Apple’s April 28, 2026 SDK upload requirement is already active; Google’s current page-size guidance sets February 1, 2027 as the block on noncompliant updates. Treat these as separate release gates, each requiring evidence from the actual shipping build or publisher account.

Key takeaways

  • Audit artifacts: inspect the archive, app bundle, merged manifest, and registration status rather than relying on an engine’s compatibility claim.
  • Check the whole dependency chain: a web-first game still needs its packaged native components reviewed.
  • Read rollout scope: Android verification depends on distribution channel and geography, not simply where your studio is based.
  • Prefer narrow media access: an avatar chooser should not become a request to browse the player’s entire library.
  • Prioritize the catalog: start with games that need an urgent update, then resolve shared dependencies across related projects.

Which deadlines matter now?

This checklist is reviewed as of October 28, 2026. The dates below come from platform owners; the later work plan is our editorial recommendation. PTKD is a pre-submission scanner vendor, so its journal is useful secondary commentary, not the authority that sets store policy.

  • Apple uploads, active since April 28, 2026: use Xcode 26 or later with the relevant platform SDK, including iOS 26 and iPadOS 26. This is an upload requirement, according to Apple’s SDK minimum requirements.
  • Android native compatibility, upcoming update block: Google covers apps targeting Android 15, API level 35, and higher on 64-bit devices. Its current compatibility guide specifies February 1, 2027 for blocking updates without 16 KB support.
  • Developer verification, regional phase from September 30, 2026: protections begin at participating stores in Brazil, Indonesia, Singapore, and Thailand on certified devices running Android 7 or later. Google lists global expansion for 2027 and beyond in its verification timeline.
  • Photo and video permissions, already mandatory: Google’s current policy gives May 28, 2025 as the full-compliance deadline, including extensions. This is existing maintenance work, not a new grace period.

What should an iOS game team change?

PTKD’s App Store Xcode 26 requirement: what changed on 28 April 2026 makes a useful distinction:

“The SDK requirement concerns how a build is made, not which devices it runs on.”

— Laurens Dauchy, Founder, PTKD, PTKD Journal

Apple’s 2026 notice concerns uploaded builds. Do not interpret it as an instruction to make the minimum supported operating system match the SDK number. Check the selected toolchain’s supported deployment targets before changing your player compatibility promise.

Our recommendation is to reproduce the release archive before modifying gameplay. Record the compiler selection, SDK, signing configuration, dependency lockfiles, and build runner. Then rebuild the same game with the required toolchain and investigate errors by dependency owner. A local editor opening successfully should not be your acceptance criterion.

For a casual game, we would test the path from cold launch to a completed puzzle, then purchases, rewarded-ad return, sound interruption, and background resume. Test native sheets and permission prompts separately from the game canvas. Keep before-and-after screenshots so an interface change does not get mistaken for a gameplay regression.

For a wrapper project, pair that work with our Capacitor publishing guide. We would preserve the web asset revision alongside the native archive, making it clear which combination was tested. Upload a candidate to TestFlight early and retain the processing result as evidence for that specific archive.

Does a web-first game need a native-library audit?

Yes: inspect the packaged Android game before deciding it is unaffected. PTKD’s Google Play 16 KB page size requirement: who must fix what by 2027 offers a concrete starting point:

“Check whether your app ships any .so files.”

— Laurens Dauchy, Founder, PTKD, PTKD Journal

Google’s current Android guidance, checked in 2026, recommends AGP 8.5.1 or higher, NDK r28 or higher, and compatible prebuilt dependencies. Inspect APK Analyzer’s native-library results, then verify packaging and runtime behavior. Updating your compiler does not replace a vendor’s prebuilt library.

We would split the audit by what actually ships:

  • Unity, Cocos, or another native engine: list the engine runtime and exported plugins. Ask which maintained release supports the required packaging, then validate your own export.
  • Custom NDK code: assign ownership for rebuilding libraries and reviewing memory assumptions. Keep the build recipe with the resulting binary.
  • Ad, analytics, or mediation SDKs: trace each packaged shared library to its supplier. Include adapters and transitive dependencies in the inventory.
  • HTML5 with a Capacitor shell: examine the release package before declaring it unaffected. Treat each native plugin as an audit candidate, even if the puzzle logic is JavaScript.

Our rule of thumb: archive the library inventory, alignment results, and device test notes together. Exercise optional features, including ad loading and media import, rather than stopping at the title screen. A reusable test route is more helpful than a vague statement that the engine is supported.

Keep the browser game and mobile package as separate release candidates. For a project in the style of Juice Fruit, we would protect the merge interaction and save flow while changing packaging. Our engine selection guide provides context if a dependency upgrade turns into a larger migration decision.

Who must handle Android developer verification?

PTKD’s Android developer verification in 2026: what changes and who must act identifies the ownership issue:

“Android developer verification ties every installable app to a verified developer identity, its package name and its signing keys.”

— Laurens Dauchy, Founder, PTKD, PTKD Journal

The article’s broad opening and direct-download advice need qualification. Google’s verification FAQ explicitly says the September 30, 2026 phase does not yet apply to direct sideloading or stores outside the participating list. We follow Google’s narrower scope: do not tell players that every unregistered APK is already blocked.

Google directs publishers distributing on and outside Play to Play Console; publishers distributing exclusively outside Play use Android Developer Console. Automatic registration is not a substitute for checking your own package list. Match each game to the responsible account and investigate missing registrations.

For a Vietnam-based studio, our recommendation is to map player destinations and distribution channels, not assume the studio address determines exposure. Assign identity paperwork to an account owner and signing evidence to a technical owner. Keep a recovery contact available before an old contractor’s build becomes the next emergency update.

Google’s FAQ describes package registration and signing-key requirements. We would record the release signing certificate for each distribution channel and reconcile it with registration records. Store key material securely; an audit document should identify credentials and their custodian without copying secrets into a shared checklist.

Should a puzzle game request photo access?

PTKD’s Google Play photo and video permissions policy: picker or declaration recommends a narrower default:

“The photo picker is exactly such a mechanism: the user chooses, the app receives only the chosen items, and no permission is granted.”

— Laurens Dauchy, Founder, PTKD, PTKD Journal

Under Google’s policy checked in 2026, apps targeting Android 13, API level 33, or later may request READ_MEDIA_IMAGES and READ_MEDIA_VIDEO only when system pickers cannot serve core functionality. A branded custom chooser does not automatically qualify. For an optional player avatar, our recommendation is to use a system picker and remove unnecessary broad permissions.

Inspect the merged release manifest. Android’s manifest documentation explains that the packaged manifest combines project, variant, and library inputs. Removing a line from the main source manifest is therefore insufficient evidence: inspect the final output and identify the dependency responsible for any remaining declaration.

The Android photo picker provides access to selected media instead of the entire library. We would test cancellation, a cloud-backed image, an unreadable selection, and returning from the chooser after backgrounding. Keep avatar selection optional so a failed import cannot block the next puzzle.

How should a small studio audit its old catalog?

The following is our proposed work plan from the editorial review date above, not another platform deadline. Use a shared checklist with an owner, evidence link, blocker, and next action for each game. Avoid a single “compliant” checkbox that hides which gate was checked.

  1. Start now: inventory every maintained release. Record package identifiers, storefronts, source location, build recipe, dependency versions, account owner, and signing custodian. Flag any game whose release cannot be reproduced.
  2. Before the next submission: inspect artifacts. Produce a fresh archive and Android bundle. Record toolchain evidence, native-library findings, merged permissions, and package registration status.
  3. Next maintenance pass: group shared fixes. Compare engine exports, wrapper plugins, and ad dependencies across games. Pilot a replacement in a representative title before applying it to the catalog.
  4. Before scheduling rollout: test player journeys. Include save continuity, interrupted sessions, purchase restoration where offered, and returns from ads or external screens. Keep failures attached to the exact candidate build.
  5. Close the audit: make a maintenance decision. Mark each title ready, awaiting a named dependency, or needing a separate retirement discussion. Do not silently treat an abandoned project as safe because its store page still exists.

At NabiGame Studio, our view is that publishing maintenance belongs beside puzzle polish in release planning. We would prioritize a reproducible update path over cosmetic changes to an aging build. Our game development services outline where we can help; contact us if you want to discuss a focused catalog review.

FAQ

Does the Apple SDK rule require the newest operating system on every player’s phone?

No. Apple’s upload requirement specifies the build tools and SDK. Review deployment-target support separately and test the oldest operating system you intend to support.

Is a Capacitor game automatically exempt from native compatibility work?

No blanket exemption should be assumed. Inspect its packaged libraries against Android’s compatibility guidance, then test the native integrations used by that release.

Are all direct Android downloads already blocked without verification?

No. Google’s FAQ limits the initial rollout to participating stores and says direct sideloading is not yet covered by that phase. Prepare registration while checking the current scope for your actual distribution route.

Can an avatar feature justify broad photo permissions?

Do not assume so. Google’s policy requires a qualifying core need that system pickers cannot satisfy. We would use a picker for an optional avatar and verify the final manifest no longer requests unnecessary access.

What should we fix first in a neglected game?

We would first prove that its release can be reproduced and signed by the correct owner. Then inspect upload blockers and dependencies before spending time on new content. Keep a clear decision record if a missing library or credential prevents maintenance.

Sources