App Store Submission Checklist: Launching Your iOS App in 2026
Apple rejects roughly 40% of first-time submissions. Almost none of those rejections are about your code — they're about paperwork, screenshots and metadata that don't match what App Review expects. Here's what to check before you hit submit.
Metadata that won't get flagged
Your app name, subtitle and keywords need to be accurate, not aspirational. Apple has tightened enforcement on keyword stuffing in app names ("MyApp - Best Budget Tracker Free 2026" will bounce) — put search terms in the dedicated Keywords field instead, comma-separated, no spaces, 100 characters max.
Your app description should describe what the app does *today*, not a roadmap. If a feature is behind a paywall or requires sign-up, say so — Apple checks this during review, not just users after launch. Double-check your support URL and privacy policy URL both resolve (dead links are an instant rejection) and that the privacy policy is specific to your app, not a generic template pasted across five products.
Pick your primary category carefully. "Utilities" as a catch-all gets more scrutiny than a well-matched category, and category mismatches now trigger manual review more often than they used to.
Screenshots and previews
You need screenshots for every device size you support — 6.9" and 6.3" iPhone sets are mandatory in 2026, plus iPad sizes if your app runs universal. Apple will auto-scale from your largest set if you don't provide every size individually, but auto-scaled shots often crop badly, so it's worth generating each size properly.
Screenshots must reflect the actual UI. Marketing overlays, device frames and text callouts are fine; showing screens, flows or features that don't exist in the shipped build is not, and it's one of the more common reasons for rejection under Guideline 2.3 (Accurate Metadata). If you use an app preview video, keep it under 30 seconds and capture it from an actual device or the simulator, not a mockup tool.
Privacy nutrition labels and permissions
This is where most avoidable rejections happen. Your App Privacy details in App Store Connect must match what your app actually collects — Apple cross-checks this against your binary's declared entitlements and any third-party SDKs you've bundled (analytics, crash reporting and ad SDKs are the usual culprits for undeclared data collection). If you're not sure what an SDK reports home, check its privacy manifest — third-party SDKs are required to ship one, and Xcode will flag missing manifests at archive time.
Every permission request (camera, location, contacts, tracking) needs a purpose string in Info.plist that's specific to your use case — "This app needs your location" gets rejected; "Used to show nearby stores in the map view" doesn't. If you use App Tracking Transparency, the prompt has to appear before any tracking happens, not after.
Guideline pitfalls and review timelines
The fastest way to get rejected is still Guideline 4.3 (Spam/Duplicate) — near-identical apps from the same developer account, or an app that's just a wrapper around a website with no native functionality. If your app is thin on native features, expect questions.
Sign-in apps need to offer Sign in with Apple if they offer any other third-party login (Google, Facebook, etc.) — this one still catches people out every year. And if your app has account creation, make sure account deletion is available in-app too, not just via a support email.
Review times in 2026 typically run 24–48 hours for most submissions, though expedited review is still available for genuine launch-critical bugs (request it via App Store Connect, don't abuse it). Build in a buffer of at least a week before any hard launch date or press embargo, since a rejection resets the clock.
Getting the app built is the hard part — getting it *found* once it's live is the next problem. If you want the store listing itself optimised for search and AI-driven discovery once you're through review, that's exactly the kind of thing our Sentinal product at Web-ly is built to handle.