App Store Submission Guide: How to Get Approved on Apple & Google Play (2026)

Here's a fun stat: roughly 40% of apps get rejected on their first submission to the Apple App Store. Google Play is more lenient upfront, but they'll happily suspend your app (or your entire developer account) after the fact.

Either way, you lose time. Sometimes weeks. And if you're an indie developer who just spent months building something, getting that rejection email feels like a punch in the gut.

The good news? Most app rejection reasons are completely avoidable. The stores publish their rules. Developers just don't read them.

This guide covers the app publishing best practices for both Apple App Store and Google Play Store — what to do, what to avoid, and how to submit your app with confidence.

Why Apps Get Rejected (The Big Picture)

Before diving into store-specific requirements, let's talk about the most common app rejection reasons across both stores:

1. Crashes and bugs — The #1 reason. If the reviewer hits a crash, it's an instant reject.
2. Broken or incomplete features — Placeholder screens, "coming soon" sections, or features that simply don't work.
3. Privacy violations — Missing privacy policy, undisclosed data collection, or requesting unnecessary permissions.
4. Misleading metadata — Your screenshots don't match the actual app, or your description promises features you don't have.
5. Poor UI/UX — Apple is especially strict here. If your app looks like it was built in 2012, expect pushback. (See our guide on 10 UX mistakes that kill ratings.)
6. Intellectual property issues — Using someone else's name, logo, or content without permission.
7. Missing login credentials — If your app requires login, you need to provide a demo account for the reviewer.

Let's be brutally honest: most of these are just developers not doing their homework. So let's do the homework.

Apple App Store: What You Need to Know

Apple's review process is notoriously strict. A real human reviews your app, and they follow the App Store Review Guidelines to the letter. Here's what trips people up most.

Design Standards

Apple cares deeply about design. They publish the Human Interface Guidelines (HIG) and expect you to follow them. This doesn't mean every app has to look the same, but it does mean:

• Native components — Use standard iOS UI elements where appropriate. Custom is fine, but don't reinvent navigation patterns for no reason.
• Dynamic Type support — Your app should respect the user's text size preferences.
• Safe areas — Content shouldn't hide behind the notch, Dynamic Island, or home indicator.
• Dark mode — Not strictly required, but increasingly expected. At minimum, it shouldn't break if the user has dark mode on.
• No web app wrappers — If your "app" is just a WebView loading your website, Apple will reject it. They want native experiences.

Functionality Requirements

• Your app must do something — This sounds obvious, but Apple rejects apps that are too simple, duplicative, or pointless. A flashlight app in 2026? No.
• No hidden features — Everything your app does must be discoverable by the reviewer. Secret menus or features that require special codes are a red flag.
• Sign in with Apple — If you offer third-party sign-in (Google, Facebook, etc.), you must also offer Sign in with Apple.
• In-app purchases — Digital goods and subscriptions must use Apple's IAP system. No linking to external payment methods for digital content. This is the rule that gets everyone riled up, but it's non-negotiable.

Review Process Tips

• Provide demo credentials — In the App Review notes field, include a working test account.
• Explain non-obvious features — If your app needs location access, Bluetooth, or specific hardware, explain why in the review notes.
• Use TestFlight — Beta test thoroughly before submitting. This is Apple's own tool. Use it.
• Appeal rejections professionally — If you disagree with a rejection, use the Resolution Center. Be polite and specific. Reviewers are human.

Google Play Store: What You Need to Know

Google Play's review process is faster (often hours, not days), but they enforce the Google Play Developer Policy aggressively — sometimes retroactively. An app that's been live for months can get suspended overnight.

Design Standards

Google is less prescriptive about design than Apple, but they have the Material Design Guidelines and expect modern Android apps to look... modern.

