• How do the mobile SDKs handle airplane/flight mode?

    When a user is in flight or airplane mode on their mobile device, LaunchDarkly will use the latest stored flag settings.  When the user reconnects to a network, LaunchDarkly will reconnect to the stream to see if there are any new flag updates.  This ensures that your users will always receive the most up-to-date flag settings, even if their devices are not currently connected to a network.

  • I’m seeing inconsistencies while testing the iOS SDK

    There are a few things to be aware of with the iOS SDK:

    • When an app is first installed, until the first response is received back from LD, the default variation values will be used. There is a delegate pattern (see userDidUpdate) that can be used to block until the first response is received.
    • The iOS SDK polls for changes based on the TTL set in your environment settings (https://app.launchdarkly.com/settings#/projects). Unlike our other SDKs, a minimum TTL of 1 minute is enforced. So if your TTL setting is 0, changes will still take 1 minute to propagate to your mobile client
    • If your app has a login flow, or you need to change to a brand new user context for any reason, you should use the userDidUpdatedelegate to wait until the feature flags for the new user have been received. Once the user context has been seen at least once, it is cached on the device.
    • If you change environments during testing (say by changing your API key from a test key to a production key), you should clear the device cache.
  • Why is there a different mobile environment SDK key?

    The server SDK keys are intended to be embedded in trusted environments. The mobile SDK keys are suitable for use in (untrusted) mobile clients. If a mobile user were to somehow decompile your app, or gain access to your mobile key, there is really no impact, as those keys can only access a restricted subset of our APIs that do not reveal any private data.