·7 min read

App Store Submission for a Privacy-First App: What They Don't Tell You

Real challenges submitting Inner Gallery to the App Store - bundle ID migrations, privacy manifests, iPad compatibility, and the specific hurdles privacy apps face that generic guides skip.

TL;DR

Most App Store guides are generic. None prepare you for the specific challenges of privacy apps: bundle ID decisions, privacy manifest requirements, iPad compatibility without cloud sync, and review strategies when your core value is "we know nothing about your data."

Three weeks ago, I finally clicked "Submit for Review" for Inner Gallery after months of development. This wasn't my first App Store submission, but it was my first for a privacy-first photo vault where the entire value proposition is local-only storage.

The preparation revealed challenges no generic guide covers.

Bundle ID Decisions Matter More Than You Think

My biggest early mistake: I started with com.junglelabs.inner. Studio name first, typical developer naming.

Three months before submission, I realized this was wrong. Inner Gallery needs to exist independently of Jungle Labs. If I sell the app, license it, or simply rebrand the studio, the bundle ID should stay stable.

I migrated to io.innerapp.inner. Product-centric, future-proof. Simple change in Xcode, right?

Wrong.

Bundle ID changes break everything tied to your app identity: TestFlight builds, App Store Connect configurations, code signing certificates, App Groups for share extensions, and CloudKit containers if you use them.

The migration required:

  • New App Store Connect entry from scratch
  • Re-generating all certificates and provisioning profiles
  • Updating App Groups for the share extension
  • Re-testing all device features (biometric auth, file access, inter-app communication)
  • New TestFlight invites for beta testers

Lesson: Choose your bundle ID like you're choosing a domain name. Product-first, not studio-first.

Privacy Manifests: More Than a Checkbox

Apple's privacy manifest requirements became mandatory in 2024. For most apps, it's a simple disclosure. For privacy apps, it's your entire differentiator.

My PrivacyInfo.xcprivacy file:

<key>NSPrivacyCollectedDataTypes</key>
<array></array>
<key>NSPrivacyAccessedAPITypes</key>
<array>
    <dict>
        <key>NSPrivacyAccessedAPIType</key>
        <string>NSPrivacyAccessedAPICategoryUserDefaults</string>
        <key>NSPrivacyAccessedAPITypeReasons</key>
        <array>
            <string>CA92.1</string>
        </array>
    </dict>
</array>

That empty NSPrivacyCollectedDataTypes array? That's the point. Zero data collection, zero analytics, zero tracking. But proving that to Apple's review team required more thought than I expected.

The challenge: how do you demonstrate your app works as intended when your core feature is that you know nothing about how users actually use it?

iPad Compatibility: The Unexpected Requirement

App Store validation flagged Inner Gallery for missing iPad support. I built it iPhone-only intentionally — photo vaults feel more personal on phones.

But Apple's guidelines are clear: new iOS apps should support all device families unless there's a technical limitation.

"I didn't design for iPad" isn't a technical limitation.

Adding iPad support for a local-first app created specific problems:

  • No sync means device silos: photos imported on iPhone stay on iPhone
  • Different interaction patterns: pinch-to-zoom works differently on tablets
  • Screen real estate: photo grids that work on iPhone feel sparse on iPad

My solution: embrace the limitation. iPad becomes a separate, private space. No sync required if you position it as intentional privacy design.

For privacy apps, device isolation isn't a bug — it's a feature. Market device silos as intentional privacy design.

Code Signing for Privacy Apps

Standard code signing works for most apps. Privacy apps need extra attention.

My App Store Connect configuration:

  • Hardened Runtime: Enabled for macOS Catalyst compatibility
  • Automatic signing disabled: Manual control over entitlements
  • App Groups configured: Required for share extension communication
  • No CloudKit: Intentionally excluded to prevent accidental cloud dependencies

The share extension required particular care. It runs in a separate process and needs access to the main app's encrypted storage. App Groups provide the bridge, but the entitlement setup is fragile.

