What Happens After You Submit Your App to Apple?

You press submit on your app build and watch the progress bar complete, then you're left staring at App Store Connect wondering what happens next and when you'll actually see your app go live. The waiting period between submission and approval can feel like a black box, and after building apps for Apple's platform for over ten years, I can tell you that understanding this process properly can save you days of stress and help you plan your launch much more accurately.

The app review process is less mysterious than most developers think, but it does follow specific patterns that are worth understanding before you submit.

Apple receives thousands of app submissions every single day, and each one goes through multiple automated checks and human review stages before it can appear on the App Store. The timeline can range anywhere from a few hours to several days, depending on factors like your app's complexity, the time of year, and whether you've submitted apps before. Getting rejected isn't uncommon (about 40% of first submissions face some kind of pushback), but most rejections are for straightforward reasons that can be fixed quickly once you know what to look for.

Preparing Your App Build for Submission

Before you even think about uploading, your app needs to be properly archived in Xcode with all the right settings configured. This means making sure your bundle identifier matches what you've set up in App Store Connect, your app icons are included in all required sizes (which ranges from 20x20 pixels up to 1024x1024 pixels for the App Store), and your version number follows Apple's formatting rules. The build needs to be signed with a distribution certificate, not a development one, which is a mistake I've seen trip up new developers more times than I'd like to admit.

Your Info.plist file needs to be squeaky clean. Any privacy-related features (camera access, location services, photo library, microphone, contacts, anything that touches user data) must have clear usage descriptions written in plain English explaining why your app needs that permission. Writing something vague like "This app needs camera access to function" will get you rejected... you need to be specific, like "This app uses your camera to scan barcodes and help you track your shopping."

Test your app thoroughly on actual devices, not just the simulator, because performance issues and crashes that don't show up in testing will definitely get flagged during review. Understanding binary requirements for app approval is crucial at this stage. I always run through a complete user journey on at least two different devices before submitting, checking that all buttons work, all screens load properly, and nothing breaks when you lose internet connection or get interrupted by a phone call.

Understanding App Store Connect

App Store Connect is Apple's web-based portal where you manage everything related to your app submission, and it's where you'll spend quite a bit of time during the review process. You need to create an app record before you can upload any builds, which involves filling in your app name (which needs to be unique across the entire App Store), choosing your primary category, setting your price (or marking it as free), and adding at least one localisation with screenshots and descriptions.

Set up your app record and fill in all the metadata at least a day before you plan to submit your build, because you'll inevitably find something missing or realise your screenshots need adjusting.

The interface is split into several sections that you need to understand:

• My Apps: where you manage your app listings, metadata, screenshots, and descriptions
• App Analytics: shows download numbers, usage data, and user behaviour once your app is live
• Sales and Trends: displays your revenue and download statistics if you're charging for the app
• Users and Access: where you manage team members and their permissions
• Agreements, Tax, and Banking: needs to be completed before you can release a paid app or use in-app purchases

The metadata you enter here (your app description, keywords, screenshots) is what potential users will see on the App Store, but it's also what the review team uses to understand what your app is supposed to do. Make sure your description accurately reflects your app's features, because if you claim to do something you don't actually do, that's an instant rejection. You should also consider when you might need to review and update your app's category for optimal discoverability.

The Initial Upload and Processing Stage

When you upload your build through Xcode or Transporter, it first goes through an automated processing stage before it even reaches a human reviewer. This usually takes between 15 minutes and a couple of hours, depending on your app's size and how busy Apple's servers are. During this time, Apple's systems are running automated checks on your binary, looking for issues like missing architectures, incorrect provisioning profiles, or references to private APIs that developers aren't supposed to use.

You'll see the build status change from "Processing" to "Ready to Submit" in App Store Connect once this stage completes. Sometimes builds fail during processing, and you'll get an email explaining why (usually something technical like an invalid signature or missing required device capabilities).

Once your build shows as "Ready to Submit," you need to select it in your app version and click the submit button. This is when you'll be asked questions about export compliance (whether your app uses encryption), advertising identifiers (if you're tracking users for ads), and content rights (confirming you have permission to use all the content in your app). Answer these truthfully because Apple can verify them, and false answers can get your developer account suspended.

What Apple's Review Team Actually Checks

The review team is looking at your app through two main lenses: technical quality and guideline compliance. They'll open your app on a real device and go through the main user flows to check that everything works as described. This isn't an exhaustive test of every feature, but they'll definitely try the core functionality, test any purchases or subscriptions, check that links work, and verify that your app does what your description claims it does. Learning how to navigate app store review guidelines successfully is essential for passing this stage.

Reviewers spend an average of about 20 to 40 minutes with each app, so they're looking at the main features and obvious issues rather than exploring every corner.

They're checking whether your app provides enough value to exist on the App Store (apps that are just wrappers around websites often get rejected unless they add something meaningful). They're verifying that you're not copying another app's functionality and branding, that you're not misleading users about what the app does, and that any content in your app meets Apple's standards around things like violence, gambling, and adult content. Understanding app store compliance and navigating platform rules can help you avoid common pitfalls during this review stage.

Privacy and Data Handling

Privacy has become a huge focus in recent years, and reviewers pay close attention to how you collect, use, and share user data. If your app asks for permissions, they'll check that you actually need those permissions for the features you've described. An app that asks for camera access but never actually uses the camera will get questioned. Your privacy policy needs to be accessible, written in clear language, and accurately describe your data practices. If you're developing apps for younger users, make sure you understand privacy laws for educational apps that collect children's data.

