General: DevForums subtopic: App & System Services > Processes & Concurrency Processes & concurrency covers a number of different technologies: Background Tasks Resources Concurrency Resources — This includes Swift concurrency. Service Management Resources XPC Resources Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com"

hello, i have an issue spawning continued background processing tasks: they are never started, even after restarting the device, regardless of which app spawns a task. deleting and reinstalling an app, or installing a new app that didn't exist before also does not work. it can be reproduced by setting your device local time to one year in advance and then trying to spawn the task. the task will not start and even after returning to the proper date, all apps on the device are still unable to spawn any. i also believe there are other things that trigger this issue (or something related), as many of my users have complained about tasks not starting. prior to my changing the date of my device, they worked perfectly for me. one user changed their date to test at the same time as me and the only fix they found was erasing their device and restoring a backup. on ios 26 tasks fail silently, but on ios 27 with the new api to submit a task, an error is caught: Error Domain=BGTaskSchedulerErrorDomain Code=1 "connection to service with pid 94 named com.apple.duetactivityscheduler" UserInfo={NSDebugDescription=connection to service with pid 94 named com.apple.duetactivityscheduler} in addition, a more detailed error with a stack trace is logged at the same time: <NSXPCConnection: 0x10c60c0a0> connection to service with pid 94 named com.apple.duetactivityscheduler: Exception caught during decoding of reply to message 'submitTaskRequest:withHandler:', dropping incoming message and calling failure block. Ignored Exception: Exception while decoding argument 0 (#1 of invocation): <NSInvocation: 0x10c6d72c0> return value: {v} void target: {@?} 0x0 (block) argument 1: {@} 0x0 Exception: value for key 'NS.objects' was of unexpected class 'NSSet' (0x20620c358) [/System/Library/Frameworks/CoreFoundation.framework]. Allowed classes are: {( "'NSDate' (0x20620c268) [/System/Library/Frameworks/CoreFoundation.framework]", "'NSError' (0x2061fd3b0) [/System/Library/Frameworks/Foundation.framework]", "'NSNumber' (0x2061fd478) [/System/Library/Frameworks/Foundation.framework]", "'NSData' (0x20620c650) [/System/Library/Frameworks/CoreFoundation.framework]", "'NSArray' (0x20620c6c8) [/System/Library/Frameworks/CoreFoundation.framework]", "'NSString' (0x2061fd428) [/System/Library/Frameworks/Foundation.framework]", "'NSDictionary' (0x20620c538) [/System/Library/Frameworks/CoreFoundation.framework]", "'NSURL' (0x20620c678) [/System/Library/Frameworks/CoreFoundation.framework]" )} ( 0 CoreFoundation 0x000000019fbc2e0c 43092235-E272-3CAF-B9AE-76669EC5AE46 + 622092 1 libobjc.A.dylib 0x000000019f940298 objc_exception_throw + 88 2 Foundation 0x00000001a002beac E642F95D-61DA-3E8C-A2D2-CFEB7F7B688B + 126636 3 Foundation 0x00000001a0035090 E642F95D-61DA-3E8C-A2D2-CFEB7F7B688B + 163984 ...

We're working on an Endpoint Security extension and using Swift 6 with Concurrency. I've heard there are some subtleties to getting the threading right across those two domains and am hoping that someone can help shed light on it. In particular, ES events can be delivered on a high priority thread and I'd like to be sure that any work done in the Concurrency domain retains that priority to minimize latency between event delivery and response.

