Flutter iOS Privacy Manifest Errors: How to Fix App Store Connect Rejections

If a Flutter iOS build is rejected or warned about a privacy manifest, do not start by adding random __INLINE_CODE_0__ keys until App Store Connect becomes quiet.

Apple validates privacy manifests at the app and SDK bundle level. A failure can come from your own iOS target, a Flutter plugin, a binary SDK, a malformed privacy manifest, or a required-reason API that has no approved reason declared in the bundle that actually uses it.

That distinction matters because a privacy manifest in the Runner target cannot automatically repair every third-party framework.

A reliable diagnosis looks like this:

text

App Store Connect message
        ↓
Identify the exact bundle/path
        ↓
Inspect the built archive
        ↓
Validate PrivacyInfo.xcprivacy
        ↓
Check required-reason APIs
        ↓
Upgrade or fix the responsible plugin/SDK
        ↓
Rebuild archive
        ↓
Validate before upload

This guide focuses on that workflow for Flutter applications.

What is __INLINE_CODE_0__?

__INLINE_CODE_0__ is Apple's privacy manifest file.

Apple's privacy manifest documentation says the manifest can describe:

data collected by an app or SDK
required-reason APIs used by an app or SDK
whether tracking occurs
tracking domains

The file is a property list and must be named:

text

PrivacyInfo.xcprivacy

For Flutter teams, privacy manifests can exist in more than one place:

text

Runner.app
├── PrivacyInfo.xcprivacy
├── Frameworks/
│   ├── SomePlugin.framework/
│   │   └── PrivacyInfo.xcprivacy
│   └── AnotherSDK.framework/
│       └── PrivacyInfo.xcprivacy
└── ...

This is the first important concept:

There is not necessarily one privacy manifest for the entire Flutter application.

Your application may have its own manifest while individual SDKs or plugin bundles have their own manifests.

Why can a Flutter app still fail when __INLINE_CODE_0__ exists?

Because Apple evaluates the component that uses the API.

Apple's required-reason API guidance states that if a required-reason API is used by a third-party SDK, that SDK needs to report the use in its own privacy manifest. A third-party SDK cannot simply rely on the host application's privacy manifest to declare its API usage.

That creates two different cases.

Your app code uses a required-reason API

For example, custom Swift/Objective-C code inside the Runner target accesses an API category covered by Apple's required-reason policy.

Then the application's privacy manifest needs the appropriate declaration.

A Flutter plugin or native SDK uses the API

Then that plugin/SDK's own packaged privacy manifest needs to declare the use.

Adding the same reason to:

text

ios/Runner/PrivacyInfo.xcprivacy

may not solve the SDK-level problem.

That is why the path included in Apple's validation message is valuable.

Step 1: read the exact App Store Connect error

Do not reduce every privacy-manifest problem to:

"Apple wants a privacy file."

The exact message tells you which class of failure you have.

Invalid privacy manifest

Apple documents errors such as:

text

ITMS-91056: Invalid privacy manifest

Apple's TN3181 troubleshooting note explains that this occurs when the manifest is malformed or contains keys/values App Store Connect does not accept.

This is a manifest validity problem.

Missing required-reason declaration

Another class of failure occurs when code uses an API Apple classifies as a required-reason API but the responsible bundle does not declare an approved reason.

This is an API-use declaration problem.

Third-party SDK requirement

Apple maintains a current list of third-party SDKs that require privacy manifests and signatures.

The list includes SDKs and Flutter-adjacent dependencies such as:

__INLINE_CODE_0__
__INLINE_CODE_0__
AppAuth
BoringSSL / __INLINE_CODE_0__
Firebase-related dependencies
Facebook SDK components
other commonly used native libraries

If the rejection points into a framework or plugin bundle, investigate that dependency before editing the Runner manifest.

Step 2: inspect the actual release archive, not only your source tree

A source repository can contain a perfectly good manifest that never reaches the final app bundle.

The archive is what Apple validates.

Build an iOS archive through your normal Flutter/Xcode release path, then inspect it.

A typical Flutter release build can begin with:

bash

flutter build ipa --release

or through Xcode's Archive workflow.

If you have an __INLINE_CODE_0__, inspect:

text

