Privacy answers and SDK creep
Privacy work feels optional during feature weeks. It becomes urgent exactly when you wanted to ship. Solo founders don’t need a legal department — they need a living store-facts doc.
Why this burns solo founders
In a team, someone owns compliance leftovers. Alone, you are engineering, support, and App Store ops. SDKs accumulate quietly: analytics “just for funnels,” a crash reporter, a paywall, a free trial helper. Each one can change purpose strings, tracking stance, nutrition labels, or reviewer questions.
Failure mode: upload-day archaeology
Guessing is the bug. The fix is boring documentation kept close to the code that causes the answers to change.
The store-facts doc (minimum viable)
Keep one markdown file in the repo. Update it whenever packages change.
- App name / bundle id / primary category
- Account/sign-in model (none, Sign in with Apple, email, etc.)
- Permissions actually used (camera, mic, contacts, tracking, etc.)
- Purpose string inventory (key → why → where shown)
- Third-party SDKs list (name, why, data collected, docs link)
- ATT / tracking stance
- Privacy Nutrition Label answers summary
- Export compliance answer
- Last reviewed date + git SHA
Template: store-facts-template.md
SDK creep patterns to watch
- “Temporary” analytics that never leave.
- Paywall SDK that brings its own network/identity surface.
- Crash tooling extras enabled by default.
- Copy-pasted pods from a tutorial, never audited.
- SDK major bumps between TestFlight and App Store candidate.
Preflight when dependencies change
- Diff Package.resolved / Podfile.lock / SPM list since last shipped build.
- For each new/updated package: why is it here, what data can it touch, is it in store-facts?
- Re-read purpose strings against actual API usage in code.
- Re-check tracking stance if anything advertising/measurement-related appeared.
- Note reviewer-facing implications in the next release log.
# Examples — adapt to your package manager git log -p -- Package.resolved | head xcodebuild -resolvePackageDependencies
What not to do
- Don’t invent privacy answers under time pressure.
- Don’t claim “no tracking” if an SDK measurement path is on.
- Don’t treat nutrition labels as a one-time wizard you never revisit.
- Don’t wait for Connect to educate you about your own binary.
Copy/paste privacy preflight
- STORE_FACTS.md exists and dated.
- SDK list matches the archive you are about to upload.
- Purpose strings compile and match real features.
- Nutrition/tracking answers reviewed if packages changed.
- Export compliance answer known without guessing.
- Release log notes any privacy-affecting dependency change.