General: Forums subtopic: App & System Services > Processes & Concurrency Forums tag: Background Tasks Background Tasks framework documentation UIApplication background tasks documentation ProcessInfo expiring activity documentation Using background tasks documentation for watchOS Performing long-running tasks on iOS and iPadOS documentation WWDC 2020 Session 10063 Background execution demystified — This is critical resource. Watch it! [1] WWDC 2022 Session 10142 Efficiency awaits: Background tasks in SwiftUI WWDC 2025 Session 227 Finish tasks in the background — This contains an excellent summary of the expected use cases for each of the background task types. iOS Background Execution Limits forums post UIApplication Background Task Notes forums post Testing and Debugging Code Running in the Background forums post Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com" [1] Sadly the video is currently not available from Apple. I’ve left the link in place just in case it comes back.

If I create a BGContinuedProcessingTaskRequest, register it, and then "do work" within it appropriately reporting progress, and before my task has finished doing all the work it had to do, its expirationHandler triggers... does the task later try again? Or does it lose the execution opportunity until the app is next re-launched to the foreground? In my testing, I never saw my task execute again once expired (which suggests the latter?). I was able to easily force this expiry by starting my task, backgrounding my app, then launching the iOS Camera App. My example is just using test code inspired from https://developer.apple.com/documentation/backgroundtasks/performing-long-running-tasks-on-ios-and-ipados let request = BGContinuedProcessingTaskRequest(identifier: taskIdentifier, title: "Video Upload", subtitle: "Starting Upload") request.strategy = .queue BGTaskScheduler.shared.register(forTaskWithIdentifier: taskIdentifier, using: nil) { task in guard let task = task as? BGContinuedProcessingTask else { return } print("i am a good task") var wasExpired = false task.expirationHandler = { wasExpired = true } let progress = task.progress progress.totalUnitCount = 100 while !progress.isFinished && !wasExpired { progress.completedUnitCount += 1 let formattedProgress = String(format: "%.2f", progress.fractionCompleted * 100) task.updateTitle(task.title, subtitle: "Completed \(formattedProgress)%") sleep(1) } if progress.isFinished { print ("i was a good task") task.setTaskCompleted(success: true) } else { print("i was not a good task") task.setTaskCompleted(success: false) } } try? BGTaskScheduler.shared.submit(request) Apologies if this is clearly stated somewhere and I'm missing it.

Hello everyone, I am currently developing a simple driver log book app and I’m hitting a wall regarding a seamless user experience. My goal is very straightforward: I want my app to be notified/triggered in the background as soon as CarPlay is activated or deactivated, so it can automatically start or stop tracking a trip. Even with the official CarPlay entitlement granted, I cannot find a reliable API or workaround to achieve this. It feels like something that should be incredibly simple. I know that Apple Shortcuts (Kurzbefehle) handles this beautifully—the automation triggers for CarPlay work great. However, from an app developer's perspective, this isn't a viable solution for production: The average user will never go through the hassle of manually creating a Shortcut automation just to make the app work. Third-party apps are not allowed to programmatically create or inject these automation triggers for the user. It’s quite disappointing because the OS clearly detects the state perfectly, but doesn't expose a clean way for eligible navigation/driving apps to act on it in the background. Has anyone found a robust workaround for this? Or is there a specific API within the CarPlay framework I am overlooking that allows background execution exactly at the moment of connection/disconnection? Appreciate any insights or feedback!

