Hello,
I need to develop a Network Extension (Transparent Proxy) that sends data to the host application for analysis. Network Extension - XPC client Host application - XPC service
I am trying to implement it with XPC. However, when attempting to connect, I see the following error in the system logs on client side.
[0x1015a2050] failed to do a bootstrap look-up: xpc_error=[3: No such process]
I assume the problem occurs because the Network Extension cannot find the registered XPC service. On the service side, I see the following message in the logs:
2026-02-24 13:15:36.419345+0300 localhost fgstnehost[58884]: (libxpc.dylib) [com.apple.xpc:connection] [0x100bdee70] activating connection: mach=true listener=true peer=false name=TEAM_ID.group.app_id.netfilter.xpc
Entitlements Network Extension:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>com.apple.developer.networking.networkextension</key>
<array>
<string>app-proxy-provider-systemextension</string>
</array>
<key>com.apple.security.application-groups</key>
<array>
<string>TEAM_ID.group.app_id.netfilter</string>
</array>
<key>com.apple.security.app-sandbox</key>
<true/>
<key>com.apple.security.xpc.mach-lookup.global-name</key>
<array>
<string>TEAM_ID.group.app_id.netfilter.xpc</string>
</array>
</dict>
</plist>
Entitlements host application:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>com.apple.developer.networking.networkextension</key>
<array>
<string>app-proxy-provider-systemextension</string>
</array>
<key>com.apple.developer.system-extension.install</key>
<true/>
<key>com.apple.security.application-groups</key>
<array>
<string>TEAM_ID.group.app_id.netfilter</string>
</array>
<key>com.apple.security.app-sandbox</key>
<true/>
<key>com.apple.security.xpc.mach-service.name</key>
<array>
<string>TEAM_ID.group.app_id.netfilter.xpc</string>
</array>
</dict>
</plist>
Server.m
@interface XPCServer ()
@property (nonatomic, strong) NSXPCListener *listener;
@end
@implementation XPCServer
- (instancetype) init
{
self = [super init];
if (self != nil)
{
_listener = [[NSXPCListener alloc] initWithMachServiceName: XPC_SERVICE_ID];
_listener.delegate = self;
}
return self;
}
- (void) start
{
[self.listener resume];
}
- (BOOL) listener:(NSXPCListener *) listener shouldAcceptNewConnection:(NSXPCConnection *) newConnection
{
return YES;
}
@end
Client.m
@interface XPCClient ()
@property (nonatomic, strong) NSXPCConnection *connection;
@end
@implementation XPCClient
- (void) connect
{
self.connection = [[NSXPCConnection alloc] initWithMachServiceName: XPC_SERVICE_ID options: NSXPCConnectionPrivileged];
self.connection.invalidationHandler =
^{
[[OSLogger sharedInstance] error: "XPCClient: connection can not be formed or the connection has terminated and may not be re-established"];
};
self.connection.interruptionHandler =
^{
[[OSLogger sharedInstance] error: "XPCClient: the remote process exits or crashes"];
};
[self.connection resume];
}
@end
What could be the root cause of this issue? Are there any recommendations for implementing IPC between a Network Extension and aß Host Application?
Thank you in advance.
I need to develop a … Transparent Proxy … that sends data to the host application for analysis.
You mean the container app, right? [1]
If so, this architecture is a concern. A transparent proxy operates system wide, so:
- There may be 0, 1, or more active GUI login sessions.
- Each active GUI login session can be running an instance of your container app.
So if multiple users are logged in and they each run a copy of your container app, what are you expecting to happen?
This architecture also informs your XPC architecture. A NE sysex, which operates much like a launchd daemon, can’t connect to a named XPC endpoint advertised by an app because the system wouldn’t know which app to connect to [2].
Given the above, the only architecture that works is for your sysex to advertise the named XPC endpoint and for your apps to connect to it. And that’s exactly what’s demonstrated by the Filtering Network Traffic sample code.
There are a couple of things to note here:
- The NE sysex must be sandboxed, so the XPC endpoint name must be a ‘child’ of an app group ID.
- The container app may or may not be sandboxed. If it is, it must claim access to the same app group ID.
- App group IDs have a long and confusing history on the Mac. App Groups: macOS vs iOS: Working Towards Harmony.
- But one key point is that having an app group ID like
TTT.group.something, whereTTTis your Team ID, is weird. It’s a macOS-style app group ID that contains the iOS-stylegroupprefix for no reason. It’s better to stick with one style or the other. - The
NetworkExtension>NEMachServiceNameproperty in your sysex’sInfo.plistmust list the name of the XPC endpoint.
Finally, looking at what you posted:
com.apple.security.xpc.mach-lookup.global-nameisn’t a valid entitlement. It’s not causing problems, because everything in thecom.apple.security.is unrestricted [3], but it’s not helping either.- Likewise for
com.apple.security.xpc.mach-service.name. - In future, it’d be to good check whether an entitlement is actually valid before using it. See Determining if an entitlement is real.
- It looks like you were aiming for a temporary exception entitlement. You shouldn’t need any of those to make this work but, for reference, you can learn more about these in The Case for Sandboxing a Directly Distributed App.
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"
[1] In Apple parlance, the container app is the app in which the extension is embedded and the host app is the app that’s using the extension. In the case of a sysex, the host app isn’t an app, but the system itself.
[2] Indeed, that’s part of the reason why the system prevents apps from advertising named XPC endpoints. See XPC and App-to-App Communication.
[3] See TN3125 Inside Code Signing: Provisioning Profiles for a definition of that term.