• Target API level — Google requires you to target recent Android API levels. As of 2026, new apps must target at least the latest major API level. Updates to existing apps get a short grace period.
• Edge-to-edge display — Support for different screen sizes, foldables, and cutouts.
• Adaptive icons — Required for a polished look on modern Android launchers.

Policy Landmines

These are the Google Play Store guidelines that catch developers off guard:

• Families Policy — If your app targets children (or could appeal to children), you must comply with the Families Policy. This includes strict ad and data collection rules.
• Subscription transparency — Free trials must clearly disclose when billing starts, how much, and how to cancel. Google is cracking down on "dark patterns" in subscription flows.
• Permissions — Only request permissions your app actually needs. Google audits this and will reject or suspend apps that request SMS, phone, or location access without justification.
• Background location — If you need background location access, you must submit a separate permission declaration form explaining why. Expect extra scrutiny.
• Deceptive behavior — Apps that mimic system notifications, use fake close buttons in ads, or trick users into clicking things will get removed.

Testing Before Submission

• Internal testing — Start here. Up to 100 testers, instant deployment, no review required.
• Closed testing — Larger group, still private. Google may review your app at this stage.
• Open testing — Public beta. Good for gathering feedback before a full launch.
• Pre-launch report — Google automatically tests your app on various devices and flags crashes, accessibility issues, and security vulnerabilities. Read this report.

Privacy & Data Requirements (Both Stores)

This is where both stores have converged: privacy is non-negotiable. And the requirements are more detailed than you might think.

Apple's Privacy Requirements

Apple requires you to complete App Privacy Details (the "nutrition labels") for every app. You must disclose:

• What data your app collects (including third-party SDKs)
• Whether data is linked to the user's identity
• Whether data is used for tracking across other companies' apps
• Your data retention and deletion policies

You also need App Tracking Transparency (ATT) if you track users for advertising. Yes, that's the popup everyone complains about. If you need it, implement it.

Google's Data Safety

Google has its own version: the Data Safety section. You must declare:

• What data is collected and shared
• Whether data collection is optional or required
• Your security practices (encryption, deletion requests)
• Whether your app follows the Families Policy (if applicable)

Both Stores Require

• A privacy policy URL — Linked in your store listing. Not optional. This must be a real, accessible web page that explains what data you collect and how you use it.
• Data deletion mechanism — Users must be able to request deletion of their data. Both stores now require this.
• Account deletion — If users can create an account, they must be able to delete it from within the app.
• Third-party SDK disclosure — You're responsible for what your SDKs do. If Firebase Analytics collects data, that's your data collection. Audit your dependencies.

Technical Requirements

Beyond policy compliance, your app needs to be technically solid. Both stores will catch (and reject) sloppy builds.

Apple Technical Requirements

• Latest Xcode — Build with the current stable version of Xcode. Apps built with outdated tools get rejected.
• 64-bit only — 32-bit has been dead for years. Make sure all your dependencies are 64-bit.
• No private APIs — Apple's automated checks will catch calls to private frameworks. Don't try it.
• App size — Keep your download size reasonable. Apple won't reject for size alone, but apps over 200MB can't be downloaded over cellular without user permission.
• IPv6 support — Your app must work on IPv6-only networks. This catches people who hardcode IPv4 addresses.

Google Play Technical Requirements

• Android App Bundle (AAB) — Google requires AAB format for new apps. No more plain APKs on the Play Store.
• Target SDK version — Must meet the current target API level requirements.
• App signing — Use Play App Signing. Google manages your signing key — there's no way around this for new apps.
• 64-bit support — All apps with native code must include 64-bit libraries.
• Foreground service types — If you use foreground services, you must declare the correct type (camera, location, microphone, etc.).

Store Listing Best Practices

Your store listing is your sales pitch. Even if your app is technically perfect, a bad listing means fewer downloads. Here's how to submit an app with a listing that converts.

App Name & Title

