LDClient.start fails when not running in a sandbox on macOS

[GaryHughes]

Describe the bug The succeeded flag passed to the LDClient.start completion is always false if the application is not sandboxed. LDClient.start(config: config, startWaitSeconds: 10.0) { succeeded in

To reproduce Create a new default macOS application in Xcode. Add a package dependency on the LaunchDarkly iOS SDK. Add code to initialise LDClient as per the hello-ios example. Verify that LDClient.start succeeds. Change the App Sandbox setting to NO in the entitlements file. LDClient.start will now fail.

Expected behavior LDClient.start should succeed.

Library version 9.12.3

XCode and Swift version XCode 16.3, Swift 5.

Platform the issue occurs on macOS

Additional context Our applications runs as launch daemons serving XPC services where we cannot use a sandbox. I found this issue trying to get LD to work in that context, there maybe other issues in this configuration as well but the sandbox is a blocker at this point. I'm happy to supply test code if that helps but this should be simple to reproduce.

[keelerm84]

@GaryHughes

The succeeded flag passed to the LDClient.start completion is always false if the application is not sandboxed.

The parameter passed to the completion method is a boolean indicating if the initialization process timed out or not.

Receiving false would indicate that the system was able to initialize successfully. You can confirm by evaluating a flag in this completion method and ensuring you are receiving the expected variation result.

[keelerm84]

When in sandbox mode, you were likely seeing true because the SDK requires an outgoing network connection to function properly by default. If you update the entitlements file to include "Outgoing Network Connections"="YES", then it should function properly in either mode.

[GaryHughes]

It still fails unfortunately, here is the entitlements file for reference.

<?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.security.network.client</key>
	<true/>
	<key>com.apple.security.app-sandbox</key>
	<false/>
</dict>
</plist>

It would be good to have richer diagnostics exposed rather than just a boolean flag.

[keelerm84]

When I test with those same settings, the SDK operates as I would expect.

It would be good to have richer diagnostics exposed rather than just a boolean flag.

You can inspect the connection information associated with the client to receive more information about the current status. I have included a sample below (note that succeeded -> timedOut logic inversion).

In addition to this, the SDK logs a fair amount of information using the standard os_log utility (tagged with subsystem "com.launchdarkly", category: "ios-client-sdk"). Feel free to send those to me (via slack if you prefer), and we can troubleshoot this some more.

LDClient.start(config: config, context: context, startWaitSeconds: 10) { timedOut in
    if (timedOut) {
        let information = LDClient.get()?.getConnectionInformation()
        os_log(.debug, "LDClient timed out: %s", information.debugDescription)
    } else {
       os_log(.debug, "LDClient connected successfully.")
    }
}

[keelerm84]

@GaryHughes checking in to see if the logs or connection information provided any additional insight into the issue?

[github-actions[bot]]

This issue is marked as stale because it has been open for 30 days without activity. Remove the stale label or comment, or this will be closed in 7 days.