application(_:didFinishLaunchingWithOptions:) not called on MDM iPads after overnight idle — app resumes without cold start

We are seeing a strange lifecycle issue on multiple MDM-managed iPads where application(_:didFinishLaunchingWithOptions:) is not called after the device is idle overnight.

Even if we terminate the app manually via the app switcher, the next morning the system does not perform a cold launch. Instead, the app resumes directly in:

So, my first question here is how sure you are about EXACTLY what's happening. In particular, how do you KNOW didFinishLaunchingWithOptions is not being called?

In particular, how does your logging infrastructure work and how far "back" in time would it track? My concern here is that what's missing here isn't that didFinishLaunchingWithOptions isn't being called, but that the app was actually initialized at some much earlier point in time when the system launched your app into the background and then suspended it, potentially hours earlier than the point you actually opened it.

We have full logs from four separate MDM iPads showing identical behavior. Happy to share a minimal reproducible sample if required.

Do you have sysdiagnose(s) or just your own app logs? If you have a sysdiagnose, the please file a bug and post the bug number back here. In the bug report please make sure you mention exactly which app launch you consider problematic.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

Hi Kevin,

Q - How we know didFinishLaunchingWithOptions is not being called at user-visible launch time

We agree that the most important question here is when the app was actually initialized versus when the user opens it.

To address this, we have implemented explicit lifecycle logging at the very earliest entry points of the app, including:

• A log at process start
• Logs at the very beginning and end of application(_:didFinishLaunchingWithOptions:)
• Logs for all other UIApplication lifecycle callbacks

We log all lifecycle events (including process start and didFinishLaunchingWithOptions) using a dedicated serial queue and persist them directly to disk.

In simplified terms, our logging flow is:

• Logs are written via a serial logQueue

• Each log entry is appended to a file in the app’s Documents directory

• Logs include:

  • ISO timestamps
  • Explicit lifecycle markers
  • The process ID (pid)

This means:

• Logs are persisted to disk, not memory
• Logs survive suspension and backgrounding
• We do not clear or rotate logs on background transitions
• Each app process appends to the same log file

How far back the logs go

• Logs accumulate over time and remain available until explicitly uploaded
• We upload the full log file to our backend (AWS) at specific trigger points
• Because logs are file-based, they capture events that occurred many hours earlier

This allows us to determine:

• Whether a new process was created
• Whether didFinishLaunchingWithOptions was entered for that process
• Whether a user-visible launch is happening within an already-running (or resurrected) process

In the problematic cases:

• The pid remains the same
• There is no PROCESS_STARTED
• There is no DID_FINISH_LAUNCHING_START
• The app resumes directly into applicationDidBecomeActive(_:)

This behavior is consistently reproducible on supervised MDM devices and has not been observed on non-MDM devices so far.

Logs include: ... The process ID (PID)

First off, thank you and congratulations on having the foresight to include that. I've long recommended that developers include that in their logging since, from past experience, I've seen FAR too many "weird problems" that were not in fact "weird" once it was clear that the logging was coming from the same or different process.

The PID remains the same

Then this:

Terminate it manually via the multitasking app switcher.

