How to Submit an App to the App Store (2026 Checklist)

In short: To submit an app to the App Store, join the Apple Developer Program (99 USD a year), create an app record in App Store Connect, fill in the metadata, screenshots, privacy details and age rating, upload a build made with Xcode 26 or later, pick that build on the version page and click Submit for Review. Apple typically reviews at least half of submissions within 24 hours and 90% within 48 hours. Most rejections come from incomplete apps, so test the exact build you submit and give the reviewer a working demo account.

This guide follows the order App Store Connect expects, with every limit checked against Apple's documentation as of October 2026. Our running example is a hypothetical iPhone habit tracker called Streakly.

Before you start: account, Mac and agreements

1. Join the Apple Developer Program. Membership is 99 USD per membership year, for individuals and organizations alike. Both need an Apple Account with two-factor authentication. Organizations also need a D-U-N-S Number, legal entity status (Apple does not accept DBAs or trade names), a work email on the company domain and a public website. To show a company name as the seller, enroll as an organization; the D-U-N-S check can take days, so start early.

2. Accept the agreements. Apple notes that you can't add an app until the Account Holder signs the latest agreement in the Business section of App Store Connect. If you will charge for the app or sell in-app purchases, complete the paid apps agreement, tax and banking details there as well.

3. Use a current Xcode. Since April 28, 2026, apps uploaded to App Store Connect must be built with Xcode 26 or later using the 26 SDKs. An older toolchain fails at upload, not at review.

4. Selling in the EU? The same page notes that since February 17, 2025, apps without verified Digital Services Act trader status are removed from the EU App Store. Provide it in App Store Connect before launch.

Step 1: Create the app record

In App Store Connect open Apps, click the plus button and choose New App. You need the Account Holder, Admin or App Manager role. The dialog asks for:

• Platforms: iOS, macOS, tvOS, visionOS. Multi-platform apps share one bundle ID.
• Name: 2 to 30 characters. It must be unique on the store.
• Primary language: the fallback language for countries where you have no localization. You can change it later.
• Bundle ID: must match the bundle ID in your Xcode project. It can't change after you upload a build.
• SKU: your internal ID (letters, numbers, hyphens, periods, underscores). It can't change after you add the app.
• User access: full or limited to chosen team members.

Streakly: name "Streakly: Habit Tracker", English (U.S.), bundle ID com.example.streakly, SKU streakly-ios.

Step 2: Write the metadata

The version page holds the text customers read and App Store search indexes. These are the current limits:

Sources: platform version information, app information and Creating your product page, which says promotional text "doesn't affect your app's search ranking" and that subtitle and description change "when submitting a new version."

Three details trip up first submissions:

• The keyword field is 100 bytes, not 100 characters. Accented and non-Latin characters take two or three bytes each. Apple also says your app is already searchable by its name and company name, so don't repeat them, and that "names of other apps or companies aren't allowed." Our guide to App Store keywords covers how to fill the field byte by byte.
• The support URL must lead to real contact information. An empty page or a "coming soon" site is a classic completeness rejection.
• Metadata follows guideline 2.3.7: no trademarked terms, popular app names, pricing information or irrelevant phrases "just to game the system."

Before you commit to a keyword in the name or subtitle, check how many people actually search it. The free App Store keyword checker shows popularity, difficulty and the top 10 apps for any search in 50 countries, without an account.

Step 3: Screenshots and app previews

As of October 2026, Apple's screenshot specifications require:

• iPhone: at least one screenshot for "iPhone with Dynamic Island (medium display)", accepted at 1179 × 2556 or 1206 × 2622 pixels in portrait (or the landscape equivalents).
• iPad, if the app runs on iPad: at least one screenshot for the 13-inch display, 2064 × 2752 or 2048 × 2732 pixels in portrait.