Feedback ID: FB24937933 I’m seeing a persistent launch failure across multiple unrelated apps on an iPhone 15 Pro Max. Affected apps include Telegram, Box, LinkedIn, Amazon, Apple Podcasts, Shazam, and others. The behavior is consistent: I launch the app. The app stays on a black or frozen launch screen. After approximately 19–20 seconds, iOS terminates the app. Retrying may occasionally work temporarily, but the problem returns. Crash reports from multiple unrelated apps show essentially the same termination: EXC_CRASH / SIGKILL 0x8BADF00D scene-create watchdog transgression More importantly, the main thread repeatedly shows this pattern: xpc_connection_send_message_with_reply_sync NSXPCCONNECTION_IS_WAITING_FOR_A_SYNCHRONOUS_REPLY -[__NSURLBackgroundSession setupBackgroundSession] -[__NSURLBackgroundSession initWithConfiguration:delegate:delegateQueue:delegateDispatchQueue:] This appears to indicate that the app’s main thread is synchronously waiting for an XPC-backed system service while creating a background NSURLSession, and the response does not arrive before the scene-create watchdog timeout. I first reproduced this on iOS 26.6.2 and the problem still occurs after updating to iOS 27.0 (24A437). Troubleshooting already performed: • Force restart • Network Settings Reset • Background App Refresh disabled • VPN/proxy disabled • Affected apps deleted and reinstalled • iOS updated from 26.6.2 to 27.0 Because the same stack pattern is occurring across multiple unrelated third-party apps, as well as Apple apps such as Podcasts and Shazam, this does not appear to be isolated to a single application. Apple Support has also told me that similar cases have been reported and that the issue may be addressed in a future software update. Has anyone seen a system-level NSURLBackgroundSession / XPC service enter this kind of stuck state across multiple applications? Is there a known issue involving the background URLSession service or related networking daemon that could cause synchronous XPC calls during app launch to block until the watchdog terminates the process? I have submitted the full crash reports through Feedback Assistant under FB24937933.

Hi, I'm developing SafeChain, an occupational lone-working safety application for iOS and Android. One of our objectives is to detect a potential fall using the iPhone's accelerometer and notify an assigned responder if the worker doesn't acknowledge a warning. The requirement is for this to work while the iPhone is locked or the app is backgrounded, without requiring an Apple Watch. We've tested several approaches on a physical iPhone: CMMotionManager: Works reliably in the foreground, but we recorded a 254-second interruption during a five-minute locked-screen test. CMSensorRecorder: Successfully recovered 20,635 accelerometer samples from a seven-minute locked-screen recording, with a maximum sampling gap of 0.024 seconds. BGAppRefreshTask: Scheduling requests were accepted, but we could not confirm timely background execution. Our challenge isn't obtaining the accelerometer data. It's ensuring the application can analyse that data and initiate an emergency escalation promptly, even while iOS would ordinarily suspend the app. SafeChain also provides lone-worker check-ins, manual SOS, responder escalation and contact-loss monitoring. My questions are: Is there currently an Apple-supported approach for continuous or event-triggered motion analysis on an iPhone while an occupational safety application is backgrounded? Would a genuine lone-worker location-monitoring feature provide a legitimate basis for background location execution alongside Core Motion processing, assuming location tracking is itself an intended user-facing feature? Is there an entitlement or alternative API specifically available for occupational safety applications requiring timely emergency detection? If none exists, is it correct that dependable, real-time, iPhone-only fall detection is not currently supported by iOS? We want to comply fully with Apple's guidelines and avoid implementing a background-execution workaround that may prove unreliable or fail App Review. Any guidance from Apple engineers would be greatly appreciated. Thank you,

I'm trying to determine why my UIKit application was launched, specifically whether it was launched by the user or by the system to execute a background task. I recently added a BGProcessingTask to update data overnight. Consider this scenario: The user backgrounds the app at 10 AM. A background task is scheduled with earliestBeginDate set to 4 AM the following day. During those 18 hours, iOS terminates the app's process to reclaim memory. iOS later decides to execute the scheduled background task and launches a new app process in the background. My understanding is that this results in a cold launch, including a call to application(_:didFinishLaunchingWithOptions:) and the initialization performed there. This matters because some of our startup initialization triggers network requests that are unnecessary when the app is launched only to perform a background task. Questions 1. Can iOS relaunch a previously terminated app to execute a scheduled BGProcessingTask? I'm referring specifically to termination by the system (for example, memory pressure), not the user force-quitting the application. 2. Is there a reliable way to distinguish a foreground cold launch from a background task cold launch inside application(_:didFinishLaunchingWithOptions:)? I tried checking UIApplication.shared.applicationState, but in my testing it was .background during didFinishLaunchingWithOptions in both scenarios, including when the user launched the app by tapping its icon. Is there another documented API or launch context that reliably identifies why the process was started? I'm aware that iOS provides launch options for certain launch scenarios, but I'm specifically interested in distinguishing a background task-triggered cold launch from a user-initiated foreground cold launch. 3. If this distinction cannot be made reliably during didFinishLaunchingWithOptions, what is the earliest lifecycle callback where I can determine that the app is entering the foreground? For example, should foreground-specific initialization be deferred until scene(_:willConnectTo:options:), sceneWillEnterForeground(_:), or another callback? I'm specifically looking for a documented and reliable lifecycle signal, rather than heuristics or arbitrary delays. The goal is to avoid unnecessary startup initialization and network requests when iOS launches the application solely to execute a background task.

