flutter_local_notifications icon indicating copy to clipboard operation
flutter_local_notifications copied to clipboard

[flutter_local_notifications] Add support for `providesAppNotificationSettings`

Open lukemmtt opened this issue 10 months ago • 7 comments

Adds support for custom notification settings UI on iOS 12.0+ and macOS 10.14+. When enabled, users see a "Configure Notifications in <app name>" button in the notification's context menu, allowing access to app-specific notification settings.

Changes

  • Added requestProvidesAppNotificationSettings option to DarwinInitializationSettings
  • Added isProvidesAppNotificationSettingsEnabled to permission check results
  • Updated iOS and macOS implementations to support the feature
  • Added test coverage

Platform Support

  • iOS 12.0 or newer
  • macOS 10.14 or newer

Closes #2557.

Before & After

before after

iOS Example app demo:

https://github.com/user-attachments/assets/fec8f9e1-e2c3-41d3-874a-07b36b936c55

lukemmtt avatar Feb 23 '25 22:02 lukemmtt

Thanks a lot for the PR.

Sure thing! Glad to contribute 🙏🏻

The addition of pictures adds a lot and makes reviews a lot more easier so thanks so much for being thoughtful about that.

Of course! I advocate for the same in my own project's PRs—pictures and videos are invaluable!

I've left some comments that are minor and happy to discuss them further if needed.

Great stuff, thank you for the prompt and thoughtful review.

Besides that, are you able to update example app so this setting is requested? It looks like it's a safe one to request so I'm thinking it's worth requesting it so that those running the example app will see the effect without making code changes

Sure thing, happy to 🚀 will report back shortly.

Thank you Michael!

lukemmtt avatar Feb 24 '25 12:02 lukemmtt

Btw @MaikuB, wasn't sure if you're aware of the handy PR suggestion tool, but I'm a big fan of it, especially for edits to code comments, makes nits really easy. Forgive me if you already know it well—I only found out about it last year after years of PR reviews!

https://github.com/user-attachments/assets/e6b1c940-0f6c-4d47-8455-4abba7afa72b

lukemmtt avatar Feb 24 '25 12:02 lukemmtt

No I wasn't aware of it so thanks for the tip I'll need to look up how that works. Have used it for Azure DevOps but currently responding on phone (and will go to bed soon...) so suspect functionality will be limited. I imagine it'll be similar in highlighting a portion of the code to make a suggestion

MaikuB avatar Feb 24 '25 12:02 MaikuB

Glad I could help! In case it's not clear from the video, this button is the key:

image

lukemmtt avatar Feb 24 '25 13:02 lukemmtt

I've added a demo to the iOS Example app. See updated PR description for video.

I've not touched the Mac example app, as I'm short on time. Hopefully this is adequate to merge, but I'm happy to revise as needed.

lukemmtt avatar Feb 24 '25 17:02 lukemmtt

@MaikuB All PR comments and DCM lints are resolved

lukemmtt avatar Mar 01 '25 20:03 lukemmtt

Hey @lukemmtt, checking back on to see if you're able to look at the PR comments.

MaikuB avatar Jun 01 '25 00:06 MaikuB

Thanks for your patience @MaikuB and thank you for taking the time to review my PR in the first place, I appreciate it!

I've merged in master, resolved conflicts, and resolved the issue you pointed out as best as I could. I also resolved the lints and ran dart format against the Flutter 3.22.0 SDK. I don't have a DCM subscription at the moment, but let me know there are any lingering issues and I'll be happy to address.

Thank you!

lukemmtt avatar Oct 09 '25 17:10 lukemmtt

Thanks for making those changes. I picked up a problem in the example app. Can you take a look?

Thanks for the latest review @MaikuB; I've committed your suggested edit; I'll test the example app manually as well.

In the interest of time and to help out, I thought I could make the changes myself. However, I believe you haven't enabled the setting that would've allowed me to push the changes myself.

Thanks for bringing this to my attention—I didn't even realize that such a setting existed. I looked into it, and found out why I can't see this setting—it isn't an option for organization-owned repositories, and I happened to create this fork in my own org, so I'm out of luck, even though I'm the sole owner of the org. Bummer. I'll make my forks in my personal repo from now on.