We are developing a system consisting of two iOS apps from the same developer (same Team ID): ・App A acquires data from an external accessory. For regulatory/compliance reasons that we cannot detail here, App A must have no networking capability at all. ・App B is intended to receive data from App A and upload it to a server. Two important environmental constraints: ・The deployment environment is a closed local network. The server App B talks to is on the local network, and Internet access is not guaranteed. Therefore, any APNs-dependent approach (silent push, etc.) is not viable. ・Latency requirement: near-real-time is ideal, but a delay of up to a few minutes is acceptable. What we have considered: 1.App Groups shared container — App A can write data, but there is no way to wake App B in the background when new data is written. 2.URL schemes — can launch App B reliably, but bring it to the foreground, which disrupts the user's workflow. 3.BGTaskScheduler — rejected; execution timing is entirely at the system's discretion. 4.Silent push — rejected; requires APNs / Internet connectivity, which we cannot assume (see above). Our current leading candidate is a combination of (1) and (2): App A writes data to the App Groups container, then opens App B via a URL scheme; App B reads the container and uploads. This works, but the foreground app switch on every hand-off is far from ideal. We are aware that some apps abuse background modes (e.g., playing silent audio) to stay resident. We assume this violates App Review Guideline 2.5.4 and is not an option for us — please correct us if there is any legitimate variant of this approach. Questions: 1.Is there any supported mechanism to keep App B running (or reliably woken) in the background, so that it can receive data from App A and upload it — without user interaction and without Internet access? 2.If not, is there any way to mitigate the foreground switch in our current App Groups + URL scheme approach (e.g., returning to App A automatically after the hand-off)? Or would that ping-pong pattern itself be an App Review concern? Any guidance would be appreciated.

Short version, in case it saves someone the trip I just took: if your app plays audio AND uses a background URLSession with sessionSendsLaunchEvents = true, playback can be killed mid-episode the moment you call the handleEventsForBackgroundURLSession completion handler, but only in a process that was launched into the background and never went foreground. There is no crash log and no jetsam event: applicationWillTerminate simply fires. To users it looks exactly like the app crashed while playing, which is how it was reported to me, and why I wasted a while looking for a crash that did not exist. My setup: podcast app, audio background mode a background URLSession (sessionSendsLaunchEvents = true, isDiscretionary = false) used only to refresh RSS feeds those feed downloads are started from a BGAppRefreshTask What happens: iOS launches the app into the background to run a BGAppRefreshTask. The scene connects unattached; the process never becomes foreground. The task starts a batch of feed downloads on the background session. They outlive the ~10 s refresh window and finish about two minutes later. Meanwhile the user presses Play on their AirPods. Playback starts, inside that same never-foreground process. The downloads finish. iOS calls handleEventsForBackgroundURLSession. I store the handler and invoke it on the main thread from urlSessionDidFinishEvents, as documented. ~1 ms later applicationWillTerminate fires and the audio stops. At that moment the app is playing audio: AVAudioSession active, category .playback, and -[UIApplication backgroundTimeRemaining] returning greatestFiniteMagnitude. A sysdiagnose shows audiomxd holding a MediaPlayback isPlayingProcessAssertion for the process, taken 27 s earlier, invalidated only as part of the teardown, and CMSessionMgr logging "pid ... is now Terminated. Background entitlement: YES" while IsPlayingOutput:YES. The tell, and the thing that took me longest to spot: if the process HAS been foreground at some point in its life, calling the identical completion handler on the identical session does not kill it, and playback carries on. Across a full day of logs, "has this process ever been foreground" is the only variable that predicts the kill. The audio background mode is not the problem, the app happily played for ~6 minutes as a never-foreground process on another occasion, and died only at the completion-handler call. Half of this is documented behaviour: the system takes a power assertion when it resumes you for the session, and calling the completion handler releases it. What I did not expect is that the audio assertion does not take over at that point. My workaround so far is sessionSendsLaunchEvents = false on the feed session. RSS refreshes are not urgent: the transfers still run in the background, and the system hands the results to me at the next launch, where my refresh task parses them. I'm still verifying if this works as expected. So, questions for anyone who has been here: Has anyone else with an audio app hit this? I have a hunch it shows up in the wild as unexplained "the app crashed while playing" reports, particularly for podcast and audiobook apps that refresh content in the background, because there is no crash log to point at. If you combine background audio with a background URLSession, how do you handle it? Do you avoid launch events entirely, or split urgent from non-urgent transfers across separate sessions? Is there a better pattern than turning launch events off for transfers that genuinely are not urgent? Filed as FB23789310 with a sysdiagnose and a timestamped log excerpt. If you have seen this too, a dupe would help.

Summary: Starting from iPadOS 26.4, the maximum memory available to a single app has been reduced from approximately 6GB to 3GB on an 8GB iPad. This change persists in iPadOS 26.5 and has not been addressed. This breaks core functionality of memory-intensive applications such as 3D scanning apps that require large amounts of RAM to process models. Device: iPad with 8GB RAM Affected versions: iPadOS 26.4, iPadOS 26.5 Working version: iPadOS 26.0 / 26.1 / 26.2 / 26.3 Measured Data: iPadOS 26.0–26.3: App available memory ≈ 6GB (75% of total RAM) iPadOS 26.4–26.5: App available memory ≈ 3GB (37.5% of total RAM) Measurement method: Apple system API Impact: This is a regression, not expected behavior. The available memory per app has been cut by 50% without any official documentation or release notes mentioning this change. As a result, our 3D scanning application crashes immediately when attempting to process 3D models on iPadOS 26.4 and later. The app requires substantial RAM to load and process 3D model data. With only 3GB available, memory allocation fails during model processing, causing the app to crash (EXC_RESOURCE / OOM kill). This core functionality was working correctly on iPadOS 26.3 and earlier with the same device and same app binary. This regression makes our app's primary feature completely unusable for all users on iPadOS 26.4+. Steps to Reproduce: On an 8GB iPad, install iPadOS 26.0 Measure available app memory using Apple system API Upgrade to iPadOS 26.4 or 26.5 Measure available app memory again Observe: available memory drops from ~6GB to ~3GB Expected Result: Available memory per app should remain consistent across minor OS updates, or any changes should be documented. Actual Result: Available memory per app dropped by 50% starting in iPadOS 26.4, with no documentation of this change. Additional Notes: Disabling Apple Intelligence does not resolve the issue This issue was not fixed in iPadOS 26.5 Other developers have reported increased crash rates starting in iPadOS 26.4 (Apple Developer Forums)

In /usr/include/libproc.h, there are a few number of APIs listed as private but which are commonly used (e.g. proc_pidpath). I'm trying to figure out how the proc_listallpids API is supposed to be used. From the examples I'm seeing in open source projects, the idea is to: call proc_listallpids(NULL, 0) to get a hint about the number of pids currently existing. call proc_listallpids with an appropriate buffer and retry if needed (I guess if the number of processes grew more than expected between the 2 calls). OK. What I'm not getting is how the resulting array of pids is to be used. What I am observing is that the array of pids you get is a list of the existing of the existing pids in a descendant order. BUT after pid 0, there can be additional pids. Numerous projects are just skipping pid = 0, but are using the pids after 0 as if they were valid. From what I'm seeing these are not valid pids and the correct way to handle the array of pids is to stop at pid 0 (or 1 if you want to skip the "kernel"). [Q] Is the proc_listallpids like the proc_pidpath a Voldemort API? Everyone can see it but you are not allowed to discuss it and to get more info about it you need to contact DTS. Or is it possible to know the right way to use this API and its results?

Hi everyone, I am currently working on a specialized analytics and time-tracking application, and I am trying to find a reliable way to detect which app the user currently has open in the foreground in real-time. On Android, this is typically handled via Accessibility Services or UsageStats, but I am well aware of iOS’s strict sandboxing rules and privacy protections. So far, I have researched and tested a few workarounds, but none perfectly fit the use case: Screen Time API (FamilyControls / DeviceActivity): This is fantastic for blocking apps or getting daily aggregate usage, but it does not provide real-time callbacks or the bundle ID of the app currently on the screen. MDM (Mobile Device Management): Requires enterprise enrollment and wiping the device, which isn't feasible for a consumer-facing app. ReplayKit (Broadcast Extension): We are currently utilizing RPBroadcastSampleHandler to screen record the device and using OCR and Core ML to visually identify the app (e.g., detecting the YouTube UI). However, this is incredibly resource-intensive and pushes the 50MB Jetsam limit for extensions. My Question: Is there any official API, restricted entitlement, or system notification (like NSWorkspace.shared.frontmostApplication on macOS) that allows a background process to simply read the bundleID of the active foreground app on iOS? If not, is ReplayKit combined with OCR or Machine Learning truly the only way to detect what app a user is actively viewing on iOS without a jailbreak? Thank you in advance for any insights!

