[quote='788783022, DTS Engineer, /thread/755911?answerId=788783022#788783022'] You could engage with the Syphon community to rework or extend the protocol into something that’s compatible with the App Sandbox. [/quote] I wish, but not gonna happen. It is a very established protocol / framework that all of the big name programs already use (Processing, Max/MSP, TouchDesigner, Resolume, BlackMagic, etc). The first idea seems a little too obtuse for the users. If I have to self distribute, I might as well self distribute the actual "Pro" version of the app. The key piece that I was missing ended up being that payloads are not allowed in NSDistributedNotificationCenter. Bummer. Thanks a bunch for your time and help!

[quote='788593022, DTS Engineer, /thread/755911?answerId=788593022#788593022'] So who sends the notification? The server, when it start ‘advertising’? Or the clients when they start ‘browsing’? [/quote] Both. When a server instance is started, it sends a ServerAnnounce notification (this has a payload). When a client is started, it sends a ServerAnnounceRequest notification - which requests for all servers to send out ServerAnnounce notifications. Clients can then build a list of all servers available. [quote='788593022, DTS Engineer, /thread/755911?answerId=788593022#788593022'] The App Sandbox allows distributed notifications but disallows any payload. See the discussion in Protecting user data with App Sandbox. [/quote] I believe this is the fundamental problem, as the CFMessagePort name is part of the ServerAnnounce payload - it is how clients discover what CFMessagePort to connect to for each server. And matches what I see empirically - if I add an App Group and change the naming convention of the CFMessagePort to match the App Group - I no longer see the "Permission Denied" error, however, because there is no payload, the client has no way of discovering the CFMessagePort name that my app (a server) is using. [quote='788593022, DTS Engineer, /thread/755911?answerId=788593022#788593022'] Oh, one last thing: Are you concerned about sandboxing because you want to ship on the Mac App Store? Or just because it’s the right thing to do? [/quote] My app is already shipping on the Mac App Store, and Syphon support is one of the most requested features among VJ enthusiasts and professionals. Keeping it on the Mac App Store is a high priority, but it looks like the Sandbox restriction of no payload for distributed notifications is a big hurdle. If the App Store didn't require a sandbox, I would not be using the Sandbox at all.

[quote='788466022, DTS Engineer, /thread/755911?answerId=788466022#788466022'] It seems like Syphon is a peer-to-peer thing, that is, there’s no centralised daemon or agent that the user has to install. Is that correct? If so, how do Syphon peers discover other Syphon peers? [/quote] I am not too familiar with the internals of Syphon - but after looking over the source code (it's open source) - it looks like it is using NSDistributedNotificationCenter as a centralized messaging system for discovery and IPC setup. In Syphon lingo, a server is an app that publishes frames - a client is an app that can consume frames from any of the servers currently running. I believe it goes something like this: What I have found is that Syphon clients are sensitive to the CFMessagePort naming convention, i.e., if you mess with this naming convention at all, discovery stops working.

Hi Quinn, now that the weird build issue is resolved (though I'm still not sure how I got into that state) - do you have any suggestions / examples of how to use CFMessage ports in an Sandbox App other than the App Group naming convention (I can't change the port naming convention, as it is a long established naming convention of Syphon, which is supported by hundreds of video apps). I have a sample (non sandboxed) app that simply publishes SpriteKit frames to a Syphon Server instance. Is there anyway possible to do this in a Sandbox App? Sample Project

That confirms that the sandbox is enabled. I’m not sure what’s going with your project to build it this way, but the presence of that entitlement explains the runtime behaviour you’re seeing. Yes, I saw that. Anyway, I think it might be an Xcode bug. I looked through the build settings, and in the CodeSigning section of the Build Settings, the Enable App Sandbox setting was set to true, even though I had deleted that Entitlement in the Signing & Capabilities project tab. After setting the build setting of "Enable App Sandbox" to No - it is no longer building as a Sandbox App, and export of the Metal Texture is working perfectly. Cheers

Oh, and just for clarity, here is info on my developer machine: macBook Pro: M1 Max Xcode: Version 15.3 (15E204a) macOS: Sonoma 14.4.1

Here is the output of codesign -d --entitlements: [Dict] [Key] com.apple.application-identifier [Value] [String] R6FVYGV9JW.com.alloneword.macOS.Euler [Key] com.apple.developer.icloud-container-identifiers [Value] [Array] [String] iCloud.com.alloneword.eulervs [Key] com.apple.developer.icloud-services [Value] [Array] [String] CloudKit [Key] com.apple.developer.team-identifier [Value] [String] R6FVYGV9JW [Key] com.apple.security.app-sandbox [Value] [Bool] true [Key] com.apple.security.files.user-selected.read-write [Value] [Bool] true [Key] com.apple.security.get-task-allow [Value] [Bool] true