I am working on a live activity showing realtime NYC subway arrival countdowns at a station. As trains arrive I want to remove them from the live activity so that only inbound trains are displayed. As I understand it this will require a broadcast push notification every time a train arrives, but this is incredibly inefficient (and will likely be throttled) as trains can arrive many times per minute at a busy station. MTA data includes approximately 90 minutes of train arrivals. Is there no way to create a live activity timeline the way widgets can update at planned intervals? The only viable option I've found is keeping the entire app alive in the background to update the live activity when required by registering for background location updates, but this seems like an unfriendly solution.

Our app supports large-file uploads (20 GB+) and uploads of many files. We use a background URLSession so transfers can continue if the user backgrounds the app. In separate affected-device captures, Console logs and a sysdiagnose show dasd declining upload activities under Energy Budget Policy or Data Budget Policy. Upload tasks are created and resumed, but no bytes are transferred. Subsequent uploads can also remain queued, including after earlier uploads are cancelled and the app is relaunched. The issue is intermittent but can persist: one device recovered after approximately 24 hours; another remained affected for several days. We have not established what causes recovery or how the relevant budget eligibility is computed or replenished. Foreground and power observations For the energy-budget reproduction, the user kept the app foregrounded. Application lifecycle logs and RunningBoard running-active-Visible notifications corroborate foreground/active state around the affected task creation and resume operations. The rejection repeatedly reports: Energy Budget Policy [energyBudget]: Required:1.00, Observed:0.00 Decision: MNP Battery samples were approximately 68%, with Low Power Mode off. New uploads using the same session succeeded while the device was connected to external power and were rejected again after disconnection. Discretionary configuration versus daemon classification Our upload-session factory does not set isDiscretionary to true. In a separate, successful reproduction, instrumentation read isDiscretionary from the actual owning URLSession.configuration at task creation: 10:35:04.234749-0500 Frame.io: Upload task 1 created in session com.frameio.backgroundSession.diagnostics, configured isDiscretionary: false The corresponding daemon entry was: 10:35:04.245137-0500 nsurlsessiond: NDSession <8BA476D9-E790-46B6-B1DA-0246E14BBDAF> Task <1B16494D-BBE8-448F-9297-9DB8772ADD92>.<1> current discretionary status for com.frame.FrameIO is discretionary (opt-in: 0) All five tasks in that successful upload showed this combination. We do not yet have the instrumented configuration readout from the failed energy-budget reproduction. Implementation notes Large files are split into smaller files to support resumable uploads through our backend API. Each part is submitted as a file-backed upload task through the same background session, using a stable session identifier across launches. Goal User-initiated uploads make progress while the app is foregrounded and the network is available, and continue when possible after backgrounding. We understand background execution is system-controlled, but need to avoid uploads remaining stalled for days with no actionable recovery. We are considering switching between foreground and background URLsessions when the app moves between the foreground and background, but have concerns about that the bookkeeping on that path could be a brittle pattern. We have also considered using a BGContinuedProcessingTaskRequest for the entire upload, but have concerns about running into new scheduling issues there. Questions What session configuration and task-submission pattern does Apple recommend for this requirement? Is a background URLSession appropriate for both foreground and background uploading, or should we use a different architecture? Is it expected that tasks created and resumed while the app is foreground/active, with the owning session reporting isDiscretionary = false, can be blocked by Energy Budget or Data Budget Policy? If so, what supported approach allows these user-initiated uploads to progress while the app remains foregrounded? When this restriction persists across cancellation, new uploads, and app relaunch, what supported recovery mechanism should we implement? Can the app detect the restriction and take an effective action, rather than requiring external power or waiting an unknown amount of time? For 20 GB+ files and large upload batches split into file-backed tasks, are there recommended chunk sizes, outstanding-task limits, or session-management practices that prevent this failure mode? If the captured foreground behavior is unexpected, is this a known OS issue with an available fix or supported workaround? What additional evidence is needed to obtain a concrete remediation?

