Keep Permissions as a Plugin

[tafelnl]

In the Capacitor 3.x Plugins issue (#3227) I read that the current Permission Plugin will be removed. I think this is not a good idea for two reasons:

1: If the Plugins will be accessible from the native side anyway, why not use that Plugin to make it possible to check for permission status?

2: I think this one is the most important one. But it also needs a little explanation:

Asking for permissions is a really UX-loaded thing. Because when the user denies the permission the first time on iOS, it can never be asked again. You will have to redirect the user to the settings screen instead. On Android this luckily only happens when the users checks the "do not ask again" checkbox. (which can only be done from the second time on btw).

If you will let the plugin handle the permissions themselves, you will have zero control over when the user is shown the permission dialog. And thus you reduce your chances of the user accepting the permission, as you do not really know when the explain that they may really need this permission.

Let me explain that further with an example:

Let's say you have an app that also supports video chatting. For this you will have to get permission to the camera. You can let a video chatting plugin handle that all by themselves. Within a perfect happy flow, this works just fine. But when the user denies the permission request, you've got a problem. Because you will now have to redirect them to the settings screen.

What you actually want to do is the following:

1 . Check if the user already granted a certain permission.

2 A. If granted -> Nice, the permission flow stops here. You can now open up the video chatting screen/

2 B. Not granted -> Very important: Show a clear explanation what is going to happen and why the users really needs to give the app access to his camera if he want to go on with video chatting.

3 . Ask the user if he wants to go ahead and accept the permission (so not the native permission request, but a customized one)

4 A. User agrees -> ask the user for permission

4 B. User denies -> do not ask the user for permission. Instead go to the previous screen for example. Or explain that he really should reconsider his decision. This way you prevent wasting your only chance of requesting the permission.

Now every plugin could of course go through all these steps as well. But it is not so likely that every single plugin will implement this flow. And above all, the flow will probably be very inconsistent and not in your style / corporate identity.

Therefore, I think that this decision really needs to be reconsidered.

[tafelnl]

A good read that explains this problem a bit more detailed: https://blog.prototypr.io/3-best-practices-for-in-app-permissions-dce7d36544a4

[ikeith]

To be clear, the plan is not "remove the ability to check permissions" but rather "break the permissions API out into the separate plugins." E.g. the ability to check the geolocation permissions will not be removed, it will be moved from the Permissions plugin into the Geolocation plugin.

This is to address several problems:

• Plugins will be broken apart and we want to avoid dependencies between them. You shouldn't have to add the permissions plugin to use the geolocation plugin. Similarly, if you don't add the geolocation plugin, you shouldn't have to link the related system libraries just because the permissions plugin references them.

• Permissions have become more granular over time. Right now, all API permissions are reduced to granted, denied, or prompt. That starts to break down when you look at newer APIs like iOS 14's upcoming "reduced accuracy" mode for location access. That will necessitate either a supplemental permissions call or more permission types (which aren't applicable to other APIs) so it would be good to allow separate plugins to customize how permissions are represented.

The goal is to rethink how the permissions are handled and come up with a consistent pattern for checking and requesting them that each plugin implements. The API will change but the functionality will not regress, at least for the core plugins. The application should still be responsible for controlling the UX.

No, we cannot make every plugin in existence obey the same pattern for handling permissions but ensuring that they follow the best practices will be part of the minimum quality standard for acceptance into the community.

[tafelnl]

Thank you for your elaborate answer.

To be clear, the plan is not "remove the ability to check permissions" but rather "break the permissions API out into the separate plugins.

I totally agree with the philosophy here.

However, what I might not have explained good enough in my first comment is the following:

I do not want to the permissions plugin to be exclusively responsible for checking/requesting permissions. I totally agree that every library should handle permissions on it's own. Especially since Android (an iOS maybe) like to crash when you are trying to use an API that you do not have permission for.

But I also think that there should be a universal permission API available. So that when there is the need of customizing the permission flow, every developer can use the same best practices. Both in native and in JS code.

So practically this may come down to indeed breaking down every type of permission into its own class. But with an abstract class as its parent, so that common permissions as granted, denied and prompt can be handled easily. When an API has more advanced permissions, the abstract class can be extended to accept multiple types.

Just some ideas.

But again, I think the most important takeaway here is that I think the JS client should still have consistent access to the same permission APIs, just like the native code has.