FYI for future reference regarding linter issues, these do not need a DCM subscription. I don't have one myself and linter issues will show up with your IDE. I picked these up by opening your PR on VS code

Also great to know! I used to have a DCM subscription myself but cancelled it for cost reasons; I've never tried using it without a sub. I appreciate the insight and will give this a try.

Thanks and I'll let you know when it's ready for re-review shortly 👍🏻

lukemmtt avatar Oct 12 '25 14:10 lukemmtt

Hey @MaikuB,

I've implemented the edits you've requested. I haven't yet tested or fixed any possible DCM lints—having trouble getting it set up, it's complaining about my expired license.

Additionally, one other thing to note: in my latest iteration, I attempted to verify this feature actually works on macOS (since it has the API support, but I had omitted it from the example app before). In my attempt, in which I temporarily added support to the macOS AppDelegate and the example app, the UI button did not seem to actually appear in notification context menu on macOS upon right-clicking. I also couldn't find any examples online of this feature working on macOS either.

This seems to suggest that while the macOS API supports the providesAppNotificationSettings API, the feature may not actually implemented on the OS level for macOS.

Commit links:

  • d2e06fa: macOS POC attempt with full AppDelegate implementation (documents it doesn't work)
  • 0dab96c: Revert of POC
  • 9a2b243: Updated API documentation to reflect findings

I've left the macOS API support in place in this PR (as it was before), mostly for completeness, and also in case the OS changes to actually implement the UI in the future (or someone finds evidence to the contrary that suggests that macOS DOES support this in its UI). Let me know if you'd prefer to strip it out completely.

Thanks!

lukemmtt avatar Oct 12 '25 16:10 lukemmtt

Hmm I merged this but I just thought of a question. Would it have been possible for the plugin to handle the method instead of requiring developers to implement it in their own AppDelegate? I believe it would have been possible given the plugin handles other ones but didn't get to test in this context. If it's possible, this is what comes to mind and let me know what you think

  • This enum is updated to support an additional type that is iOS-specific and could be called something like selectedShowAppNotificationSettings specific to the scenario in this PR
  • Presumably picking the option in the context menu can launch the app. If so, plugin users could make use this method to know that the app was launched by that option. The new response type should become in the object returned and along with the notification details
  • Similarly, if the app is running, it should fire the onDidReceiveNotificationResponse callback that is part of the initialisation method

MaikuB avatar Oct 14 '25 08:10 MaikuB

Thanks for the merge @MaikuB! I'm grateful for your diligence in reviewing my PR and maintaining this plugin, and for your offering the plugin to the community in the first place!

As for your question about whether the plugin could have handled the method instead of requiring devs to implement it on their own, it's a really thoughtful idea! I'd much prefer something like that myself. Unfortunately though, I looked into it, and it seems that it might not be possible at all, due to a Flutter engine limitation.

Specifically, Flutter's addApplicationDelegate forwarding system only forwards two specific delegate methods:

  1. userNotificationCenter:willPresentNotification:withCompletionHandler:
  2. userNotificationCenter:didReceiveNotificationResponse:withCompletionHandler:

openSettingsFor is not forwarded, so plugins registered via addApplicationDelegate (like flutter_local_notifications) would never receive this call.

See: FlutterAppDelegate.mm and FlutterPluginRegistrar Protocol

As I understand it, that makes such an implementation on iOS impossible, at least without Flutter engine changes. macOS of course doesn't use this forwarding system, so we could theoretically implement some built-in support for this feature on macOS, but that's pointless of course, since macOS doesn't seem to have a UI implementation for this capability to begin with.

Let me know if this adds up; this is all new to me and I'm certainly no expert in this domain, I simply did some digging.

Thank you!

lukemmtt avatar Oct 14 '25 20:10 lukemmtt

Thanks for the response and references. Yep I took a look and you're right. What you shared would indicate Flutter isn't forwarding the calls. If it was then there should be some code that invokes the method like it does for the ones you highlighted

MaikuB avatar Oct 17 '25 05:10 MaikuB