App submissions get rejected far more often for missing a documented requirement than for a genuine bug. Both Apple and Google publish their review guidelines — the problem is they're long, they change on a real schedule, and teams tend to read them once at project kickoff and not again before submission. This guide covers what actually matters at submission time, including the current SDK and target-API deadlines both platforms are enforcing through 2026.
Quick Answer: What's Different in 2026
If you only take two dates from this guide: Apple requires the iOS 26/iPadOS 26 SDK (built with Xcode 26 or later) for any new submission or update as of April 28, 2026. Google Play requires new apps and updates to target Android 16 (API level 36) as of August 31, 2026, with an extension option to November 1, 2026 for teams that request it in Play Console. Missing either of these blocks submission entirely, independent of how good the app itself is — so they're worth checking before anything else in a release plan.
App Store (Apple) Requirements
Developer Account and Agreements
You need an active Apple Developer Program membership, with the relevant program license agreements accepted, before you can submit anything. If your app involves in-app purchases or subscriptions, the associated agreements and banking/tax information need to be completed too — a surprisingly common last-minute blocker.
The 2026 Minimum SDK Requirement
As of April 28, 2026, apps and games uploaded to App Store Connect must be built with the iOS 26 and iPadOS 26 SDK or later; tvOS, visionOS and watchOS apps have the equivalent SDK-version requirement for their platform. In practice this means building with Xcode 26 or later. This is an SDK requirement, not a deployment-target requirement — building with the newer SDK doesn't stop your app from still running on older iOS versions, as long as your deployment target is set appropriately.
One practical side effect worth planning for: apps built with the iOS 26 SDK apply Apple's "Liquid Glass" visual treatment to native UI components by default, unless a developer explicitly opts out. If your app relies on standard system controls, budget time to review how they render under the new SDK rather than assuming a rebuild is purely mechanical.
App Review Guidelines
Apple's review is manual, and covers functionality (the app has to actually work, with no placeholder or broken screens), design (following their human interface guidelines reasonably closely), and content policy (no misleading claims, appropriate age rating for the actual content). A demo account and clear reviewer notes for anything gated behind login meaningfully speeds this up.
Privacy and Data Requirements
Apple requires a privacy policy URL and an accurate "App Privacy" nutrition-label style declaration covering what data is collected and how it's used — including data collected by third-party SDKs embedded in the app, not just your own code.
Other Technical Requirements
Beyond the current SDK deadline above, builds need to run cleanly without crashes on the devices and OS versions still in active use, and any App Store screenshots and previews need to accurately represent the actual current version of the app being submitted — outdated screenshots from a previous version are a common, avoidable metadata rejection.
Google Play Requirements
Developer Account Setup
A registered Google Play Console account is required, along with completed store listing details before an app can be published — even in internal or closed testing tracks.
The 2026 Target API Level Deadline
Starting August 31, 2026, new apps and app updates must target Android 16 (API level 36) to be published on Google Play; existing published apps need to target at least Android 15 (API level 35) to remain visible and downloadable on newer Android versions. Developers can request an extension to November 1, 2026 through Play Console for apps that need more time. Wear OS and Android Automotive OS apps have a slightly different bar (Android 15 / API 35), and Android TV and Android XR apps need at least Android 14 (API 34) — worth checking directly against your specific app category rather than assuming the general mobile requirement applies uniformly.
This deadline moves forward on a predictable annual cadence, so treat it as a recurring release-planning item rather than a one-time fix — an app that just barely meets this year's bar will likely need another target-API bump within roughly a year.
Content Policy and Restricted Content
Google's policies restrict certain content categories and require accurate content ratings. Apps in sensitive categories (health, finance, apps aimed at children) face additional policy scrutiny and, in some cases, additional declarations.
Privacy Policy and Data Safety Section
Google requires a "Data Safety" section in the store listing that discloses what data is collected, whether it's shared with third parties, and how it's secured. Like Apple's equivalent, this needs to account for every SDK in the app — analytics, crash reporting, ad networks — not just first-party data collection.
App Store vs. Google Play: A Direct Comparison
App Store vs. Google Play submission process
| Apple App Store | Google Play | |
|---|---|---|
| Review type | Manual human review | Largely automated, with policy checks |
| Typical review time | Generally a matter of days, can vary | Often faster, can also vary by app risk category |
| 2026 build requirement | iOS 26/iPadOS 26 SDK (Xcode 26+) as of April 28, 2026 | Target Android 16 (API 36) as of August 31, 2026, extension to Nov 1, 2026 available |
| Update flexibility | Every update goes through review | Staged rollouts and faster iteration are more common |
| Design scrutiny | Strict adherence to Human Interface Guidelines expected | More flexible on design, stricter on policy automation |
| Data disclosure | "App Privacy" nutrition label | "Data Safety" section |
Common Rejection Reasons
- Incomplete or inaccurate metadata — screenshots that don't match the actual app, or a description overstating functionality.
- Broken core functionality during review — a login wall with no working demo credentials is one of the most common, avoidable causes.
- Privacy disclosures that don't match actual data collection — especially missing third-party SDK data collection.
- Placeholder or incomplete content still present in a build submitted for review.
- Missing or inappropriate age rating relative to the app's actual content.
- A build submitted against an SDK or target API level below the platform's current minimum, blocking submission outright regardless of app quality.
Keeping Up With Requirements That Change Every Year
Both platforms update their minimum SDK and target API requirements on a predictable annual cycle, tied to their own OS release schedules — this isn't a one-time hurdle to clear and forget. The practical approach is to check each platform's current developer requirements page as a standing item ahead of every major release, not just when a submission gets rejected. Treating this as a recurring release-checklist item, not a one-off fire drill, is what keeps a team from being caught off guard by a deadline that was public knowledge for months beforehand.
Pre-Submission Checklist
- Confirm developer account status and agreements are current on both platforms.
- Verify the build is targeting the current required SDK (iOS) or API level (Android) for the platform, not an older one that will block submission.
- Verify the privacy policy URL is live and accurately describes data collection, including third-party SDKs.
- Complete the App Privacy label (Apple) and Data Safety section (Google) to match what the app actually does.
- Provide working demo credentials and clear reviewer notes for anything gated behind login.
- Test the exact build being submitted on real, current devices — not just a development build.
- Confirm screenshots and store listing content reflect the actual current version of the app.
How Apptechies Handles App Store Submissions
Submission requirements are checked during our quality assurance phase, not discovered for the first time at submission — the same discipline we apply to every 7-phase engagement. Our iOS and Android teams build against current platform requirements from the start, which is the single biggest way to avoid a late, avoidable rejection.
