Kevin, thank you — this is very helpful, and it has changed how I am approaching the problem. Having looked closely at both options, I think the audio category conversation is the one I should pursue, and I want to explain why BGContinuedProcessingTask does not fit rather than simply saying so. Three reasons. First, duration. A live performance runs two to three hours, sometimes longer with soundcheck. The documented window for continued processing is many minutes, not many hours. I recognise a musician could reasonably start a session per set rather than per gig, which narrows that gap — but the second point below applies regardless of how the session is divided. Second, and more fundamentally, the progress model runs against this use case. The WWDC session states that the system expects these tasks to make measurable progress, and developers on these forums report tasks being marked stalled and expired after roughly thirty seconds without a progress update, with the system log naming the elapsed time since the last update. If that is accurate, it is decisive for me. A performance session has no progress to report. There is no unit of work and no fraction complete — the app is waiting on events that arrive when the musician plays, and between two songs there may be a minute of silence with nothing to update. The API would therefore expire my task not as an edge case but as its normal designed behaviour, because the defining property of the workload is the absence of measurable progress. I would welcome your correction if I have that wrong, since the cadence figure comes from developer reports rather than documentation, and it is the load-bearing part of my reasoning. Third, availability. iOS 26 and later excludes a significant part of my audience. Musicians very commonly dedicate an older iPad or iPhone to rig control — a deliberate choice rather than a reluctance to upgrade, because a dedicated device on a mic stand is more reliable than a phone that also takes calls. Gating this behind iOS 26 would mean the feature is absent on exactly the hardware most likely to be used for it. On the audio category: your point about indirect involvement is the one I would like to explore with App Review. My app does not itself produce audio, but it controls hardware synthesisers, effects processors and vocal processors that are actively producing it throughout a performance. If the app stops receiving MIDI mid-set, the audible consequence is immediate — a patch change does not happen, or an effect does not switch, in front of an audience. The relationship to audio is not incidental to the app; it is the entire purpose of it. I should be straightforward about something here. I did consider adding a metronome click to the app, which would have made it produce audio directly and qualify for the category without any argument. I decided against it. A metronome that exists only to satisfy a background mode is not a feature, it is a workaround wearing a feature's clothes, and I would rather ask for the category on the merits of what the app actually does than manufacture a technicality. I mention it because I think it illustrates the gap: the app can trivially become eligible by adding something musicians do not need, while remaining ineligible for doing the thing they do need. I have filed the Feedback report you asked for, describing the indeterminate-continuation case: FB24176109. If continued processing were to support sessions of unbounded duration without progress semantics, it would suit this well — it is the current shape that does not fit, not the concept. Thank you again for taking this to your colleagues. Knowing which door to knock on is worth a great deal.

Thank you for the note, and for the interest and care you've taken with this. Knowing you've discussed it with colleagues is genuinely reassuring — and useful in itself, since it tells me the question doesn't have an obvious answer I'd simply overlooked. Let me be clearer about where this sits for me, because my original post understated it. I've been treating Split View as the answer on iPad, but in practice it's a workaround. A musician on stage is reading lyrics or following backing tracks while MIDIDeviceManager sends Program Changes and SysEx to their instruments. Splitting the screen makes both apps harder to use at exactly the moment when legibility and hit targets matter most — dim light, mid-song, no second chances. On iPhone there's no Split View at all, so switching apps stops MIDI reception altogether. What I'm after is the behaviour audio apps already have: continue receiving and sending CoreMIDI while another app is frontmost. I understand why audio is the wrong declaration — MIDI is a control protocol, not an audio stream, and my earlier submission declaring it was rightly rejected under 2.5.4. But the runtime need is the same one that mode exists to serve: real-time work for someone who is looking at something else. I'll be honest that this matters more than a nice-to-have. The app is with beta testers now and I'm reluctant to release it publicly while a performer can lose MIDI control mid-song simply by glancing at their setlist. That's not a failure mode I want a musician discovering on stage. So two questions, and I'd welcome either answer. Is there a supported architecture for this today that I've missed? And if not, would an enhancement request be the right way to raise it? I'd rather ask for the right thing through the right channel than keep bending an existing mode to fit. Thanks again for the time you're giving this.