App Logout / Termination Behavior When Changing Bluetooth Settings With and Without Multitasking

When changing Bluetooth settings from the system Settings app without using multitasking, the app does not terminate but instead logs the user out.

However, when changing Bluetooth settings while using multitasking, the app terminates completely.

I'm not sure what you're actually referring to here. What do you mean by "while using multitasking"? Are you talking about iPadOS's multitasking interface? Or something else entirely?

In terms of the question here:

Whether there is any system behavior that causes the app to refresh or restart when Bluetooth settings are changed

No, the system doesn't do anything special/unusual with this setting. Generally speaking I wouldn't expect toggling the bluetooth state to have any effect on apps, however, that actual behavior would depend on the details of the apps involved (particularly memory use).

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

“while using multitasking” means reducing the app’s size and displaying it side by side with the Settings screen at the same time. For better understanding, I will attach an image.

Additionally, I found that YouTube also terminates when the “Allow Tracking” permission is changed in Settings while using the multitasking interface.

“while using multitasking” means reducing the app’s size and displaying it side by side with the Settings screen at the same time. For better understanding, I will attach an image.

Ahh, now I understand. So, the first thing to understand here is that a number of our settings (particularly around authorization) don't really have a "unauthorize" path. That is, many APIs provide a way for an app to check if they're authorized, but they don't have a notification/delegate for "you used to be authorized but now you're not". Often this issue is as much architectural as it is API. For example, in the case of Bluetooth you'd need to invalidate all existing Bluetooth objects (since the app doesn't have access anymore) and you'd also need a way to recreate them again (when authorization is restored). All of this is quite unwieldy, so instead of building that architecture, the system just terminates the app instead. As you noticed, this is "Allow Tracking“ example:

Additionally, I found that YouTube also terminates when the “Allow Tracking” permission is changed in Settings while using the multitasking interface.

Another example is changing the interface language. Even at the system level, we don't "change" the language of running apps, we terminate everything (both system UI and apps), then relaunch the "entire" system. Similar to the case above, the issue isn't that we COULDN'T make this dynamic, it's that making it dynamic would be a lot of extra work and risk without a great deal of extra value.

That leads back to what you said here:

...the app does not terminate but instead logs the user out.

I didn't mention this in my original post, but the system can't really "do" that. The system doesn't really know what your app "does" and can't really force it to perform a high-level state change like "logging out". What actually happened here wasn't that your app logged out, it was the system terminated your app when the setting was changed and your app then launched back in the "logged out" state.

In other words, both of the two cases here are actually doing the same thing (terminating the app when the setting changes). They just look different due to how the overall user experience works.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware