← All

App store submission checklist for first-time builders

App store submission checklist for first-time builders

You built the app. Now it needs to pass review. For most first-time builders, the submission process is where momentum dies. A missing Privacy Manifest file, screenshots uploaded in wrong dimensions, or forgotten demo credentials can cost you weeks. These are the most common first-submission mistakes, and all of them are preventable.

This checklist walks you through every requirement for publishing to the Apple App Store and Google Play Store in 2025 and 2026. You will learn what each platform requires at every stage, from setting up accounts and meeting privacy rules to preparing visuals and passing technical review. The article also covers compliance deadlines that are actively converging across both platforms. Each section builds on the previous one so you can work through the checklist in order.

Apple's annual transparency report showed that reviewers examined 7.7 million app submissions in 2024 and rejected 1.9 million of them, roughly a 24.7% rejection rate. Most of those rejections fall into predictable, preventable categories. This checklist covers every one of them.

Developer accounts: what each platform costs and requires

Before you submit anything, you need active developer accounts on both platforms. The setup process is straightforward, but Google has added a mandatory closed testing requirement that catches many solo builders off guard.

Apple charges $99 per year with 48-hour processing

The Apple Developer Program costs $99 per year, recurring. Enroll through the Apple Developer app. You will need an Apple Account with two-factor authentication and a valid payment method. Account processing typically takes 24 to 48 hours.

Google requires $25 and a 14-day testing period for new accounts

Google charges a $25 one-time registration fee. That lower price comes with a catch. New personal accounts created after November 13, 2023 must run a closed test with at least 12 opted-in testers for 14 continuous days before publishing to production. The 14-day period begins once your test is active with a build uploaded and you have your testers opted in. You can upload improved versions during this time without resetting the clock.

Privacy compliance: a leading cause of rejection

With accounts set up, privacy compliance is your next priority. Privacy violations are a leading cause of rejection on both platforms. You are responsible for disclosing data collected by every third-party SDK in your app, even if you did not write the code.

Apple mandates three privacy components for every app

Apple requires three universal privacy components for all apps:

  • A Privacy Manifest file declaring tracking status, collected data types, and required reason APIs
  • Privacy Nutrition Labels completed in App Store Connect that disclose collected data types, including opt-in features
  • An App Tracking Transparency (ATT) prompt for apps that track users across other apps or websites

ATT applies to analytics and advertising SDKs that track users across apps or websites owned by other companies, particularly when using identifiers like the IDFA. Many analytics SDKs that do not perform such cross-app tracking do not require ATT consent.

Your privacy policy must be linked in App Store Connect and accessible within the app itself. It must identify what data you collect, how you use it, and describe how users can request data deletion and access.

Google displays your data disclosures before users install

Google requires a Data Safety form that displays on your listing before users install. You must declare every data type collected by your app and all third-party SDKs. For each data type, specify whether collection is required or optional, your encryption practices, and any third-party sharing arrangements. You must declare data from every third-party integration in your app, including analytics, advertising, authentication, and payment SDKs.

Visual assets that meet exact store specifications

With privacy requirements handled, prepare your store-ready graphics. Both platforms reject apps with incorrect asset specifications. Getting these right the first time prevents an entirely avoidable rejection cycle.

Apple scales one 1024-pixel icon across all devices

Your app icon must be 1024 by 1024 pixels, PNG or JPEG, RGB color space, with no transparency. Apple scales this single icon for all device contexts.

For iPhone screenshots, submit at the 6.9-inch display size using one of these portrait dimensions: 1260 × 2736 pixels, 1290 × 2796 pixels, or 1320 × 2868 pixels. Apple automatically scales these for smaller devices. You need 1 to 10 screenshots per device size.

Screenshots must show actual in-app UI. Do not add device frames. Apple adds those automatically.

Google Play requires a feature graphic for publication

Google Play requires a 512 by 512 pixel app icon as a 32-bit PNG with alpha transparency. You also need a feature graphic at 1024 by 500 pixels. This graphic is mandatory for publication, and missing it will block your listing. Provide a minimum of two mobile screenshots.

Metadata rules that determine discoverability and approval

Visual assets get users to look. Metadata determines whether they find you and whether reviewers approve you. Both platforms enforce character limits and content restrictions that differ in significant ways.

Apple and Google enforce different character limits

Apple's App Store review guidelines require that metadata meet these specifications:

Character limits:

  • Main description: 4,000 characters maximum
  • Promotional text: 170 characters (updatable without new app version)
  • Subtitle: 30 characters (appears below app name)
  • Keywords: 100 characters total, comma-separated, no spaces

Content restrictions:

  • No mention of other mobile platforms
  • No pricing information (displayed separately by Apple)
  • No promotional language like "limited time offer"
  • Must accurately describe app features
  • Plain text only (no HTML or rich formatting)

Google Play also limits titles to 30 characters but provides no separate keyword field. Keywords must appear naturally in your title and description. Write your description to be comprehensive and include natural keyword references that describe your app's core features and benefits. Both platforms allow 4,000-character descriptions, but Google rewards strategic keyword placement throughout the full text since it has no dedicated keyword field.

Misleading metadata guarantees rejection on both platforms

Your app description must accurately reflect what the app does. Inaccurate metadata results in guaranteed rejection under Apple's review standards. Google Play enforces similar requirements, and descriptions that misrepresent app functionality will be flagged during review.

Select primary and secondary categories carefully. Smaller, more specific categories often provide better visibility for new apps than competing in saturated major categories.

Technical testing before you hit submit

Your listing looks great. Now verify the app actually works under review conditions. Apple tests on real devices, not simulators. Simulator-only testing misses device-specific crashes that cause preventable rejections.

Test on physical devices because simulators miss real crashes

Test on a physical iPhone running the current iOS version. Test on a real Android device, ideally a mid-range model rather than a flagship. Device-specific crashes do not appear in simulators. Every major user flow must complete without crashes, multiple times, on real devices.

Missing demo credentials delay review by weeks

Apps requiring login must include working demo account credentials in App Store Connect (for iOS) or Play Console (for Android) in the designated fields. Test those credentials yourself immediately before submission. Remove all placeholder content, "Coming Soon" features, and test data. Every button and link must function.

Each platform enforces different SDK and format requirements

For Apple, verify your build uses the current required Xcode and iOS SDK versions and includes a mandatory Privacy Manifest. Apps offering in-app purchases must include a working "Restore Purchases" button.

For Google Play, verify your build uses Android App Bundle format (AAB, not APK). Complete the content rating questionnaire and ads declaration in Play Console. Verify your build supports 16KB memory page sizes, which is required for current Android targets.

Test your app with screen readers enabled (VoiceOver on iOS, TalkBack on Android). The European Accessibility Act requires compliance for apps targeting customers in the European Union.

Compliance deadlines converging in 2025 and 2026

Multiple compliance deadlines are stacking up, and missing any one of them can delay or block your submission entirely. These deadlines affect both new submissions and updates to existing apps. Plan your development timeline around the earliest deadline that applies to your app.

  • June 28, 2025: European Accessibility Act compliance for EU-targeting apps
  • August 31, 2025: New apps must target Android 15 / API level 35
  • November 1, 2025: 16KB memory page size support required (Android)
  • April 28, 2026: All iOS submissions must be built with the iOS 26 SDK or later

Verify your app building platform supports these requirements before deadlines arrive. Platform updates can take weeks or months to roll out, so confirm compatibility well in advance.

Final verification: confirm every requirement before submitting

This consolidated checklist covers both platforms. Work through it in order before every submission. Each item confirms you completed the work detailed in the sections above.

Accounts and compliance:

  1. Apple Developer account active and paid
  2. Google Play account active, paid, and identity verified
  3. Google Play closed testing completed (if required for your account)
  4. Privacy policy URL live and accessible in-app
  5. Apple Privacy Manifest verified with platform support
  6. Google Data Safety form completed with all SDK data disclosed
  7. Age rating questionnaire completed on both platforms

Visual assets prepared:

  • App icons uploaded and validated on both platforms
  • iPhone screenshots uploaded in required dimensions for each device size
  • Google feature graphic uploaded
  • All screenshots show real in-app UI

Metadata finalized:

  • App title includes primary keyword within character limits
  • Description accurately reflects actual app functionality with no placeholder content
  • iOS keyword field optimized with no duplicates
  • Privacy policy URL provided and accessible within app
  • Export compliance questions answered
  • No references to other platforms or pricing in descriptions
  • Content rating questionnaire completed on both platforms

Technical verification:

  • Tested on real iOS and Android devices
  • Zero crashes across all core user flows
  • Demo credentials prepared and tested
  • All placeholder content removed
  • In-app purchase restore function working (if monetized)
  • AAB format confirmed for Google Play
  • Target SDK and API levels meet current platform requirements
  • All compliance deadlines reviewed against your timeline

Review timeline budgeted:

  • Apple: 1 to 3 days for updates, 3 to 7 days for first submissions (budget 5 to 7 days for potential rejections)
  • Google Play: Up to 7 to 10 working days for reviews (budget 10 to 14 days for store listing change delays)
  • Do not modify your Google Play store listing during review. Any changes may restart the review process

The difference between a smooth approval and a weeks-long rejection loop comes down to preparation. Work through the complete pre-submission checklist before you submit, not after you get rejected. Try Anything free if you want a platform that handles many of these technical requirements for you. Test thoroughly on real devices, and confirm all privacy and compliance documentation is complete and accurate before beginning your app submission.