Hello everyone, We have a feature in our iOS app called "automatic background sync", which syncs data between the mobile app and our backend periodically. It is specifically designed to work when the app is in a backgrounded state. We use both silent remote notifications that are sent from our backend periodically (using Firebase Cloud Messaging), and also BGAppRefresh task. The sync process should be as reliable as possible and work continuously while the app is in the background, even if the user does not open the app for a long period of time. We enforce a 20 second deadline to call the completion handler to match the 30 second limit. We have a specific customer that has multiple where the background sync does not work properly: One of them has continuous syncs for about a week, then it stops until the user opens (moves to foreground) the app again. Another user only has a sync when they open the app, then it stops when it is backgrounded. Looking at their logs: The app remains in the background and is rarely being actively killed, and it likely is not the reason that the user stopped receiving syncs. Their background app refresh setting in iOS settings is enabled. Both user's app stopped waking up and doing the task either from silent remote notifications or background tasks. Thank you!

I have run into an interesting topic today. So far, I have been under the impression that when I am using the setCodeSigningRequirement() function on an NSXPCConnection, I am completely removing any chance of receiving AND sending messages to untrusted XPC Peers. However, I created a malicious replacement for my daemon, and I wanted to check if my application can still send and receive messages to it. I checked with codesign --verify that the replacement does NOT fulfil the code signing requirement. I put a system log instruction in the malicious tool's XPC function. When calling the XPC Peer, I expected to see: XPC connection to <redacted> failed! [Error Domain=NSCocoaErrorDomain Code=4102 "The code signature requirement failed." UserInfo={NSDebugDescription=The code signature requirement failed.}] and I did. However, I also saw the system log from the malicious tool's XPC function. Then, I checked all XPC documentation, and I found for the original C implementation - xpc_connection_set_peer_code_signing_requirement() - the following in the discussion section: All messages received on this connection will be checked to ensure they come from a peer who satisfies the code signing requirement. For a listener connection, requests that do not satisfy the requirement are dropped. When a reply is expected on the connection and the peer does not satisfy the requirement XPC_ERROR_PEER_CODE_SIGNING_REQUIREMENT will be delivered instead of the reply. (this is in xpc/connection.h) which seems to align with the observed results. However, this is (embarassingly?) new for me, I would have never expected this, given how in my head pre-checking before any connection is made seems straightforward, even with public Apple SDK APIs: Grab a SecCode (not SecStaticCode) object of the daemon (malicious or not). This is running code, so it cannot be substituted between the check and the outgoing message. Perform validations on the SecCode object in some form - on macOS 15.0+ it's pretty easy with LightweightCodeRequirement's SecCodeCheckValidityWithProcessRequirement(). Immediately drop the connection if the peer is untrusted, before any message is sent. Am I overlooking something or making wrong assumptions here? or Am I right and this is something that I have to accept that's implemented less than ideally and I can perform above steps 1-3 myself and make a difference? Thanks in advance!

Hi everyone! I'm writing a watch app using backgroud refresh. But the backround task was not triggered either on simulator or real watch device. main code