In-App Purchases and Monetisation

If your app includes any way to pay for content or services, the review team will test that these work properly and comply with Apple's rules about using their in-app purchase system. You can't bypass their payment system for digital goods (things like premium features, subscriptions to content, or virtual currency), though you can use external payment for physical goods or services rendered outside the app. Consider how different login options might affect your app's development costs when planning your monetisation strategy.

Common Rejection Reasons and How to Avoid Them

After reviewing hundreds of submissions over the years, I can tell you that most rejections fall into a handful of predictable categories. The single most common issue is incomplete information or functionality... when the app crashes on launch, when a key feature doesn't work, or when the reviewer can't figure out how to test the app because you didn't provide proper test credentials for a login screen.

Apps get rejected for guideline 4.3 (which covers spam and copycats) when they're too similar to other apps already on the store or when they don't offer enough unique value. I worked on a recipe app that got rejected under this guideline because it was essentially just displaying content from a website without adding any native functionality or offline access. We had to add features like recipe collections, a meal planner, and a shopping list generator before it was approved. It's worth understanding how to avoid plagiarism in app development to prevent these types of rejections.

Design and User Experience Issues

Apple expects a certain level of polish and adherence to their Human Interface Guidelines. Apps that look outdated, have broken layouts on different screen sizes, or use non-standard UI patterns can get rejected for providing a poor user experience. Your app needs to work properly on all the device sizes you claim to support, from the smallest iPhone SE up to the largest iPad Pro. If you're developing for Apple Watch, consider whether Apple Watch development is worth your time and be aware of design patterns to avoid in wearable applications.

Misleading Metadata or Functionality

If your screenshots show features that don't exist, if your description promises something your app doesn't deliver, or if your app name or keywords are misleading, you'll get rejected for metadata issues. Be honest about what your app does, and make sure your App Store listing accurately represents the actual experience users will have.

The Review Timeline and What Affects It

Most apps move from "Waiting for Review" to "In Review" within 24 to 48 hours, though this can stretch longer during busy periods like September (when iOS updates typically launch) or early January (after the holiday break when submissions pile up). Once your app enters the "In Review" status, the actual review process usually takes a few hours to complete, and you'll either get approved or receive a rejection message with specific reasons.

Don't submit your app right before a major holiday or the weekend if you're hoping for a quick turnaround, because review times can stretch significantly during those periods.

Your account history affects your review time... developers with a track record of approved apps and no previous violations tend to move through the queue a bit faster than brand new accounts. Apps that are updates to existing apps generally get reviewed faster than completely new submissions. The complexity and category of your app also plays a role, with simpler apps getting processed more quickly than complex ones with payments, subscriptions, or unusual permissions.

You can request an expedited review if you have a legitimate urgent need (like fixing a critical bug that's affecting users), but this should be used sparingly because Apple limits how often you can make these requests. I've used expedited reviews maybe four or five times in ten years, always for situations like fixing a crash that was preventing users from accessing their data or resolving a security issue that needed immediate attention. Learn more about how to expedite your app's review process legally for those rare urgent situations.

What to Do If Your App Gets Rejected

Getting a rejection notice isn't the end of the world, and in most cases you can address the issues and resubmit within a day or two. Read the rejection message carefully because it will explain exactly what needs to be fixed, often with references to specific guideline numbers that you can look up in Apple's App Store Review Guidelines document.

Your options when you receive a rejection:

1. Fix the issues mentioned in the rejection message and submit a new build
2. Respond through Resolution Centre if you think the rejection was a misunderstanding
3. Request a phone call with the review team if the issue is complex and needs discussion
4. Appeal the decision if you genuinely believe your app complies with the guidelines

I find that the vast majority of rejections are straightforward to resolve. If your app crashed, you fix the crash. If you're missing a privacy policy, you add one. If a feature doesn't work, you fix it. The ones that require more discussion are usually around interpretation of guidelines, like whether your app provides enough value or whether a particular feature counts as bypassing the in-app purchase system.

When you respond through Resolution Centre, be professional and specific. If the reviewer misunderstood how a feature works, explain it clearly and provide step-by-step instructions on how to test it. If you need to provide test accounts, make sure they're actually working accounts with all necessary permissions enabled. The review team wants to approve your app if it meets the guidelines, so help them understand why it does.

After Approval and Going Live

Once you see that green "Ready for Sale" status in App Store Connect, your app is live on the App Store and users can download it. The app usually appears in search results and category listings within a few hours of approval, though it can take up to 24 hours to fully propagate through Apple's servers worldwide.

Your work isn't finished when the app goes live. You need to monitor crash reports and user reviews in the first few days after launch, because real-world usage at scale will often uncover issues that didn't show up during testing. I always keep a bug-fix update ready to submit within the first week of launch, just in case something critical comes up that needs immediate attention. If you haven't already, this is also the perfect time to start implementing your email list building strategy to engage with your new users.

Updates to your app go through the same review process as the initial submission, though they typically move a bit faster since the reviewers are just checking what's changed rather than reviewing the entire app from scratch. You can update your app's metadata (description, screenshots, keywords) without submitting a new build, and those changes go live immediately without review, giving you flexibility to test different messaging and improve your conversion rates over time. Remember that you can update your app after it's in the App Store whenever needed.

If you need help navigating the app submission process or want experienced developers who know how to get apps through review smoothly, get in touch with us and we can talk through your project.

Frequently Asked Questions