Docs: per-app defines ship in flutter-watchos 0.1.2

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<MACRO>=1` (in Swift, `-D<MACRO>`) 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

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

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 `<true/>` 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 `<true/>` 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 |

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:

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

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;

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

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