[iamoguzhanarslantas]

Summary

Adds flutter_local_notifications_watchos 0.0.1, the watchOS implementation of flutter_local_notifications, over UserNotifications and dart:ffi.

Not verified on a physical Apple Watch. Everything below was checked on the watchOS 27.0 Simulator and on the host only. I could not get a watch to show up in Xcode, so no device run has been done.

• flutter_local_notifications is not fully federated: on platforms that report iOS, which the watch does, the app-facing calls check that the platform instance is an IOSFlutterLocalNotificationsPlugin. This package's class therefore extends it and overrides every method that would use the method channel. It depends on flutter_local_notifications itself, which does not depend back on it.
• Supported: initialize (categories with their actions, default presentation, the permissions the settings ask for), requestPermissions / checkPermissions, show, zonedSchedule (a calendar trigger in the date's own time zone, repeating by matchDateTimeComponents), periodicallyShow / periodicallyShowWithDuration, cancelling, the pending and delivered lists, getNotificationAppLaunchDetails, and taps through onDidReceiveNotificationResponse.
• The flutter-watchos host's FlutterWatchOSAppDelegate owns the notification-center delegate and rebroadcasts its callbacks. The native file observes them from a load-time constructor, so the tap that launched the app is caught before Dart runs. Each notification carries its id, payload and presentation flags in userInfo under keys of this package's own, and callbacks for anyone else's notifications (pushes, other plugins) are left alone.
• Not supported, documented in the README: named sounds (the default sound plays), typed text input on an action, onDidReceiveBackgroundNotificationResponse, and openAppNotificationSettings (returns false). isBadgeEnabled is always false.
• The root README gets the table row; tool/upstream_versions.yaml gets flutter_local_notifications; the word allow-list gets the package's C free(.

Verified

On the watchOS 27.0 Simulator (Apple Watch Series 12, 46 mm):

• Upstream's example/integration_test/flutter_local_notifications_test.dart passes, unchanged but for the formatting CI checks, after the permission prompt is allowed (flutter-watchos test reinstalls the app, so the prompt comes back each run).
• example/integration_test/watchos_notifications_test.dart (4 tests) passes: the permission flags, the launch details, and scheduling, listing and cancelling against the real notification center. It fails on the first commit's code (see the second commit).
• By hand with the example: a notification scheduled ten seconds out was listed as pending, shown on the watch face with the app in the background, and its tap reached onDidReceiveNotificationResponse with its id and payload. A cold launch from a notification is reported by getNotificationAppLaunchDetails.
• The example builds with every ffiSymbols entry in the export table.

Off the watch:

• 14 host tests through the app-facing FlutterLocalNotificationsPlugin, with the target platform set to iOS.
• Every tool/ check, dart format as CI runs it, and pub publish --dry-run are clean.

Not verified

• A physical Apple Watch. Nothing has run on a device.
• A notification arriving while the app is in front: it was added but not seen on screen in the Simulator, so the host's willPresent path and the five present… flags are unchecked.
• Action buttons on a delivered notification, and repeating triggers firing more than once (they were scheduled and listed, not watched over time).

Notes for review

• The app must install the host's application delegate (@WKApplicationDelegateAdaptor(FlutterWatchOSAppDelegate.self)), as flutter-watchos create does.
• A banner shown while the app is in front closes when tapped and sends no response: watchOS does not report that tap. The README says so.
• example/lib/ is a small watch demo, because upstream's example needs flutter_timezone, which has no watchOS implementation.
• Three commits: the package; the BOOL fix (@(a == b) boxed an int, so the launch flag and every permission flag reached Dart as 1 and read false) with the new integration test; and the formatting of upstream's test.
• Like my other open PRs here, this one edits the root README's table and tool/upstream_versions.yaml, so whichever merges first leaves the others a conflict there; I will rebase each one after a merge.

🤖 Generated with Claude Code

[MAUstaoglu]

Thank you, this is a careful port with good coverage (Simulator-tested, as the description says). Before merging:

Must-fix

1. LICENSE:1 names only FlutterWatch. Sibling packages keep their upstream's notice, and this one ships upstream code and tests, so please add Michael Bui's BSD-3 notice.
2. watchos/Classes/flutter_local_notifications_watchos_ffi.m:501-502: upstream 22.3.2 ignores UNErrorDomain errors when adding a request, because iOS 27 reports a missing permission that way. Here they become a PlatformException, so show() without permission likely throws on watchOS 27. Please match upstream.
3. _ffi.m:208-210 and lib/flutter_local_notifications_watchos.dart:140: any response that arrives before initialize, including dismissals and background actions, becomes the launch tap. Dismissals are also always reported, while upstream reports them only when dismissIsolate is set, and that setting never reaches native here.
4. example/integration_test/watchos_notifications_test.dart:25-29: setUpAll requests permission, so the suite blocks on the prompt. Please gate it as AUTHORING §2c describes.

Nice-to-have

• _ffi.m:
  • :169 and :172 hide banner and list when presentAlert is false; upstream ignores that flag on iOS 14+;
  • :463-464 counts provisional as enabled;
  • :446 returns true when nothing is requested, where upstream returns false.
• PORTING_REPORT.md:71: providesAppNotificationSettings exists on watchOS 5+, and criticalSoundVolume is dropped without a note.
• README: mention the time-sensitive and critical-alert entitlements, and that tz.local stays UTC on the watch.
• Extending upstream's concrete iOS class means a method added in an upstream minor release will throw MissingPluginException; 23.0.0 is at dev.4. Worth a note.
• Allow-list: free( is justified, since it is a C function. Please keep the list alphabetical, and fix the reason text: the export is _release.

We'll start the CI run after your update. Thanks!

Posted from the wrong account; superseded by the maintainer review.

[iamoguzhanarslantas]

Thanks for the review. Pushed 7d903c9:

Must-fix

1. LICENSE now has Michael Bui's notice, upstream's text verbatim, next to ours. The README says so.
2. UNErrorDomain errors from addNotificationRequest are ignored, as in 22.3.2.
3. Routing now follows upstream:
   • Only a default tap, or an action with .foreground, becomes the launch response.
   • A dismissal is reported only when the details set dismissIsolate, which now reaches native.
   • A main-isolate dismissal that arrives before initialize is dropped.
   • Background actions and the remaining dismissals are queued for onDidReceiveNotificationResponse, because the watch has no background isolate.
   • Each notification's userInfo records which of its category's actions open the app, because a launch response arrives before initialize.
4. The prompt is gated behind --dart-define=FLNW_PROMPT=true. Without it the suite asks for nothing: 1 test passes and 3 are skipped.

Nice-to-have

• Banner and list ignore presentAlert.
• isEnabled no longer counts provisional.
• initialize and requestPermissions answer false when nothing is requested.
• providesAppNotificationSettings is requested and reported.
• criticalSoundVolume uses defaultCriticalSoundWithAudioVolume:.
• README: the time-sensitive and critical-alert entitlements, tz.local staying UTC, and a note on extending the concrete iOS class.
• Allow-list: alphabetical, and the reason names _release.

Checked: 15 host tests. On the watchOS 27.0 Simulator:

• The watchOS suite without the define: 1 passed, 3 skipped.
• The watchOS suite with the define, after allowing the prompt: 4 passed.
• Upstream's suite: 5 passed.

I did not re-run taps from the watch face after the routing change.

🤖 Generated with Claude Code

[MAUstaoglu]

Thanks! All four must-fixes and every nice-to-have are in, and they match upstream 22.3.2. Before merging:

1. A test for the UNErrorDomain fix: a watchos_notifications_test case where show() completes without permission, gated as skip: _prompt. It runs unattended and checks the watchOS 27 claim.

2. A Simulator pass over the new response routing:

   • a tap and a foreground action at cold launch;
   • a background action;
   • a dismissal, with and without dismissIsolate.

   Please note the results in PORTING_REPORT.

3. Docs: update the native header's JSON contract (_ffi.h:41-55 lacks providesAppNotificationSettings and isProvidesAppNotificationSettingsEnabled; the host fake follows that header), and PORTING_REPORT lines 41–43 and 15–19, which still describe the old launch rule.

Optional: requestAuthorization errors throw here, while upstream ignores them and returns granted.

[MAUstaoglu]

On the example, for the record. AUTHORING.md §3 asks for upstream's own example, unchanged. Here upstream's example cannot launch on the watch: main() awaits FlutterTimezone.getLocalTimezone() with no guard, and flutter_timezone has no watchOS implementation, so it throws before runApp.

That makes your watch demo the right call for this package, and the report's Example section says why. The official integration test is upstream's, as the rule asks. Nothing to change here beyond the round-2 items.

[iamoguzhanarslantas]

Thanks! Pushed ced2c4c:

1. UNErrorDomain test. show completes without permission runs when _prompt is false. It skips itself if notifications are already allowed. On the watchOS 27.0 Simulator the add fails with UNErrorDomain code 2003 ("Source is not authorized"). Against the old error handling the test fails with that PlatformException; with the fix it passes.
   The test passes DarwinNotificationDetails without attachments, and that found an older crash. attachments: null reached native as NSNull, and _content iterated it, so any show() with iOS details ended the app. Attachments, categories and actions are now only iterated when they are arrays.
2. Simulator pass over the routing. The demo has new buttons: a lap category with a foreground "Resume" action, a background "Skip" action and customDismissAction, scheduled with and without dismissIsolate. Results, also in PORTING_REPORT:
   • Tap, app not running: launch details ✅
   • "Resume", app not running: the app launches, and the action arrives through onDidReceiveNotificationResponse instead of the launch details. A log shows the host posting it about 0.2 s after Dart read the launch details, so it takes the late-launch queue. It is not lost, but it differs from iOS. The README says to read both.
   • "Skip", app in the background: the app stays in the background, and the action reaches the callback ✅
   • Dismissal with dismissIsolate: notificationDismissed ✅
   • Dismissal without it: not reported ✅
3. Docs. The header's JSON contract now has providesAppNotificationSettings, isProvidesAppNotificationSettingsEnabled, dismissIsolate and the new launch and queue rules. PORTING_REPORT describes the new launch rule.

Optional: done. A requestAuthorization error is no longer reported, and the answer is granted, as upstream.

Checked:

• 15 host tests.
• The watchOS integration test from a fresh install, unattended: 2 passed, 3 skipped.
• The same test with the prompt allowed: 4 passed, 1 skipped.

And thanks for the note on the example.

🤖 Generated with Claude Code