1

I've turned off my iPhone. Then I turn it back on.

I have my phone connected to the macOS console. I filter by process:SomeAppName And about 1 minute after reboot, I see app name appear with that filter.

Is that expected?

mfaani
  • 33,269
  • 19
  • 164
  • 293
  • TIL: "anything with background permissions". Is that documented? I suppose it has to do that so it re-registers every process to listen for things e.g. notifications, location tracking. But is that necessary? I mean for the same way that an app is registered for silent notifications while it's out of memory, can't the registration be persisted without the need to launch the app after reboot? FWIW this app that I saw launching upon reboot: uses hotspotHelper – mfaani Nov 17 '21 at 16:45
  • And no. I haven't see all apps opened... – mfaani Nov 17 '21 at 17:04
  • Re “hotspot helper,” I could easily imaging that they are using background location services as the trigger to determine what hotspots are available at the new location. Background location services can be configured to trigger an app launch. – Rob Nov 17 '21 at 18:59
  • @Rob see https://support.apple.com/en-us/HT208086 The OS would do that. "- You turn on Wi-Fi in Control Center. - You connect to a Wi-Fi network in Settings > Wi-Fi. - You walk or drive to a new location. - It's 5 AM local time. - You restart your device." i.e. no need to have location tracking – mfaani Nov 23 '21 at 22:52
  • There is not a public API for waking your app on the change of wifi status. (For BLE, yes, but not wifi.) If "hotspot helper" is a third party app, it's likely relying upon location or some other service to connect. If this is some internal iOS service, then they might be availing themselves of whatever private API they have access to. But as app developers, we can't wake our apps on wifi changes. – Rob Nov 23 '21 at 23:02
  • @Rob Were you thinking that HotSpotHelper is some random app? It's an Apple framework. These are the commands they have: https://developer.apple.com/library/archive/documentation/NetworkingInternet/Conceptual/Hotspot_Network_Subsystem_Guide/Contents/CommandHandlingDetails.html ‘evaluate’ is a callback that you get upon an attempt to connect to a wifi network. ‘Filterscan’ is one that you get upon scanning the wifi. There are more but these are public API. Also see [here](https://developer.apple.com/documentation/networkextension/hotspot_helper) – mfaani Nov 24 '21 at 12:11
  • 1
    No, I’m not saying that `NEHotspotHelper` is private. (And , yes, I was not clear whether your reference to “hotspot helper” was referring to the daemon for `NEHotspotHelper` or whether you were talking about some third party app.) Regardless, I’m saying that the API/mechanism that that that daemon uses internally to fire up that process when the device is rebooted is private. (And, if I’m not incorrect, that’s what this question was about, namely, why did that particular process start when the phone was rebooted and, more generally, whether “all apps” are restarted.) – Rob Nov 24 '21 at 13:02

1 Answers1

2

It would not “open all apps.” But certainly, it may open some apps (e.g., particularly certain “Background Modes” that are configured under a target’s “Capabilities”). See About the Background Execution Sequence, About the App Launch Sequence, Choosing Background Strategies for Your App, and WWDC 2020 Background execution demystified. None of these enumerate the specific cases where apps can be launched in the background automatically, but might be a starting point for your research.

FWIW, each of the target “Capabilities” » “Background Modes” has slightly different behaviors (i.e., some cause an app to be relaunched in the background triggered by some system event, others launch at the discretion of the OS, for example, if on wifi and/or when charging, and some gather data out-of-process and are delivered when the user launches the app). So you have to go through these individual “background capabilities”, one by one, and see which cause the app to be launched in the background and which do not.

But if an app has one or more background capabilities enabled, it could easily be relaunched. The “Background fetch” and “Background processing” are two prominent examples that can easily cause the app to be launched in the background without user intervention. The background location services can be configured either way (launch the app on location change vs. deliver location updates when the user next launches the app). It just varies for each of these background modes. As a general rule, Apple tries to offer out-of-process solutions where it can (to minimize power-draining launches of apps in the background), but provides methods to have the app launched in the background where needed.

In the past we would have concerned ourselves solely with apps being launched as a result of background capabilities. But, as About the App Launch Sequence says, iOS 15 complicates the “which apps might launch” question, as it has “prewarming”. So that might cause apps to launch in the background without user intervention, too.

You ask:

Would the app get killed/suspended after getting launched?

As a general rule, apps are never “killed”, unless you violate the contract of the background execution (e.g., fail to call the completion handler appropriate for that background service or block the main thread and get killed by the watchdog process). All of the various background modes have some mechanism to gracefully inform the OS that your background process is done and that the app can now be suspended again. But in those cases where the OS kills a misbehaving app, it generally no longer participates in future background execution, which is why it is so important to finish background processes gracefully.

Obviously, suspended apps can be evicted/jettisoned when memory is required by the OS. But this graceful termination is very different than an app being “killed.”

BTW, to clarify the observation that killed apps will not be launched by most background services, the old “App Programming Guide for iOS” gave us hints about how most background services will not be launched again, but that background location services might. The guide is no longer found on Apple’s site, but here is the relevant excerpt:

In most cases, the system does not relaunch apps after they are force quit by the user. One exception is location apps, which in iOS 8 and later are relaunched after being force quit by the user. In other cases, though, the user must launch the app explicitly or reboot the device before the app can be launched automatically into the background by the system. When password protection is enabled on the device, the system does not launch an app in the background before the user first unlocks the device.

The new documentation verifies that background location services “relaunch an app … even after the user force-quits your app.” But this older quote places that observation in a broader context.

Rob
  • 415,655
  • 72
  • 787
  • 1,044
  • 1. I don't think the iOS15 stuff are related to the cold start mentioned by myself [here](https://stackoverflow.com/questions/69623550/whats-the-difference-between-cold-launch-warm-launch/69623551#69623551): "Cold launches occur after reboot" That's solely talking about _user_ opening after reboot I assume. Right? 2. Trying to understand the wording of the link you shared about App Lanch. Does the following mean it shouldn't ever hit `didFinishLaunching`? "Prewarming executes an app’s launch sequence up until, but not including, when `main()` calls `UIApplicationMain(_:_:_:_:)`" – mfaani Nov 17 '21 at 17:46
  • Following along the note on location tracking you made, the hotspothelper functionality seems to launch a killed app upon scanning wifi or connecting to a wifi network – mfaani Nov 17 '21 at 19:52
  • I know what background fetch is. What is 'background processing' about? Are you talking about the new API that replaced background fetch? i.e. [BackgroundTask](https://developer.apple.com/documentation/backgroundtasks)? – mfaani Nov 24 '21 at 11:49
  • Yes, when I used the term “background processing”, I was referring to that particular checkbox in the “Background Modes” of your target’s capabilities. And, yes, this checkbox is associated with one’s requesting permission to use [`BGProcessingTask`](https://developer.apple.com/documentation/backgroundtasks/bgprocessingtask), one of the two types of background tasks in that link you reference. (This background processing task is the sibling to the background fetch task, [`BGAppRefreshTask`](https://developer.apple.com/documentation/backgroundtasks/bgapprefreshtask).) – Rob Nov 24 '21 at 13:30
  • In short, background processing is for time-consuming tasks, often non-network related. The aforementioned [Background execution demystified](https://developer.apple.com/videos/play/wwdc2020/10063/) video walks through this, as does the prior year’s [Advances in App Background Execution](https://developer.apple.com/videos/play/wwdc2019/707). – Rob Nov 24 '21 at 13:41
  • Prewarming is iOS 15 and this might be a good read on potential issue with it https://twitter.com/steipete/status/1466013492180312068 – CyberMew Jan 20 '22 at 09:03