YourApp.xcarchive/
└── Products/
    └── Applications/
        └── YourApp.app/

Search for privacy manifests:

bash

find "/path/to/YourApp.xcarchive/Products/Applications/YourApp.app" \
  -name "PrivacyInfo.xcprivacy" -print

That tells you which manifests were actually bundled.

This is far more useful than asking:

"Does my Flutter project contain a privacy manifest somewhere?"

The real question is:

Which bundle inside the shipped app contains the privacy manifest Apple expects?

Step 3: validate every manifest as a property list

Apple recommends __INLINE_CODE_0__ for basic validation.

Run:

bash

plutil -lint PrivacyInfo.xcprivacy

For every manifest in the archive:

bash

find "/path/to/YourApp.app" -name "PrivacyInfo.xcprivacy" -print0 |
while IFS= read -r -d '' file; do
  echo "Checking: $file"
  plutil -lint "$file"
done

A successful syntax check produces an __INLINE_CODE_0__ result.

But this only verifies that the file is a valid property list.

Apple explicitly notes that a manifest can still fail App Store validation if the keys or values are not allowed.

So validation has two levels:

text

Valid plist syntax
        ↓
Valid Apple privacy-manifest schema

Both need to pass.

What does a privacy manifest look like?

A simplified manifest may contain keys such as:

xml

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN"
  "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>NSPrivacyTracking</key>
    <false/>

    <key>NSPrivacyCollectedDataTypes</key>
    <array/>

    <key>NSPrivacyAccessedAPITypes</key>
    <array>
        <!-- required-reason declarations -->
    </array>
</dict>
</plist>

Do not copy this blindly into production.

The contents must describe what your application or SDK actually does.

An empty array is not automatically appropriate, and inventing a reason merely to satisfy validation can violate Apple's policy.

Step 4: understand required-reason APIs

Apple created required-reason APIs because certain low-level device signals can be misused for fingerprinting.

Examples of covered categories include APIs relating to:

user defaults
file timestamps
disk-space information
system boot time
active keyboard information

The exact API categories and approved reasons should always come from Apple's current required-reason API documentation.

A declaration conceptually looks like:

xml

<key>NSPrivacyAccessedAPITypes</key>
<array>
    <dict>
        <key>NSPrivacyAccessedAPIType</key>
        <string>API_CATEGORY</string>

        <key>NSPrivacyAccessedAPITypeReasons</key>
        <array>
            <string>APPROVED_REASON_CODE</string>
        </array>
    </dict>
</array>

The reason code is not a free-text explanation.

It must be one of Apple's approved values for that API category and it must accurately describe the way the API is used.

A technically valid reason code that does not match your actual use is not a legitimate fix.

Step 5: identify whether the API comes from your code or a Flutter plugin

This is the part that often turns a five-minute App Store warning into an afternoon of guessing.

Start with the path in Apple's message.

If it points to:

text

YourApp.app/PrivacyInfo.xcprivacy

investigate the main app bundle.

If it points to:

text

YourApp.app/Frameworks/SomeSDK.framework/PrivacyInfo.xcprivacy

or another embedded bundle, investigate the corresponding SDK/plugin.

Then inspect your dependency tree.

Useful Flutter commands:

bash

flutter pub deps
flutter pub outdated

For CocoaPods-based iOS projects, also inspect:

text

ios/Podfile.lock

A Flutter package can pull in a native iOS dependency indirectly.

For example:

text

Flutter package
      ↓
iOS implementation package
      ↓
CocoaPod / framework
      ↓
Required-reason API

The package named in __INLINE_CODE_0__ may not be the bundle named in App Store Connect.

Step 6: upgrade plugins before hand-patching their installed files

If an upstream package has already fixed its privacy manifest, upgrade it rather than editing a cached plugin copy.

This matters because Flutter plugin packages have had real privacy-manifest fixes.

For example, the current __INLINE_CODE_0__ changelog records a fix for a missing iOS/macOS privacy manifest in version 6.1.3.

The __INLINE_CODE_0__ changelog records earlier privacy-manifest additions and later path fixes.

A practical sequence is:

bash

flutter pub outdated

Then investigate the affected plugin:

text

Current version
      ↓
Plugin changelog
      ↓
Was privacy manifest added/fixed later?
      ↓
