I believe this is a known issue - I have never expected silent push to work on the simulator.

This is a pretty common topic and you should first invest more time reading the main developer documentation on Notifications. Then also look at how apps are allowed to execute background code. If your use case is really about incoming calls, you should also look more specifically to the Pushkit framework.

It turns out I had actually not updated the right piece of code to request the additional .criticalAlert type to the UNUserNotificationCenter. (had updated an old piece of code that no longer runs...) It is worth noting that even with the appropriate entitlement, the Notifications settings for your app won't show the "Critical alert" control until your app has made the authorization request for the .criticalAlert. I need to dig a bit more to understand what this implies to migrate existing users who already have been exposed to the once in the lifetime notification authorization pop-up...

forgot to mention that I'm using token-based authentication

Will you make connections to the Sandbox Server fail prior to the production server transition date for connections that do not include the new certificate? If yes, can you please publish the transition date for the Sandbox server? Thank you!

Technically the subscription is not attached to the user account in your own system, but is attached to the Apple ID. I believe you should let a user with an active subscription delete their account in your system, and ideally give them a warning that deleting their account won't terminate their subscription. You also have to keep in mind that if a user delete their account, and create a new one later one, even with totally new email/ identification info, they will still be able to enjoy their legacy suscription by using the "restore purchase" mechanism.

Hi everyone, I was struggling with the same issue and revisited Sign In With Apple documentation. I don't know if this is new, but there is a server-to-server notification system for Apple to let your backend know about a SIWA account being revoked. See "Processing changes for sign in with apple accounts" on the developer website. (link is being blocked here... ) As a result, I believe the following approach will be the best:  • in your app, if a SIWA user initiates an account deletion request, provide instruction to guide the user into the SIWA revocation system, and indicate that all account information will be deleted after the revocation. • On receipt of a server-to-server notification, delete all user data in your backend.  The only missing bit here would be the ability to notify the user of the completion of the deletion process. If the user has not shared an actual email address with you, you won't be in capacity to successfully notify the user through a relay address as it should be deactivated by the time you get notified. Maybe a perfect approach would be to offer the user to submit a notification email address if they wish to receive confirmation of the account deletion.  Hope this helps!

Apple has now provided API that allows a much better flow: when a SIWA user wants to delete their account, you should use the SIWA Rest API to revoke the SIWA account on Apple's server. This requires that you have an access token for the user, which you can get thought the sign in action in your app. If you did not initially obtained and stored access tokens for accounts created, you can request a new sign-in when the user requests the account deletion, which also has the benefit of ensuring the account deletion requests come from the actual device owner. With the new sign in, you get a short-lived authorization code that you can exchange against an access token. Then the access token allows you to request the account revocation. There is quite a lot of coding involved as all this works by exchaging JWT tokens with Apple servers.

Hi there, I'm keeping an iPhone SE 1st gen on a non-recent i0S version (iOS 15.2 currently) to perform some quality tests with my app and got a sporadic occurence of the -34018 error. My app uses Firebase Auth with a shared access group. The access group is shared with both the app's Intent extension, and another iOS app (which itself also includes a widget extension and a WatchOS app extension accessing the same group for user authentication). I got the sporadic -34018 error (reported through the Firebase Auth logs) in the following context: iPhone SE physically connected to my Macbook XCode 14.1 RC building the app and running it on the iPhone SE iPhone SE was busy fetching debug symbols while XCode was ready to request launch of the app app finally got launched after symbols fetch was completed This is a sporadic occurence and I have no authentication / shared access group issue otherwise. I however do not have the proper analytics capacities to know if such error sometimes happen on the field. Adding that before performing this Build+Run action, I manually launched a previous version on my app on the device and got no keychain issue.

Responding to myself: there is no active runloop associated to a background task thread, so after adding the timer to the runloop, I also need to start it with RunLoop.current.run() Wondering if it is a safe thing to do only based on the context not being the main thread: if Thread.current.isMainThread == false {       RunLoop.current.run()     }

I would suggest you double check whether the App Store systems intiially tried to deliver a notification by using the App Store Server API. https://developer.apple.com/documentation/appstoreserverapi/get_notification_history

Does your app calls registerForRemoteNotifications() when launched?

Possibly, I'm getting misled by Icon Composer as it tends to show you a large version of the icons. If I scale Icon Composer rendering toward a ~6% zoom, I do get the kind of design issues I'm seeing on the actual device. Lowering the rendering scale to such level is not even suggested by the pre-available values in the scale menu of the app, not sure why...