Flutter — Releasing to the App Store

This guide walks through releasing a Flutter app that uses Sankofa Deploy to the Apple App Store. The most important step — easy to miss, hard to recover from — is the Xcode checkbox in §3.

1. Build the release

Bump your pubspec.yaml version (e.g. version: 1.0.4+1), then run:

sankofa release ios

# Flavored app (gradle flavors + per-flavor entrypoint):
sankofa release ios --flavor production -t lib/main_production.dart

This produces a signed .ipa at build/ios/ipa/ (plus the .xcarchive at build/ios/archive/Runner.xcarchive) and registers the release with Sankofa under the version + build number from your pubspec.yaml. The .ipa is the binary you submit to App Store Connect — Sankofa stores only the release record and serves your patches. The version + build number ARE the patch addressing key, so any later patch must target the same 1.0.4+1 you set here.

For uncodesigned builds (CI farms that sign elsewhere), pass --no-codesign — it builds just the .xcarchive for you to sign + export in Xcode.

2. Upload to App Store Connect

Three equivalent options — pick whichever your workflow already uses.

3. The Xcode checkbox that breaks patches

The Sankofa CLI prints this same warning at the end of every sankofa release ios run; it is duplicated here because the upload step is where customers actually hit the dialog.

4. App Store Connect — privacy and encryption answers

App Store Connect will ask you two questions during the listing. Both have the same answers for every Sankofa Deploy–enabled Flutter app:

4.1 Encryption export compliance

Add this to your ios/Runner/Info.plist:

<key>ITSAppUsesNonExemptEncryption</key>
<false/>

Sankofa uses only TLS (built into iOS) and signature verification (authentication, not encryption — categorically exempt under US export rules). Setting this key to false bypasses the annual self-classification questionnaire on every upload.

If your app uses additional encryption beyond what Sankofa adds, set this to true and complete the classification flow per Apple's instructions.

4.2 Privacy Manifest

The sankofa_flutter package ships a Privacy Manifest (PrivacyInfo.xcprivacy) declaring exactly two Required-Reason API categories:

The Sankofa SDK's bundled framework also ships a slice-level manifest covering only FileTimestamp. Apple's App Store Connect validator (ITMS-91061 / ITMS-90683) will pass on a clean Sankofa-only app.

If you add other SDKs that use Required-Reason APIs (analytics, advertising, etc.), each one ships its own manifest — your app's combined manifest is the union.

5. Submit for review

In App Store Connect, attach the uploaded build to your release, fill in screenshots and metadata, and submit.

Sankofa Deploy patches are not reviewed by Apple — they update the Dart layer of your already-reviewed app under the over-the-air update provisions Apple's guidelines permit. What you submit for review is the base binary; patches modify the Dart layer of the already-reviewed app. As long as your patches don't change the app's primary purpose (no new categories of feature, no covert storefront), this is the same compliance posture over-the-air update tools have shipped under for years.

6. Ship a patch

Once your release is approved and in production:

# Edit Dart code, then:
sankofa patch ios

Devices on the matching release version (1.0.4+1 in this example) will pick up the patch on the next app launch. No App Store review, no waiting period, no version bump.

Troubleshooting

See also

• Deploy product overview
• Flutter SDK overview
• Apple App Store Review Guideline 2.5.2
• Apple TN3183 — Required Reason API entries