App Store Connect Missing Compliance: How To Fill In 2026 Encryption Export Information?

The build uploaded successfully, but TestFlight shows Missing Compliance and will not let you continue distribution.

Fastest fix: do not mark every HTTPS app as requiring complex export files, and do not blindly select “no encryption.” Inventory the complete app bundle first. Apple-only encryption usually follows the exemption path; external standard algorithms or non-standard encryption require answers in the App Store Connect questionnaire and may require supporting material. After confirming an exempt case, configure ITSAppUsesNonExemptEncryption in the final Info.plist, then archive and upload a new build.

This guide is for you if you maintain an iOS or macOS app blocked after upload, use HTTPS, Keychain, a login SDK, a payment SDK, or end-to-end encryption, or repeatedly upload builds from a remote Mac or continuous integration system.

SECTION 01What does App Store Connect Missing Compliance actually mean?

Missing Compliance means the uploaded build does not yet have the required export compliance information attached to it. It is not automatically an invalid binary, a code-signing failure, or a build that is still processing. Apple lists build states separately, so check the build status before changing signing settings or rebuilding for unrelated reasons. See Apple’s build status reference.

A useful incident pattern looks like this:

The archive completes successfully.
Upload validation accepts the package.
App Store Connect lists the build.
TestFlight shows a compliance task or missing export information.
The team assumes the binary must be rebuilt, although the unresolved item may be a questionnaire or an unlinked approval.

The decision is based on the encryption present in the uploaded product, not only on the Swift, Objective-C, or configuration files you inspected. Your review must include:

Encryption written by your own application code.
Apple operating system APIs such as networking and Keychain services.
Static libraries and dynamic frameworks embedded in the app.
Login, payment, analytics, messaging, VPN, security, or storage SDKs.
Cryptographic code enabled only in a release configuration.
Encryption included in extensions, helper tools, watch components, or macOS targets.

Apple’s export compliance overview explains that the export review concerns the app submitted for distribution. Treat the archive as the source of truth.

SECTION 02First step: classify the encryption source before answering

Do not start by editing Info.plist. Start with an evidence sheet for the exact build you plan to upload. Record each dependency, its version, whether it contains cryptographic implementation, which feature enables it, and whether the code is included in the release artifact.

The following comparison is the decision tool for the initial triage:

Build scenario	Evidence to collect	Likely App Store Connect route	Release gate
Only Apple-provided encryption services	Network and Keychain usage, dependency inventory, final archive review	Usually an exemption or no-file path, subject to the questionnaire	Save the answers and verify the final `Info.plist`
Third-party SDK with standard cryptographic implementation	SDK documentation, binary contents, enabled features, distribution regions	Complete the questionnaire; determine whether supporting material is required	Keep the SDK evidence with the release record
App-owned standard encryption outside Apple services	Source modules, linked libraries, feature flags, release configuration	Questionnaire-based classification; prepare material if the answers require it	Do not rely on a source-only review
Non-standard algorithm or proprietary protocol	Algorithm description, protocol purpose, technical classification	Treat as a higher-risk review and prepare formal documentation	Obtain professional advice where classification is uncertain
Security is the app’s main commercial purpose	Product function, cryptographic design, storage or communication model	Do not assume an ordinary app exemption	Resolve the regulatory and App Store Connect path before release

This table describes an engineering triage route, not a legal classification. The Apple encryption export compliance documentation and BIS encryption FAQ should be reviewed for the facts relevant to your distribution and product.

Scenario A: the app only uses Apple system encryption

A normal utility app may use HTTPS through Apple networking frameworks, store credentials in Keychain, or rely on other operating system cryptographic services. Those facts alone do not mean you should upload a complex export document.

The important limitation is scope. You must confirm that the app does not also embed an external cryptographic implementation. A business code search for https or Keychain is not enough because a dependency may include encryption in a precompiled framework or activate it only in release builds.

Keep these internal records before answering:

The dependency lockfile or package list for the submitted build.
A short explanation of each security-related feature.
The release configuration and enabled feature flags.
The final archive’s embedded frameworks and extensions.
A screenshot or export of the completed App Store Connect answers, with account details removed.

For this scenario, the operational conclusion is usually: answer the questionnaire according to the Apple-service-only facts, select the applicable exemption path if the questionnaire provides it, and avoid inventing a “no encryption” answer merely because the app does not implement AES or another algorithm directly.