• Include your primary keyword naturally (e.g., "Budgetly — Expense Tracker & Budget Planner")
• Don't keyword-stuff — both stores penalize titles like "Best Budget App Money Finance Tracker Free"
• Keep it memorable and brandable

Screenshots

• First 2-3 screenshots are critical — they show in search results. Lead with your best feature.
• Add captions/overlays — Explain what users are seeing. "Track expenses in 2 taps" beats a bare screenshot.
• Show real content — No "John Doe" placeholder data. Make it look like a real person uses the app.
• Cover multiple device sizes — Apple requires screenshots for each device size you support. Don't skip the iPad ones if you support iPad.

Description

• First sentence is everything — It shows in search results and above the "read more" fold.
• Structure with short paragraphs and bullet points — Nobody reads walls of text.
• Include social proof — "Trusted by 50K+ users" or "Featured on ProductHunt".
• End with a CTA — "Download now and start..."

Video Preview (If You Have One)

• Keep it 15-30 seconds
• Show the core value proposition in the first 5 seconds
• Works without sound (most users watch muted)
• Don't show splash screens or loading — get right to the good stuff

Category & Content Rating

• Choose the most accurate category, not the least competitive one
• Fill out the content rating questionnaire honestly — lying about this can get you removed
• If your app has user-generated content, declare it

Pre-Submission Checklist

Before you hit that submit button, run through this list. Print it out if you have to — or use our free interactive checklist tool that saves your progress.

Technical ✅

• ☐ App doesn't crash on launch (test on multiple devices)
• ☐ All features work as described
• ☐ No placeholder content, "TODO" text, or test data visible
• ☐ Tested on both Wi-Fi and cellular connections
• ☐ Tested in airplane mode (graceful offline handling)
• ☐ Deep links and universal links work correctly
• ☐ Push notifications work (if applicable)
• ☐ Built with latest SDK/Xcode version

Privacy & Compliance ✅

• ☐ Privacy policy URL is live and accessible
• ☐ App Privacy Details / Data Safety section completed accurately
• ☐ All permissions have clear justifications
• ☐ Account deletion flow works (if accounts exist)
• ☐ ATT prompt implemented (if tracking on iOS)
• ☐ GDPR/CCPA compliance in place for relevant regions
• ☐ Third-party SDKs audited for data collection

Store Listing ✅

• ☐ Screenshots match the actual current app
• ☐ Description is accurate — no promises you can't keep
• ☐ Content rating questionnaire completed
• ☐ Support URL/email is valid
• ☐ App category is appropriate
• ☐ No trademarked terms used without permission

Review-Ready ✅

• ☐ Demo account credentials provided (if login required)
• ☐ Review notes explain any non-obvious functionality
• ☐ Special hardware requirements noted
• ☐ Beta tested with real users (not just you and your co-founder) — see our guide on getting honest app feedback

One More Thing: Get External Feedback First

Here's what we see constantly at RealAppReview: developers submit their app, get rejected, fix the issue, resubmit, get rejected for something else, and repeat. Each cycle costs days (Apple) or hours (Google), but the frustration compounds fast.

The smartest thing you can do before any app store submission is get an outside perspective. Not from your co-founder, not from your mom — from someone who doesn't know your app and will actually try to break it.

That's exactly what we do. Our app reviews cover UX, store listing, technical issues, and compliance — the same things Apple and Google reviewers look for. We catch the problems before they cause rejections.

---

Ready to submit with confidence? Get your app reviewed by RealAppReview before you hit "Submit for Review." We'll tell you exactly what needs fixing — no sugar-coating.

---

📚 Related Articles

• Top 15 Most Common App Store Rejections in 2026 — The specific rejection reasons ranked by frequency, with exact fixes.
• The Ultimate App Launch Checklist (2026) — Submission is just part of the launch. Here's the full checklist.
• ASO 101: App Store Optimization for Indie Developers — Once approved, make sure your listing actually converts.

See what our pre-submission review covers in our sample reports, or order your review now.