From a1f4d3036840f899eebc56301e5e0905e318c418 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Mehmet=20Ali=20Ustao=C4=9Flu?= Date: Sat, 31 Oct 2026 19:50:23 +0100 Subject: [PATCH] Docs: per-app defines ship in flutter-watchos 0.1.2 "The first flutter-watchos release after 0.1.1" is now flutter-watchos 0.1.2, released on 2026-10-31, in AUTHORING.md, tool/README.md, the native check's comments and permission_handler_watchos's README, CHANGELOG, PORTING_REPORT and pubspec comment. AUTHORING links the CLI's "Compiling out what an app does not use" again, now that the section is on its main. --- AUTHORING.md | 5 +++-- packages/permission_handler_watchos/CHANGELOG.md | 2 +- packages/permission_handler_watchos/PORTING_REPORT.md | 5 ++--- packages/permission_handler_watchos/README.md | 10 ++++------ packages/permission_handler_watchos/pubspec.yaml | 4 ++-- tool/README.md | 2 +- tool/check_native_sources.sh | 2 +- tool/lib/src/plugin_defines.dart | 4 ++-- 8 files changed, 16 insertions(+), 18 deletions(-) diff --git a/AUTHORING.md b/AUTHORING.md index d68b4d2..0f6db36 100644 --- a/AUTHORING.md +++ b/AUTHORING.md @@ -284,7 +284,7 @@ flutter: - NSLocationAlwaysAndWhenInUseUsageDescription ``` -From the first flutter-watchos release after 0.1.1, the CLI compiles the +From flutter-watchos 0.1.2, the CLI compiles the plugin's native sources with `-D=1` (in Swift, `-D`) for each macro whose key the watch app's Info.plist sets. A plugin that declares `defines` also gets the marker, `FLUTTER_WATCHOS_PLUGIN_DEFINES`, on every @@ -332,7 +332,8 @@ neither, so guard each group to keep it in apps built by one: The rules, which values turn a macro on, what `-v` prints and why a plugin built through SwiftPM (§2d) is not covered, are in the CLI's -`doc/plugins.md`, from the first flutter-watchos release after 0.1.1. +[Compiling out what an app does not use](https://github.com/flutterwatch/flutter-watchos/blob/main/doc/plugins.md#compiling-out-what-an-app-does-not-use), +from flutter-watchos 0.1.2. `permission_handler_watchos` is the worked example. ## 3. Verify diff --git a/packages/permission_handler_watchos/CHANGELOG.md b/packages/permission_handler_watchos/CHANGELOG.md index f1dbe30..8d831a2 100644 --- a/packages/permission_handler_watchos/CHANGELOG.md +++ b/packages/permission_handler_watchos/CHANGELOG.md @@ -13,7 +13,7 @@ physical watch. * Each group is compiled into the app only when the watch app's Info.plist sets one of its keys, as the iOS implementation's `PERMISSION_*` macros do: the pubspec maps the same macros to the keys under `defines`, which - the first flutter-watchos release after 0.1.1 applies. A group left out + flutter-watchos 0.1.2 applies. A group left out answers as an unknown permission does, and none of its class names, selectors or keys are in the binary. Calendar and reminders are one group, as on iOS: with only some of their keys, each status is still diff --git a/packages/permission_handler_watchos/PORTING_REPORT.md b/packages/permission_handler_watchos/PORTING_REPORT.md index af184d7..c2ad4e4 100644 --- a/packages/permission_handler_watchos/PORTING_REPORT.md +++ b/packages/permission_handler_watchos/PORTING_REPORT.md @@ -29,8 +29,7 @@ that an app does not reference an API it never asks for: App Store Connect warns about a missing usage description (ITMS-90683) for the privacy APIs a binary references. A watch app has no Podfile to set those macros. Instead, the pubspec maps the same macros to the Info.plist keys each group's prompts -check, under `defines`, and from the first flutter-watchos release after -0.1.1 the CLI reads the app's Info.plist on every build and compiles the +check, under `defines`, and from flutter-watchos 0.1.2 the CLI reads the app's Info.plist on every build and compiles the plugin with the macro of each group whose key is set, after `FLUTTER_WATCHOS_PLUGIN_DEFINES`. Each group's file guards its code with `#if !defined(FLUTTER_WATCHOS_PLUGIN_DEFINES) || PERMISSION_X` and gives the @@ -122,7 +121,7 @@ watchOS would not show again. | `calendarFullAccess`, `calendarWriteOnly`, `calendar`, `reminders` | ✅ EKEventStore, with the full-access and write-only requests. With only some of the group's keys, each status is still read, and a request whose prompt is left out answers its status without a prompt, as on iOS; the write-only prompt needs its own key even with the full-access key, where iOS does not check (see Design) | | `bluetooth` | ✅ CBCentralManager: creating it asks, its first state update answers; service status is whether it is powered on | | `criticalAlerts` | ✅ UNUserNotificationCenter's critical alert setting and request; needs the Critical Alerts entitlement | -| `assistant` | ◐ INPreferences (watchOS 6+), Siri, for an app that opts in; needs the Siri capability. INPreferences throws in an app without it (seen on the Simulator), so the Info.plist key `PermissionHandlerWatchosSiri` (`YES`) is the opt-in, and from the first flutter-watchos release after 0.1.1 the same key turns the iOS implementation's `PERMISSION_ASSISTANT` macro on. Only the Boolean `YES`, or a string `YES`, `true` or `1` in any case, opts in. `NSSiriUsageDescription`, which apps on an older flutter-watchos add with every other group's, does not switch it on. Without the opt-in Siri is never asked, so an app without the capability keeps running, and its status is `denied`. If Siri's code is left out, which the CLI does when the key does not count (a non-empty string or `` counts), Siri answers as an unknown permission: a request `permanentlyDenied`, the service `disabled`. If the code is in, as with any other non-empty string (`NO`, say), under 0.1.1 or earlier, which compiles every group in, or when the CLI cannot read the Info.plist, a request answers `denied` and the service is not applicable. With the opt-in and no `NSSiriUsageDescription`, a request fails with `MISSING_USAGE_DESCRIPTION` | +| `assistant` | ◐ INPreferences (watchOS 6+), Siri, for an app that opts in; needs the Siri capability. INPreferences throws in an app without it (seen on the Simulator), so the Info.plist key `PermissionHandlerWatchosSiri` (`YES`) is the opt-in, and from flutter-watchos 0.1.2 the same key turns the iOS implementation's `PERMISSION_ASSISTANT` macro on. Only the Boolean `YES`, or a string `YES`, `true` or `1` in any case, opts in. `NSSiriUsageDescription`, which apps on an older flutter-watchos add with every other group's, does not switch it on. Without the opt-in Siri is never asked, so an app without the capability keeps running, and its status is `denied`. If Siri's code is left out, which the CLI does when the key does not count (a non-empty string or `` counts), Siri answers as an unknown permission: a request `permanentlyDenied`, the service `disabled`. If the code is in, as with any other non-empty string (`NO`, say), under 0.1.1 or earlier, which compiles every group in, or when the CLI cannot read the Info.plist, a request answers `denied` and the service is not applicable. With the opt-in and no `NSSiriUsageDescription`, a request fails with `MISSING_USAGE_DESCRIPTION` | | `storage` | ✅ granted, service not applicable, as on iOS | | `camera`, `photos`, `photosAddOnly`, `mediaLibrary`, `speech`, `appTrackingTransparency`, `backgroundRefresh`, `phone` | ✗ not on watchOS: `denied`, a request `permanentlyDenied`, service `disabled`, as iOS answers for an unknown permission | | The Android-only permissions | answered as an unknown permission, as on iOS | diff --git a/packages/permission_handler_watchos/README.md b/packages/permission_handler_watchos/README.md index c1982e2..9e8e265 100644 --- a/packages/permission_handler_watchos/README.md +++ b/packages/permission_handler_watchos/README.md @@ -44,8 +44,8 @@ would terminate the app. As in the iOS implementation, a permission group's code is compiled into the app only when the app uses the group, which it says by setting one of the -group's keys in the watch app's Info.plist. This takes the first -flutter-watchos release after 0.1.1: on every build, it reads +group's keys in the watch app's Info.plist. This takes flutter-watchos +0.1.2: on every build, it reads `watchos/Runner/Info.plist` and defines the macro of each key the app sets, as the package's pubspec maps them under `defines`. @@ -103,8 +103,7 @@ every group it never asks for too (see App Review). ### App Review App Store Connect asks for the usage description of each privacy-sensitive -API a binary references (ITMS-90683). With the first flutter-watchos release -after 0.1.1, a group the app's Info.plist leaves out is not in the binary: +API a binary references (ITMS-90683). With flutter-watchos 0.1.2, a group the app's Info.plist leaves out is not in the binary: none of its framework's class names, selectors or usage-description keys are. A watch app that only asks for notifications then references the same privacy API as a native watch app that does only that, @@ -123,8 +122,7 @@ The location strategy keeps one flag in `NSUserDefaults`, whether "always" was asked for, since watchOS shows that prompt once. `NSUserDefaults` is a required-reason API, so an app with this code declares `NSPrivacyAccessedAPICategoryUserDefaults` with reason `CA92.1` in its -privacy manifest (`PrivacyInfo.xcprivacy`). With the first flutter-watchos -release after 0.1.1, that is an app whose Info.plist sets +privacy manifest (`PrivacyInfo.xcprivacy`). With flutter-watchos 0.1.2, that is an app whose Info.plist sets `NSLocationAlwaysAndWhenInUseUsageDescription` or `NSLocationAlwaysUsageDescription`, or whose Info.plist the CLI cannot read; with an older one, every app that uses the package: diff --git a/packages/permission_handler_watchos/pubspec.yaml b/packages/permission_handler_watchos/pubspec.yaml index 0f87a30..85c4cc6 100644 --- a/packages/permission_handler_watchos/pubspec.yaml +++ b/packages/permission_handler_watchos/pubspec.yaml @@ -54,8 +54,8 @@ flutter: - permission_handler_watchos_take_result - permission_handler_watchos_release # Each permission group's native code is compiled in only when the - # app's Info.plist sets one of its keys: from the first - # flutter-watchos release after 0.1.1, the CLI then defines the + # app's Info.plist sets one of its keys: from flutter-watchos + # 0.1.2, the CLI then defines the # group's macro, and an older one compiles every group in. The names # are the iOS implementation's PERMISSION_* macros, each keyed to the # usage descriptions its prompts check. Notifications, critical diff --git a/tool/README.md b/tool/README.md index f7366a1..6e28ea5 100644 --- a/tool/README.md +++ b/tool/README.md @@ -134,7 +134,7 @@ compiling, and the Ubuntu tool tests run it on fixtures. The compile fixtures run on macOS, in the `native` job. A package that declares `defines` in its pubspec (macros that the app's -Info.plist turns on, from the first flutter-watchos release after 0.1.1) is +Info.plist turns on, from flutter-watchos 0.1.2) is compiled several times per target, so each guard compiles with its macros all on, all off and one at a time, nested guards included: - with no `-D`, as an older CLI compiles it; diff --git a/tool/check_native_sources.sh b/tool/check_native_sources.sh index 740064d..d31f3d1 100755 --- a/tool/check_native_sources.sh +++ b/tool/check_native_sources.sh @@ -19,7 +19,7 @@ # and listed: its sources import that package's modules, which only a # SwiftPM build provides, and the CLI builds such a plugin with xcodebuild. # - A plugin that declares `defines` in its pubspec (macros the app's -# Info.plist turns on, from the first flutter-watchos release after 0.1.1) +# Info.plist turns on, from flutter-watchos 0.1.2) # is compiled with no -D, as an older CLI compiles it; with # FLUTTER_WATCHOS_PLUGIN_DEFINES and every macro, as for an app that sets # every key; with the marker alone, as for an app that sets none; and, when diff --git a/tool/lib/src/plugin_defines.dart b/tool/lib/src/plugin_defines.dart index fd5e5db..7bc24c8 100644 --- a/tool/lib/src/plugin_defines.dart +++ b/tool/lib/src/plugin_defines.dart @@ -5,8 +5,8 @@ /// The per-app defines each plugin declares, for `check_native_sources.sh`. /// /// A plugin maps preprocessor macros to app Info.plist keys under -/// `flutter.plugin.platforms.watchos.defines` in its pubspec. From the first -/// flutter-watchos release after 0.1.1, the CLI compiles the plugin's native +/// `flutter.plugin.platforms.watchos.defines` in its pubspec. From +/// flutter-watchos 0.1.2, the CLI compiles the plugin's native /// sources with `FLUTTER_WATCHOS_PLUGIN_DEFINES` and each macro whose key the /// app's Info.plist sets; an older CLI passes neither, and nor does the CLI /// for a plugin that declares none. So the check compiles such a plugin with