"Missing API declaration" warning from Apple #612
Comments
Done because it's the first step in our plan to resolve zulip#612, the "Missing API declaration" warning from Apple. This is the result of `tools/upgrade pod-major`. No breaking changes requiring synchronous code changes were found. Changelogs: https://pub.dev/packages/device_info_plus/changelog https://pub.dev/packages/file_picker/changelog https://pub.dev/packages/flutter_local_notifications/changelog https://pub.dev/packages/package_info_plus/changelog https://pub.dev/packages/share_plus/changelog https://pub.dev/packages/pigeon/changelog All of these changelogs except `pigeon` mention adding "privacy info" or "privacy manifest" in the version we're taking here -- exactly the kind of thing we want to see, with zulip#612 in mind. I would guess that `pigeon` doesn't need one, as it's mainly just a code generator tool. Related: zulip#612
Done because it's the first step in our plan to resolve zulip#612, the "Missing API declaration" warning from Apple. This is the result of `tools/upgrade pod-major`. No breaking changes requiring synchronous code changes were found. Changelogs: https://pub.dev/packages/device_info_plus/changelog https://pub.dev/packages/file_picker/changelog https://pub.dev/packages/flutter_local_notifications/changelog https://pub.dev/packages/package_info_plus/changelog https://pub.dev/packages/share_plus/changelog https://pub.dev/packages/pigeon/changelog All of these changelogs except `pigeon` mention adding "privacy info" or "privacy manifest" in the version we're taking here -- exactly the kind of thing we want to see, with zulip#612 in mind. I would guess that `pigeon` doesn't need one, as it's mainly just a code generator tool. Related: zulip#612
Done because it's the first step in our plan for zulip#612, the "Missing API declaration" warning from Apple. This is the result of `tools/upgrade pod-major`. No breaking changes requiring synchronous code changes were found. Changelogs: https://pub.dev/packages/device_info_plus/changelog https://pub.dev/packages/file_picker/changelog https://pub.dev/packages/flutter_local_notifications/changelog https://pub.dev/packages/package_info_plus/changelog https://pub.dev/packages/share_plus/changelog https://pub.dev/packages/pigeon/changelog All of these changelogs except `pigeon` mention adding "privacy info" or "privacy manifest" in the version we're taking here -- exactly the kind of thing we want to see, with zulip#612 in mind. And `pigeon` shouldn't need one, as it's a dev dependency only, not part of the actual build. Related: zulip#612
Done because it's the first step in our plan for zulip#612, the "Missing API declaration" warning from Apple. This is the result of `tools/upgrade pod-major`. No breaking changes requiring synchronous code changes were found. Changelogs: https://pub.dev/packages/device_info_plus/changelog https://pub.dev/packages/file_picker/changelog https://pub.dev/packages/flutter_local_notifications/changelog https://pub.dev/packages/package_info_plus/changelog https://pub.dev/packages/share_plus/changelog https://pub.dev/packages/pigeon/changelog All of these changelogs except `pigeon` mention adding "privacy info" or "privacy manifest" in the version we're taking here -- exactly the kind of thing we want to see, with zulip#612 in mind. And `pigeon` shouldn't need one, as it's a dev dependency only, not part of the actual build. Related: zulip#612
Actually, I have a hunch that this will be enough for zulip#612, '"Missing API declaration" warning from Apple'. As that issue says, the only category of "required reason APIs" that Apple is alerting about is "user defaults APIs". There's just one API in this category: `NSUserDefaults`. Using Step 4 in these instructions from a Flutter maintainer -- flutter/flutter#145269 (comment) -- I found that firebase_messaging and flutter_local_notifications, but no other dependencies, have calls to NSUserDefaults without declaring reasons in this category in a "privacy manifest" file. Moreover, unlike in zulip-mobile, our Podfile calls `use_frameworks!`, which should mean we don't have to manually copy anything from our dependencies into a privacy manifest file of our own. See zulip/zulip-mobile#5859 for a link to a mention in the Flutter project about `use_frameworks!`. So I'm hoping that the following upgrades, made here, will address Apple's alerts: - firebase_messaging to v14.9.0, in which that dependency gets a privacy manifest that declares a reason for using "user defaults APIs": https://github.com/firebase/flutterfire/releases/tag/firebase_messaging-v14.9.0 - flutter_local_notifications to v17.1.0. In v17.0.1, a "user defaults APIs" reason declaration was added to this dependency's privacy manifest: https://github.com/MaikuB/flutter_local_notifications/releases Fixes: zulip#612
|
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 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:
Our Flutter app does call So if the Apple bug is the issue, then we should try copying the reasons from |
|
(Oh, and: |
Actually, I have a hunch that this will be enough for zulip#612, '"Missing API declaration" warning from Apple'. As that issue says, the only category of "required reason APIs" that Apple is alerting about is "user defaults APIs". There's just one API in this category: `NSUserDefaults`. Using Step 4 in these instructions from a Flutter maintainer -- flutter/flutter#145269 (comment) -- I found that firebase_messaging and flutter_local_notifications, but no other dependencies, have calls to NSUserDefaults without declaring reasons in this category in a "privacy manifest" file. Moreover, unlike in zulip-mobile, our Podfile calls `use_frameworks!`, which should mean we don't have to manually copy anything from our dependencies into a privacy manifest file of our own. See zulip/zulip-mobile#5859 for a link to a mention in the Flutter project about `use_frameworks!`. So I'm hoping that the following upgrades, made here, will address Apple's alerts: - firebase_messaging to v14.9.0, in which that dependency gets a privacy manifest that declares a reason for using "user defaults APIs": https://github.com/firebase/flutterfire/releases/tag/firebase_messaging-v14.9.0 - flutter_local_notifications to v17.1.0. In v17.0.1, a "user defaults APIs" reason declaration was added to this dependency's privacy manifest: https://github.com/MaikuB/flutter_local_notifications/releases Fixes: zulip#612
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. |
|
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. |
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:
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 flutter/flutter#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 Determine how to handle privacy manifests in packages flutter/flutter#131940 (comment) ; see also update at Determine how to handle privacy manifests in packages flutter/flutter#131940 (comment) .
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 | grepare here and in the comments after it.Useful threads in the Flutter tracker include:
The text was updated successfully, but these errors were encountered: