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

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

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.