Common failure: the share extension builds but can't communicate with the main app. You discover this during TestFlight testing, not Xcode simulation.

Local Authentication Gotchas

Inner Gallery uses Local Authentication for biometric access. Privacy apps hit specific edge cases:

The double-evaluation bug: iOS can trigger Face ID twice in rapid succession if your app background/foreground events overlap. Users see Face ID, authenticate, then immediately see it again. Confusing and broken-feeling.

My fix: pass a persistent LAContext instead of creating new ones:

private let authContext = LAContext()

func authenticateWithContext() async throws -> Bool {
    return try await authContext.evaluatePolicy(.deviceOwnerAuthentication, 
                                               localizedReason: "Access your private space")
}

Biometric bypass during lockout: If a user enters an incorrect PIN repeatedly, the app locks them out. But biometric auth can still trigger and succeed, bypassing the lockout. Security hole.

Solution: check lockout state before offering biometric options.

Review Strategy: Leading with Privacy

Most apps optimize App Store listings for conversion. Privacy apps face a different challenge: communicating value without being able to show real user data.

My review strategy:

  • Screenshots with demo content: Real gallery views, obviously fake photos
  • Privacy-first copy: Lead with "local storage only" before listing features
  • Clear technical details: Mention CryptoKit, no-network architecture, zero analytics
  • Competitor comparison: Honest comparison with cloud-based alternatives

The hardest part: demonstrating sophisticated features without sophisticated user data. Photo vaults get interesting with hundreds of photos. Demo screenshots with 3 generic images don't convey the experience.

I solved this with technical credibility signals: mention CryptoKit, specify encryption algorithms (ChaCha20-Poly1305), link to architecture documentation.

Privacy apps can't show real usage data. Compensate with technical transparency and architectural clarity.

What Generic Guides Miss

Standard App Store submission advice optimizes for mainstream apps with standard architectures. Privacy-first apps face different trade-offs:

Analytics are forbidden: You can't A/B test onboarding flows or track feature usage. Design decisions rely on intuition and user feedback.

Cloud dependencies break your value prop: SDKs that "phone home" contradict local-first promises. Every third-party integration needs audit.

Error reporting is limited: Crash reports are fine, but user behavior analytics violate privacy principles.

Marketing becomes harder: No usage data means no conversion optimization, no retention analysis, no funnel metrics.

Technical Debt During Submission

My git log from the final submission week:

feat: add privacy manifest and legal section for App Store submission
fix: resolve App Store validation errors for iPad compatibility  
refactor: migrate bundle ID from com.junglelabs to io.innerapp.inner
chore: add code signing and supported orientations for App Store submission

Each line represents hours of work that didn't exist in my original timeline. Technical debt hidden in "just submit to the App Store."

The biggest time sink: iPad compatibility. What started as "add iPad screenshots" became "redesign navigation for tablet interaction patterns."

Mistakes I Made (So You Don't Have To)

Starting bundle ID with studio name: Harder to migrate later, creates business dependencies.

Delaying iPad support: Easier to design universally from the start than retrofit.

Assuming privacy manifests are simple: They're your core differentiator, not a compliance checkbox.

Not testing share extensions on device: Simulator doesn't catch App Group entitlement issues.

Building for iPhone screen sizes only: iPad compatibility requires rethinking layouts, not just stretching them.

What's Next

Inner Gallery is currently "In Review." The waiting period gives time to prepare for post-launch: ASO optimization, user feedback collection (via email, not analytics), and planning the first update.

If you're building privacy-first apps, the submission process reveals design decisions you didn't know you were making. Bundle ID strategy, device compatibility philosophy, privacy manifest storytelling — these shape your product as much as feature decisions.

The App Store review process forces clarity. That's valuable, even when it's frustrating.

Related reading:


Discover Inner Gallery

App Store submissionprivacy appindie deviOS developmentInner Gallerybundle IDprivacy manifest