- 1. Before you start
- 2. Create the app record (5 fields, immutable)
- 3. App Information (always-on fields)
- 4. Pricing & Availability
- 5. App Privacy (the legal one)
- 6. Age Rating questionnaire
- 7. Version metadata (per-release)
- 8. Screenshots & previews — exact specs
- 9. App Review Information
- 10. Version Release timing
- 11. Submit for Review
- 12. Top submit-blockers
This page exists because the App Store Connect UI is a 12-form gauntlet and Apple's own docs are scattered across 40-odd pages. Here it's one scroll. Use it as a checklist on your first submission and a reference on every one after.
Where this fits. Magic Deploy handles the binary: archive, sign, upload to TestFlight in one click. This page covers everything you fill in around that binary — the metadata, screenshots, pricing, and disclosures. The two together are the whole submission.
1. Before you start
You need three things before you can create an app record:
- An Apple Developer Program membership ($99/year). Sign up at developer.apple.com/programs/enroll. Individual or Organization — both can ship to the App Store.
- A Bundle ID registered at developer.apple.com/account/resources/identifiers. The reverse-DNS name (
com.yourcompany.appname) that ties Xcode → App Store Connect → certificates → entitlements together. Pick carefully — this string is permanent. Also: pick the right type:- App ID for iOS / iPadOS / tvOS / watchOS / visionOS apps
- App ID with the "Mac" platform checkbox for macOS apps
- Use an explicit ID (
com.you.app), not a wildcard (com.you.*) — wildcards can't be used for App Store distribution.
- The app's icon built into the binary at the right resolutions (1024×1024 marketing icon mandatory; Asset Catalog "AppIcon" set in Xcode handles the per-device sizes). Apple now requires the 1024 icon to be opaque (no transparency, no alpha channel).
2. Create the app record
App Store Connect → My Apps → + → New App. Five fields. Most are permanent; getting them wrong now means a deletion-and-recreation later.
| Field | Limit | What to put / Why it matters |
|---|---|---|
| Platforms | — | Tick every platform this app record will ship to (iOS, macOS, tvOS, visionOS). You can add more later, but each platform shares the same name + bundle ID, so think about it now. macOS Catalyst counts as iOS here, not macOS. |
| Name | 30 chars | The display name shown on the Store and the home screen. Public. Don't include the category in the name (Apple rejects "MyApp – Note Taking" — use the Subtitle for that). Editable, but only between submissions. |
| Primary Language | — | Permanent. The fallback locale for users whose language you haven't localized to. Almost always English (US) unless you're region-specific. Cannot be changed after the first submission goes live. |
| Bundle ID | — | Permanent. Pick the App ID you registered in step 1. If you don't see yours, you registered it under a different team or for a different platform. Once an app record uses a Bundle ID, that ID can't be deleted or repointed. |
| SKU | — | Internal stock-keeping identifier. Never shown publicly. Used in sales reports and the API. Use something like MYAPP-IOS-001. Unique within your account; can be any string. Don't put PII or anything you'd be embarrassed to see in a CSV. |
| User Access | — | Leave on Full Access unless you have an account with multiple developers and you want to wall this app off from some of them. |
Click Create. You're now looking at an empty app record. The next sections are the forms you'll fill from here.
3. App Information
Left sidebar → App Information. These fields apply to every version of your app — you fill them once and update them rarely.
| Field | Limit | What to put / Why it matters |
|---|---|---|
| Localizable Name | 30 chars | Same as the Name from creation. Localizable: per-language overrides under Add Language. |
| Subtitle | 30 chars | One-liner shown under the name on the Store. This is some of your most valuable real estate — use it for keywords + a hook ("Note-taking for engineers"). Localizable. Editable any time. |
| Privacy Policy URL | — | Required. Public URL that loads the moment Apple's reviewer hits it (no login walls). If you don't have one, generate a starter at privacypolicies.com and host it on your domain. Localizable. |
| Category | — | Pick a Primary and (optionally) Secondary from Apple's fixed list (Books, Business, Education, Finance, Food & Drink, Games, Graphics & Design, Health & Fitness, Lifestyle, Music, News, Photo & Video, Productivity, Reference, Shopping, Social Networking, Sports, Travel, Utilities, Weather, etc.). The Primary one drives Search ranking and the chart your app competes on; pick the most accurate, not the least-crowded. |
| Content Rights | — | "Does your app contain, show, or access third-party content?" Tick yes if you display licensed media (music, video, news), no for purely user-generated. If yes, you'll need rights documentation on file with Apple — keep contracts/permissions. |
| Age Rating | — | Edit → questionnaire (covered in section 6). |
| Custom Product Pages | — | Optional. Lets you create alternate Store pages with different screenshots/text and drive traffic to them via custom URLs (great for ads / A/B tests). Skip on first submission. |
| In-App Events | — | Optional, only relevant if you run timed events (live streams, challenges, sales). Skip on first submission. |
4. Pricing & Availability
Left sidebar → Pricing and Availability.
| Field | Limit | What to put / Why it matters |
|---|---|---|
| Base Country / Region | — | The country whose price you set; Apple converts to other territories using their price tier matrix automatically. Pick the country where you live or where most of your customers are. |
| Price Tier | — | Tier 0 = free. Otherwise tiers run $0.49 → $9999.99 in increments Apple defines. You cannot set arbitrary prices — only tier values. The tier in your base country determines all other countries; you can override per-country if you want. |
| Availability | — | 175 territories ticked by default. Untick any country your app legally can't ship to (encryption rules, content laws). For paid apps, Apple's tax obligations differ by territory — Tax and Banking needs to be filled in Agreements, Tax, and Banking first or Apple will hold your earnings. |
| Volume Purchase Program | — | Tick if you want enterprises and schools to buy your app in bulk at a 50% discount through Apple's VPP. Free for you to enable; only relevant for paid apps. |
| Pre-Order | — | Optional. Lets users "pre-order" up to 180 days before release. Useful for marketing big launches; overkill for most apps. |
Tax + Banking is a separate gauntlet. For paid apps and apps with In-App Purchase, you must complete the Paid Applications Agreement + tax forms (W-9 for US, W-8BEN for non-US) + banking info before your first submission. Find it under Business → Agreements, Tax, and Banking. Until that's done, paid downloads are blocked. Apple won't tell you this is the problem — the app will just be unavailable in some countries with no error.
5. App Privacy
Left sidebar → App Privacy. This is the public "Privacy Nutrition Label" shown on your Store page. You answer it as a legal attestation — wrong answers can get the app pulled.
Apple asks you to declare every type of data your app (or any SDK in your app) collects. For each type, you specify:
- Linked to user? (i.e. tied to their identity / account)
- Used for tracking? (linked across other companies' apps/sites for ads — triggers App Tracking Transparency)
- Purpose: analytics, app functionality, third-party advertising, developer's advertising, product personalization, other
Categories Apple enumerates (full list in their App Privacy details):
- Contact Info — name, email, phone, address
- Health & Fitness — HealthKit data, fitness
- Financial Info — payment info, credit info
- Location — precise / coarse
- Sensitive Info — race, religion, sexual orientation, etc.
- Contacts — your address book
- User Content — photos, videos, gameplay content, audio, customer support, other
- Browsing History
- Search History
- Identifiers — User ID, Device ID
- Purchases
- Usage Data — product interaction, advertising data, other
- Diagnostics — crash data, performance data, other
SDKs count. If you use Firebase, Google Analytics, Meta SDK, Sentry, Crashlytics, etc., their data collection counts as yours. Each major SDK publishes its own privacy disclosure list — check it and roll those into your answers. Common gotcha: Crash reporters collect Diagnostics → Crash Data and Identifiers → Device ID even if you didn't write a line of "tracking" code.
Why this isn't auto-filled by tools: Apple deliberately requires the developer to attest to this in the web UI as a legal record. No tool — including Magic Submit — can answer this for you. Allow ~15 minutes the first time; subsequent updates are usually no-op unless you added an SDK.
6. Age Rating
App Information → Age Rating → Edit. A questionnaire about content frequency. Apple computes your rating (4+, 9+, 12+, 17+) from your answers.
Categories asked about: Cartoon/Fantasy Violence, Realistic Violence, Sexual Content/Nudity, Profanity, Alcohol/Tobacco/Drugs, Mature/Suggestive Themes, Simulated Gambling, Horror/Fear, Medical/Treatment Info, Unrestricted Web Access, Gambling, Contests.
For each: None / Infrequent / Mild / Frequent / Intense.
Rules of thumb:
- Most productivity / utility apps: None on every category → 4+.
- Anything with an in-app browser (WKWebView pointing at user-supplied URLs) → tick Unrestricted Web Access. This forces 17+ regardless of other answers, because Apple can't audit what users will browse.
- Social apps with user-generated content: tick "Unrestricted Web Access" only if users can post arbitrary URLs without moderation; otherwise leave it off and let the content categories drive the rating.
Why this isn't auto-filled either: same reason as App Privacy — it's a legal attestation. Magic Submit can open this page in your browser, but you fill it.
7. Version metadata
Left sidebar → iOS App / macOS App → the version row (e.g. "1.0 Prepare for Submission"). These fields are per-version — you fill them every release.
| Field | Limit | What to put / Why it matters |
|---|---|---|
| Version | — | Semver string (1.0.0, 1.0.1, …). Must be ≥ the previous public version. Match it to CFBundleShortVersionString in your Info.plist or the upload's rejected. Magic Deploy doesn't auto-bump this — you do, in Xcode's target settings. |
| What's New | 4000 chars | Release notes. Empty on first submission. From v1.0.1+, this is required and shown in the Updates tab. Localizable. Be specific — "Bug fixes" gets ignored; "Fixed crash when exporting PDFs over 100 pages" gets read. |
| Promotional Text | 170 chars | Marketing line above the description. Editable any time without resubmitting — Apple's only "live" field. Use it for time-sensitive callouts ("New: Markdown export"). Localizable. |
| Description | 4000 chars | The pitch. Plain text, line breaks render. Apple's algorithms parse this for keywords too, but Apple has said keywords-stuffing in the Description hurts more than it helps. Lead with the value prop in the first 3 lines (the rest is hidden under "more"). Localizable. |
| Keywords | 100 chars total | Comma-separated list, not visible to users, used by Search. Most powerful real estate per character. Don't repeat the App Name or Subtitle (already indexed). Don't include competitor names — Apple rejects. Use comma without spaces (note,markdown,export,sync) to fit more. Localizable. |
| Support URL | — | Required. Public URL where users can get help. Loads without login. If you don't have a site, a public Notion/Linear page or a GitHub Issues link works. Localizable. |
| Marketing URL | — | Optional. Your app's home page on your site. Localizable. |
| Copyright | — | Year + entity name: 2026 Your Company, Inc. or 2026 Jane Doe. Apple checks this matches your developer account's entity. |
| Trade Representative Contact | — | EU DSA requirement (since 2024). Address, phone, email of a contact for EU regulatory queries. Apple stores this; users in EU can request to see it. Required for distribution in the EU. |
| Routing App Coverage File | — | Only relevant for navigation/maps apps that handle http://maps.apple.com/?dirflg=… URL routing. Skip otherwise. |
8. Screenshots & previews
Same page as Version metadata, top section. This is the part that fails the most reviews — wrong size = instant rejection without explanation other than "binary is invalid."
iPhone screenshots — required device classes
Apple requires at least one screenshot for one of the largest current iPhone sizes. Apple uses these to render previews on smaller iPhone screens too — you don't need to upload every size.
| Device class | Pixel size | What it represents |
|---|---|---|
| 6.9" Display | 1290 × 2796 (portrait) | iPhone 16 Pro Max, 15 Pro Max, 14 Pro Max — required for new submissions in 2025+. Apple stretches these to cover all smaller sizes if you upload nothing else. |
| 6.5" Display | 1242 × 2688 (portrait) | iPhone XS Max, 11 Pro Max, 8 Plus class. Optional but used as fallback. |
| 5.5" Display | 1242 × 2208 (portrait) | iPhone 8 Plus / 7 Plus. Optional. Apple deprecated this requirement in 2024 — no longer needed. |
iPad screenshots
| Device class | Pixel size | What it represents |
|---|---|---|
| 13" Display | 2064 × 2752 (portrait) or 2752 × 2064 (landscape) | iPad Pro M4 (13"). Required if your app supports iPad and you ship to iOS. |
| 12.9" Display | 2048 × 2732 / 2732 × 2048 | iPad Pro 6th-gen and prior. Apple now treats 13" as the canonical — uploading both is allowed but redundant. |
macOS screenshots
Required if you ship a Mac app. Sizes: 1280 × 800, 1440 × 900, 2560 × 1600, or 2880 × 1800. Pick one — most submissions use 2560 × 1600 (Retina 13") since it's sharp on every display Apple sells.
Per-screenshot rules
- Up to 10 per device class. Order matters — first one is the gallery thumbnail.
- PNG or JPG. No transparency. No animated formats.
- RGB color space, not P3 (will be silently downconverted).
- No status bar mockups. Apple wants the actual UIStatusBar in your screenshot, or a clean status-free shot. Don't paste fake "9:41 AM" bars unless they match Apple's marketing-image standard.
- No "coming soon" overlays for features not in this build. Apple rejects.
- No price stickers or "Free!" badges. Apple rejects.
- No competitor names. Apple rejects.
App Previews (video)
Optional. Up to 3 per device class, each 15–30 seconds, .mov or .mp4, ProRes recommended. Records on-device gameplay/usage; static text/marketing footage is rejected ("Apple wants to see the app in action").
9. App Review Information
Same page, scroll down past Screenshots.
| Field | Limit | What to put / Why it matters |
|---|---|---|
| Sign-In Required | — | Tick if your app requires login to use any feature. If yes, demo credentials are MANDATORY — without them, instant rejection. |
| Demo Account: User Name | — | Working credentials Apple's reviewer uses. Real account, in your prod database, with realistic data. Do not lock it; reviewer will hit it from various IPs and devices. |
| Demo Account: Password | — | Same idea. Don't 2FA-protect this account. Apple's reviewers will not retrieve a code from your server. |
| Notes | — | Anything the reviewer needs to test all features. Examples: "To test the export flow, navigate Home → +. To test push notifications, send any message from a second device." Be specific — vague notes get the app rejected for "missing functionality." |
| Contact Information | — | First name, last name, phone (international format), email of someone who can answer Apple's reviewer fast. Apple does call this number. Often. |
| Attachment | — | Optional. Use for proof-of-rights documents, regulatory licenses, NDA-required test plans. Doesn't appear publicly. |
10. Version Release
Same page, top.
- Manually release this version: app sits in Pending Developer Release after Apple approves it; goes live when you click Release. Lets you sync with marketing / press / your launch tweet.
- Automatically release this version: goes live ~30 minutes after Apple approves. Default; fine for most updates.
- Automatically release this version after App Review, no earlier than [date]: same as above but pinned to a launch date. Apple will hold the binary until your date even if review finishes early.
Phased release (optional): rolls the update out to a percentage of users per day over 7 days (1% → 2% → 5% → 10% → 20% → 50% → 100%). Lets you abort the rollout if you spot a regression. Only available for updates, not first submissions. Highly recommended for any app over a few thousand DAU.
11. Submit for Review
Top right: Add for Review → Submit to App Review. Pre-flight checklist Apple makes you tick:
- Export Compliance — does your app use encryption? Almost always yes, because HTTPS counts as encryption use. Apple gives you exemptions to declare:
- "Uses encryption only for HTTPS / SSL" → exempt under ATS
- "Uses encryption that's already exempt under U.S. export law" → most apps
- If unsure, fill out the actual form. The penalty for misdeclaring is the app being pulled.
- Content Rights — same checkbox as App Information. Just match it.
- Advertising Identifier (IDFA) — does the app use IDFA for ads / tracking / attribution? Honest yes/no. If yes, you'll need App Tracking Transparency prompt code (
ATTrackingManager.requestTrackingAuthorization) in the binary.
Click Submit. The status flips to Waiting for Review, then In Review (~24h median, can be faster), then Pending Developer Release or Ready for Sale.
12. Top submit-blockers
The five rejections that hit most first-time submitters:
- Guideline 2.1 — App Completeness. Reviewer hit a feature that crashed or didn't work. Fix: test on a real device with airplane mode + slow networks before submitting. Most "incomplete" rejections are network-related.
- Guideline 2.3.10 — Accurate Metadata. Your description / screenshots claim a feature your binary doesn't have. Fix: prune marketing copy down to what the build actually does today.
- Guideline 5.1.1 — Privacy / Data Collection and Storage. Sign-in flow asks for data unrelated to the app. Fix: only ask for what you need; defer optional sign-in until the user hits a feature requiring an account.
- Guideline 4.0 — Design / Minimum Functionality. "App is too minimal / a website wrapper." Fix: ship at least one capability that wouldn't work as a webpage (offline mode, push, biometrics, sensors, share sheet).
- Demo account credentials missing or expired. See section 9. The single most preventable rejection.
If rejected: read the message in the Resolution Center. Reply with a fix or an explanation; you do not need to resubmit a new build unless the binary itself is the problem. ~30% of "rejections" turn into approvals after a clarifying reply.
Done filling? Hand the binary upload to Magic Deploy and the metadata to Magic Submit — fills the API-doable ~80% of these fields automatically (Description, Keywords, What's New, Promotional Text, URLs, build selection) and opens the App Privacy + Age Rating pages in your browser to finish the rest.
Related guides
- Magic Deploy: App Store — how the binary gets archived, signed, and uploaded.
- How App Store code signing works — the trust chain explained.
- JWT auth in 5 minutes — how Apple's API authenticates.
- Glossary — every deploy term in plain English.
- Apple's App Review Guidelines — the source of truth, updated frequently.