Can an app using only HTTPS and Keychain complete the export questionnaire without uploading a file?
Often, yes, when the complete submitted app relies only on Apple-provided encryption capabilities and falls within the applicable exemption. You still need to answer the questionnaire truthfully and verify third-party components. HTTPS and Keychain are evidence to review, not a universal automatic answer.

Scenario B: a login or payment SDK contains standard cryptography

A third-party login or payment SDK needs a separate review. The fact that your application calls only login() or authorizePayment() does not prove that the SDK is cryptographically irrelevant. A library may implement TLS helpers, certificate pinning, secure token storage, signing, or another security function inside its binary.

For each SDK, ask four concrete questions:

Does the vendor document encryption or cryptographic functions?
Is the implementation inside the binary, or does it only call Apple APIs?
Which functions are enabled in the submitted release?
Where will the app be distributed, including any country-specific route?

Do not classify an SDK from its marketing name. Inspect its documentation, package contents, release notes, and enabled modules. If the vendor supplies a compliance statement, retain it with the build record, but do not treat a vendor statement as a replacement for your own App Store Connect answers.

What should you prepare when a login or payment SDK uses encryption?
Prepare the SDK name and version, the relevant vendor documentation, a plain-language description of the enabled security function, the app’s distribution regions, and any classification or approval information requested by Apple. If the SDK implements standard cryptography outside Apple services, use the questionnaire to determine whether a document is required instead of selecting an exemption by assumption.

The same rule applies to open-source cryptographic libraries. A library included for a single feature can still change the compliance analysis of the complete binary. Review static linking, dynamic embedding, transitive dependencies, and release-only modules.

France may create an additional review question for cryptographic products or services. Do not make an unconditional country-law claim from a generic Apple answer. Review the French authority’s cryptography control guidance and obtain specialist advice when the app’s function or distribution model falls outside a routine case.

Scenario C: proprietary protocols, non-standard algorithms, and security products

A proprietary protocol deserves a more conservative route. The same applies when the app uses an algorithm that is not adopted as a recognized standard, or when secure communication, encrypted storage, VPN functionality, password management, or another security capability is the product’s primary purpose.

Do not try to make the warning disappear by editing a property-list value. Info.plist records an answer about the submitted binary; it does not change the cryptographic implementation or create a regulatory exemption.

You may need to separate several documents and decisions:

An App Store Connect questionnaire answer identifies the encryption characteristics of the submitted build.
An export classification or approval addresses a regulatory classification question.
A CCATS-related process, where applicable, concerns a United States export-control classification and is not a substitute for every other jurisdictional requirement.
A French declaration or filing, where applicable, addresses a separate national process.
Apple’s review of submitted code or metadata is not the same as a government export classification.

The BIS encryption material is useful for understanding the United States control framework, but it does not provide a universal answer for every product, country, or commercial model.

Should you choose “no non-exempt encryption” to bypass a difficult case?
No. If your app includes proprietary encryption, a non-standard algorithm, or a security function that may fall outside a routine exemption, pause the release and collect technical facts. Ask a professional with export-control experience to review the case rather than changing the declaration to match the desired TestFlight status.

SECTION 03How do you resolve the TestFlight task and configure Info.plist?

Once you know which scenario matches the build, process the compliance task against the exact uploaded version.

Second step: open the compliance task for the uploaded build

In App Store Connect, open the app and locate the affected build in the TestFlight area. Use the build’s export compliance action, commonly presented as Provide Export Compliance Information, then answer the questions based on the release artifact.

Apple documents this beta-build workflow in its TestFlight export compliance instructions. If Apple offers the option to associate previously approved material, verify that the material actually covers the app, encryption function, and distribution context of the current build.

Do not reuse an answer merely because the marketing version changed only slightly. A new SDK, enabled feature, new target, or changed cryptographic implementation can alter the evidence.

Third step: decide what `ITSAppUsesNonExemptEncryption` means

The ITSAppUsesNonExemptEncryption key is a build-level declaration. In practical terms:

NO states that the app does not use non-exempt encryption.
YES states that the app uses non-exempt encryption and may require further export compliance handling.
An omitted key does not prove that the app uses no encryption; it can leave App Store Connect without the build-level information needed to reduce repeated questions.

Apple’s property-list key documentation defines the key and its expected values. Use NO only after your inventory supports the exempt conclusion. Do not use it as a shortcut for “the app has no custom cryptography.”