...did not happen. Per standard Unix semantics, process ID's are uniquely assigned at creation. PIDs are reused if/when the process ID space is exhausted and the "wraps" back around; however, they're a 32-bit value (so exhausting the space isn't trivial) and, more importantly, system process creation is "chaotic" enough that getting the same PID doesn't really happen. It's difficult to do INTENTIONALLY[1], so this isn't something that’s going to happen by accident.

[1] There are a class of security attacks that rely on getting the same PID as a previously/recently terminated process, so some amount of work has gone into figuring out how to do this.

Similarly, all of the things "failed" to happen:

There is no PROCESS_STARTED There is no DID_FINISH_LAUNCHING_START The app resumes directly into applicationDidBecomeActive(_:)

...because your process did not in fact "start“; it was already running.

This behavior is consistently reproducible on supervised MDM devices

What is your MDM configuration actually "doing"? Are you locking the device into single app mode? I haven't looked into this in detail, but I wouldn't be surprised if locking the device into single app mode disabled the normal force quit operation. Similarly, the full range of configuration options is large enough that I wouldn't be surprised if one of them disables force termination.

As a side note, keep in mind that our interfaces are not always "trustworthy" once MDM is involved. Quoting myself:

"Across our technology stack, there are often many points where any given "block" could be implemented, with the general trade-off being that lower-level blocks are harder to bypass but also make it more difficult to provide "feedback" as to what's actually happening. There are exceptions, but in general, our MDM "blocks" tend to be implemented at lower levels of the system at points that minimize the "disruption" to the rest of the system. This both makes them harder to bypass and reduces the risk that they'll cause other problems."

...even if that means that some of our UI may show the wrong value or not work as expected. This forum thread has an example of how this can play out.

With all that context, let me return to here:

Even if we terminate the app manually via the app switcher, the next morning the system does not perform a cold launch. Instead, the app resumes directly in:

What are you actually trying to do here? Why is it important that your app cold launch? If you specifically want your app to cold launch then the simplest way to do so is to simply have it call exit(). While that's generally something we generally discourage, as it will look like your app has crashed, exit() is an API and there are situations where it's a very reasonable choice.

Notably, I STRONGLY recommend that developers of apps that are designed to be "locked" into single app mode and run "forever" include some kind of periodic exit call in their design. The problem here is that it's not unusual for an app to include small bugs (notably Mach port leaks) which will eventually cause catastrophic failure IF the app runs "long enough". It's one thing to test and validate that your app works great when run continually for a few days or a week. It's quite another to validate that your app works great after running for a month... or 3 months... or 6 months[1].

[1] This is not hypothetical. I once helped a developer investigate an app hang that ONLY occurred after his app had been in the foreground CONTINUALLY for 6+ months. I eventually determined that, ironically, the diagnostic code they'd added to improve stability by tracking resource usage (primarily memory) was slowly leaking Mach ports, eventually causing their entire app to seize up.[2] They were able to find and fix the issue, but if they'd simply called "exit()" every few weeks, they'd have never had an issue.

[2] This is also my canonical example of why using our Mach APIs is a terrible idea. They're difficult to use correctly, and incorrect usage will cause wildly unpredictable but generally catastrophic failures.

__
Kevin Elliott
DTS Engineering, CoreOS/Hardware

Hi Kevin,

The sysdiagnose files are quite large (3 files, ~250–300 MB each), so we’ve uploaded them to Google Drive.

Drive link:

https://drive.google.com/drive/folders/1RyEuo2zCoNHyHMUD8cVQqW3mZWki3aN0?usp=sharing

These correspond to the issue we encountered again on January 16. Please review and let us know if you need anything else from our side.

Thanks, Manish

These correspond to the issue we encountered again on January 16. Please review and let us know if you need anything else from our side.

I've looked over all three logs and, to be honest, I'm a bit confused as to what you're asking. I've looked over all three logs and basically found exactly what I expected. That is:

• All logs include at least one case where the app was launched on one day and reopened the next day.

• There's no evidence at all that any attempt was made to quit/terminate the app.

• Everything in the log indicates that this is perfectly normal system behavior, as the app was simply suspended on one day and then resumed the next day.

There is one oddity in the console log from:

sysdiagnose_2026.01.16_09-00-46-0600_iPhone-OS_iPad_23A355

That log has two "overnight" runs (4774, 6054) mixed in with many other runs, with the oddity being that both apps run for ~2s after they return to the foreground (the next day), then stop running. I can't tell for certain exactly what happened from the available data, but it wasn't triggered by the system itself and the process simply exited, so I suspect this was something you chose to implement (by calling exit).

That leads me back to the question I asked here:

What are you actually trying to do here? Why is it important that your app cold launch?

Expanding on that, the basic behavior you're describing is entirely normal iOS behavior, which means the real question here isn't really "why is this happening?", but is actually "why is this a problem for your app?".

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

Hi Kevin,

As per our tester, he explicitly ensured that the app was force-closed at the end of the day. However, as you correctly pointed out, the logs indicate that the app was never actually terminated by the system—it was moved to the background and then resumed the next morning.

The challenge we are facing is that certain functionality does not behave correctly when the app resumes the next day without a normal cold start. The primary issue is with the SLM (Sound Level Meter) framework, which relies on audio sessions. In these resumed states, the audio session is not always reinitialized cleanly, causing our calibration process to fail and leading to the core issue we observed.

To address this, we implemented a controlled, app-initiated exit in such scenarios to ensure the app always starts in a clean state. This approach resolved the issue successfully.

More recently, we encountered a case where we did not even receive the applicationDidEnterBackground callback. We extended the same force-exit handling to cover this scenario as well.

And We shared the corresponding sysdiagnose files to confirm whether this behavior is possible under MDM / Single App Mode conditions and to ensure that this approach is acceptable and would not negatively impact the app review or expected system behavior.

Please let us know if this aligns with expected platform behavior or if you see any concerns with this approach.

Thanks, Manish Lalwani

The challenge we are facing is that certain functionality does not behave correctly when the app resumes the next day without a normal cold start. The primary issue is with the SLM (Sound Level Meter) framework, which relies on audio sessions. In these resumed states, the audio session is not always reinitialized cleanly, causing our calibration process to fail and leading to the core issue we observed.

If you haven't already, this sounds like something worth filing a bug about. Have you, and if so, what's the bug number?

More recently, we encountered a case where we did not even receive the applicationDidEnterBackground callback. We extended the same force-exit handling to cover this scenario as well.

Do you have any more information/context about this case? There are cases where apps aren't formally put "into" the background (for example, I believe swiping control center down will trigger applicationWillResignActive but NOT applicationDidEnterBackground), but all of these cases should also mean that the app isn't really "in the background". Notably, it should NOT be possible for an app to suspend without applicationDidEnterBackground first having been sent to the app. Indeed, blocking or taking too long to receive applicationDidEnterBackground will cause the system to terminate your app.

That leads to here:

As per our tester, he explicitly ensured that the app was force-closed at the end of the day. However, as you correctly pointed out, the logs indicate that the app was never actually terminated by the system—it was moved to the background and then resumed the next morning.

Short of putting a camera over your users’ shoulder, there isn't really any way to know EXACTLY what happened in a given testing scenario. However:

• Whatever the console log shows is what happened as far as the lower-level system is concerned. For example, in theory [1], it's possible that some kind of UI bug might make it look like a force quit occurred when "nothing" actually happened. It's NOT possible that the system initiated that quit and the quit then failed invisibly. Even if the quit [2] failed, that's the kind of thing that's visible in the system log.

• The processes (app launching, app backgrounding, etc.) we're talking about are all part of the system "core" design, common to basically "every" app on the entire system. That doesn't mean that they're necessarily bug-free, but it does mean that bugs in this area are not particularly common and, when they do occur, they're never straightforward or "obvious". That's not necessarily because of any special "perfection" on our part, but simply because a straightforward failure tends to be extremely visible/problematic.

Because of those factors, I would always start with the assumption that the system did what it was "supposed" to do and that whatever you think you're seeing is either caused by a problem with your app and/or the data you're looking at.

And we shared the corresponding sysdiagnose files to confirm whether this behavior is possible under MDM / Single App Mode conditions and to ensure that this approach is acceptable and would not negatively impact the app review or expected system behavior. Please let us know if this aligns with expected platform behavior or if you see any concerns with this approach.

So, let me answer that in a few different ways:

• In terms of the broader "system", calling exit has no real impact. The system is already prepared for apps to just "go away" (that's what happens when an app crashes) and, from that perspective, exit() is just an abort() that doesn't generate a crash log.

• Strictly speaking, there are a few code paths [3] where your app actually ends up calling exit() already, so the call itself isn't actually that "new".

• From an App Review/user experience perspective, the issue with exit() is that it's functionally equivalent to your app crashing. Calling exit in the foreground is grounds for rejection by App Review because, quite correctly, it's considered "an app crash"... because that's what it "is". If your call to exit isn't "visible" (because your app isn't in the foreground), I don't see why there'd be an issue.

Single App Mode conditions

The first thing I'll say here is what I said in an earlier post:

Notably, I STRONGLY recommend that developers of apps that are designed to be "locked" into single app mode and run "forever" include some kind of periodic exit call in their design. The problem here is that it's not unusual for an app to include small bugs (notably Mach port leaks) which will eventually cause catastrophic failure IF the app runs "long enough". It's one thing to test and validate that your app works great when run continually for a few days or a week. It's quite another to validate that your app works great after running for a month... or 3 months... or 6 months.

I stand by that advice, as I think it is EXTREMELY difficult to create an app of any complexity that will actually work "perfectly" when run in the foreground for weeks/months. Software quality is obviously still important, but it's simple enough for an app to do some very simple tracking (or just make it a setting) on the local device and then call exit at whatever time is least likely to be noticed by the user. Just like the broader system, SAM (Single App Mode) will treat this as a crash and relaunch your app, so the only real impact is that your app is briefly unavailable as it's relaunched.

[1][2] Note that both of these are entirely theoretical examples that I just made up. I've actually never seen ANY case where a user’s initiated force quit failed.

[3] Most notably, what actually happens when a user force quits an app is that the system calls "applicationWillTerminate" and if/when that returns, your app then calls exit().

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware