I tried but that's not what I want, the master view contrioller show only be visible when the user choose to, not all the time

Me too, and resubmitted the form by mistake. I've been accepted on December but still I can't tell for sure Apple is taking 15% instead of 30%.

iOS 16.1.2 didn't fix this issue, I was wondering about the betas if anyone has tried. Would be interesting to know apple guidance about this, should we just wait for a fix at o/s level and avoid any complex rendering in the meantime ? I had to disable some of the features when my app is running on iOS16, users were complaining about freezes.

Hi, I'm observing a similar behaviour with a small fraction of our users (seems only on iOS16). I keep receiving the same old token over and over again refused as Unregistered by the APN. Are you still experiencing this issue ?

I've just observed the same odd behaviour. I kept receiving an Unregistered token myself when testing the app (I was using testflight though) , I could verify the token was coming from a didRegisterForRemoteNotificationsWithDeviceToken and did not change. The only way to get a new valid token was to remove and reinstall the app.

same here, production apns, keep receiving the same expired token from apns at each registerForRemoteNotifications call, users complaining about not getting notifications anymore and leaving bad reviews. remove+reinstall fixes this but it can't be given as a solution.

Add this at the end of your podfile (+ pod install) to override the iOS Deployment Target of all your pods. Make sure to choose the appropriate minimum deployment target (iOS 11 or above). post_install do |installer| installer.pods_project.targets.each do |target| target.build_configurations.each do |config| config.build_settings['IPHONEOS_DEPLOYMENT_TARGET'] = '11.0' end end end

Hi, thank you for your reply. I've double-checked the notifications received over the last two years, but I've only received REFUND and REVOKE notifications for non-consumable in-app purchases. Do you think it's safer not to block content for the end user when the revocation date is missing? If the user regains access, wouldn't they receive a different transaction ID? It seems that REVOKE transactions with the 'FAMILY_SHARED' ownership type don't have a revocation date unless they were revoked because the family member the made the purchase obtained a REFUND. If the user simply exits the family, the date is never included.