You can upload up to 10 screenshots per device size in JPEG or PNG, with no alpha channel or transparency. If your interface is the same across sizes, Apple scales the highest required resolution down to smaller devices, so one well-made set is enough. Required sizes change as new iPhones ship, so check the page on the day you export.

Guideline 2.3.3 adds that screenshots "should show the app in use, and not merely the title art, login page, or splash screen." Text overlays are fine. For Streakly, five screenshots: today's habits, a streak calendar, reminders, statistics and the widget.

If your app is iPhone only, make sure the Xcode target doesn't also include iPad, or you will need iPad screenshots too.

Step 4: Privacy details, policy and manifest

Privacy has three separate parts, and each one can block you.

App Privacy details (the "nutrition label"). In App Store Connect, under App Privacy, you declare what data the app and every third-party SDK in it collects, whether it is linked to the user and whether it is used for tracking. Apple says this information "is required to submit new apps and app updates." Answers can be updated later and published without a new version. Analytics, crash reporting, ads and login SDKs all count.

Privacy policy. Guideline 5.1.1(i) requires a privacy policy link both in App Store Connect and inside the app, "in an easily accessible manner." Apple's App Review page adds that it must say what data you collect, how you use it, and how you handle retention and deletion.

Privacy manifest and required reason APIs. Since May 1, 2024, apps uploaded to App Store Connect must include approved reasons for the listed "required reason" APIs used by your code, including code from third-party SDKs. You declare them in a PrivacyInfo.xcprivacy file in the app bundle. Common examples are UserDefaults, file timestamp and disk space APIs. Update your SDKs before you archive; current versions of popular SDKs ship their own manifests.

If your app lets people create an account, guideline 5.1.1(v) also requires account deletion inside the app.

Step 5: Age rating, category and content rights

Apple updated the age rating system on July 24, 2025: it added 13+, 16+ and 18+ to the existing 4+ and 9+, and added required questions about in-app controls, capabilities, medical or wellness topics and violent themes. Developers had until January 31, 2026, to answer them. For a new app you simply answer the whole questionnaire under App Information; an app left unrated can't be published on the App Store. Answer honestly: App Review compares your answers with what the app does.

In the same section pick a primary and optional secondary category (Apple's search indexes both) and answer the content rights question if the app shows third-party content.

Step 6: Archive, export compliance and upload

Every build asks about encryption. Apple's export compliance overview explains that you must determine your obligations if the app uses, accesses or contains encryption. If your app only uses encryption that is exempt, typically standard HTTPS through Apple's networking APIs, add the ITSAppUsesNonExemptEncryption key set to NO in Info.plist so App Store Connect stops asking on every build. If you use proprietary or non-standard cryptography, you may need to upload documentation. Apple states that you carry the liability for a wrong exemption claim.

Then upload. Apple's upload builds page lists these routes as of October 2026:

1. Xcode: Product › Archive, then Distribute App › App Store Connect. The simplest path.
2. Transporter: a free Mac app for uploading an exported .ipa.
3. altool: xcrun altool --upload-app from the command line. It is still documented for App Store uploads (only notarization moved to notarytool in 2023).
4. App Store Connect API: build uploads with the same JSON Web Tokens you use for the rest of the API.
5. Xcode Cloud: builds and uploads in Apple's CI.

After upload, Apple processes the build; it appears under TestFlight and on the version page when processing finishes. If it never appears, check the email Apple sends to the account, which reports problems such as missing usage descriptions.

Step 7: Test the exact build in TestFlight

Install the processed build with TestFlight before you submit it. Up to 100 internal testers from your team can install it right away; up to 10,000 external testers can join by email or public link after the first build in a group passes Beta App Review. Builds stay testable for 90 days.

For Streakly the minimum pass is: fresh install, onboarding, sign in with the demo account, create a habit, receive a reminder, delete the account, and run once offline.

Step 8: Fill in App Review information and submit

On the version page:

1. In Build, select the processed build and answer the export compliance question if your Info.plist does not.
2. In App Review Information, add a contact person who will answer the phone, and sign-in information if the app has a login. Guideline 2.1 says to "include demo account info (and turn on your back-end service!)". If you can't provide one for legal reasons, a built-in demo mode needs Apple's prior approval.
3. In Notes, explain anything a reviewer can't discover alone: hardware the app pairs with, region-locked features, where the paywall is. Guideline 2.3.1 asks that new features be described "with specificity" here.
4. Choose the release option: release automatically after approval, release manually, or schedule a date.
5. Click Add for Review, then Submit to App Review.

You can have one app version in review per platform at a time, plus one separate submission of items such as in-app events or custom product pages.

Step 9: Review time and release

Apple states that App Review typically reviews at least 50% of submissions in less than 24 hours and 90% in less than 48 hours. Complex apps and repeat rejections take longer. For a critical bug fix or an event tied to your app, you can request an expedited review through Apple's Contact Us form.

For updates, consider a phased release. Over 7 days the update goes to 1%, 2%, 5%, 10%, 20%, 50% and then 100% of users with automatic updates on. You can pause for up to 30 days in total or release to everyone at any time. Anyone can still update manually, so treat it as a crash guard, not a feature flag.

The full release checklist

Why apps get rejected, and how to avoid it

Apple reports that over 40% of unresolved issues relate to guideline 2.1, App Completeness. The guidelines below cover most of the problems Apple lists on that page:

After a rejection: reply, fix, resubmit or appeal

A rejection arrives as a message in the App Review section of App Store Connect (developers still call it the Resolution Center). To answer, open the app, click the unresolved issues link, then Resolve › Reply to App Review. You can attach screenshots or documents until you resubmit.

Decide which case you are in:

1. The reviewer misunderstood something. Reply with specifics: the exact screen, the steps, a short screen recording. Apple's advice is to "be specific about what you're asking."
2. It is a metadata problem. Fix the text or screenshots and resubmit. Apple says you "can resubmit the same build" for metadata issues.
3. It is a real bug or policy gap. Fix it, upload a new build and resubmit with a note explaining the change.
4. You disagree with the decision. Submit one appeal per rejected submission to the App Review Board through the Contact Us form, not the reply field, with specific reasons why the app complies.

For apps already on the store, Apple's guidelines say bug fixes "will not be delayed over guideline violations except for those related to legal or safety issues"; ask for this in your reply and fix the issue in the next version.

Automating releases

Once you ship every few weeks, clicking through the same pages gets slow. Your options:

• fastlane. deliver (alias upload_to_app_store) keeps metadata and screenshots in files, uploads them with the binary and can submit for review; pilot (alias upload_to_testflight) uploads builds and manages testers. Both accept App Store Connect API keys.
• The App Store Connect API. Apple's REST API can create versions, manage metadata and screenshots, handle TestFlight, manage phased releases and submit for review. It is what every tool in this list uses underneath.
• Searvia's Release tab. In the Searvia app, an App Store project has a Release tab with a checklist read live from App Store Connect. You create the version, upload screenshots (checked against Apple's exact pixel sizes first), pick the build, answer export compliance, fill in App Review details and the age rating, then submit. App Privacy can't be read through Apple's API, so the checklist links you to it. After submission Searvia checks the review status every 30 minutes and can notify you by email, Telegram, Slack or webhook.
• Searvia CLI (in development). The Searvia CLI is an open-source, MIT-licensed command-line tool that is still being built; command names may change before the first release. The plan: pull and push store listings in fastlane-compatible folders, run an offline ASO audit (including the 100-byte keyword field and repeated words), upload screenshots and builds, and create the version, attach the build, answer export compliance and submit with one command, using your own App Store Connect API key in CI.

Ship it, then measure it

Approval is the start. If you would rather not repeat this checklist by hand, Searvia runs the release from one screen, tells you when Apple's review status changes and then tracks where your new version ranks for the keywords you chose, so you know whether the listing you shipped is working.