Requirement Description The app operates as a central device. It connects to a Bluetooth peripheral via Core Bluetooth. Once connected, the peripheral enables a Wi-Fi hotspot. The app joins this hotspot and transfers data over a TCP connection. The app needs to remain active in the background until this TCP data transfer is complete.  Question Regarding the Proposed Solution One proposed approach is to have the peripheral send periodic BLE notifications (reporting transfer progress) to the app, using each notification to briefly wake the app and extend its background execution time. Would this method successfully keep the TCP connection alive in the background until the transfer finishes? Does it comply with App Store review guidelines?  Request for Alternative Solutions If this approach is not viable, could you advise on any supported mechanisms or recommended architectures that would allow a local Wi-Fi TCP data transfer to complete reliably after the app moves to the background?

Hello, I am developing an iPhone application to help users avoid missing important phone calls. The intended behavior is: A user receives a regular cellular call through the built-in iPhone Phone app. The user does not answer the call. Our application automatically detects the missed call. The application schedules repeated local notifications until the user acknowledges the missed call. The critical requirement is that detection must work while our application is in the background, without the user reopening it. Implementation We currently use CXCallObserver to observe cellular call events. When an incoming call ends without being connected, we classify it as a missed call and schedule notifications using UNUserNotificationCenter. Test environment Device: iPhone 17 iOS: 26.7.1 Distribution target: Standard App Store, Japan Testing: Physical device without an attached Xcode debugger Observed behavior Scenario A: Our application is visible immediately before the iPhone is locked. Missed calls have been detected and notifications scheduled after more than 30 to 60 minutes of device lock. Scenario B: Our application is moved to the background before the iPhone is locked, for example by returning to the Home Screen or opening Safari. Missed calls are not detected promptly, even after only a short period in the background. When the user subsequently opens our application, CXCallObserver callbacks may arrive and the earlier missed call is then detected. This defeats the purpose of the application because the user must reopen it to receive alerts. Questions Is CXCallObserver expected to deliver callbacks while its application is suspended, or only when the process is executing? Is there any supported public iOS API, extension, or background execution mechanism that allows a third-party application to detect missed calls from the built-in Phone app while the application is suspended or terminated? Can a regular cellular missed-call event wake or relaunch a third-party application? If CXCallObserver cannot support this use case, is there another Apple-supported solution available to ordinary App Store applications distributed in Japan? We are looking for an approach that does not require external hardware, carrier integration, private APIs, or unsupported background execution techniques. If this use case is not supported by the public iOS SDK, confirmation of that limitation would be very helpful. Thank you for your guidance.

Hi Apple team, I’m developing Awaira, an iPhone app that runs real-time, on-device camera detection during a user-initiated support session. Its purpose is to help users notice hand-to-hair behavior. The user explicitly starts and stops the session; the camera indicator remains visible; camera frames are processed on-device; and the app does not record or transmit video. A common user request is to continue the session while using another app. On Android, this can be implemented with visible foreground-service behavior. On iOS, the capture session stops when Awaira is no longer foreground. I found AVCaptureSession.isMultitaskingCameraAccessSupported and isMultitaskingCameraAccessEnabled. The documentation says iOS 18 apps using UIBackgroundModes = voip may support multitasking camera access, and Apple’s PiP documentation discusses video-call apps. We do not provide a genuine person-to-person VoIP or video-calling service, and we do not want to misuse the VoIP background mode or create a fake call solely to keep camera detection active. Could Apple clarify: Is there any App-Review-approved API or entitlement for this kind of explicit, visible, user-initiated on-device camera session to continue while another app is foreground? Is declaring voip and using the multitasking-camera API permitted only for genuine VoIP/video-call apps? If no current approved path exists, is there a recommended design pattern for this accessibility/health-oriented use case? We will only ship an implementation that complies with the intended purpose of Apple’s APIs and App Review Guidelines. https://developer.apple.com/documentation/avfoundation/avcapturesession/ismultitaskingcameraaccesssupported Thank you.