I develop a tool on macOS which is composed of an UI app to manage the main app settings, and an Agent that runs in background doing some tasks ? (Running the agent is optional, can be launched from the UI app, and can be launched by macOS at startup with SMAppService. ) Agent has the LSUIElement flag set, and only shows a Menu Extra (or whatever it now named), and sometimes some notifications. The whole App package is bundled this way MainAppUI.app/Contents/Library/LoginItems/AppAgent.app (for SMAppService to work) This has been working correctly for years Now on macOS 27 beta, once I quit the UI App, having launched the Agent, the Dock reports the UI App is still running in background (with the grey dot) . But only the Agent is running, not the UI app process. Moreover, System Settings->Background apps reports both the UI app AND the Agent as both requesting to run in background. I would have expected only the Agent being listed in System Settings, and nothing appearing in the Dock. Is this a bug in the OS beta , showing the top-level container bundle as the app running in background instead of the executable direct container ? Or maybe it's on me and I should bundle my app differently ? (I cannot "reverse" the bundle and put the Agent as the main app, with UI "inside", as double clicking the main app should launch the UI App , not the Agent. ) BTW, filed FB23203848 for the same subject. thanks for any direction

I have a weird situation arising in my app where calling BGTaskScheduler.shared.submit(request) seems to fail silently, without raising any of the BGTaskScheduler.Error's. Here's what's happening. A user registers and submits 5 BGContinuedProcessingTask's, with different ID's using the wildcard. When trying to submit the 6th task like this: try bgTask.submit() //submit task isCreatingBGTask = false // toggle ProgressView off dismiss() //Dismiss the sheet The sheet will dismiss, but the device never gives the haptic feedback, and the task is not visible in the notification centre. Having a maximum number of running tasks makes sense, but why isn't it raising the error BGTaskScheduler.Error(.immediateRunIneligible). It also doesn't seem like there's a way to query the tasks that are in progress (at least I couldn't find a way). So for now I'll just track my own tasks manually, and prevent submission at 5 tasks, but I'm wondering what would happen if another app had 2 tasks going, and then my user tries to submit 3 or something like that.

I have one report from a customer, who migrated all data from his old MacBook to a new one. His is on Tahoe 26.5.1 (25F80). Here is my relevant code: + (BOOL)enableLoginItem:(BOOL)enable { NSOperatingSystemVersion osv = NSProcessInfo.processInfo.operatingSystemVersion; if (osv.majorVersion >= 13) { NSError* error; SMAppService* service = [SMAppService loginItemServiceWithIdentifier:MY_HELPER_APP_ID]; if (![service registerAndReturnError:&error] && error) @throw error; return YES; } return SMLoginItemSetEnabled((__bridge CFStringRef)MY_HELPER_APP_ID, enable); } What should I do to re-enable the login helper?

I just noticed something on macOS 27 beta 1 and I'm not sure if it's a bug or just how the new feature works. After quitting an app with Cmd+Q, the Dock keeps showing the gray dot with the "Running in Background" message. So I checked — ps aux shows nothing running for the app at all. The only trace is its auto-updater job in launchctl list (com.anthropic.claudefordesktop.ShipIt), which is registered but has no PID, so it's not actually executing anything. Out of curiosity I tried Discord and got the exact same thing (com.discord.discord.ShipIt), so this probably happens with any Electron app that uses the Squirrel updater. Is this intended behavior? Trying to understand if the indicator reflects registered background items (and not just live processes) so I know what to expect for Electron-based apps.

Platform: iOS 26 (23E254) Xcode: 26.0 Reproduces on: Debug builds AND TestFlight Summary: I'm using Apple-Hosted Managed Background Assets with on-demand download policy. The .aar archives download successfully (correct file size, status = downloaded), but the contents are never extracted into the asset pack namespace. AssetPackManager.shared.contents(at:) returns fileNotFound for all path variants, and url(for: FilePath(".")) returns a URL that exists but contains zero children. Root Cause from Sysdiagnose: The backgroundassets.user daemon logs reveal this error on every download attempt: A bundle record couldn't be looked up for the application identifier "AtlasDrift.SnapTrail": Error Domain=NSOSStatusErrorDomain Code=-10814 "(null)" UserInfo={_LSFile=LSBindingEvaluator.mm, _LSLine=1973, _LSFunction=runEvaluator} Error code -10814 is kLSApplicationNotFoundErr. The BA daemon downloads the .aar blob, then attempts to find the app bundle via LaunchServices to locate the extension for extraction — but the LS lookup fails. Without the extension, extraction never occurs. Verified Configuration Everything matches the documentation and WWDC sessions: Extension embedded at SnapTrail.app/Extensions/BackgroundDownloadExtension.appex Bundle IDs: App = AtlasDrift.SnapTrail, Extension = AtlasDrift.SnapTrail.BackgroundDownloadExtension (correct parent-child pattern) Extension point: com.apple.background-asset-downloader-extension Product type: com.apple.product-type.extensionkit-extension Protocol: StoreDownloaderExtension from StoreKit (for Apple-hosted packs) App group: group.AtlasDrift.SnapTrail (matching in both app and extension entitlements) Info.plist keys: BAAppGroupID, BAHasManagedAssetPacks = YES BAUsesAppleHosting = YES (no BAInitialDownloadRestrictions or other BA keys) .aar Packaging Archives built with xcrun ba-package from the Assets directory. Manifest format: { "assetPackID": "ireland", "downloadPolicy": { "onDemand": {} }, "fileSelectors": [{ "directory": "POIRegions/ireland/IR" }], "platforms": ["iOS"] } Uploaded via App Store Connect API with assetType: "ASSET". Diagnostic Observations AssetPackManager.shared.assetPack(withID:) returns valid metadata (correct download size) ensureLocalAvailability(of:) completes without error assetPackIsAvailableLocally(withID:) returns true url(for: FilePath(".")) returns a URL that exists but has zero children (empty namespace) contents(at:) returns fileNotFound for all path variants tested The extension never runs — breadcrumb file written in init() is never created The -10814 error appears in daemon logs for every download cycle Questions Has anyone successfully used Apple-Hosted Managed Background Assets on iOS 26 beta? Is the daemon's LaunchServices integration known to be broken in this seed? Is there anything about the bundle identifier format or provisioning profile setup that could cause the BA daemon's LS lookup to fail, even though the app installs and runs fine otherwise? Are there any additional Info.plist keys or entitlements beyond what's documented that might be required for the daemon to locate the app bundle? Any guidance would be appreciated. I've filed a Feedback report with the full sysdiagnose attached.

Hello, We are currently investigating an issue where our app is being terminated by the system while running in the background. At the moment, the app does not perform any significant background activity, and memory usage remains relatively low (approximately 150–200 MB). Despite this, the app is still being terminated in the background, even under conditions where other apps appear to remain active. From our investigation so far, the issue does not appear to be related to: High memory consumption Explicit background task misuse Application crashes on our side For additional context, we had previously used silent push notifications to trigger heavy upload operations in the background. Since we suspected this behavior might be contributing to the issue, we completely stopped using this mechanism approximately two weeks ago. However, the background terminations are still occurring. We would like to better understand the possible causes of this behavior. Specifically, could this be related to: Watchdog terminations Background assertion or lifecycle violations RunningBoard resource management Jetsam policies Background execution timeouts Any other system-level resource or process management constraints We would greatly appreciate any guidance on how to identify the root cause or which logs/diagnostics we should focus on to further investigate the issue. Thank you.

We are developing a mileage tracking application that depends on continuous background location updates on iOS. Our app has the required background modes enabled: <key>UIBackgroundModes</key> <array> <string>remote-notification</string> <string>processing</string> <string>fetch</string> <string>location</string> </array> We are observing inconsistent behavior with background location tracking in app terminated state. In some cases, after a period of time, location updates stop completely. Sometimes iOS successfully relaunches the app when movement is detected and location updates resume correctly. However, in other cases, the app is not relaunched by the system, and we stop receiving location updates entirely. We reviewed Apple’s documentation on handling background location updates: https://developer.apple.com/documentation/corelocation/handling-location-updates-in-the-background Based on our observations, we would appreciate clarification on the following points: Is this considered expected iOS behavior or a system limitation? Under what conditions does iOS decide not to relaunch a terminated app for location events? Are there recommended best practices to improve the reliability of background location relaunch behavior? Is there any logging, diagnostics, or debugging mechanism available to determine why the app was not relaunched? Apple’s documentation mentions that location updates may be queued while the app is terminated and later delivered after relaunch. However, in some scenarios we do not receive those queued updates after the app restarts. Under what conditions can queued location updates be discarded or not delivered? Additional notes: We are using standard Core Location background updates. “Always” location permission is granted. Background App Refresh is enabled. The issue is observed intermittently across multiple iOS devices.

Hi, hoping for guidance on what's a long-running bug for our app. The problem We have a transcription app on iPhone 17 Pro Max running iOS 26.5. Recording flow uses AVAudioEngine.installTap(onBus:) to capture PCM into a JS bridge for streaming to a remote transcription service. A parallel AVAudioRecorder writes the same audio to disk as backup. When the user starts a recording and locks the phone, iOS terminates our process with SIGKILL at approximately 50 seconds of continuous background time, despite: UIBackgroundModes includes audio (verified in shipping IPA's Info.plist) AVAudioSession.setCategory(.playAndRecord, mode: .default) is active AVAudioEngine is running with installTap producing PCM buffers right up to the moment of death UIApplication.backgroundTimeRemaining returns Double.greatestFiniteMagnitude at applicationDidEnterBackground (verified in our event log) No AVAudioSession.interruptionNotification is delivered before the kill. iOS terminates the process cleanly with no warning event to our observer. Evidence Our Swift observer module writes an event log to disk on every system event. On relaunch we ship it to our crash reporter. Excerpt from a recent kill on iOS 26.5 / build 2.1.32: T=0.000s session-start (engineRunning: true) T=57.199s app-will-resign-active (bufferCallbackCount: 22) T=58.913s app-did-enter-background (backgroundTimeRemaining: infinity, bufferCallbackCount: 39) [no further audio events captured] [Swift heartbeat written every 5s for next ~46 seconds] T~105s Process SIGKILLed (heartbeat last-alive: 09:31:01.597Z) Background time before kill: ~46 seconds. engineRunning: true and bufferCallbackCount was still incrementing at the moment the event log stops capturing - the audio engine was alive and feeding buffers when iOS terminated us. What we've tried (35 documented attempts) Hopefully not all relevant but listing for completeness: Various AVAudioSession category/mode/options combinations (Default, Measurement, VoiceChat, .mixWithOthers, .defaultToSpeaker, .allowBluetoothHFP) Parallel AVAudioRecorder writing a .caf file as a "real recording app" signal SFSpeechRecognizer with requiresOnDeviceRecognition = true consuming PCM in-process (50s request rotation) BGContinuedProcessingTask with Progress.completedUnitCount reporting monotonic progress every 5 seconds Live Activity (ActivityKit) with NSSupportsLiveActivitiesFrequentUpdates = true Live Activity update pushes via APNs (confirmed wake widget extension only, not host) Silent device-token APNs background pushes (confirmed iOS ~5/day rate limit) CallKit fake call (CXProvider + CXCallController) - works but creates the green pill UI which our product can't ship WebRTC peer connection with active media stream (via react-native-webrtc loopback) UIBackgroundModes: voip declaration (without CallKit) beginBackgroundTask + engine bounce (Apple's own guidance says don't, our test confirmed it's actively harmful) CLLocationManager background updates All die at ~50s background. None of them survive. What works on the same device Three App Store transcription apps survive indefinite background recording on our exact device + iOS version. We have inspected their IPAs (Mach-O LC_LOAD_DYLIB analysis + embedded entitlement extraction): Otter (com.aisense.otter) - UIBackgroundModes: audio + fetch + processing + remote-notification. Uses OneSignal-driven Live Activity push tokens + NotificationServiceExtension. No CallKit, PushKit, or WebRTC. Granola (com.granola.ios-prod) - has UIBackgroundModes: voip but the voip is for their separate outbound-phone-call feature (TwilioVoice + CallKit, lives in their PhoneCalls.framework). Recording-path uses ONLY AVAudioRecorder + PlayAndRecord + ModeDefault + Live Activity with frequentPushesEnabled. Zero PushKit anywhere in the bundle. Transcribe Speech to Text by DENIVIP (ru.denivip.transcribe) - the smallest API surface: UIBackgroundModes: audio + remote-notification only. AVAudioEngine + .playAndRecord + .default + SFSpeechRecognizer consuming PCM. No CallKit, PushKit, BGTask, Live Activity, WebRTC, or VoIP. Three apps, three different mechanisms, all working. We've implemented bits of all three approaches in our app and still die at 50s. Apple Voice Memos (system app, private entitlements) also survives indefinite recording on the same device. Questions What is the supported API path for indefinite background microphone-only recording on iOS 26.5? Voice Memos and competitor apps clearly accomplish this - what's the missing piece? Why does UIApplication.backgroundTimeRemaining return Double.greatestFiniteMagnitude at applicationDidEnterBackground but the process is terminated ~50 seconds later? Is the meaning of this property changing in iOS 26? What causes the iOS 26 process scheduler to revoke the audio-mode background runtime classification? No AVAudioSession.interruptionNotification is delivered before SIGKILL. Where can we observe the classification change? Does iOS 26 distinguish "audio recording with no audible output" from "audio recording with audible output (e.g. a media playback session)"? If so, what is the supported API to register as a recording-only background-audio app? Does BGContinuedProcessingTask (new in iOS 26) actually extend background CPU time for an app that is also using UIBackgroundModes: audio and an active AVAudioSession? Or is it for finish-what-you-started bursts only (per WWDC 2025 session 227)? Any guidance - even pointers to specific WWDC sessions, sample code, or technotes - would be hugely appreciated. We've spent ~40+ hours on this and want to know what the supported path looks like in iOS 26. Happy to share more event-log data, IPA inspection notes, or build a focused Xcode reproduction if helpful. Thanks!

Hello! I'm trying to implement an editor app (macOS) that allows the user to write code, which will be compiled and executed, showing the result in the editor window. Imagine it like SwiftUI previews, but the graphic output is created with Metal, not SwiftUI. I found that IOSurface can be used to share that kind of data over XPC, so I would not have to rely on the private NSRemoteView. However, I'm confused if it is, at all, possible for my editor app to connect to an XPC Service, that was NOT bundled with it (but compiled by it at runtime). I succeeded to launch an XPC service defined as: <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>Label</key> <string>com.myteam.myproject.service</string> <key>MachServices</key> <dict> <key>com.myteam.myproject.service</key> <true/> </dict> <key>Program</key> <string>/Path/to/service/run_my_service.sh</string> </dict> </plist> But the call to let connection = NSXPCConnection(machServiceName: "com.myteam.myproject.service") let proxy = connection.remoteObjectProxyWithErrorHandler { error in continuation.resume(throwing: error) } as? MyServiceProtocol fails with "The connection to service named com.myteam.myproject.service was invalidated: Connection init failed at lookup with error 3 - No such process." I have added <key>com.apple.security.temporary-exception.mach-lookup.global-name</key> <array> <string>com.myteam.myproject.service</string> </array> to my entitlements. Since the tutorials I followed are quite old, I'm wondering if support for something like this was dropped at some point. Thanks for any advice!

Hi all, Technical architecture question for those experienced with iOS background audio / microphone constraints. I’m exploring an app concept where: the user explicitly starts a temporary active session during that session, on-device wake-word / keyword detection runs locally no audio is stored or transmitted during passive monitoring monitoring stops when the user ends the session The intended UX is that the user may then lock the phone or place it away while the active session remains in progress. Question: Is there any App Store-compliant architecture that would allow local keyword / wake-word detection to continue while the device is locked or the app is backgrounded during that active session? Or would iOS lifecycle / background execution rules make this infeasible for custom wake-word detection? Interested in practical experience around: AVAudioSession background audio modes on-device speech processing App Review acceptability Thanks in advance.