-
Notifications
You must be signed in to change notification settings - Fork 1.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[iOS] Lifecycle for push notifications needs to be conditionally implemented #24237
Comments
Hi I'm an AI powered bot that finds similar issues based off the issue title. Please view the issues below to see if they solve your problem, and if the issue describes your problem please consider closing this one and thumbs upping the other issue to help us prioritize it. Thank you! Closed similar issues:
|
There is also another warning in the console if you run about some other override. I forget exactly, so when I get to my mac I can update this issue. |
PerformFetch
You're missing: [Export("application:didFailToRegisterForRemoteNotificationsWithError:")]
public void FailedToRegisterForRemoteNotifications(UIApplication application, NSError error) |
Ok, sounds like responds to selector will not be enough, and that the static analysis apple does is going to flag the inclusion of it. We may need to revert these changes for now. |
Apple doesn't care about the PerformFetch as much since it is deprecated, but they will not be happy with push hooks if they aren't actually being used. I've been trying to solve this one for a while, but just gave up and document the fact that you have to hook these methods manually |
Unfortunately, when these lifecycle events were added, we didn't consider the implications of having the methods implemented on the appdelegate had with Apple app store submissions. Basically if the app delegate implements these methods, Apple assumes in their static analysis of the submitted apps that you intend to use them, and will warn about requiring the appropriate entitlements to therefore be declared. Given there's no obvious/easy way to conditionally export these selectors at this time, we are reverting the change to maintain the no warning/no error submission behaviour. For more information and to track future potential implementations of these lifecycle events, follow: #24237
Unfortunately, when these lifecycle events were added, we didn't consider the implications of having the methods implemented on the appdelegate had with Apple app store submissions. Basically if the app delegate implements these methods, Apple assumes in their static analysis of the submitted apps that you intend to use them, and will warn about requiring the appropriate entitlements to therefore be declared. Given there's no obvious/easy way to conditionally export these selectors at this time, we are reverting the change to maintain the no warning/no error submission behaviour. For more information and to track future potential implementations of these lifecycle events, follow: #24237
…thods (#24907) * Revert: Add MauiUIApplicationDelegate remote notification methods #23452 Unfortunately, when these lifecycle events were added, we didn't consider the implications of having the methods implemented on the appdelegate had with Apple app store submissions. Basically if the app delegate implements these methods, Apple assumes in their static analysis of the submitted apps that you intend to use them, and will warn about requiring the appropriate entitlements to therefore be declared. Given there's no obvious/easy way to conditionally export these selectors at this time, we are reverting the change to maintain the no warning/no error submission behaviour. For more information and to track future potential implementations of these lifecycle events, follow: #24237 * Remove delegates
In previews we had added new app lifecycle events for iOS push notifications, but have removed them from GA since there are potential issues with app store submissions the way they have been added. This change reverts them: dotnet/maui#24907 This issue tracks adding them back in the future: dotnet/maui#24237
* Remove previously added iOS App Lifecycle events for push In previews we had added new app lifecycle events for iOS push notifications, but have removed them from GA since there are potential issues with app store submissions the way they have been added. This change reverts them: dotnet/maui#24907 This issue tracks adding them back in the future: dotnet/maui#24237 * Remove extra blank line * Also remove events from app lifecycle doc. --------- Co-authored-by: David Britch <davidbritch@users.noreply.github.com>
Description
For .NET 9 Preview 7, we added
iOSLifecycle.OnReceivedRemoteNotifications
andiOSLifecycle.OnRegisteredForRemoteNotifications
lifecycle events in #23452 (Yay!)But we forgot to ensure that for cases when an app does not want these implemented, it needs to appear to Apple that it is not using them, otherwise I believe apps will be flagged in submission for not including the appropriate entitlements (need to fact check this).
I believe we could do this by overriding
RespondsToSelector
on the delegate and checking for these selectors and returning false if we have determined the app isn't actually wiring up the registration (need to fact check this).We need to decide how we want to determine that. Maybe we can look at the entitlements at runtime and see if
aps
entitlement is declared? or we can set a flag when registering for the lifecycle event, however this may conflict with cases where someone manually overrides these methods on their delegate. We could also have a property on the delegate to toggle this on and off.Version with bug
9.0.0-preview.7
Is this a regression from previous behavior?
Yes, this used to work in .NET MAUI
Last version that worked well
9.0.0-preview.6
Affected platforms
iOS, macOS
Did you find any workaround?
For now, one could manually override RespondsToSelector and return false when these are queried if they do not want to appear to have them implemented.
Thanks @aritchie for noticing this change and helping flag the potential issues with it!
The text was updated successfully, but these errors were encountered: