iOS app submission
in 2026: a walkthrough.

Writing the app is the first 30%. The rest is everything Apple makes you do before a single user can download it. We've put around forty apps through App Review since 2014 — our own and clients' — and the difference between a two-day approval and a six-week saga is almost never the code. It's the metadata, the signing, the privacy declaration, and increasingly in 2026, whether Apple thinks a human actually built it.

This is the walkthrough we wish someone had given us before our first submission. It covers what's changed in 2026 — including Apple's quiet but real crackdown on AI-generated apps — and what we still see clients trip over week after week.

The two-paragraph version

If you only read this far: a clean iOS submission in 2026 takes 24 to 48 hours in App Review for an experienced developer, and 2 to 6 weeks of stop-start cycles for a first-timer who didn't know what to set up first. The submissions that fail almost never fail because the code crashes. They fail because the App Privacy declaration doesn't match what the binary actually does, the screenshots don't reflect the live app, the metadata describes features that aren't there, or Apple's reviewers think the app was assembled by a model rather than designed by a person.

Apple's review system has always been a quality filter. In 2026, it's also an authenticity filter — and the authenticity check is the part most surprising new submitters. Knowing what trips it before you upload is the difference between a Tuesday launch and a Q3 launch.

1. The Apple Developer Program — the boring bits that block you on Day 1

You can't submit anything without an active Apple Developer Program membership. £79/year for individuals, £79/year for organisations — but the organisation route requires a verified D-U-N-S Number, which Dun & Bradstreet issue free but can take five to ten working days to assign. We've seen launches delayed a month because nobody started the D-U-N-S process until after the build was ready.

Other Day 1 paperwork that has nothing to do with code:

• Identity verification — government ID upload, sometimes with a follow-up call from Apple. 1–7 days.
• Banking and tax forms in App Store Connect — required before a paid app or in-app purchase can go live, not just before you get paid. The W-8BEN-E (or UK equivalent) routinely catches first-timers.
• Agreements — every time Apple updates the Paid Applications Agreement (which is roughly twice a year), you have to log in and re-accept it. Forget to, and your app silently disappears from sale until you do.

If you're commissioning a developer, your first question shouldn't be "when can you start?" — it should be "have you started the D-U-N-S yet?"

2. The provisioning rabbit hole

This is where most independent developers, and almost every "I'll just use AI" attempt, actually fall over. Code-signing on iOS is a chain of four moving pieces:

• Bundle Identifier — the reverse-DNS string (com.monexapps.appname) that uniquely identifies your app. Once it's used, it's used forever; you can't reuse it for a different app or transfer it cleanly between accounts.
• Certificates — your Apple-issued cryptographic identity. There's a Development cert (for running on test devices) and a Distribution cert (for the App Store). They live in your Mac's Keychain and they expire — usually annually — and yes, your app stops being buildable when they do.
• Provisioning Profiles — the file that ties a certificate to a bundle ID with a specific list of entitlements. They live in ~/Library/MobileDevice/Provisioning Profiles/. There's a Development profile, an Ad Hoc profile (for distributing to specific test devices), and an App Store profile.
• Capabilities and Entitlements — what your app is allowed to do: Push Notifications, iCloud, Sign in with Apple, In-App Purchase, HealthKit, App Groups, Associated Domains, Background Modes, and a couple of dozen others. Each one has to be enabled for the bundle ID in the Developer Portal and declared in the entitlements file and match the provisioning profile and in some cases require an explicit Apple approval before submission.

Xcode's "Automatically manage signing" mostly handles the choreography for you. Mostly. The half-day debugging session that hits every new developer eventually is when something falls out of sync — usually because someone enabled a capability in the portal but the local profile didn't refresh, or a certificate expired and Xcode quietly created a new one that doesn't match the profile in CI. The error messages — "No matching provisioning profiles found", "Code signing entitlement does not match", "The executable was signed with invalid entitlements" — are notoriously bad.

The shortcut every experienced iOS developer eventually adopts: when in doubt, delete every profile in ~/Library/MobileDevice/Provisioning Profiles/, regenerate from the Developer Portal, and re-download. About 60% of provisioning issues fix themselves. The other 40% are real entitlement misconfiguration that no amount of clicking fixes.

3. Archive, validate, upload

Once signing is healthy, the build flow is:

