App Store submission: what a managed release actually covers
Most companies searching for someone to handle an App Store submission are not buying a specific task. They are buying an outcome: a build that passes review, goes live, and carries the required filing number inside the app. What "we handle it" actually covers — and which steps still require the account holder to act — is less vague than it sounds.
This is one real delivery, broken into stages: two apps for a manufacturing client, taken from account verification all the way to the filing number being displayed inside the app.
Step 1: account entity verification, the stage people underestimate
Enterprise developer accounts normally sit under the client's own name. Many clients assume an account just works once it is purchased. In practice, whether it can submit anything depends on whether the entity details have been verified: does the D-U-N-S number match the legal entity name, and can the account distribute builds at all.
Two hard blockers live here.
A three-way entity mismatch. The developer account holder, the contracting party and the O field in historical certificates may not agree with each other. Nothing fails immediately — archiving and signing both look normal — but the mismatch turns into a dispute over signing ownership and at handover. Our approach is to put all three on the table at kickoff and report any mismatch early, rather than discovering it the day before submission.
An unaccepted developer agreement. This is the classic problem you cannot find until you submit. However complete the preparation looks, the account may be blocked at the moment of submission. Accepting the agreement can only be done by the account holder, and a contractor cannot do it on their behalf. That is why we list it as a kickoff item: confirm the agreement status, and tell the client in advance if they need to act.
Step 2: CSR, certificates and provisioning profiles
Once the entity is verified, the certificate chain begins: generate a CSR, issue a distribution certificate in the developer portal, and export the .p12 with its private key stored safely. Certificates are valid for one year and must be reissued on expiry, so our delivery documents record the certificate fingerprint and public key together — the filing step later needs both.
Provisioning profiles come in two sets. The App Store profile is for store distribution; the Ad Hoc profile is for internal testing on a limited set of devices, authorised by a UDID whitelist. These two are often confused. An Ad Hoc build cannot be uploaded to App Store Connect, and if you want both channels you need both profiles. The testing profile also requires the client to collect the UDIDs of the test devices — whoever holds the devices supplies the list.
This stage is something a contractor can cover, provided the client grants access to the developer portal. The account stays in the client's name throughout. That boundary protects the client's asset.
Step 3: archive, upload and rejection handling
We script the upload path — validate, archive, export, upload — and keep a receipt for every upload, so that when something fails we can locate which step it failed at. The reason is practical: some errors only surface on a real upload. A local archive and export can both be clean while Apple's servers refuse the build outright — for example when the deployment target no longer meets the current requirement, and the build never even enters the review queue.
Beyond upload there is review. Three common rejections — UIWebView deprecation, a server-side refusal of the deployment target, and an app icon containing an alpha channel — are broken down in our earlier note on App Store rejections. Rejection handling is the most technical part of a managed release, and the best test of whether a vendor has actually shipped before. There is also a class of subjective rejections, such as 4.3 on duplicated apps, where the fix is not in the code but in articulating how the product is different — a separate discipline of its own.
Step 4: the filing and the privacy manifest
Passing review is not the finish line. Apps published in mainland China must complete the MIIT filing, with materials that include the filing information form and the certificate public key and fingerprint used for the filing. We organise the material list into a client-facing document. Entity information and qualification materials must come from the client — the filing entity is the client, so this cannot be delegated.
Once the filing number is issued it has to be displayed inside the app, usually on a Settings → About screen. It looks like a small item, but compliance checks look for it, and we keep it as a fixed line on the pre-launch checklist.
The privacy manifest (PrivacyInfo.xcprivacy) works the same way: every Required Reason API the app touches — UserDefaults, file timestamps, system boot time, disk space and similar — must be declared individually, alongside the privacy policy page, review notes and permission usage descriptions. We turn these into a repeatable compliance self-check script rather than relying on memory.
Who does what
Laid out plainly:
We do: account entity checks and problem triage; CSR and certificate issuance; both provisioning profiles; the internal testing channel; archive, upload and receipt retention; rejection handling; filing material preparation and public-key/fingerprint extraction; the privacy manifest and compliance self-check.
The client must act: opening and paying for the developer account; providing and verifying entity information; accepting the updated license agreement; granting us access to the account; collecting UDIDs for test devices; supplying entity and qualification materials for the filing; and the company details that appear in the privacy policy.
In one sentence: we cover the technical stages, and the client must be present for identity and asset stages. That is not passing work back — the account and the filing entity sit in the client's name, and those steps should not be delegated in the first place.
The value is in the sequencing
A managed release is not about clicking the upload button for you. It is about identifying every stage that can block the release before it blocks you: check entity consistency at kickoff, confirm the license agreement before submission, align the deployment target before upload, and prepare filing materials in parallel with development. Once the chain has been walked end to end, the second app moves much faster than the first.
If a build is already developed and stuck at submission, send us the rejection text and we can tell you where it is blocked. If you are starting from zero, we can walk the whole release path with you.
Learn more: App Publishing and Release. Or describe your business on the requirements page and get a scope list in seconds.
Tell us what you want to build.
What the product does, which platforms or devices are involved, and your timing. We reply within three working days, in English, with questions or a short written proposal.