“We are unable to process your request”

Thanks for the reply! I have also tested AVAudioSession with .playback + .mixWithOthers on watchOS. That works for mixing my metronome with Spotify while the metronome app is in the foreground, which matches the behavior I already see on iPhone. However, on watchOS the metronome stops once the app goes to the background, while longFormAudio keeps it alive but then conflicts with Spotify. So this seems to be a watchOS-specific limitation rather than a general AVAudioSession limitation on Apple platforms. It would be very useful if watchOS supported a way to combine background audio persistence (longFormAudio) with cooperative mixing behavior (mixWithOthers) for lightweight apps like metronomes, cues, or coaching audio. Is there any way I can formally request this feature other than the FB22273077 I have already submitted?

[quote='880623022, timboudreau, /thread/818192?answerId=880623022#880623022, /profile/timboudreau'] that would … probably run afoul of one or another App Store policy [/quote] I don’t work for App Review, and thus can’t give definitive answers about their policies. My only advice is that you peruse the App Review Guidelines. At a technical level, on macOS it is possible for an app extension to communicate with an app or launchd agent or daemon that you control, even in the presence of sandboxing. If you want the server side of this to be an app, the best option is for that app to listen on a Unix domain socket that’s located in an app group container. If you want it to be a launchd job, prefix the named XPC endpoint with an app group ID. Both of these are documented in App Groups Entitlement. For more on the XPC side of this, see the various links in XPC Resources. Specifically, XPC and App-to-App Communication has a bunch of backstory you’ll need. And please don’t use Mach messaging directly! [quote='8806240

[quote='880466022, jzilske, /thread/817599?answerId=880466022#880466022, /profile/jzilske'] it's not a WebView where I suspect the traffic comes from [/quote] Ah, OK, thanks for setting my straight. [quote='880467022, jzilske, /thread/817599?answerId=880467022#880467022, /profile/jzilske'] How would I go about setting that up? [/quote] Which bit? To get the source information from mitmproxy, view the request, switch to the Detail tab, and look at the Client Connection section. Getting process information from the packet trace is a small extension of the RVI process described in Recording a Packet Trace: Set up RVI per the Set Up iOS Packet Tracing section. When you get to the tcpdump command, add the -k option to cause it to dump each packet’s metadata. And tcpdump naturally logs the port numbers in each packet, so you can look for outgoing packets whose source port matches the port number you get from the proxy. Having said that, this won’t help given your clarification that the co