Upload a build to App Store Connect in one step, then wait for processing before it reaches TestFlight.
You upload a build to App Store Connect from Xcode, from Swift Playground, from the altool command line, or from Transporter, the free macOS app. The upload is almost never the part that fails. Apple's documentation is explicit that a build has to be processed in Apple's system before it appears in App Store Connect, and that you get an email when that finishes, so a successful upload and a visible build are two separate events. The rest of the sequence is publishing to the App Store.
Every step, field name and limit below was read from Apple's and Google's own documentation on 3 October 2026, with the page titles named so you can check them. Where the two stores differ, and on uploads they differ more than most pages admit, the difference is stated rather than implied.
Diagnose a build that will not appearThe short version
A finished upload is not yet a build anyone can install.
Three things have to happen in order. The upload has to complete, Apple has to process the binary into device variants, and the build has to carry an export compliance answer. Miss the third and the build sits there reading Missing Compliance, which to the person waiting looks exactly like nothing happened.
Apple publishes one number that settles most of the panic. If a build stays in the Processing state for more than 24 hours, Apple's documentation says there may be an issue and tells you to open a Feedback Assistant ticket. Under 24 hours you are waiting. Apple does not publish a typical processing time, so anyone quoting you one is guessing.
Four ways to upload, and what all four need first
The app record has to exist before the first upload. Each time you upload, the bundle ID and the version number inside the app bundle are what associate the build with an app and version record, and the build string is what uniquely identifies that build across the system. With no matching record there is nothing for the binary to attach to, so create an app store connect record first. Uploading needs the Account Holder, Admin, App Manager or Developer role.
Apple's own list of upload tools is Xcode, Swift Playground, altool and Transporter. Transporter is a free macOS app on the Mac App Store that shows delivery progress, warnings, errors and past deliveries. altool runs through xcrun, with --validate-app to check a file and --upload-app to send it. Apple states that upload for all target types is supported for Transporter and altool, which is why both still exist alongside Xcode. If you use the App Store Connect API, Apple suggests the Transporter command line tool with the same JSON Web Tokens, so there is no second credential. That API replaced an older route: Apple's requirement notes record that the XML feed stopped supporting in app purchases, subscriptions, metadata and app pricing in November 2022, and Game Center in July 2024.
Two acceptance requirements changed this year and they reject uploads outright. Apple's Upcoming Requirements page, read on 3 October 2026, says that since 28 April 2026 apps uploaded to App Store Connect must be built with Xcode 26 or later using an SDK for iOS 26, iPadOS 26, tvOS 26, visionOS 26 or watchOS 26, and that since 9 September 2026 iOS and iPadOS apps must target iOS 13 or later. The upload page itself still lists Xcode 6 or later as an acceptable uploading client, with only a note that Xcode 14 or later will be required at some point during 2026. Apple does not publish the month, so treat the SDK requirement as the real floor.
None of this can be rehearsed on a simulator. Uploading, processing and TestFlight all need a real signed archive, and a real device to install the result on.
Your build uploaded and it is not in TestFlight
There are two status columns and confusing them is the whole problem. The upload has a status, in the Build Uploads section, reading Processing, Failed or Complete. The build then has a separate beta status, which is what the TestFlight list shows, and that is where Missing Compliance, Invalid Binary, Ready to Submit and Ready to Test live. Apple's status reference is blunt about the consequence: Invalid Binary and Rejected builds are not visible in TestFlight for internal or external testing. So a Complete upload can still be invisible to everyone.
The documented path, checked on 3 October 2026: in Apps, select the app, click the TestFlight tab, select the platform in the sidebar, then expand Build Uploads and read the Status column. An All Statuses dropdown sits at the top right of that table. Selecting a status shows the errors and warnings behind it, which is where a Failed upload explains itself. Apple emails you when a build moves to Processing, Failed or Complete, so the inbox beats refreshing. On a Complete upload, clicking the build string in the Version and Build column opens the build and its Build Metadata tab.
Processing means Apple is still running app thinning and generating a variant per device. Two things hide inside a Complete status. A warning badge can sit beside it, and Apple says those warnings are worth reading before the next upload rather than after. Separately, if any device variant exceeds the 200 MB over the air download limit, a yellow warning icon appears next to the build string and Apple emails you. That is a warning, not a rejection, which is why it gets ignored until a customer complains.
Two quieter causes are worth ruling out. A build whose provisioning profile is missing an application identifier shows Not Available for Testing and cannot be used with TestFlight at all. And every build is testable for up to 90 days, after which its status becomes Expired, so a build that was there last quarter is not a bug. The tester side of this, groups, invitations, the 100 internal and 10,000 external ceilings and the review only the first external build needs, is a guide of its own: ios testflight.
Apple, App Store Connect Help: View builds and metadata, read 3 October 2026
Work out which one you have
What App Store Connect is telling you
Pick the thing you can actually see on the screen. Every verdict below comes from Apple's own status documentation.
Two status columns exist and they mean different things. The upload has one, under Build Uploads. The build has a separate beta status, which is what the TestFlight list shows.
Missing Compliance is the most common silent block
Missing Compliance does not mean anything is wrong with your binary. It means the build has no export compliance answer yet. Apple asks because uploading puts your app on a server in the United States, which makes any encryption in it an export, and Apple's documentation says the questions come back for every new version unless you answer them in the project.
The fix, as Apple documents it and as read on 3 October 2026: in Apps select the app, click the TestFlight tab, click the platform under Builds in the sidebar, then click the app icon or build string in the Build column for the build missing compliance information. From there, click Manage beside the build and answer the questions, or click Choose File to upload documentation Apple has already approved. One role difference catches teams out. Uploading allows the Developer role. Providing export compliance information does not: Apple lists Account Holder, Admin and App Manager only.
Answer it once in the project and the question stops. Apple's security documentation says to add the ITSAppUsesNonExemptEncryption key to the app's information property list as a Boolean. Set it to NO when the app, including every third party library it links against, uses no encryption or only exempt forms, and Apple gives HTTPS through the operating system as its example of an exempt form. Set it to YES otherwise. If Apple reviews documentation for you it returns a code, which goes in the same file as ITSEncryptionExportComplianceCode.
When the beta status finally reads Ready to Submit, the build can go to internal testers, to TestFlight App Review for external testing, or to App Review for customers. That submission and the waiting attached to it is a separate procedure: what happens next.
The same upload on Google Play behaves differently
Google Play has no processing status to wait on, and that is the largest single difference between the two stores. You upload one signed Android App Bundle and Play generates the per device APKs itself. Play Console Help, read on 3 October 2026, puts the uploaded artifact under Test and release, in App bundle explorer, with Details, Downloads and Delivery tabs and a version filter at the top right. If you arrived from a page hunting for the Artifact library, that is the screen it became, and Google says so.
Play's delays are real but they sit elsewhere. Google says a new app bundle published to the internal test track becomes available to testers within minutes, and that a first time upload reaches internal testers immediately while showing temporary name and listing information for up to 48 hours. The same page says the test link itself can take several hours to become available after a test is published for the first time, and that later changes can too. Both statements are Google's and they do not conflict: the artifact is ready, the invitation route is not yet.
The limits do not line up either, so do not carry a number across. Google's ceiling is a 200 MB maximum compressed download size for the APKs generated for a single device, and Google states plainly that the bundle itself can be many times larger. Apple measures the uncompressed app instead: 4 GB with a 500 MB executable for iOS 9.0 and later, across all the __TEXT sections in the binary. Play also takes the United States export laws declaration once, when you create the app, rather than per build, which is why Android developers almost never meet anything like Missing Compliance.
Google Play Console Help: Create and set up your app, read 3 October 2026
What each store does after the upload finishes
| After the upload | App Store Connect, iOS | Google Play Console, Android | Can hide the build |
|---|---|---|---|
| Where the upload first appears | TestFlight tab, Build Uploads table | Test and release, App bundle explorer | No |
| A processing step with its own status | Processing, then Failed or Complete | None published | Yes |
| Export compliance answer | Per build, or the status reads Missing Compliance | Declared once, when the app is created | Yes |
| Published time from upload to installable | Not published; over 24 hours means an issue | Within minutes on the internal test track | No |
| Published size ceiling | 4 GB app, 500 MB executable, iOS 9 and later | 200 MB compressed download per device | Yes |
When something else runs the upload for you
All of the above assumes you pressed the button. If a build service or a CI pipeline uploads for you, the steps move rather than disappear. Ask three things of any of them. Which role does it hold in your App Store Connect account, since export compliance needs more than Developer. Does it answer the compliance questions, or leave the build reading Missing Compliance. And does it submit for review, or stop at the upload.
Newly is an AI app builder. You describe an app in plain English and it writes a real React Native and TypeScript project you own, runs it on cloud iOS and Android simulators while it builds, then uploads to App Store Connect and TestFlight. That upload is owner or admin only. It does not press submit, and that is deliberate rather than missing: Apple's guideline 4.2.6 puts submission on the person whose app it is, not on the service that generated it. On Android it publishes to Google Play internal testing and separately builds a standalone production APK. It is $25 a month and there is no free plan.
The processing wait belongs to Apple either way, so the diagnosis above stays yours whoever uploaded. To run the upload yourself, the project comes out as a ZIP from Settings, through the two way GitHub sync under Deploy, or with the newly command line tool, and from there it is an Xcode archive like any other.
Questions people ask about uploading builds
Check the two status columns separately. The Build Uploads status says whether the upload itself finished: Processing, Failed or Complete. The beta status says whether the build is usable, and Apple lists Invalid Binary and Rejected builds as not visible in TestFlight at all. A Complete upload with a Missing Compliance beta status is the most common version of this. Also check for Not Available for Testing, which means the provisioning profile is missing an application identifier, and for Expired, which happens 90 days after upload.
Get to a build that is Ready to Submit
Confirm the app record exists, upload with Xcode, Transporter or altool, watch the Build Uploads status until it reads Complete, then answer export compliance before you go looking for the build in the tester list.
Start building