Why does call to embedded framework fail in app archive?

My Swift app uses a 3rd party framework to control a peripheral. The framework was written for Objective-C so I created a bridging header to make it work in Swift. It all works perfectly when I run the app within Xcode, or when I build the app and run it directly from the Debug folder.


But when I archive the app and then export a copy to my hard drive, some (but not all) calls to the 3rd party framework fail. [details removed]


UPDATE:

Issue is App Sandbox. Debug builds had it off. Archives had it on. Debug builds with Sandbox break too.


The 3rd-party framework is set as "embedded content" with "embed and sign" turned on. Calls to it return basic data, like version number. This framework needs to communicate with a 3rd party app to actually talk to the USB peripheral. That may be the hurdle; is there a way over it?


Note: When the 3rd party framework calls out to initialize a link to the 3rd party app (and fails) I see a "Connect Error: No such file or Directory" log entry in the Xcode output window.

Up vote post of Jeff Dickson Down vote post of Jeff Dickson
329 views
Posted by
Jeff Dickson
Reply
Add a Comment

Replies

After a day spent researching, this seems to be the damning line from Apple: The following app behaviors are incompatible with App Sandbox...you cannot sandbox an app that controls another app. Link. I do not know the inter-process communication method the 3rd party SDK uses to talk to its partner app, but it's not AppleEvents. The interface is proprietary.


My app already has "Accessibility" privileges turned on in the Security & Privacy control panel (it has to monitor the keyboard)...that works fine. I tried giving my app "Full Disk Access" and the SDK still will not connect to the partner app. I can find no other entitlement that applies in this case.


Any suggestions?

Posted by
Jeff Dickson
Up vote reply of Jeff Dickson Down vote reply of Jeff Dickson
Add a Comment

A sandboxed app can definitely control another app. However, the other app has to be designed for that. What framework are you using? What does the developer of the framework say when you ask them about this problem?


On a more fundamental level, why are you even sandboxing? Do you plan to release this app in the Mac App Store? It requires Accessibility and Full Disk Access? Sorry, but that's dead on arrival.


On an even more fundamental level, why are you doing this at all? Have you been following macOS developments over the past few years? I suggest coming up with a different idea for an app that would work on iOS. Such an app would be easy to port to macOS in the Mac App Store.

Posted by
john daniel
Up vote reply of john daniel Down vote reply of john daniel
Add a Comment