Be exact about the boxes Apple ships. There is no Foundation Models API that sandboxes a tool for you.
| Option | iOS 27 | macOS 27 | What it really does |
|---|---|---|---|
| App process sandbox | Always on | On if you enable App Sandbox | Limits the app against the system. Every in-process tool shares those rights. |
| XPC service | Limited, special cases | First choice for a second process | Moves work out of the UI process. You can give the helper fewer rights. |
| App extension | Yes, for extension types Apple defines | Yes | A separate runtime Apple already isolates. You cannot invent a new extension kind. |
| stdio child MCP process | Not a general app tool | Possible for a helper you sign | Do not plan an iOS shipping app around spawning random binaries. |
On iOS, your honest design is usually this: keep the tool in-process, then enforce an allow-list, a timeout, and no network unless the method needs it. If the work matches an existing extension point, use that extension. Do not tell a stakeholder that iOS will run an unsigned helper in its own sandbox because you used MCP.
On macOS, add an XPC service target. Talk to it with a typed protocol. Give that target a tighter App Sandbox. The UI process holds Foundation Models. The helper holds file or script work. See XPC and App Sandbox.
Read Talk to tools with MCP, Stop prompt attacks and leaks, and Make several agents agree first before a helper is allowed to see raw user text.
Next, put every tool through one executor type.
Key concepts
- No Foundation Models API sandboxes a tool for you.
- On iOS 27 the app sandbox is always on. XPC is limited. App extensions are Apple-defined types.
- On macOS 27 an XPC service is the first choice for a second process with fewer rights.
- A stdio child MCP process is macOS-only, not a general iOS shipping plan.
Takeaways
- Name the OS and the box. Do not sell macOS XPC as an iOS feature.
- On iOS use allow-lists and extensions Apple already defines.
- On macOS move risky work to an XPC helper.