Guide
How to answer App Store export compliance for encryption
Answer App Store Connect export compliance questions correctly: when encryption documentation applies, common HTTPS cases, and how Helm surfaces compliance before you ship.Export compliance is the encryption documentation step App Store Connect requires for many builds before TestFlight or App Store distribution. A missing answer is a classic blocker: the build is processed, testers are waiting, and nothing can go out. This guide explains what the questions are asking, when you need extra documentation, and how Helm releases keep compliance visible in the ship path.
What Apple is asking
In plain terms:
- Does your app use encryption?
- Is that encryption only exempt / standard uses (often including HTTPS), or do you implement something that needs documentation?
- Have you provided any required documents for your case?
Exact question wording and available answers change over time in App Store Connect. Always read the current prompts for the build. This guide is operational guidance, not legal advice.
Common app situations
Mostly HTTPS and platform crypto
Many apps only use HTTPS and standard OS cryptography APIs. They often qualify for standard exemptions, but you must still answer honestly based on what the binary includes. Do not copy a teammate’s answers from another app without checking.
Custom cryptography
If you ship proprietary protocols, custom ciphers, or specialized crypto modules, assume you need a careful review with counsel and Apple’s current documentation. Guessing here is how apps get stuck or misdeclared.
No encryption at all
Some builds truly use no encryption. Helm includes clearer compliance settings, including a No Algorithm path when that matches your situation. Only choose it when it is accurate.
When the answers are required
You typically confront export compliance when:
- A new build finishes processing and TestFlight distribution is blocked
- You try to submit a version for App Review
- Apple requires a fresh declaration after capability or build changes
Bake the decision into your launch checklist so it is not rediscovered under Friday-night pressure. See prepare a launch checklist.
Practical workflow for teams
- Decide once per crypto posture. Document whether you are “standard HTTPS / exempt,” “docs required,” or “no encryption.”
- Store the rationale. A short internal note beats tribal knowledge when someone new uploads a build.
- Apply answers promptly after each upload that needs them.
- Revisit when crypto changes. Adding a custom VPN-like feature or new secure channel is a trigger to reassess.
- Escalate edge cases. Regulated industries and proprietary crypto deserve counsel, not Slack polls.
TestFlight and App Store both care
Missing compliance blocks TestFlight external progress and storefront submission alike. If you are preparing an external beta, finish compliance before you submit for Beta App Review. If you are storefront-bound, finish it before you submit for App Review.
How Helm helps
Helm surfaces export compliance in the release path with enhanced settings so the requirement sits next to build selection, What’s New, and review info. The launch checklist flags encryption gaps before you submit. The goal is clarity: see the blocker early instead of discovering it when invites fail.
Compliance answers still come from your knowledge of the binary. Helm makes the step harder to miss. It does not invent a legal position for you.
Checklist
- Crypto posture documented for the app
- Current build questions answered in ASC or Helm
- Docs uploaded if your case requires them
- Team knows who owns re-answers after crypto changes
- Compliance checked on the launch checklist before submit
- Counsel involved when custom cryptography is in play