Upgrade if compatible
      ↓
flutter clean
      ↓
flutter pub get
      ↓
reinstall iOS dependencies if required
      ↓
rebuild archive

Do not make permanent edits inside:

text

~/.pub-cache/

or generated Pods as your main solution.

Those edits disappear when dependencies are refreshed and are difficult to reproduce in CI.

Step 7: if you own the plugin, bundle the manifest correctly

For private or in-house Flutter plugins, having __INLINE_CODE_0__ in the repository is not enough.

It must be included as a resource in the plugin's iOS packaging.

Flutter's current plugin development documentation shows privacy manifests being included as resources for native plugin packaging.

For CocoaPods, a plugin can expose a resource bundle from its podspec.

Conceptually:

ruby

s.resource_bundles = {
  'your_plugin_privacy' => [
    'path/to/PrivacyInfo.xcprivacy'
  ]
}

Flutter's newer Swift Package Manager plugin guidance similarly requires the resource to be processed in __INLINE_CODE_0__.

Conceptually:

swift

resources: [
    .process("PrivacyInfo.xcprivacy"),
]

After changing plugin packaging, verify the archive, not just the plugin source folder.

Step 8: remember that Apple has a special third-party SDK list

Some SDKs receive additional scrutiny.

Apple's third-party SDK requirements state that listed SDKs must include privacy manifests, and signatures are required when applicable as binary dependencies.

The important operational consequence is:

Updating your Flutter application may introduce a new version of a native SDK that changes your App Store privacy obligations.

Therefore privacy validation should be part of release maintenance, not a one-time project setup task.

Before a major dependency upgrade, review:

newly added plugins
newly added iOS implementation packages
binary frameworks
advertising/analytics SDKs
authentication SDKs
payment SDKs
Firebase/Google dependencies
social login SDKs

Then compare them with Apple's current requirements.

Step 9: distinguish privacy manifests from App Store privacy labels

These are related but not identical.

Privacy manifest

Lives inside the application/SDK bundle:

text

PrivacyInfo.xcprivacy

It describes required-reason APIs and certain privacy practices at the binary/resource level.

App Privacy information

Configured in App Store Connect.

This is the information users see in the App Store privacy section.

A valid privacy manifest does not automatically mean your App Store privacy answers are correct.

And updating App Store Connect privacy answers does not repair a missing required-reason API declaration in a framework.

Think of them as separate layers:

text

Code / SDK behaviour
        ↓
Privacy manifests
        ↓
App Store validation
        ↓
App Store Connect privacy disclosures

They should be consistent, but they are not interchangeable.

Step 10: generate an Xcode privacy report before submission

Xcode can aggregate privacy information from the app and its dependencies into a privacy report.

This is useful because a Flutter app may contain several manifests scattered across Runner, Flutter framework, plugins, CocoaPods, Swift packages and embedded native SDKs.

Use it as a release review tool rather than waiting for App Store Connect to become your first validator.

A good release process is:

text

Dependency update
      ↓
Build archive
      ↓
Inspect bundled manifests
      ↓
Generate privacy report
      ↓
Validate manifests
      ↓
Review App Store privacy disclosures
      ↓
Upload

A diagnosis matrix for Flutter privacy-manifest failures

Symptom	Best next check
__INLINE_CODE_0__	Run __INLINE_CODE_0__, then verify Apple-supported keys and values
Error path points to Runner	Inspect the app-level __INLINE_CODE_0__
Error path points to a framework	Upgrade/fix that plugin or SDK's own manifest
Manifest exists in source but Apple says it is missing	Inspect the final __INLINE_CODE_0__ resource packaging
Warning appeared after adding a plugin	Check the new plugin's iOS implementation and native SDKs
Old plugin version fails but current version does not	Review changelog and upgrade
Local edit works until __INLINE_CODE_0__	You patched generated/cache files instead of the source dependency
App manifest declares reason but framework still fails	The SDK may need its own declaration
Plist is valid but App Store rejects it	Keys/reason values may be unsupported or mismatched
Privacy label looks right but upload fails	App Store privacy labels do not replace bundled manifests

A safer fix workflow

1. Preserve the exact Apple error

Save the ITMS code, failing file path, framework/bundle name, build number and upload timestamp.

