< All ArticlesGuide

The Ultimate App Store Submission Checklist for 2026

Team Fload

Team Fload

Founders

Feb 25, 2026

The Ultimate App Store Submission Checklist for 2026

You've built your app. You've polished the UI, fixed the bugs, and you're ready to ship. But between you and your users stands one final gatekeeper: the app store review process.

If you've ever had an app rejected, you know the pain. Days of waiting, only to receive a cryptic rejection message citing “Guideline 2.1” or “Data Safety form incomplete.” You fix what you think is the problem, resubmit, and wait another week. Meanwhile, your launch date slips, your stakeholders are asking questions, and your competitors are shipping.

This guide exists to save you from that nightmare. It's based on real-world rejection data, Apple and Google's latest 2026 requirements, and hard-won lessons from developers who've been through the trenches. This isn't generic advice — these are the specific, actionable details developers actually need.

Let's get your app approved on the first try.

Why App Store Rejections Happen (And How to Avoid Them)

According to research by Adapty, 88% of app rejections come from a handful of preventable issues. The most common culprits:

  1. App crashes or bugs (Guideline 2.1) — over 40% of rejections
  2. Privacy policy violations — missing or incomplete privacy disclosures
  3. Metadata inaccuracies — screenshots don't match actual app
  4. In-app purchase violations — using external payment for digital goods
  5. Missing demo credentials — reviewer can't test your app

The good news? All of these are preventable. The key is systematic preparation before you hit “Submit for Review.”

Part 1: Pre-Submission Prep (The Stuff That Seems Boring But Will Save Your Launch)

Your App's Identity: Metadata That Matters

Think of your app's metadata as its resume. Get it wrong, and you won't get past the first impression.

App Name & Branding

Your app name has strict limits:

But here's the catch: your name can't be confusingly similar to existing apps, and it definitely can't violate trademarks. Naming your app “SuperChat for WhatsApp” is a fast track to rejection.

Pro tip: Check the App Store and Google Play for similar names before you design your icon and branding. Rebranding after rejection is expensive.

Keywords: The Hidden Battleground

iOS gives you exactly 100 characters to tell the algorithm what your app does. Here's how to use them:

The URLs Nobody Checks (Until Rejection)

You need three URLs before you can submit:

  1. Privacy Policy — Must be publicly accessible HTTPS. No exceptions.
  2. Support URL — Must actually work. Reviewers will check.
  3. Terms of Service (if your app requires accounts or subscriptions)

Pro move: Before submitting, open these URLs in an incognito browser. If they don't load, neither will your approval.

Part 2: Screenshots That Convert (And Don't Get Rejected)

Let's talk about the elephant in the room: screenshot requirements changed in 2024-2026, and if you're still using old sizes, you're going to have problems.

iOS Screenshot Sizes (2026 Edition)

Apple now primarily requires two sizes:

iPhone:

iPad:

If you don't provide 6.9" iPhone screenshots, you must provide 6.5" Display screenshots (1284 x 2778px or 1242 x 2688px). Otherwise, your submission will be rejected.

The Screenshot Sins That Get Apps Rejected

  1. Showing features that don't exist — Reviewers will test your app against your screenshots. If your screenshot shows “AI-powered recommendations” but the app doesn't actually have it, rejection.
  2. Using device mockups — Don't put your screenshots inside a phone frame. Apple wants the actual UI, no embellishments.
  3. Placeholder content — “Lorem ipsum” text, broken images, or “Coming Soon” screens visible in screenshots = instant rejection.
  4. Personal data — Don't use real user names, emails, or photos. Use obviously fake/anonymized data.

Google Play Screenshots

Android is more forgiving on sizes but stricter on quantity:

App Preview Videos (iOS)

If you're including video (optional but effective for conversion):

What you can't show in videos:

Part 3: The Technical Gauntlet (iOS)

This is where most “Guideline 2.1 - Performance” rejections happen. Apple's reviewers are ruthless about technical issues.

Before You Even Archive Your Build

✅ Build Settings Checklist:

Privacy Manifest: The 2024 Requirement Nobody Warned You About

Since May 1, 2024, Apple requires a Privacy Manifest (PrivacyInfo.xcprivacy) if your app uses certain “Required Reason APIs.”

These APIs include seemingly innocent things like:

If you use any of these without declaring why (with an approved reason code), your submission will be rejected.

How to add a Privacy Manifest:

  1. Add PrivacyInfo.xcprivacy to your Xcode project
  2. Declare all Required Reason APIs you use
  3. Select an approved reason code for each

Example:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" 
  "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>NSPrivacyAccessedAPITypes</key>
    <array>
        <dict>
            <key>NSPrivacyAccessedAPIType</key>
            <string>NSPrivacyAccessedAPICategoryUserDefaults</string>
            <key>NSPrivacyAccessedAPITypeReasons</key>
            <array>
                <string>CA92.1</string>
            </array>
        </dict>
    </array>
</dict>
</plist>

Permission Purpose Strings That Actually Work

Every permission (camera, location, photos, etc.) needs a purpose string. But not all purpose strings are created equal.

❌ Bad (will get rejected):

NSCameraUsageDescription: "Camera access"
NSLocationWhenInUseUsageDescription: "Location needed"

✅ Good (clear and specific):

NSCameraUsageDescription: "We need camera access to let you scan QR codes 
  and add items to your cart."
NSLocationWhenInUseUsageDescription: "We use your location to show nearby 
  restaurants and display accurate delivery times."
NSPhotoLibraryUsageDescription: "We need photo access so you can upload 
  profile pictures and share images in posts."

Reviewers want to see why your app needs the permission, not just what the permission is.

TestFlight: Your Secret Weapon

Here's a secret: you can submit to TestFlight beta review before full App Store submission. TestFlight review is:

TestFlight workflow:

  1. Upload build to TestFlight
  2. Add internal testers (your team — no Apple review required)
  3. Fix obvious bugs
  4. Enable external testing (triggers Apple beta review)
  5. Get real user feedback
  6. Fix remaining issues
  7. Submit to App Store with confidence

If you skip TestFlight and go straight to App Store submission, you're gambling with your launch timeline.

Part 4: Google Play's Secret Requirements

Google Play is generally more forgiving than Apple, but they have their own landmines.

The Data Safety Form: Google's Privacy Gauntlet

Since July 20, 2022, every app must complete the Data Safety form in Play Console. This is non-negotiable.

What you need to declare:

The catch: You also need to declare data collected by third-party SDKs.

Using Firebase? Facebook SDK? Adjust analytics? Each of those collects data, and you're responsible for declaring it.

Target API Level: The Rolling Requirement

Google requires apps to target the latest Android API within one year of release.

As of August 31, 2025:

How to update:

In build.gradle:

android {
    compileSdk 35
    defaultConfig {
        targetSdkVersion 35
    }
}

But wait—don't blindly bump the version. Higher API levels introduce behavior changes:

Test thoroughly on Android 15 devices/emulator after updating.

Content Rating: The Questionnaire Nobody Wants to Fill Out

Google uses the IARC (International Age Rating Coalition) system for content ratings. You must complete a questionnaire about:

Answer honestly. If your app has user-generated content (chat, forums, social features), you must disclose it. Reviewers will check.

Part 5: The Top 10 Rejection Reasons (And Exact Fixes)

Let's talk about the greatest hits of app rejection, with specific solutions for each.

1. App Crashes (Guideline 2.1)

Why it happens:
The #1 rejection reason. Over 40% of rejections. Reviewers run your app through a script, and if it crashes even once, rejection.

How to fix it:

2. Incomplete App / Placeholder Content

Why it happens:
Your app has “Lorem ipsum” text, “Coming Soon” features, broken images, or incomplete screens.

How to fix it:

3. Privacy Policy Missing or Non-Compliant

Why it happens:
No privacy policy URL, or the policy doesn't actually cover what your app does.

How to fix it:

4. Missing or Vague Permission Descriptions

Why it happens:
Your purpose strings are generic (“App needs camera”) or missing entirely.

How to fix it:
Write purpose strings that answer: “Why does this app need this permission to deliver its core functionality?”

5. In-App Purchase Violations (Guideline 3.1.1)

Why it happens:
You're using Stripe, PayPal, or external checkout for digital goods.

Apple's rule: Digital goods (subscriptions, premium features, in-app content, virtual currency) must use In-App Purchase (StoreKit). No exceptions.

How to fix it:

Exception: Physical goods/services (Uber rides, food delivery, hotel bookings) can use external payment.

6. Metadata Doesn't Match App (Guideline 2.3)

Why it happens:
Your screenshots show features that don't exist, or your description oversells what the app actually does.

How to fix it:

7. App is Just a Website Wrapper (Guideline 4.2)

Why it happens:
Your app is a WebView showing your website with no native functionality.

How to fix it:

8. No Demo Account Provided

Why it happens:
Your app requires login, but you didn't provide test credentials in App Review Information.

How to fix it:

9. Age Rating Mismatch

Why it happens:
Your app contains mature content (violence, gambling, sexual themes, profanity), but you marked it as age 4+.

How to fix it:

10. Using Required Reason APIs Without Declaration (iOS)

Why it happens:
You're using APIs like UserDefaults, file timestamp APIs, or system boot time without declaring why in your Privacy Manifest.

How to fix it:

  1. Audit your code for Required Reason APIs
  2. Add PrivacyInfo.xcprivacy to your Xcode project
  3. Declare each API with an approved reason code

Part 6: After You Hit Submit (What to Expect and How to Respond)

Review Timelines (2026)

iOS:

Google Play:

When (and How) to Respond to Rejections

You got the rejection email. Now what?

  1. Read the entire rejection message carefully. Apple and Google provide specific guideline citations and (usually) helpful details. Don't skim — read every word.
  2. Check Resolution Center. Sometimes there are screenshots or additional details not included in the email.
  3. Fix the root cause, not just the symptom. If you're rejected for “app crashes,” don't just fix the one crash they mention — audit for all potential crashes.
  4. Reply in Resolution Center if you need clarification. You can ask reviewers for specifics. Be polite and professional.
  5. Resubmit only after you've actually fixed the issue. Resubmitting without changes wastes everyone's time and can flag you as a problem developer.

Part 7: The Final Pre-Submission Checklist

Before you click “Submit for Review,” run through this one last time:

Technical

Privacy & Permissions

Metadata

Testing & Review Prep

Business Rules

If you can check every box, you're ready. Hit submit.

The Real Secret to App Store Approval

Here's the truth nobody tells you: app store approval isn't about perfection. It's about showing respect for the platform's rules and the reviewer's time.

Apple and Google aren't trying to make your life harder. They're protecting their ecosystems from scams, malware, and poor-quality apps. If you approach the review process with this mindset — “How can I prove my app is safe, functional, and honest?” — approval becomes straightforward.

The checklists above are your insurance policy. Follow them systematically, fix issues before submission (not after rejection), and you'll join the minority of developers who get approved on the first try.

What's Next?

You've submitted your app. While you wait for review, here's what you should be doing:

  1. Monitor crash reports (set up Crashlytics, Sentry, etc. if you haven't)
  2. Prepare your launch plan (app store optimization, marketing, press outreach)
  3. Line up user feedback channels (support email, in-app feedback, social media)
  4. Plan your first update (feature improvements, bug fixes based on early user feedback)

Need help with your app submission?

If you're using Fload to manage your app's analytics and performance, our platform automatically tracks submission requirements and alerts you to potential rejection risks before you submit.

Learn more about Fload →

About This Guide
This checklist is maintained by the Fload team and updated regularly with the latest App Store and Google Play requirements. Last updated: February 2026.

Bookmark this page. You'll need it for every submission. 🚀

Team Fload

Team Fload

Founders

Share𝕏in