Onboarding after in-app reset: Notifications are not activated

[dsarkar]

Avoid duplicates

• [x] Bug is not mentioned in the FAQ
• [x] Bug is not already reported in another issue

Technical details

• Device name: iPhone 6s
• iOS Version: iOS 14.4
• App Version: 1.15.1

Describe the bug

Onboarding after In-App reset: Notifications are not activated.

Steps to reproduce the issue

1. install CWA
2. in-app reset
3. OS settings > Notifications > Corona-Warn > Allow Notifications: set slider to OFF
4. start CWA onboarding
5. On screen 5 "Receive warnings and ..." select "Next"
6. Observation: The iOS notification pop-up to allow notifications is missing
7. complete onboarding
8. check: OS settings > Notifications > Corona-Warn > Allow Notifications: slider is OFF

Expected behaviour

Onboarding after In-App reset: Notifications should be activated when desired

Possible Fix

Additional context

This issue does not occur when re-installing CWA, only after in-app reset

---

Internal Tracking ID: EXPOSUREAPP-6000

[Ein-Tim]

@dsarkar I don't see a fix for this in version 2.0.3.

[dsarkar]

@Ein-Tim Indeed, was not fixed. Onboarding story has to be changed.

---

Corona-Warn-App Open Source Team

[ndegendogo]

According to Apple documentation: Asking Permission to Use Notifications: "The first time your app makes this authorization request, the system prompts the user to grant or deny the request and records the user’s response. Subsequent authorization requests don’t prompt the user."

In the onboarding after loading the app freshly, (for the very first time, or after having deleted cwa), this is regarded as "the first time". However, an in-app reset is not. So in that case the previous setting survives. If the user had the notifications allowed, they stay allowed. If the user had the notifications disabled, they stay disabled. iOS will not show another prompt to the user.

[ndegendogo]

I don't find any mechanism to force this dialog after this first time. However, we can programmatically find out the current status of notification settings, and especially the current authorisation status.

So the issue could be mitigated as follows:

• during onboarding, we retrieve the current authorisation status.
• if it is notDetermined, the user will get the dialog and all is fine.
• if it is authorised, the user has agreed to notifications before, and all is fine. No harm if the dialog is not shown.
• same for provisional or ephemeral
• however, if it is denied, we can send the user into their settings, so they get a chance and reminder to think about the settings and change them.

This should be at the end of the Onboarding flow. So even when the user leaves the Settings with the Home button, and does not return directly to cwa, he is not forced to go through the Onboarding flow a second time.

[svengabr]

I have just checked the linked Jira issue.

Jira Ticket is flagged as: Resolution: Unresolved Status: BLOCKED

Developer comment:

if the notification is shown or not is not under the control of the CWA. If the user has declined notification once, the OS does not ask for permissions again.

The preferred solution would be to show a different screen if notifications are disabled which informs the user how to enable notifications again in the OS settings. Moved the bug to a story as this needs to be planned incl. UX Design.

The Jira issue is stale for a year. I have re-assigned the issue and asked for an update on this topic.

[30mar]

will set to obsolete as the effect is only until 31.4.2023