Do not troubleshoot from memory.

2. Reproduce from a clean release build

bash

flutter clean
flutter pub get
flutter build ipa --release

If the application uses CocoaPods, ensure the lockfile and Pods state match the intended release configuration.

3. Inventory all bundled manifests

bash

find "/path/to/YourApp.app" -name "PrivacyInfo.xcprivacy" -print

4. Validate every manifest

bash

plutil -lint "/path/to/PrivacyInfo.xcprivacy"

5. Map the failing bundle to the Flutter dependency

Use:

bash

flutter pub deps

and inspect __INLINE_CODE_0__ where appropriate.

6. Check the current plugin release

Look for privacy-manifest additions, resource-path fixes, CocoaPods resource-bundle fixes, Swift Package Manager resource fixes, or native SDK upgrades.

7. Fix the real owner of the manifest

Use one of:

app-level manifest update
plugin upgrade
private plugin packaging fix
native SDK upgrade
replacement of an unmaintained dependency

8. Rebuild from clean state

Do not reuse an archive that contains the old framework.

9. Re-inspect the archive

Confirm the correct __INLINE_CODE_0__ exists in the correct bundle.

10. Upload a new build number

App Store Connect validates the uploaded binary. A source-code fix has no effect until a new artifact is submitted.

What not to do

Do not paste every approved reason into the manifest

More declarations are not inherently safer.

Each reason is supposed to describe actual API use.

Do not invent data collection declarations

The manifest is not a place to add every conceivable category "just in case."

Do not patch only __INLINE_CODE_0__

That creates a local snowflake build that your CI or another developer may not reproduce.

Do not confuse a plugin's Dart code with its native implementation

The iOS privacy issue may live in __INLINE_CODE_0__, a CocoaPod, Swift package, or binary framework pulled in underneath the Dart package.

Do not assume the newest Flutter version fixes every plugin

Flutter can provide its own privacy metadata, but third-party plugins remain responsible for their own native behaviour and packaging.

Do not silence App Store errors without understanding the API reason

Privacy manifests are policy declarations, not compiler flags.

How can CI catch this before App Store Connect?

A basic release check can verify that privacy manifests exist and are valid property lists.

bash

APP_PATH="/path/to/YourApp.app"

mapfile -d '' manifests < <(
  find "$APP_PATH" -name "PrivacyInfo.xcprivacy" -print0
)

if [ "${#manifests[@]}" -eq 0 ]; then
  echo "No privacy manifests found"
fi

for manifest in "${manifests[@]}"; do
  echo "Validating $manifest"
  plutil -lint "$manifest" || exit 1
done

That will not prove policy compliance.

It catches malformed plist files, resources that disappeared from packaging, and obvious release inconsistencies.

For a mature app, you can also maintain an expected-manifest inventory for critical SDKs and fail CI if a required privacy resource disappears after a dependency upgrade.

Should you create a privacy manifest for every Flutter app?

The correct answer is based on the APIs and privacy practices in the shipped binary, not on Flutter alone.

Current Flutter itself includes privacy-manifest support, and Flutter's plugin authoring documentation explicitly accounts for plugins that need their own __INLINE_CODE_0__.

But your application may still need its own manifest if your own target uses required-reason APIs or needs to describe applicable privacy behaviour.

Likewise, every third-party SDK does not automatically require a custom manifest written by you. Maintained SDKs should package their own declarations where required.

The right model is:

text

Each component
      ↓
Declares the privacy/API use it owns
      ↓
Final application bundle
      ↓
Aggregated privacy picture

FAQs

Why is App Store Connect rejecting my Flutter app even though I added __INLINE_CODE_0__?

Because the failing API or invalid file may belong to a third-party framework rather than the Runner target. Use the path in Apple's error message and inspect the final archive to identify the responsible bundle.

What is __INLINE_CODE_0__?

Apple documents __INLINE_CODE_0__ as an invalid privacy manifest error. The file may be malformed or contain privacy-manifest keys or values App Store Connect does not accept.

Can my Runner privacy manifest declare required-reason APIs for Flutter plugins?

Not always. Apple says third-party SDKs that use required-reason APIs need to declare that use in the SDK's own privacy manifest rather than relying on the host application's manifest.

