We’re having an iPad issue accessing the local network with iPadOS 26.3. We have an automation system that tests our app on an iPad using accessibility tags. the XCTest test code sends messages from the iPad via TCP/IP to setup external test equipment. The messages abruptly stopped transmitting across the iPad blood-brain barrier with iPadOS 26.3 (26.2.1 and earlier works fine).
The technique that worked involved installing a helper app with the same bundleID as our app, allowing the helper app to access the network, and when our app runs it has network access through the helper. It’s clever and kludgey.
Forums that we referenced in the past:
https://developer.apple.com/forums/thread/663858
TN3179: Understanding local network privacy | Apple Developer Documentation
I suspect that something was changed in 26.3 that closed our window. I need two things: ID what is different in 26.3 and fix the automation system. If there’s a new way for XCUITest code to access the local network I’m happy to try it out.
XCTest Bundle cannot access local network.
For those reading along at home, I helped one of ADietz’s colleagues with this issue a few years back, so I have some inside knowledge.
For example, I know that they filed a bug about this back then (FB12846267). I just checked on it, and there’s nothing helpful to share on that front.
It’s clever and kludgey.
Yeah, and unfortunately it has come unstuck. That’s why I was hoping that we’d provide a real fix for this issue, but that hasn’t happened )-:
I’d like to confirm that this is tied to the OS version rather than the Xcode version. If you use Xcode 26.3 to run this test on iOS 26.2 and 26.3, it works on 26.2 but fails on 26.3. Right?
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"
The combinations we've confirmed are:
Xcode 16.x + iPadOS 18.x.x = works
Xcode 26.2 + iPadOS 18.x.x = works.
Xcode 26.2 + iPadOS 26.2.1 = works.
Xcode 26.2 + iPadOS 26.3 = broken.
Have we tried Xcode 26.3? No - honestly I was neck deep in troubleshooting when Xcode 26.3 came out last week. And we're a med device company so we typically don't rush to update tools because we need to maintain specific development environments. I know you're thinking "what could it hurt at this point?" lol. I'll test that today.
Xcode 26.2 + iPadOS 26.3.1 = broken
Xcode 26.3 + iPados 26.2.1 = works
Xcode 26.3 + iPadOS 26.3 = broken
Xcode 26.3 + iPadOS 26.3.1 = broken
Thanks for all that extra info. So, it’s definitely correlated with iOS 26.3. Which is strange, because I can’t think of any iOS 26.3 aligned change to local network privacy that would affect this.
You could file a bug about this issue, but I’m not sure it’d get traction. As you noted in your first post, this whole process is a bit of a kludge, and it’s hard to argue that we should fix this (in contrast to FB12846267, which we definitely should fix, but haven’t yet).
But if you do file a bug, please post your bug number, just for the record.
At this point I think it might be worth considering different approaches. I zenned on that a bit today and I wasn’t able to come up with anything I’m truly happy with.
One approach that I like is to have your UI test use some sort of IPC mechanism to the app, have the app connect to the accessory under test, and then proxy the UI test’s requests to that accessory. Unfortunately I couldn’t think of a good way to do that. It is possible to set up an IPC channel between apps that you own — for example, by using a Unix domain socket in an app group that both apps have access to — but the issue here is that Xcode doesn’t let you configure any capabilities on the MyAppUITests-Runner app that hosts your tests [1].
There are IPC channels that don’t require entitlements — named pasteboards, Darwin notifications, keychain access groups [2], and possibly more — but none of them are particularly appealing. They’d all require serious kludgery to set up the proxy that I described above.
Probably the best option I can think of was to do this off device:
- You set up a central proxy server, one not on the local network used by your test setup.
- You have a Mac app that registers with the proxy server.
- Your UI test code opens a connection to the proxy server. This is not on the local network, so local network privacy doesn’t apply.
- The proxy server tells the Mac about this connection.
- The Mac connects to your accessory.
- And then traffic flows via UI test <-> proxy server <-> Mac <-> accessory.
It’s a bit of a faff to set up, but it should work OK both today and in the foreseeable future.
ps You’ve probably worked this out already (-: but it’s better to reply as a reply, rather than in the comments; see Quinn’s Top Ten DevForums Tips for this and other titbits.
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"
[1] I tried forcing the issue via some choice build settings, but Xcode wasn’t happy with that. And even if I got it to work, I’m not sure it’s a sustainable solution.
[2] Well, keychain access groups are mediated by entitlements, but the test runner has an App ID keychain access group which the main app could claim access to because it starts with your Team ID.
Here's the bug identifying information.
Mar 6, 2026 at 4:13 PM – FB22152886 iPadOS 26.3 breaks test automation ability to communicate on local network.