Short version: we run a sandboxed helper as a hidden service account, started at boot by an SMAppService daemon. It works, even before login. But when the user turns our app off in Background App Activity, only the daemon stops. The helper keeps running. Is this setup supported, and what's the right way to manage the helper? What we want A Developer ID signed, notarized app (not Mac App Store) with a helper that parses untrusted input. The helper should: run as a dedicated, hidden, non-login local account; use App Sandbox, with its own container; be available before anyone logs in (after FileVault unlock). What we built An unsandboxed root LaunchDaemon, registered with SMAppService.daemon, runs this at boot: launchctl bootstrap user/<serviceUID> <fixed-agent-plist> The agent plist uses LimitLoadToSessionType=Background. The helper is a nested app in the same bundle, with com.apple.security.app-sandbox=true. We don't create a GUI session, change UID after the sandbox starts, or use private APIs. What we measured macOS 27.0 (26A428), arm64, dummy data only: Register and approve: the daemon starts. The helper starts as UID 60000, its container works, and reads outside it are denied. Turn the app off in Background App Activity: the daemon gets SIGTERM and stops. The helper keeps running (same PID). Turn it back on: the daemon starts again. Its bootstrap returns exit 5, because the old helper is still loaded. Call unregister(): the daemon stops. The helper keeps running. Cold boot (tested with a plain /Library/LaunchDaemons job, not yet SMAppService): the helper started and worked before login finished. For comparison, running the same sandboxed helper as a system daemon with UserName set to this account fails before main: Incoming message euid:60000 does not match secinitd uid:0. Questions Is this setup supported for shipping, including the sandbox starting before anyone logs in? Does the approval for daemon-bundled helpers cover a helper bootstrapped into another account's domain? Our plan: when the daemon gets SIGTERM, it runs bootout on the helper and its domain, and it treats bootstrap exit 5 as "already loaded". Is that the intended pattern, or is there a supported way for the helper to follow the app's Background App Activity setting? If this setup isn't supported, what public mechanism gives a sandboxed helper its own non-root identity before login? I can share the plists, entitlements and logs from a minimal reproducer.

I am testing a native Swift iPhone app that adds synthesized speech to an existing cellular call using: AVAudioApplication microphone injection permission AVAudioSession.setPreferredMicrophoneInjectionMode(.spokenAudio) AVSpeechSynthesizer CXCallObserver The audio background mode Device: iPhone 16 Pro Carrier: Vodafone Romania iOS version: [enter exact version] Both the system “Add Audio in Calls” setting and the app permission are enabled. Confirmed behavior: With the app in the foreground, the iPhone’s accessibility Auto-Answer Calls feature answers the call, and the remote caller hears the synthesized greeting. Problem: With the iPhone locked, the phone answers automatically, but the greeting does not start. Logs show ringing, connected, and ended events being processed together when the app returns to the foreground. This suggests the app was suspended. The app does not record the call or play continuous audio while waiting. Questions: Is there a supported public API that lets this app wake or execute when a cellular call connects while the iPhone is locked? Can microphone injection support this use case without keeping the app in the foreground? If supported, what audio-session configuration and background execution mechanism should be used? If unsupported, can you confirm this limitation? I can provide a minimal sample project and diagnostic logs.

Hi, Overview I have a SwiftData project which automatically syncs with CloudKit. When I run the app, I see the following error in Xcode logs. Error updating background task request: Error Domain=BGSystemTaskSchedulerErrorDomain Code=3 "(null)" My attempt I can enable Background processing (under Signing & Capabilities > Background modes), but I don't know the BGTaskSchedulerPermittedIdentifiers to add in the Info.plist Questions How can I resolve this? If I should enable background processing, what are the BGTaskSchedulerPermittedIdentifiers to add in Info.plist?

Hello, I'm developing an iOS voice alarm app. Is there a supported public API that can launch or resume app code when an AlarmKit alarm fires, so it can announce the current time while the phone is locked, without user interaction or an internet connection? The announcement needs to reflect the time playback actually begins, including when an alarm is delayed. Pre-generated audio would also work if the app can select the correct recording at playback time. My prototype subscribes to AlarmManager.shared.alarmUpdates at app startup and attempts speech when the alarm becomes .alerting. This works in the foreground, but in background trials no speech attempt occurred before reopening the app. These trials did not test termination by iOS or user force-quit. Could you clarify whether this use case is supported when the app is suspended, terminated by iOS, or force-quit by the user? If so, which API should I use? If not, could you confirm the limitation or suggest a supported alternative? Test environment: iPhone 13, iOS 26.6.1 (23G83), Xcode 26.6, iPhoneOS 26.5 SDK; release build without a debugger attached. Thank you for your guidance.

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 ...

