iOS privacy manifest guidance for precompiled SQLite in sqlite3 3.5.1

[KS3005]

We use Dart sqlite3 3.5.1 with Flutter/Drift on iOS. Our Release output contains sqlite3.framework, reports SQLite 3.53.4 in its binary strings, and imports statfs/fstatfs and stat/fstat/lstat. We found no PrivacyInfo.xcprivacy inside this framework.

Could you confirm the source revision and relevant compilation flags used for the precompiled iOS arm64 binary, and whether there is a supported privacy manifest integration or documented guidance for these APIs?

The corresponding upstream os_unix.c appears to use statfs/fstatfs for filesystem type/mount flags rather than disk capacity. We are seeking clarification from Apple rather than assuming E174.1 applies. Are there existing upstream discussions or supported build options addressing this? We do not want to alter database locking behavior or replace the database engine without assessing data safety and compatibility.

This is a pre-submission review, not a reported App Store rejection.

[simolus3]

Could you confirm the source revision and relevant compilation flags used for the precompiled iOS arm64 binary

All binaries are built in GitHub actions and have SLSA level 3 attestations as well as a CycloneDX SBOM you can use to inspect the version. For version 3.5.1 of this package, that is indeed 3.53.4 (source), compiled with these flags.

supported privacy manifest integration or documented guidance for these APIs

This package doesn't ship the XCFramework directly, it only contributes the inner .dylib files which Flutter then merges into a framework.

In this mechanism, there is no way for us to add additional files like a privacy manifest unfortunately (dart-lang/native#878 is the issue tracking that).

Another possible approach (which requires careful testing though) is using the system's SQLite version instead of bundling one with your app, which can be done by adding this to your pubspec (docs):

hooks:
  user_defines:
    sqlite3:
      source:
        default: sqlite3
        ios: system

This removes the framework from your app, but requires testing on older iOS versions to make sure you don't accidentally depend on newer SQLite features. It'll likely be fine though.

[KS3005]

Thank you for the detailed explanation and the links. This clarifies the SQLite version, build configuration, and the current limitation around including privacy manifests.

We will assess compatibility with system SQLite on iOS before changing our configuration, particularly on the oldest iOS version we support. We will also test existing database reads/writes, migrations, and backup/restore using test data.

In parallel, we are seeking clarification from Apple about the required-reason declaration for the bundled library. We will share any relevant guidance we receive.

Thank you again for your help!

[simolus3]

I also checked the reason codes we have available, and it looks like it's tricky to find a matching one:

1. For NSPrivacyAccessedAPICategoryFileTimestamp (stat), we can probably use C617.1 ("Declare this reason to access the timestamps, size, or other metadata of files inside the app container, app group container, or the app’s CloudKit container.") and 3B52.1 ("Declare this reason to access the timestamps, size, or other metadata of files or directories that the user specifically granted access to, such as using a document picker view controller.") since we wouldn't access any other files.
2. For NSPrivacyAccessedAPICategoryDiskSpace (statvfs), it's more challenging. The reason SQLite invokes that is to pick a locking method specific to the file system in use (and to skip locks on read-only filesystems, which is not applicable here). No reason code matches this at all.

Do you have more details from the pre-submission review you could share?

[KS3005]

Thank you for checking the reason codes and explaining the locking behavior.

To clarify, by “pre-submission review” I meant our own local checks before submitting the app—not a review performed by Apple. We have not submitted this build to App Store Connect, and we have not received an Apple validation warning or rejection.

Our findings came from inspecting an unsigned iOS Release build:

• The bundled sqlite3.framework imports stat, fstat, lstat, statfs, and fstatfs, as reported by nm -u.
• We did not find a PrivacyInfo.xcprivacy inside that framework.
• We then compared the corresponding SQLite source with Apple's published required-reason categories.

These were static checks, not a runtime trace of every API call. In our binary, the filesystem-related imports we observed were statfs and fstatfs, rather than statvfs.

We have contacted Apple Developer Support to ask which declaration, if any, applies to this filesystem-type/locking use case, but have not received a reply yet. We will share their response when it arrives.

Thank you again for investigating this. We are also assessing the system-SQLite alternative you suggested, but have not switched our app to it yet.