If Apple has issued an approved export compliance code for the applicable case, the relevant ITSEncryptionExportComplianceCode setting may be used as part of the approved workflow. Confirm the current Apple instructions and scope of that code before adding it to a project. An approval code is sensitive release information; never paste it into public issue reports or unredacted CI logs.

Fourth step: inspect the final archive, not just the project editor

A common failure occurs when the developer changes a build setting or source configuration but uploads an archive created before the change. Another occurs when the key is present in the source project but absent from the target that produced the final app.

Use this sequence:

Update the release target’s Info.plist or the build setting that generates it.
Confirm the value is applied to the target that will be archived.
Create a fresh archive.
Inspect the archived app’s final Info.plist.
Confirm the expected value exists in the submitted product.
Upload the new archive.
Reopen the new build’s compliance task in App Store Connect.
Verify TestFlight availability after processing and compliance handling.

Apple’s build upload guidance is the reference for the upload stage. The key point is that changing the repository is not the same as changing the already uploaded binary.

Why does a new build still ask for encryption information after Info.plist was configured?
The usual causes are a stale archive, the key being added to the wrong target, a different release configuration, an extension with its own property list, or a changed dependency that alters the compliance answers. Inspect the final archive and compare it with the build number shown in App Store Connect. If the questionnaire still applies to the actual encryption content, the key cannot remove that obligation.

SECTION 04What should your release gate check before TestFlight distribution?

Treat compliance as one release gate alongside signing, artifacts, and upload status. This is particularly important when a remote Mac or CI job performs repeated archives, because a successful command-line upload can still leave a manual App Store Connect task unresolved.

Use this five-part runbook for every material release change:

Freeze the dependency inventory. Record package versions, embedded frameworks, extensions, and release-only modules.
Review encryption behavior. Map HTTPS, Keychain, secure storage, SDK security functions, custom protocols, and cryptographic libraries to actual code paths.
Inspect the archive. Verify the bundle identifier, release configuration, embedded components, and final Info.plist values. Remove account identifiers and private paths from any shared record.
Check both upload routes. If you support graphical and automated uploads, confirm that both point to the same archive and that the resulting build number is the one reviewed.
Validate the distribution state. Confirm that the build is no longer waiting for missing compliance information and that the intended TestFlight group can access it before declaring the release complete.

Your acceptance result should fall into one of three operational outcomes:

Questionnaire complete: no additional file is required for this build, and TestFlight can proceed after normal processing.
Configuration stabilized: the confirmed exempt answer is represented in the final archive, reducing repeated manual questions on later uploads.
Materials pending: the build requires an approval, classification, or other document, so publishing waits for the applicable review rather than relying on a misleading property-list value.

Never expose these items in remote Mac screenshots, terminal output, or CI artifacts:

Apple account email addresses.
Bundle IDs tied to production apps.
App Store Connect API keys.
Export approval codes.
Private SDK names or internal repository paths.
Unredacted upload logs.

If you are moving this workflow to a hosted Mac, separate the compliance evidence from the machine-access credentials. A remote build host can reproduce an archive and upload, but it cannot make an uncertain encryption classification legally correct.

SECTION 05Is a remote Mac useful for this compliance workflow?

A remote Mac is useful when you need a repeatable Xcode archive, a controlled release configuration, and a persistent environment for TestFlight uploads without buying a separate local machine. It does not replace the encryption inventory, App Store Connect questionnaire, or regulatory review.

The current alternative has real drawbacks. A Windows or Linux workstation cannot run the native Xcode archive workflow locally; a temporary shared build environment can hide which dependency produced the final artifact; and a self-managed Mac used only for releases adds hardware, patching, access control, and recovery work. A hosted Mac can make the technical part of the process easier to repeat, especially when your team needs a stable macOS environment for archives and uploads.

Before choosing a rental, compare the required access method, persistent storage, signing-secret handling, and session recovery process. You can review MACNOX pricing options for a hosted Mac route, or inspect the MACNOX remote Mac ordering options when you need to provision an environment for a specific release window. The service is a fit for temporary release work, migration, or recurring TestFlight builds; a dedicated owned Mac may still be better for permanent heavy workloads or projects that require direct physical hardware access.

Once the questionnaire answers and final Info.plist are confirmed, continue with a redacted archive, upload, and TestFlight distribution check. That final pass shows whether your signing assets, compliance information, and automation produce the same result on every release rather than merely making the current warning disappear.