Since iPadOS 26.5, when my application is running in background (non visible but with location fetching active in background), then my users are not able to update the application from their MDM application. The installation stays frozen, until the user manually kills my app. While in iPasOS 26.2 and older iOS, the MDM was able to terminate and update my app. My understanding: The MDM app can only terminate the non-interactive applications (maxTerminationResistance:NonInteractive). My application running in background with the location activated is seen as interactive. TestFlight and Appstore can terminate all applications (maxTerminationResistance:Absolute), so they are able to terminate and update my application. Can you confirm this has changed in the ios26 (after iPadOS26.2)? What are the recommendations to allow my users to update my app?

I have a app that needs to work all the time. It is very simple: Dataflow: From Bluetooth-App with MQTT Client in Phone-Cloud MQTT Broker- Cloud Backend-MQTT Broker-App with MQTT Client in Phone. All background services is allowed on ios Phone. I do not know when it started, but now suddenly the App stops randomly in background mode. The solution is built on that BLE scanning and App mqtt client is working. This "sleep" of the App make the system not working 100% and it is useless. Why is it stopping even if background is allowed? This must be fixed in iOS!!!!

I am the developer of MIDIDeviceManager, an iOS and iPadOS application used by musicians to control external MIDI hardware during live performance. Before enabling any background execution mode, I would like to ask which architecture Apple intends for this type of application. What the application does The app organises the patches of a musician's MIDI instruments into Pads, Scenes and Setlists so they can be recalled during a performance. It sends MIDI to external hardware such as guitar processors, synthesisers and vocal processors, and it also receives incoming MIDI that triggers its own Scenes — typically from a Bluetooth foot controller, a wired MIDI controller, or another app on the same device. Its purpose is to function as the software equivalent of a programmable hardware MIDI controller. It is not a lyrics app or an audio player, and it produces no audio. The problem During a performance, musicians commonly run more than one app. A typical setup is lyrics or chord charts displayed in one app while a Bluetooth foot controller recalls presets on a Line 6 Helix through MIDIDeviceManager. This requires the app to keep receiving and processing incoming CoreMIDI events while another app is frontmost. Once iOS suspends the app, those events are no longer delivered and the foot controller stops working. This affects iPhone as much as iPad. Several of my TestFlight users perform with iPhone alone, where the device sits on a stand and is not touched during a song. What I have observed I tested this directly on an iPhone 17 Pro Max. With two apps running simultaneously, an app legitimately using the audio background mode continued to receive and act on incoming CoreMIDI events from a Bluetooth foot controller while backgrounded. At the same moment, MIDIDeviceManager received nothing once iOS suspended it. This suggests that, under certain circumstances, an app executing under an appropriate background mode may continue receiving CoreMIDI while backgrounded. Background modes considered audio — appears to provide the required behaviour, but my app produces no audio output. I do not wish to declare a background capability that does not accurately describe what the app does. bluetooth-central — does not appear applicable, since Bluetooth MIDI connections are established through CoreMIDI and managed by the system MIDI server rather than by my own Core Bluetooth session. I have not been able to identify any mode intended for continuous MIDI reception, so UIBackgroundModes is currently empty. A previous rejection An earlier submission did declare audio, and was rejected under Guideline 2.5.4 on 7 July 2026 (submission ID eab58179-8177-4d05-9c37-5e1006828a96): "The app declares support for audio in the UIBackgroundModes key in the Info.plist but we are unable to locate any features that require persistent audio. Background audio is intended for use by apps that provide audible content to the user while in the background, such as music player, music creation, or streaming audio apps." That assessment is correct — the app produces no audio, and I removed the key. But the functional requirement remains: the app needs to receive MIDI while another app is frontmost. I am asking here rather than resubmitting, because I would rather understand the intended architecture than guess again. My questions Which background mode, if any, is appropriate for an app whose purpose is to continue receiving and processing incoming CoreMIDI events while another app is frontmost? If background MIDI reception is supported, is CoreMIDI expected to continue delivering incoming MIDI to a backgrounded app, or is there a different recommended architecture for apps of this type? If the answer is that no background mode applies and this capability is not available to apps of this kind, I would very much appreciate knowing that clearly. I can then document the limitation for my users and design accordingly rather than pursue an unsupported approach. My objective is not to find a workaround, but to implement this the way Apple intends professional MIDI applications to work. Thank you.