I am having an app in which we are using NEHotspotHelper to detect wifi changes. when I try to kill the app and network change detected, we are seeing logs in NEHotspotHelper* module and after that we are able see the logs indicating app launched in background.
[Application] application(_:didFinishLaunchingWithOptions:), UIApplicationState: 2
But when I checked in the app stack, I couldn't find the app. Then I clicked icon to launch the app, it launched without splash screen as if it came from background.
Need your support to understand this is expected behaviour.
Yes, everything you've described is expected behavior. That is, the system launched the app into the background without adding it to the app stack, so it was already running when you touched the icon.
The confusion here comes from a misunderstanding of that the app stack actually is. More specifically, what the "app stack" actually is a list of the apps the user has interacted with, sorted by the order they were interacted in. With few exception, the order and contents of the app stack is determined ENTIRELY by the users own interactions and, by design, the system does not insert apps into or remove apps from the stack "on it's own".
Importantly, that also means:
-
The presences of an app in the app stack does NOT mean the app is actually running.
-
The absence of an app from the app stack does NOT mean it ISN'T actually running.
That leads to here:
I try to kill the app and network change detected, we are seeing logs in NEHotspotHelper* module and after that we are able see the logs indicating app launched in background.
Note: What I describe below it is simply the system current behavior. None of this behavior is formally documented, many of the details have changed over time, and it's entirely possible that they'll change in the future.
The current behavior of the system is that it does not launch apps the user has force quit (removed from the app stack). The primary reason for this it to try and avoid the need to create a new multi-level "force quit" then, "no, REALLY force quit" system which would force the user to manually control which apps the system would launch. However, a secondary reason is to minimize the number of apps can "invisibly" run in the way you're describing
However, there are a small number of exceptions to this rule off the top of my head:
-
Direct user interactions like interacting with notifications can launch apps.
-
PushKit will launch force quit voip apps for incoming call pushes.
-
To avoid weird edge cases failures (for example, the user force quits the app every night and launches it every morning), BGProcessingTask will launch force quit apps under very limited circumstances.
-
To support very long running location triggers (for example, "I've arrived at the airport"), certain kinds of location monitoring will launch force quit apps.
NEHotspotHelper is basically a variation of that last case. It can often be days or weeks before a particular hotspot app is useful and that's long enough that many users will force quit the app to "get it out of the way" or because "they don't need it now", not because they "don't want it to ever run".
__
Kevin Elliott
DTS Engineer, CoreOS/Hardware