• Product → Archive in Xcode — produces a .xcarchive.
• Distribute App → App Store Connect in the Organizer — uploads to TestFlight.
• Wait 5–30 minutes for Apple to process the binary. dSYMs get extracted, the app is malware-scanned (this is the iOS equivalent of macOS notarisation, even though Apple doesn't use the word for iOS), and bitcode/symbol processing runs.

Common upload errors and what they actually mean:

• ITMS-90683 / ITMS-91053: a privacy manifest issue. As of 2024 every third-party SDK must include a PrivacyInfo.xcprivacy file declaring what it does. If one of yours doesn't, the upload is rejected before it even reaches review.
• ITMS-90338: a non-public API string was found in your binary. Usually a third-party SDK reaching for something it shouldn't.
• ITMS-90111: bundle ID mismatch — usually a signing/profile drift.
• "Invalid Swift Support": your build embedded Swift libraries it shouldn't have. Always uses Xcode's "Distribute App" workflow rather than a custom export.

Always submit to TestFlight first, never directly to App Review. TestFlight is the real first review — it surfaces 80% of the problems App Review would have flagged, and it lets you push fixes in hours rather than days.

4. App Store Connect — the metadata that decides your timeline

The build is the easy part. App Store Connect is where most of the real work happens, and where most of the rejections come from. The required fields for a submission:

• App Name — exactly as it appears on the home screen. 30 chars max. Must not contain "for iPhone", "App", or competitor names.
• Subtitle — 30 chars. Heavily indexed for App Store Search.
• Keywords — 100 chars, comma-separated, behind the scenes. Don't repeat words from your name or subtitle (it doesn't help).
• Description — up to 4,000 chars. The first three lines are what users see before "more". Treat them like a meta description.
• Promotional Text — 170 chars, can be edited without resubmission. Use it for changing announcements.
• Support URL and Marketing URL — Apple checks these are live. A 404 here is an immediate rejection.
• Privacy Policy URL — mandatory for every app since 2018. Must be a real, accessible privacy policy that matches your App Privacy declaration.
• App Review Information — demo account credentials (if your app requires login), notes for the reviewer, and contact info. The reviewer will email this address if they need clarification, and they will not chase you if you don't reply within 24 hours.
• Age Rating questionnaire — about a dozen questions covering violence, mature themes, gambling, alcohol references and so on. Answer honestly; under-rating gets you rejected, over-rating costs you visibility.
• Export Compliance — does your app use encryption? Almost everything does (HTTPS counts), but most apps qualify for an exemption.

5. App Privacy — the declaration that breaks more apps than crashes do

If we had to name the single most common reason first-time submissions fail in 2026, it's this one.

App Privacy is the "nutrition label" Apple shows on every App Store listing. You declare, in App Store Connect, what data your app collects, what it links to a user identity, and what it uses to track them across other apps and websites. The categories are exhaustive — about 30 data types across 14 use cases.

The trap: every third-party SDK you embed counts. Firebase Analytics, Crashlytics, Sentry, the Facebook SDK, AdMob, RevenueCat, OneSignal, Mixpanel, Amplitude — each one collects data, often more than the developer realises. Apple's static analyser scans your binary, identifies known SDKs, and cross-references what you've declared. A mismatch is an automatic rejection under Guideline 5.1.1.

The discipline that prevents this:

• Audit every SDK in your Package.swift or Podfile. Read each one's privacy manifest.
• Match your App Privacy declarations to the union of what every SDK actually collects, not what you intended to collect.
• If you can't justify an SDK's data collection in your privacy policy, remove the SDK. The cost of having Crashlytics is rarely worth a privacy-policy paragraph that scares users away.

6. Screenshots and marketing assets

Apple's required screenshot sizes change with every iPhone refresh. As of 2026, the required uploads are:

• iPhone 6.9" — current Pro Max. Required.
• iPhone 6.5" — older Pro Max generations. Required for now; Apple has signalled this will be retired.
• iPad 13" — current iPad Pro. Required if your app supports iPad.

Each set is 3 to 10 screenshots. Apple's rules: must reflect the actual app, no marketing chrome covering content, no device frames inside the screenshot itself. App Preview videos (15–30 seconds, .mov or .mp4, 1920×1080 portrait) are optional but tend to lift conversion meaningfully — we usually see 15–30% higher install rates on listings with one.

The mistake we see often: developers submit screenshots from a build that's slightly different from the final, then App Review notices the discrepancy. Always take screenshots from the binary you're submitting, not the one you were testing two weeks ago.

7. The review queue in 2026

Once you submit, the app moves through several states: Waiting for Review → In Review → Pending Developer Release (or Ready for Sale, depending on your settings).

• Waiting for Review usually lasts 12–24 hours.
• In Review usually lasts 2–8 hours of actual reviewer time.
• Total: clean submissions in 2026 typically clear in 24–48 hours.

Caveats:

• First submissions from a new developer account get deeper scrutiny — 3 to 7 days isn't unusual.
• Holiday freezes hit every December 23–27 and around Chinese New Year. Plan around them.
• Expedited Review is available, but only twice a year per developer account, and only for genuine emergencies (a critical bug in a live app, a launch tied to an immovable date). Don't waste it on impatience.

8. The top rejection reasons we still see in 2026

From most to least common, in our submission log:

• Guideline 5.1.1 — Privacy / Data Collection and Storage. App Privacy declaration mismatch, missing privacy manifest, or privacy policy that doesn't match the declarations.
• Guideline 2.1 — App Completeness. Crash on a reviewer device (often an older iPad they're testing universal builds on), broken sign-in, dead links, placeholder text shipped to production.
• Guideline 4.3 — Spam. Duplicate of an existing app, "minimum functionality", or — increasingly in 2026 — apps Apple believes are AI-generated.
• Guideline 2.3.10 — Misleading Metadata. Screenshots show features the app doesn't have. Description over-promises. Keywords include competitor names.
• Guideline 4.0 — Design. "Generic", "low-quality", or "AI-generated" UI. This one's increasingly being applied to AI-built apps.
• Guideline 3.1.1 — In-App Purchase. Trying to charge for digital content via Stripe instead of IAP, missing "Restore Purchases", subscriptions without auto-renewal disclosure.

The pattern: 80% of rejections are not about whether the app works. They're about whether the app's presentation matches reality — privacy declarations matching SDKs, screenshots matching features, metadata matching behaviour.

9. The AI-generated app problem

This is the most-asked question we've had in 2026 from new clients: "Will Apple reject our app because we used AI to help build it?" The honest answer is: not for using AI tools — but yes if Apple thinks the app is mostly AI-generated and adds nothing original.

Apple has been quietly tightening Guideline 4.3 (Spam) and Guideline 4.0 (Design) throughout 2025 and into 2026. They are not anti-AI ideologically — Apple itself has shipped enormous amounts of AI tooling — but they are aggressively anti-low-quality, and a great deal of low-quality 2026 submissions are AI-assembled apps that wrap a public API or mimic a popular app with a generative UI.

Detection signals we've identified from working with rejected clients:

• Boilerplate code patterns. AI tools tend to emit recognisable structures — particular SwiftUI scaffolding, predictable file naming, characteristic comment styles. Apple's static analysers compare new submissions against a corpus of known AI-generated patterns.
• AI-generated icons. Apple appears to run reverse-image lookups against the major image generators' fingerprints. A DALL-E or Midjourney icon, even a heavily edited one, is detectable. We've seen apps rejected with "Your icon does not appear to be original artwork" as the explicit reason.
• Generic descriptions. ChatGPT-flavoured marketing copy — "Our app helps you streamline your workflow with intuitive design" — pattern-matches against Apple's training data of past spam submissions.
• Submission velocity. One developer account submitting six similar-looking apps in a month gets flagged automatically.
• API-wrapper apps. Apps whose entire functionality is "send the user's input to a third-party API and display the result" fail Guideline 4.3's "minimum functionality" test, full stop. This catches the bulk of AI-built ChatGPT-clone apps.
• Mismatch between declared functionality and behaviour. AI-generated descriptions over-promise; the actual app under-delivers; the reviewer notices the gap.

What gets through: apps that use AI as a tool — including AI features inside the app — but where a developer made deliberate decisions about scope, structure, design, edge cases, error handling, and user experience. Apple isn't filtering for absence of AI. They're filtering for presence of human judgement.

This is why we're seeing experienced iOS developers' approval rates remain steady through this transition while less-experienced submitters' rates have visibly dropped. It's not a vibe; it's a measurable shift in the rejection logs.

10. Why a real developer still matters

Submission is roughly 30% code and 70% process. The process knowledge that takes years to accumulate:

• Provisioning intuition. Knowing within 30 seconds why a build won't sign — cert expired, profile mismatch, capability missing, Keychain stale — instead of half a day of trial and error.
• Privacy-declaration accuracy. Reading every SDK's privacy manifest, mapping it to App Privacy fields, writing a matching privacy policy. This alone is a 4–8 hour task on a moderately complex app.
• Reviewer-empathic metadata. Writing descriptions and screenshots that don't accidentally trip 2.3.10 or 4.3.
• Crash-safe submission discipline. Testing on the oldest devices Apple still supports (currently iPhone 11 on iOS 17) before submission, not after rejection.
• Rejection literacy. Reading a rejection notice and knowing whether the right response is "appeal", "fix and resubmit with the same build number", or "back to the drawing board". Each reads completely differently and has different timelines attached.
• Lifecycle management. Build expiry (90 days), app updates, version compatibility, deprecating old iOS versions, the App Store Connect API for CI/CD.
• Expedited review timing. Knowing when to use your two-per-year quota and how to write a request that Apple will actually grant.

None of this is something an AI tool walks you through. It's the kind of knowledge that only comes from doing it forty times and watching what fails.

The honest takeaway

If you're a first-time submitter, expect the first iOS launch to take 2 to 4 weeks from "code complete" to "live on App Store" — most of that spent on metadata, privacy, signing, and the first one or two rejection cycles. With an experienced studio in 2026, the same launch typically takes 2 to 4 days. The gap is process knowledge, not coding speed.

And — relevant to the conversation we keep having with new clients — Apple is increasingly using App Review as an authenticity filter, not just a quality filter. The studio with submission scars is not just a convenience; it's the signal Apple's reviewers are increasingly looking for that an app is real.

---

If you're getting close to your first iOS submission and want a sanity check on provisioning, App Privacy, or your screenshot set before you upload, we offer free 30-minute consultations — no commitment. Email support@monexapps.com or visit monexapps.com to book a slot.

For an example of an iOS app we built and shipped — provisioning, IAP, four-country coverage, and all — see the Antennascope case study. For more on how we work, the Buyer Guide covers our pricing and process. And if you're weighing iOS-only versus a web build first, the platform comparison is the companion piece to this one.