iOS Notification Permissions Request Callback Fail

I have tested this on iOS 12 and 13.

Here an example:
index.html (1.3 KB)

This used to work, but does not seem to work anymore. I have tried it both with and without the justification text.

Basically what is happening is that the forge.permissions.check works as intended. in this case, when you click the button the first time, permission has not yet been granted so it calls forge.permissions.request.

  1. iOS does not display the justification text on either modal. (Not a deal breaker.)
  2. After allowing the permission, no callback is fired. Neither the success or error callback is fired.
  3. The permission does appear to be granted successfully though as in this example if you click the button a second time, forge.permissions.check does return granted ===true.

So I think it is just the callback for whatever reason.

In our actual app, on success, if granted is true we then call forge.parse.registerForNotifications to register the device with parse. But of course if the callback does not fire, nothing happens.

Thank you for the bug report!

It looks like it broke when Apple required us to move the permission checking code into the individual modules requiring them.

I’ve pushed a new version of the module which should resolve the callback not firing and fix the missing rationale text if you update to:

"permissions": {
    "version": "2.2",
    "config": {}

That got me part way there. It is showing the custom rationale.

When I run my test above, what happens now is that the success callback for forge.permissions.request() is firing before the user selects an option with granted === false. So, it is echoing out “Register Device: DENIED” when the prompt is displayed instead of firing it with the result of the response.

I’m seeing some pretty twilightzone-ish behaviour on my side too.

The same code we tested and pushed this morning is now no longer triggering the iOS didRegisterForRemoteNotificationsWithDeviceToken event handler.

This could be due to issues with Apple’s push servers, it wouldn’t be the first time.

Either way, the behaviour you’re describing sounds like what would happen if the app had previously been denied permission. iOS can be stubborn about letting things go so you may need to do:

  1. Delete app
  2. Reboot device
  3. Try again

If this still doesn’t work, what I suggest is that you drop the permissions module for notifications and just rely on the automatic permission flow for whatever you’re using for local and/or remote push notifications.

This whole “ask twice so I can bug you again later if you said no the first time” flow is a pretty dark pattern which I deeply regret implementing in the first place. :frowning:

The API’s were not designed for this kind of abuse either so, unless someone can make a powerful argument for why this is critical for the survival of all living things, we’re making the call to deprecate it in the next Forge platform release.

This way users aren’t feeling manipulated and we have more capacity to do really worthwhile things like improving the Trigger.IO tooling and documentation.

Skipping what I refer to as the “pre-ask” was my fallback as well and is working as of now. Thanks for dropping the UIwebview references. Apple was complaining and I am curious to see how they like the next build.

Still not sure why they wont let me log anything to console with forge.logging or allow alert(). Sure makes it harder to debug, that’s for sure.

1 Like

Have you tried ?

It’s mostly obsolete but has the one big advantage of sometimes being able to debug in situations nothing else can get to.

I will give it a whirl. Thanks