Hello guys,
while testing the implementation of https://developer.apple.com/documentation/apptrackingtransparency
we discovered that chainging the ATT-state (enabling / disabled tracking) in the system settings terminates the running app.
This makes it impossible to properly use a classic and endorsed design pattern:
If setting is "No / disabled" inform user that he needs to change his system settings and offer him a direct link to do so.
This still works great for things like location, health, etc. but in this case the user will kill the app by following the pattern.
We realize that this forces a restart and thus a clean app experience with the newly adjsuted setting but wouldn't a callback/notification be the standard and offer a vastly improved user experience that iOS-users have grown acustom to?
This means that if users that have once decided on a setting want to change it will have to restart the app (without knowing that it will happen) and thus probably lose their state/progress in the currently running app even when using some form of app state restauration.
Are we missing something that would improve the experience here?
while testing the implementation of https://developer.apple.com/documentation/apptrackingtransparency
we discovered that chainging the ATT-state (enabling / disabled tracking) in the system settings terminates the running app.
This makes it impossible to properly use a classic and endorsed design pattern:
If setting is "No / disabled" inform user that he needs to change his system settings and offer him a direct link to do so.
This still works great for things like location, health, etc. but in this case the user will kill the app by following the pattern.
We realize that this forces a restart and thus a clean app experience with the newly adjsuted setting but wouldn't a callback/notification be the standard and offer a vastly improved user experience that iOS-users have grown acustom to?
This means that if users that have once decided on a setting want to change it will have to restart the app (without knowing that it will happen) and thus probably lose their state/progress in the currently running app even when using some form of app state restauration.
Are we missing something that would improve the experience here?