"Missing API declaration" warning from Apple

gnprice commented 1 month ago

After I uploaded today's v0.0.13 release to TestFlight for our iOS beta users, we got an email from Apple with the following warning:

Although submission for TestFlight review was successful, you may want to correct the following issues in your next submission for TestFlight review. Once you've corrected the issues, upload a new binary to App Store Connect.

ITMS-91053: Missing API declaration - Your app’s code in the “Runner” file references one or more APIs that require reasons, including the following API categories: NSPrivacyAccessedAPICategoryUserDefaults. While no action is required at this time, starting May 1, 2024, when you upload a new app or app update, you must include a NSPrivacyAccessedAPITypes array in your app’s privacy manifest to provide approved reasons for these APIs used by your app’s code. For more details about this policy, including a list of required reason APIs and approved reasons for usage, visit: https://developer.apple.com/documentation/bundleresources/privacy_manifest_files/describing_use_of_required_reason_api.

Apple Developer Relations

So we'll need to resolve that in the next few weeks, by 2024-05-01, in order to continue publishing betas for iOS whenever we like.

Whatever "one or more APIs" they're referring to must be something in one of our dependencies, because we have zero Swift or Objective-C code of our own so far. Following links a bit: the relevant section is here, and the only API in that category is UserDefaults. I don't know offhand which of our dependencies might use that; it might be in code we never invoke.

It seems like Apple has just recently started sending these warnings. We didn't get one for the v0.0.12 release, just three weeks ago, and we don't have any new dependencies since then. Threads like https://github.com/flutter/flutter/issues/145269 also suggest that many people just started getting these circa 2024-03-16, a little over two weeks ago.

To handle this:

The first step is to upgrade all our dependencies. That might resolve the issue — there's a way for dependencies to provide these privacy manifests (to be aggregated into the app's manifest), and it sounds like a lot of plugins have just recently added them. Which makes sense given that these warnings just started going out to the developers using the plugins.
If that doesn't resolve it: the plugins may nevertheless have the privacy manifests, as they don't always get automatically aggregated. Detailed steps to take are at https://github.com/flutter/flutter/issues/131940#issuecomment-2006965339 ; see also update at https://github.com/flutter/flutter/issues/131940#issuecomment-2016573862 .
If that doesn't resolve it, that'll mean some plugin is missing a privacy manifest it needs. At that point it's a debugging problem. The general approach needed is described here; some examples inspecting binary dependencies with nm | grep are here and in the comments after it.

Useful threads in the Flutter tracker include:

gnprice commented 3 weeks ago

We just got the same email from Apple today, after I sent v0.0.14 to TestFlight. So this issue is still present after #628.

It's likely that we're affected here by the same App Store Connect bug discussed at https://github.com/zulip/zulip-mobile/pull/5859 . In that case, the workaround for now is to include our own privacy manifest compiled manually.

chrisbobbe commented 3 weeks ago

It's likely that we're affected here by the same App Store Connect bug discussed at zulip/zulip-mobile#5859 . In that case, the workaround for now is to include our own privacy manifest compiled manually.

Yes, that seems right. From the description quoted there, the bug:

is mainly impacting SDKs distributed as static frameworks (which includes some Flutter plugins, or in the case of Flutter apps that do not use `use_frameworks!' almost all plugins)

Our Flutter app does call use_frameworks! in its Podfile. But by searching ~/.pub-cache/hosted/pub.dev, I do find two items that have s.static_framework = true in their Podspecs: firebase_core and firebase_messaging. Only the latter uses NSUserDefaults, which is the only "required reason API" that Apple's email was alerting us about. And, as we found in 92f5dd5ea, firebase_messaging does have a "privacy manifest" file.

So if the Apple bug is the issue, then we should try copying the reasons from firebase_messaging's privacy manifest into our own privacy manifest. It declares one reason, CA92.1.

chrisbobbe commented 3 weeks ago

(Oh, and: firebase_messaging in its repo's master branch still has s.static_framework = true in its podspec.)

gnprice commented 1 week ago

It's likely that we're affected here by the same App Store Connect bug discussed at zulip/zulip-mobile#5859 . In that case, the workaround for now is to include our own privacy manifest compiled manually.

It looks like Apple has backed down on this. With a week to go, and as part of a "reminder" with no mention that it's a change of plan — classic Apple on both counts.

Here's the announcement, which I found via that Flutter issue 145269 linked from zulip/zulip-mobile#5859.

The upshot is that for now this only affects dynamic frameworks (not static frameworks, which were affected by that App Store Connect bug), moreover only newly added such frameworks, and moreover only those that are on their list of popular third-party SDKs. So the warning quoted above, for "Runner" which is our app's own main framework, shouldn't appear.

Presumably Apple will later come back and expand the scope. Hopefully by then they fix that bug, so that things go smoothly. In any event, for now things should just work, and we shouldn't need the workaround described above.

Leaving this issue open until we next attempt a release and confirm that it's resolved.

gnprice commented 4 days ago

I've sent v0.0.15 for TestFlight review, and we don't seem to have one of these warning emails. So this indeed seems fixed.

zulip / zulip-flutter

"Missing API declaration" warning from Apple #612