Do __INLINE_CODE_0 and INLINE_CODE_1__ need privacy manifests?

Apple's current third-party SDK requirements list includes both __INLINE_CODE_0__ and __INLINE_CODE_1__. Maintained versions of these plugins have also included privacy-manifest fixes in their changelogs. Check the version actually bundled in your application rather than assuming every historical version packages the manifest correctly.

Should I edit the plugin inside __INLINE_CODE_0__ to fix the rejection?

Not as the permanent fix. Upgrade the package, fork it, or repair the plugin source you control. Cache edits are fragile and usually disappear when dependencies are restored.

Is a privacy manifest the same as the App Store privacy label?

No. The manifest is bundled with your app/SDK and describes required-reason APIs and related privacy information. App Store privacy disclosures are configured separately in App Store Connect.

Conclusion

Flutter privacy-manifest failures become much easier to debug once you stop treating the app as one binary with one privacy file.

A real Flutter iOS release is an assembled product:

text

Runner
+
Flutter framework
+
plugins
+
CocoaPods
+
Swift packages
+
binary SDKs

Any of those components can introduce a privacy manifest, required-reason API, or validation problem.

So debug from the App Store error path back to the owning bundle, not from your __INLINE_CODE_0__ forward by guesswork.

The reliable sequence is:

text

Read Apple's exact error
→ inspect the archive
→ validate the manifest
→ identify the responsible component
→ upgrade or fix that component
→ rebuild cleanly
→ verify the final bundle
→ resubmit

That approach solves the rejection without turning __INLINE_CODE_0__ into a bag of copied reason codes nobody understands.

Need help getting an existing Flutter application through iOS release, dependency and App Store validation issues? Softotic's mobile app development service can handle Flutter/iOS release troubleshooting, while custom software development can support native integrations or private plugin work that needs deeper changes.

Flutter iOS Privacy Manifest Errors: How to Fix App Store Connect Rejections

Flutter iOS Privacy Manifest Errors: How to Fix App Store Connect Rejections

What is __INLINE_CODE_0__?

Why can a Flutter app still fail when __INLINE_CODE_0__ exists?

Your app code uses a required-reason API

A Flutter plugin or native SDK uses the API

Step 1: read the exact App Store Connect error

Invalid privacy manifest

Missing required-reason declaration

Third-party SDK requirement

Step 2: inspect the actual release archive, not only your source tree

Step 3: validate every manifest as a property list

What does a privacy manifest look like?

Step 4: understand required-reason APIs

Step 5: identify whether the API comes from your code or a Flutter plugin

Step 6: upgrade plugins before hand-patching their installed files

Step 7: if you own the plugin, bundle the manifest correctly

Step 8: remember that Apple has a special third-party SDK list

Step 9: distinguish privacy manifests from App Store privacy labels

Privacy manifest

App Privacy information

Step 10: generate an Xcode privacy report before submission

A diagnosis matrix for Flutter privacy-manifest failures

A safer fix workflow

1. Preserve the exact Apple error

2. Reproduce from a clean release build

3. Inventory all bundled manifests

4. Validate every manifest

5. Map the failing bundle to the Flutter dependency

6. Check the current plugin release

7. Fix the real owner of the manifest

8. Rebuild from clean state

9. Re-inspect the archive

10. Upload a new build number

What not to do

Do not paste every approved reason into the manifest

Do not invent data collection declarations

Do not patch only __INLINE_CODE_0__

Do not confuse a plugin's Dart code with its native implementation

Do not assume the newest Flutter version fixes every plugin

Do not silence App Store errors without understanding the API reason

How can CI catch this before App Store Connect?

Should you create a privacy manifest for every Flutter app?

FAQs

Why is App Store Connect rejecting my Flutter app even though I added __INLINE_CODE_0__?

What is __INLINE_CODE_0__?

Can my Runner privacy manifest declare required-reason APIs for Flutter plugins?

Do __INLINE_CODE_0__ and __INLINE_CODE_1__ need privacy manifests?

Should I edit the plugin inside __INLINE_CODE_0__ to fix the rejection?

Is a privacy manifest the same as the App Store privacy label?

Conclusion

Sources and references

Do __INLINE_CODE_0 and INLINE_CODE_1__ need privacy manifests?