App Sandbox - Outgoing connections

the same is not the case with MKMapView.

Right. MapKit does this work in a separate process that’s not affected by your sandbox configuration.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Right. MapKit does this work in a separate process that’s not affected by your sandbox configuration.

I would assume that MapKit is an exception. Or is it indeed possible to spawn a child process that exceeds the permissions of its sandboxed parent process?

Or is it indeed possible to spawn a child process that exceeds the permissions of its sandboxed parent process?

That’s not possible because the child process inherits the parent’s sandbox.

I would assume that MapKit is an exception.

I wouldn’t call it an exception per se. Rather, this behaviour is an artefact of how maps works. You could implement the same sort of thing in a third-party product. For example, if your app used XPC to talk to your non-sandboxed daemon:

• The daemon could run a network request on behalf of the app regardless of the app’s sandbox setup.

• Alternatively, the daemon could look at the sandbox setup of your app and choose not to run this network request.

It sounds like map view has chosen the first option and web view has chosen the second. To my mind that makes sense, in that map view will talk to a specific set of servers while web view can talk to an arbitrary server, but I could see how opinions might differs.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

You could implement the same sort of thing in a third-party product. For example, if your app used XPC to talk to your non-sandboxed daemon.

Will this product be (Mac) App Store compliant? As in, can you potentially ship a non-sandboxed daemon along with your app and establish an XPC communication like MapKit does?

Will this product be (Mac) App Store compliant?

My example above was about what’s technically possible, not about the App Store. App Sandbox, while required by the App Store, can be used in directly distributed apps as well. There are numerous third-party apps that explore this space.

As to what’s allowed on the App Store, App Review has the final say on that. I don’t work for them, and thus can’t interpret their guidelines for you. However, clause 2.4.5(i) seems pretty clear to me:

Apps distributed via the Mac App Store … must be appropriately sandboxed

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Thanks for taking the time to respond. I should have been clearer - the questions were specifically about apps going to the App Store. These apps (and any extension, XPC, etc) are sandboxed. I expected that com.apple.security.network.client = false would restrict all outgoing connections. But that doesn't work with MapKit - it still is able to make outgoing connections.

• Is MapKit the only exception - as in, is there any other way (or any other system framework) that is expected to bypass this entitlement? Is this list already documented?
• Besides this entitlement, is there any other way to restrict outgoing connections?

Is MapKit the only exception

No. I’m sure there are many. One example that I’m very familiar with relates to trust evaluation: When you evaluate trust on a trust object, trustd might make a network request for CRL or OCSP. Is that an outgoing network connection made by your app? Or one made by the system? It’s kind of a matter of definition.

to bypass this entitlement?

Again, I wouldn’t cast it in those terms.

I’m not super familiar with MapKit but here’s a question for you: Can you, as the app developer, control which servers are contacted by the map view?

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Can you, as the app developer, control which servers are contacted by the map view?

No.

No. I’m sure there are many.

Thanks. That certainly helps with understanding the scope of com.apple.security.network.client.