Compliance with iOS Permissions Guidelines

[JGreenlee]

Our current permissions flow is deemed unacceptable. I think this is due to:

• On iOS 13+ for location settings, we send users to the settings page without prompting any of the system popups for location requests
  • I think we are doing this to avoid the "provisional" always authorization flow, which does not work well for OpenPATH's use case. We need users to allow "always" upfront, otherwise there is no point in using the app.
  • On iOS 13.4+, we can use a 2-step strategy, where we first obtain 'when in use' permission, then obtain 'always' permission, to avoid the "provisional" always flow https://developer.apple.com/videos/play/wwdc2020/10660/?time=1274. If we do this, then it is only iOS >=13,<13.4 that we have to send users to the app settings page.
• Notifications permissions have to be optional but are currently required
  • I believe that this only applies to user-facing notifications, not silent notifications. If the users refuses this permission, tracking should still work and we can allow them to proceed. All users will be missing is labeling reminders.

And perhaps a third point:

• The verbiage we use to describe the permissions (e.g. "Fix", "Please select 'Always allow'", etc) could be perceived as "displaying a screen or window that looks like a request" or "influencing" the user's choices https://developer.apple.com/design/human-interface-guidelines/privacy#Pre-alert-screens-windows-or-views

---

I am working on the changes to resolve these issues, and hopefully provide a better onboarding UX in the process.

[JGreenlee]

Given that latest versions of iOS will use a two-step strategy, and latest versions of Android are also using a two-step strategy (#990, implemented in e-mission/e-mission-data-collection#210), I think the best long-term solution may be to split the "Location Permissions" item into two separate items

However, for now I will just try to meet the guidelines as quickly as possible so we are unblocked

[shankari]

I think we are doing this to avoid the "provisional" always authorization flow, which does not work well for OpenPATH's use case. We need users to allow "always" upfront, otherwise there is no point in using the app.

Yes. We used to use the standard popups, but then people would not give us the correct permissions and then complain that "the app does not work"

[shankari]

@catarial is going to help verify

I believe that this only applies to user-facing notifications, not silent notifications.

To do that, we need to turn off the notification permission and see if we still get the silent push notifications once an hour.
However, we currently include the notification checks as part of the regular "is my app working" checks that we do in the background, and I think that if the checks fail, we go into the START state. My recollection is that we should keep getting the push notifications even in the start state, but we should verify that.

So I would suggest two potential ways to check this:

Option 1:

1. turn off location from the app settings
2. wait for 4 hours; check to see that we went into the START state, but we do see the T_RECEIVED_SILENT_PUSH logs
3. then turn location on, but turn notifications off
4. wait for 4 hours; see if we received T_RECEIVED_SILENT_PUSH in the same way

Option 2:
We can also just disable the notification checks so that the FSM will stay in the WAITING_FOR_TRIP_STATE. In that case, we would need to change code, but we don't need to turn the location off first to set the baseline because we will still be in a valid state.

The set of checks for validity are:
https://github.com/e-mission/e-mission-data-collection/blob/dcc4853919089527427c444260f63a49dca66af3/src/ios/Verification/TripDiarySensorControlChecks.m

So to hack, we can just change checkNotificationsEnabled to always return TRUE.

With either option, we should be able to see whether turning off notifications affects silent push notifications. So we know/can see that we get silent push when the notification permission is present; do we get them when the permission is off.

[catarial]

I left the simulator running with the notification check disabled for about 2 hours and the only thing I saw in the debug logs was one instance of "Ignoring silent push notification".

[catarial]

Im getting the same thing when I turn notifications back on. I need test this more. What makes this most challenging is that I have to disable push notifications to be able to install the test app on a real phone.

[catarial]

I'll try option 1 with the app store version on a real phone and see what happens tomorrow.

[shankari]

@catarial push notifications are not delivered to the simulator (you may see the notification about that when you start up the app). You have to try it on a physical phone.