Reproduce: Download live-caller-id-lookup-example
Add
let url = URL(string: "http://another-macbook.local:80")!
let task = URLSession.shared.dataTask(with: url) {(data, response, error) in
guard let data = data else { return }
print(String(data: data, encoding: .utf8)!)
}
task.resume()
anywhere in the code
run PIRService target in xcode
Result: no dialogue, host is unreachable
Works fine when launching same binary from terminal
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.
Moreover xctest was able to present local network access dialogue when also run from Xcode it seems.
Xcode’s testing infrastructure is interesting because it runs with or without a host application. With a host application, the test inherits the privileges of that app. Without a host application things get weird.
So it can be said Im just experimenting
Right, cool. That matters because it affects what workarounds you have access to.
I tried some things here in my office and the results were… well… interesting:
-
An Xcode project created from the macOS > Command Line Tool template just works.
-
A Swift package created from the macOS > Command-Line Tool template prompts, but then fails to get access.
-
In both cases you can get things to work by choosing Product > Scheme > Edit Scheme and then selecting Options > Console > Terminal. This runs the tool in Terminal, so it inherits local network access from there.
I believe that the package case fails because the tool is ad-hoc signed with no Info.plist
:
% codesign -d -vvv Test774465b
…
CodeDirectory v=20400 size=16324 flags=0x20002(adhoc,linker-signed) hashes=507+0 location=embedded
…
Info.plist=not bound
…
Note A tool can’t have an Info.plist
file, but you can embed the Info.plist
contents into the tool’s binary. In Xcode, check out the Create Info.plist Section in Binary build setting.
That makes it impossible for local network privacy to track properly. AFAIK Xcode’s Swift package integration doesn’t let you fix this, at least not easily [1].
So, where does that leave you? I’m not entirely sure. It’s certainly reasonable for you to file a bug requesting that Xcode do better in this case. And if you do, please post your bug number, just for the record. But in terms of a short-term workaround, either switching to an Xcode project that uses your Swift package or using Terminal as your console seem like feasible options.
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"
[1] I suspect you could hack your way around both of these issues with sufficient application of .unsafeFlags(…)
. However, that kinda undermines the point of using a Swift package.