I ship a macOS audio player on the Mac App Store. I want to re-enable a remote-control feature, but I got rejected for it once already and I want to avoid burning another review cycle. I'd appreciate guidance from anyone who has shipped this pattern.
What the feature does
The Mac app runs a small local HTTP server (BSD sockets + GCD) on port 7777 and advertises itself over Bonjour as _tmstudioplayer._tcp. A companion iOS app discovers it with NWBrowser and controls playback: transport, volume, EQ, and so on.
Everything stays on the local network. There is no cloud service, no account, no login, and no user data leaves the device. The server only accepts connections while the Mac app is running and in the foreground.
This requires com.apple.security.network.server, plus NSLocalNetworkUsageDescription in Info.plist.
The rejection
An earlier build was rejected because com.apple.security.network.server was declared but App Review could not observe any functionality that justified it.
That was fair. At the time the iOS companion app did not exist publicly, so from the reviewer's side the entitlement genuinely looked unused. I removed the entitlement, and the app was approved and is on the store today with the remote feature disabled.
The iOS app now exists and works end to end. So I would like to turn the feature back on.
The actual problem
The feature is, by definition, not demonstrable on a single machine. To see it work, a reviewer needs a Mac and an iPhone on the same local network, with a build of the iOS app installed.
As far as I can tell, App Review does not link a macOS app record and an iOS app record so they get reviewed together — they are separate submissions in separate queues. So I cannot simply say "review these two together and you'll see it work."
That leaves me guessing at the right approach, and each guess costs a review cycle.
What I'm asking
- What is the correct submission order? Should the iOS companion be live on the App Store first, so I can point to it by name and App ID in the macOS Review Notes? Is a public TestFlight build enough? Does a reviewer even accept a TestFlight link as evidence?
- Is a demo video sufficient on its own? I can record the full flow — launching the Mac app, the iPhone discovering it over Bonjour, and control working — and attach it to App Review Information. Has that alone been accepted for a local-network feature, or does the reviewer still need to reproduce it?
- Is there a supported way to point one submission at another? Anything better than a plain-text description in the Review Notes — an App ID reference, a link, an attachment convention that reviewers actually follow?
- Does a reviewer have a second device available at all? If a two-device local-network setup is simply not something App Review will perform, I'd rather know now and plan around it than assume otherwise.
- Is there a fallback demo path I'm missing? For example, shipping a loopback/self-test mode in the Mac app that exercises the server on 127.0.0.1 and shows the result in the UI, so the entitlement is demonstrably used without a second device. Would that satisfy the "entitlement must be used" requirement on its own?
What I'll do either way
If the answer is that this cannot be demonstrated reliably, I'll keep the entitlement out and ship the remote feature only in a direct-distribution (notarized, non-sandboxed) build. I'd just rather not find that out through another rejection.
Any first-hand experience with local-network / companion-device features on the Mac App Store would help a lot. Thanks.