Kevin, You offered to say what would help or hurt when I put the audio category question to App Review, and I would rather use that offer than waste it. Draft below. Two things I would genuinely like your read on, if you have a moment. First, whether I have characterised the category correctly. My argument rests on the app's relationship to audio being real rather than nominal — it produces none, but every device it controls is producing audio throughout, and a dropped MIDI message is audible in the same second it fails. If that framing is wrong, or if it is a framing Review has heard and dismissed before, I would sooner know now. Second, whether anything in it would cause the letter to be set aside before the argument is reached. I have led with the July rejection deliberately, on the basis that volunteering it reads better than having it found. I may have that backwards. I have kept the deployment-target point in, since it is the reason I am still asking at all having taken your advice on BGContinuedProcessingTask. If it reads as pressure rather than as a coverage gap, tell me and I will soften it. No obligation — you have already given this more time than I had any right to expect. Hello, I am the developer of MIDIDeviceManager (Apple ID 6786022183), an iOS and iPadOS app used by musicians to control external MIDI hardware during live performance. I am writing to make the case that the audio background mode is essential to this app, and to ask you to consider it on the merits of what the app does rather than on whether it emits sound. The argument MIDI is not a peripheral technology in the musician's world. It is the control layer of every modern stage rig. When a guitarist steps on a switch between songs, what travels is not audio — it is a MIDI Program Change, and every audible thing that follows depends on it arriving. To a working musician, interapp and inter-device MIDI communication is as essential as audio itself, and a MIDI message that fails to arrive is heard by the audience in the same second. MDM sends Program Changes, Control Changes and SysEx to hardware synthesisers, guitar processors, vocal processors and effects units, and receives MIDI from foot controllers. During a performance the musician is reading lyrics or following backing tracks in a second app, so MDM must continue receiving and sending CoreMIDI while another app is frontmost. The app produces no audio itself. But every instrument it controls is producing audio continuously throughout a performance, and MDM is what changes their sounds. Its relationship to audio is not incidental — it is the entire purpose of the app. When MDM stops receiving MIDI mid-set, a patch change does not happen in front of an audience. A decision I want to be open about I considered adding a metronome click to the app. It would have taken an afternoon, it would have made MDM produce audio directly, and it would have qualified for the category without any argument at all. I decided against it, and I want to be plain that the reason was ethical rather than technical. A metronome that exists only to satisfy a background mode is not a feature — it is a workaround wearing a feature's clothes, and shipping it would have meant obtaining a capability by misrepresenting what my app is. I would rather ask you directly and be told no than qualify by a technicality I do not believe in. I mention it because I think it illustrates the gap precisely: the app can become eligible by adding something musicians do not need, while remaining ineligible for doing the thing they do. What I have already done I submitted a build declaring the audio background mode on 7 July 2026. It was rejected under Guideline 2.5.4, correctly — I had not explained the indirect relationship, and the app plainly did not produce audio. I accepted the rejection and shipped without it. I then raised the question with Developer Technical Support on the Apple Developer Forums, in the thread "Correct background mode for an app that must receive CoreMIDI while another app is frontmost". Kevin Elliott of DTS was generous with his time. He suggested BGContinuedProcessingTask, which I am implementing and which works. He also observed that apps have sometimes been approved for the audio category when their involvement with audio is indirect — for example when they control hardware that is actively playing — and suggested I discuss that with App Review directly. That is why I am writing. Why the alternative does not close this BGContinuedProcessingTask requires iOS 26. My deployment target is 17.6, deliberately. Musicians very commonly dedicate an older iPad or iPhone to rig control — a device that lives on a mic stand and does nothing else, chosen precisely because it is not the phone that takes calls mid-set. Those devices are frequently several years old and stay on the iOS they shipped with. The new API therefore solves the problem for users on current hardware and leaves it unsolved for exactly the users most likely to need it. The audio category is the only route that covers them. What I am asking That an app of this description be considered eligible for the audio background mode: an app producing no audio directly, whose sole function is to control hardware that is producing it, in a context where a dropped message is immediately audible. If the answer is no, I would be grateful to know that plainly, and ideally why, so that I can document the limitation honestly for my users rather than resubmit and hope. Thank you for your time and consideration. Christian McCormick Creator of MIDIDeviceManager

Kevin, Thank you — this is the most useful technical exchange I have had in years of building this app, and I am grateful for the time you have given it. You have corrected me on two counts and I am glad of both. The duration limit was my misreading: I had taken "many minutes" as a ceiling rather than a description, and your point that the increments can be arbitrarily fine changes the picture entirely. And your clarification on the user-action requirement — that a "Start Show" control with tasks produced on a cadence satisfies the intent — is the part I had read too narrowly. The comparison to bulk downloads made it click. So we are implementing it. Synthetic progress at interval is inelegant, as you say, but it works, and a working solution today is worth more than an ideal one later. I take your point about App Review's comparative comfort with this API over the audio category, and I understand why: visibility cuts in its favour. I will still pursue the audio category conversation, and I want to be straightforward about why, because it is not a matter of preference. BGContinuedProcessingTask requires iOS 26. My deployment target is 17.6, and that is deliberate. Musicians very commonly dedicate an older iPad or iPhone to rig control — a device that lives on a mic stand and does nothing else, chosen precisely because it is not the phone that takes calls mid-set. Those devices are often several years old and stay on whatever iOS they shipped with. So the API solves the problem for users on current hardware and leaves it unsolved for the users most likely to need it. The audio category, if it applied, would cover everyone. That is the whole of my reason for still asking. I will use the contact link you sent, and I will not represent the request as anything other than what it is: an app that produces no audio itself, but whose entire purpose is controlling hardware that does, where a dropped MIDI message is audible to an audience in the same second it fails. If there is anything you would suggest including — or avoiding — when I put that to Review, I would welcome it. You clearly know that conversation better than I do. Thank you again. You said your goal was to help me ship a product now, and you have done exactly that. It is appreciated more than a forum reply can easily convey. Christian McCormick MIDIDeviceManager

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.