• I want to cancel my account subscription

    We're sorry to see you go. To cancel your subscription, you can contact your Account Executive or email

    If you are looking to delete a trial account that has no subscription, you may wish to reference the following knowledgebase article here.

  • How do I connect to my team’s LaunchDarkly account?

    If your team already has a LaunchDarkly account, a team member with invite privileges (typically an owner or admin) must send you an email invitation to join the team. Once you receive the invitation, follow the sign up instructions and you will be automatically added to your team’s account.

    If your company uses an Identity Provider to manage access via SAML SSO, you will need to log in for the first time from the IdP in order to provision your account. You may find it helpful to reference the following knowledgebase article: Adding new team members with SSO/SAML

    If you have an existing LaunchDarkly trial account and want to use that email address to join your team, please take the following steps:

    • Log in to your existing LaunchDarkly account
    • Navigate to the team tab of your account settings
    • Scroll down to the bottom and click the button to Delete your account 
      • Please note that you can only delete your account if it is not associated with a subscription


    • You should now be able to accept the invitation from your team owner using your preferred email. 
    • If you're unable to delete your account, you also have the option of editing your email address from the profile tab of your account settings.

  • SSO: How do I provision users with specific roles?

    You can configure your identity provider to send `role` and `customRole` attributes when the team member is signing into LaunchDarkly.

    `role` is an optional attribute, which represents a built-in LaunchDarkly role. It must be one of reader, writer, admin. If unspecified, the default role is reader.

    `customRole` is another optional attribute. It must be a list of keys for custom roles to give to the team member. These will replace the member’s existing custom roles. If a member has any custom roles, they will supersede the built-in role.

  • Adding New Team Members with SSO/SAML

    When a team member tries to log in to a LaunchDarkly account which has SSO enabled, they should be redirected to login via your Identity Provider. If a team member is prompted for a password, this indicates that an account has not yet been provisioned for that team member.

    LaunchDarkly does not support automatic provisioning of new team member accounts. To add new team members, the initial login must be done via a LaunchDarkly application set up in your Identity Provider. Once that step has been taken, the account will be created. On subsequent logins, the team member will be redirected to your IdP when attempting to log in via the LaunchDarkly website.

    If you get an error saying that you can't join because the email is part of an existing account, then you should follow the steps in this knowledge base article and then try logging in through your IDP again:

    Read more about user provisioning in our documentation here.

  • What happens if I have multiple custom roles with conflicting policies?

    If a team member has multiple custom roles, we iterate through each role and see if it will approve the action. If so, the action is approved immediately. If the role denies a certain action, we continue to iterate through the remaining roles to see if any of those roles approve that action. 

    In short, if a user has a custom role that allows an action that another custom role denies, the action will ultimately be allowed.

  • I lost my Multi-Factor Authentication Code and Can't Log into my Account

    If MFA is enabled and you are locked out of your LaunchDarkly account, you can contact the LaunchDarkly owner or one of the admins at your company to get a reset code. Once you receive this reset code, you will need to head to your profile settings page and re-enable MFA using an authenticator app on your phone.

    Are you the account owner? Unfortunately, no one at your organization has sufficient permissions to reset your MFA. Reach out to and we'd be happy to assist you in regaining access to your account. 

    Read more about LaunchDarkly Multi-factor Authentication in our documentation here 

See all 10 articles

Getting Started

  • How do I get started with LaunchDarkly?

    Check out our Getting Started Checklist to get the most out of LaunchDarkly and check out our getting started docs.

    After you create a LaunchDarkly account, you will have access to our Quickstart tutorial.  The Quickstart will walk you through the creation of your first feature flag using any of our SDKs.  

    We also have sample applications for all supported SDKs. These are simple applications designed to show how the SDK works. You can find them on Github here

About LaunchDarkly

  • Why should I use LaunchDarkly?

    LaunchDarkly revolutionizes software development by allowing you to iterate quickly and safely. We allow you to easily flag your features, which enables you to manage them from the LaunchDarkly dashboard.

    • Roll out a new feature to a subset of your users (like a group of users who opt-in to a beta tester group), gathering feedback and bug reports from real-world use cases.
    • Gradually roll out a feature to an increasing percentage of users, and track the effect that the feature has on key metrics (for instance, how likely is a user to complete a purchase if they have feature A versus feature B?).
    • Turn off a feature that you realize is causing performance problems in production, without needing to re-deploy, or even restart the application with a changed configuration file.
    • Grant access to certain features based on user attributes, like payment plan (eg: users on the ‘gold’ plan get access to more features than users in the ‘silver’ plan). Disable parts of your application to facilitate maintenance, without taking everything offline.
  • Is it easy to set up and integrate?

    Yes! We’ve made LaunchDarkly extremely developer-friendly and easy to integrate. You and your team can start controlling your first feature in minutes. We also provide excellent customer support to help you get started.

    See our getting started guide.

  • Is it fast and reliable?

    Our unique streaming architecture ensures that feature flags are updated instantly, without introducing any latency to your site. LaunchDarkly's performance is even faster than storing feature flags in your own database. We also have multiple layers of redundancy. All flags are served locally and are backed up by multiple zones of AWS and our globally distributed CDN provider. With the architecture, a feature flag will always be available.

  • How do I schedule a demo or get more info?

    Complete this form to schedule a free demo and we will be happy to demonstrate the platform and answer all your questions. Our feature flag platform is built to support both small and large development teams with enterprise-grade speed and reliability.

  • How does the free trial work?

    Simply click Start free trial to create an account. All plans come with a free 30 day trial with the core Pro plan features. Contact us using the demo form if you would like a demo or have any questions.

Feature Flags

  • Which order are flag targeting rules evaluated?

    Our targeting rules evaluate from top to bottom and take the first match. The first matching rule will take precedence over any of the rules that follow.

    Learn more about this in our documentation here.

  • What can I do with feature flags?

    Feature flags are a software development best practice of gating functionality. Functionality can be deployed “off”, then turned on via the feature flag, separate from deployment. With feature flags, you can manage the entire lifecycle of a feature.

    Feature flags (or feature toggles) are meant to complement features branching and distributed version control systems. One of the primary benefits of features flags is the ability to separate feature lifecycle management from code deployment.

    LaunchDarkly provides an intuitive dashboard that lets developers wrap features or application behavior in our feature flags. You can then manage your features on the LaunchDarkly dashboard, roll out to users, and see how well things are performing. Non-technical users can observe feature performance and analytics, perform A/B testing, set and manage goals, and have full visibility into feature performance.

  • How does it work?

    LaunchDarkly lets developers wrap features or application behavior in our feature flags. You can then manage your features on the LaunchDarkly dashboard, roll out to users, and see how well things are performing. LaunchDarkly gives you total control of your application.

    • Turn features on and off for your users without waiting for engineering.
    • Roll out to percentages of your population, segments, or whatever rules you define.
    • Get faster feedback from the people you want. Measure the impact of your features with our NewRelic and Optimizely integrations.
    • Create custom rules for granular targeting
    • Manage configurations using our multivariate feature flags
  • What are boolean and multivariate feature flags?

    LaunchDarkly supports both boolean and multivariate feature flags. A boolean flag has two variations true and false, which works best for feature flags that will simply turn things on and off. A multivariate flag allows you to define two or more custom variations. These variations can be strings, numbers, JSON objects, or JSON arrays. Check out the docs.


Product Features

  • Does LaunchDarkly support SSO?

    LaunchDarkly supports single-sign on with SAML 2.0. All identity providers that support SAML 2.0 should work with our platform. We've tested support for the following SAML 2.0 identity providers:

    • Okta
    • OneLogin
    • Azure Active Directory
    • Google Apps
    • Active Directory Federation Services (ADFS)
    • PingIdentity
    • Centrify
    • Duo
    • SecureAuth

    We have official apps already built for Okta, OneLogin, and Azure. See our documentation for complete setup instructions as well as configuration tips for some specific providers.

  • User Targeting

    LaunchDarkly targeting lets you turn features on or off for individual users or groups of users. You can use the Targeting tab to roll features out for internal testing, private betas, or usability tests before performing a broader rollout. You can create your own rules to target who you want, when you want.

    Learn more about targeting users in our documentation here.

  • Targeting by attribute

    In addition to targeting individual users, LaunchDarkly allows you to set up targeting rules that target users by attribute. 

    Each rule has three parts: an attribute, an operator, and a user value.   You can create as many custom targeting rules as you want for each feature flag and even perform percentage rollouts for each rule.

    All users that have not been individually targeted or who are not targeted by a custom rule will be evaluated by the default rule.

    Learn more

  • Flag management dashboard

    LaunchDarkly provides you with a centralized dashboard to manage the lifecycle of your features from local development, to QA, to production. Manage multiple different software projects with their own development environments.

  • Projects and environments to manage your development process

    Projects allow you to manage multiple different software projects under one LaunchDarkly account. For example, you can create one project called Mobile App and another project called Web App. Each project will have its own unique set of environments and feature flags. By default, all team members in your LaunchDarkly account will have access to every project within that account.

    Environments allow you to manage your feature flags throughout your entire development lifecycle — from local development to QA, staging, and production.

    When you first sign up, you're provided with two environments within a project. By default, they're named Test and Production. Each environment has its own private SDK key, which is used to connect a LaunchDarkly SDK to a specific environment.

    Each feature flag that you create has its own unique set of targeting rules for each environment. This means that you can change your flag rollout rules in a development or staging environment for QA testing before rolling out to production.

  • The Debugger: Real-time feature flag events

    The debugger helps you test whether you've set up LaunchDarkly correctly. From the debugger, you can see your users' feature flag requests and events in real-time.

    You can access the debugger from the sidebar. The debugger must be the active tab in its browser window in order for events to appear. You can have a second window open with your application, if you need to click around in your app in order to generate events.

    Please note that in high-volume environments, the events sent to the debugger may be sampled. When this happens, you will see a subset of events on the debugger, instead of every event.

    The debugger is helpful for troubleshooting that you're successfully sending events to LaunchDarkly and is not intended as a source of truth for the variations your users are receiving. The debugger displays real-time events only and does not keep a historical record of this data. 

    Read more about the debugger in our documentation.

See all 11 articles

Use Cases

  • Can you schedule a flag?

    LaunchDarkly does not have a built in way to schedule a flag for a particular date, however this can be achieved with targeting rules. For example, you may want to serve true to show your feature, but only after November 19th, 2018.

    You can use the before/after operator to compare dates in your targeting rules. You'll simply need to include the current date as a custom attribute in your user object and then set up a targeting rule that evaluates to true if the date value in your user object is after the date specified in your targeting rule. Note that dates must be formatted in unix milliseconds for date comparisons. You can reference this in our documentation here

    Here's an example in JavaScript showing how to include the current date in unix milliseconds in your user object:

    var user = {
    "key": "67yx27g7fxl004483",
    "custom": {
    "current_date": new Date().getTime()

    And here's a screenshot showing how the targeting rule would look in the UI:

    This example user will evaluate to `true` because their current date attribute is after the date specified in the flag's targeting rules.

  • Is it required to use a unique key for anonymous users?

    Anonymous users work just like regular users, except these users are not stored in your dashboard. One of the primary reasons that users are sent anonymously is to avoid having a lot of unauthenticated users polluting the user dashboard. Another reason is to avoid sending PII, but we recommend the use of private user attributes if that is the case. 

    There are some cases where you do need to generate a unique key for anonymous users. If you are targeting users individually by key, using LaunchDarkly's A/B testing feature, or the Analytics Data Stream you would want unique keys. You also want unique keys when conducting percentage rollouts. For that reason, the general documented advice is to treat the anonymous users like regular users and assign unique IDs. 

    If you do not have a need to uniquely identify your anonymous users, you could use a shared key for these users.

  • How are A/B Test Results Calculated?

    When a conversion event comes in, we try to find the 'closest' feature event. To do this, we look for the latest feature event for this user in the 24 hours preceding the conversion event. (Failing that, we will look for the earliest feature event for that user in the 5 minutes following the conversion event, to allow for clock skew). Once we find a feature event, we look at which variation that user saw, and we add the user to the set of users who saw that variation and converted.

    So, suppose the following timeline:

    t0: user X sees variation A
    t1: user X sees variation B
    t2: user X triggers a conversion event

    As long as there is less than 24 hours between t2 and t1, user X will be added to the variation B conversion set (and *not* the variation A conversion set).

    In this same timeline, but when there is more than 24 hours between t2 and t1, we will not find a feature event, so the conversion will not count at all.

    Suppose an alternate timeline:

    t0: user Y sees variation A
    t1: user Y triggers a conversion event
    t2: user Y sees variation B
    t3: user Y triggers a conversion event

    If there is less than 24 hours between t1 and t0 AND less than 24 hours between t3 and t2, then user Y will be counted in both the variation A conversion set *and* the variation B conversion set. 

    Now, suppose a third timeline:

    t0: user Z sees variation A
    t1: user Z triggers a conversion event
    t2: user Z sees variation A
    t3: user Z triggers a conversion event

    If there is less than 24 hours between t1 and t0 AND less than 24 hours between t3 and t2, then user Z will be counted *once* in the variation A conversion set.

    Keep in mind that the important time limit here is 24 hours. If someone converts 5 days (or 2 days) after (or 2 days) getting a variation, they will not be counted.

    Contact us at if you have any additional questions.

  • Feature Flag Driven Development

    Feature flags/toggles/controls harness the power of test-driven development (TDD).   This is the process of releasing and iterating features quickly, testing those features, and making improvements.  Think of it as Lean UX methodology.  You release light features to receive market feedback.  You iterate on that feedback, make improvements, and redeploy.

    Think of feature flag-driven development as a way to receive iterative market feedback on your product, rather than solely depend on isolated customer feedback.  It’s a way to test how your features perform in the real world and not just in an artificial test environment.

    Read the full article

  • Creating a feedback loop with LaunchDarkly
    Customers use LaunchDarkly to deploy a new feature to a small subset of their users. The platforms lets you easily segment users. For example, you can:


    • Rollout to a percentage of total users
    • Create a beta group of hand-picked users
    • Give early access to a single VIP customer
    • Dogfood to internal users only
    • Create an “opt-in” allowing users to self-select to see new features
    Once you’ve rolled out the feature to a group, measure it to see if the feature has impacted behavior as you expected and use that feedback to inform your path. Fix issues and make changes as necessary then continue to rollout incrementally to the entire base.
  • Empowering team collaboration and non-technical users
    LaunchDarkly allows teams to develop software in a way that’s fundamentally healthier, removing friction from the Product and Engineering relationship. The results are a dramatic savings in time and focus as well as faster delivery with greater trust.
    Empowered product development means that both technical and non-technical team members can collaborate on software releases. Because feature rollout will be decoupled from code deployment, team members outside of Engineering would be able to control the visibility of particular features without compromising the app’s integrity. Product and QA teams are empowered to make changes to feature visibility without consuming engineering resources.
    LaunchDarkly offers end to end feature flag management to allow an entire product development organization to control who gets the right feature, when.
    • Facilitate coordination between Engineering and Product, allowing you to break up larger features into smaller deployments and release features faster to select customers
    • Give control to the Product team, taking the burden of re-deploying off of engineering
    • Reduce friction between teams, cultivating a healthier and more productive relationship
See all 7 articles


Performance, Speed, and Reliability

  • What happens if the SDK loses connectivity to LaunchDarkly?

    The SDK relies on its stored state to evaluates flags. By default the SDK first initializes with an empty state. When the SDK first initializes, it opens a streaming connection to LaunchDarkly. The initial response from LaunchDarkly contains the SDKs current state. The SDK will then keep this streaming connection open and when any change is made in the LaunchDarkly dashboard or via the Rest API, LaunchDarkly will send these changes to all currently connected SDKs.

    If the SDK ever loses connectivity to LaunchDarkly then it will continue attempting to establish a streaming connection until it succeeds. If you try to evaluate a flag before the SDK receives its initial state, or you try to fetch a flag which otherwise doesn't exist, then the SDK will return the fallback value. All SDKs provide synchronous (through blocking and/or polling) and asynchronous ways of waiting for the SDKs state to initialize.

  • Do you make a remote call every time a feature flag is requested?

    LaunchDarkly uses a novel streaming architecture to serve feature flags without making remote requests. We use server-sent events (SSE), a protocol for one-way real-time messaging, to send messages to your servers whenever you change the feature flag rules on your dashboard. SSE is widely used for server-to-browser messaging, but it works equally well for server-to-server communication. The SSE connection is all handled under the hood by our SDKs.

  • How do you ensure no latency?

    Our unique streaming architecture ensures that feature flags are updated nearly instantaneously, without introducing any latency to your site. LaunchDarkly’s performance is even faster than storing feature flags in your own database. We also have multiple layers of redundancy to ensure your users always receive a flag. 

  • Do I need to modify my firewall to use LaunchDarkly?

    In most cases no— our streaming connection only requires that your server be able to make an outbound HTTPS connection to *

  • What’s the overhead of a feature flag request?

    Almost nothing. LaunchDarkly’s SDKs use a streaming connection to asynchronously receive updates to your feature flag rules. Your actual feature flag requests are served from memory (or a Redis store, if you configure one). This adds less than 1 millisecond of latency to your page loads— about as fast as looking up a value in a hash table.

  • If I have a large number of backend servers, will LaunchDarkly serve features to my users consistently?

    Yes. With our streaming architecture, updates will be reflected in all your servers within milliseconds. If you require even stronger consistency guarantees, you can configure our SDKs to read and write from a shared Redis store.

See all 8 articles

How It Works

  • What is the targeting logic for percentage rollouts?

    The variation a user receives is determined based on the users key. When a percentage rollout is evaluated it generates a hash from the user's key, the user's secondary attribute if available, and a hidden salt attribute stored in the flag. The SDK then uses this hash to generate a percentage which is used in conjunction with the percentage rollout configuration to determine the variation a user receives.

  • Are anonymous users tracked when A/B testing?

    Yes, anonymous users are included in A/B testing. You will need to set an appropriate user key for anonymous users so that we can track each anonymous user separately; a session key might be appropriate. We don't display anonymous users on the Users screen because anonymous users couldn't be managed from LaunchDarkly, so they would only add clutter to the screen.

  • What happens when the MAU limit is reached?

    We do not impose a hard cap on MAUs. We'll never halt access or send you a bill based on overages. We allow for variance as we know a company's user base can grow unexpectedly over time. That said, we do limit the amount of users that will be saved in your dashboard. 

    When you exceed your MAU, your new users and changes to existing users (such as new attributes) will no longer appear in the dashboard. It's important to note that your users will continue to evaluate their flags correctly. This only impacts your ability to view user updates in the dashboard.

  • Do you have a REST API?

    All of our SDKs are built on top of the LaunchDarkly REST API. In fact, the entire LaunchDarkly web site is driven via the same API, so it’s heavily tested and complete. If you want to build a custom integration or export your data this API reference is the place to start.

  • What is the default rule?

    The default rule is a final rollout rule for any users that are not individually targeted and do not match any of your configured targeting rules.

    As with other rules, you can choose to serve a specific variation, or apply a percentage rollout to any remaining users.

    For a straightforward percentage rollouts, you can simply use the default rule for a feature flag. For example, to roll out the true variation to 50% of your users, set the default rollout rule to true 50% and false 50%.

  • How do you calculate confidence interval for A/B tests?

    We use a z-score.

See all 17 articles



  • Why should I avoid individually targeting too many users?

    Individually targeting users increases the size of the payload fetched by the SDK when initializing, and the memory footprint of the SDK.

    A better strategy would be to assign a custom attribute to the users who should receive the feature flag and then set up the targeting rules to serve the flag to users who have that attribute. This allows you to target groups of users without increasing the size of the payload.

    Read more about our targeting rules. 

  • How can I be notified of interruptions to the LaunchDarkly service?

    The best way to get updates from us regarding service status is by subscribing to this RSS feed:

  • The difference between SP- and IdP-Initiated SSO?

    LaunchDarkly supports only IdP-initiated SSO:

    Identity Provider Initiated (IdP-initiated) SSO.  With this option, your end users must log into your Identity Provider's SSO page (e.g., Okta, OneLogin, or Microsoft Azure AD) and then click an icon to log into and open LaunchDarkly the web application. 

    Service Provider Initiated (SP-initiated) SSO.  LaunchDarkly does not support this option: This option gives your end users the ability to sign into the apps Login page and then sends an authorization request to the Identify Provider (e.g., Okta, OneLogin, or Microsoft Azure AD). Once the IdP authenticates the user's identify, the user is logged into app. 

  • MFA Verification Failed. Code is Invalid

    You may see an error indicating your MFA code is invalid. This error is caused when the 6 digit code generated by your authenticator app has expired or is tied to the wrong QR code. 

    If you're trying to set up MFA for the first time, or re-enable MFA after a reset, one possibility is that you're using a 6 digit code from your authenticator app that is tied to a different QR code than the one displayed on the current page. If you're setting up MFA by scanning a new QR code, be sure not to refresh the page before entering your 6 digit code, or a new QR code will be generated, rendering the code on your applicator obsolete. If you're signing up for a new account, or setting up MFA for the first time, we recommend taking the following steps to ensure you're working with the correct QR code:

    1. Delete all existing LaunchDarkly QR codes in your authenticator app.
    2. Follow the invitation link from your email and scan the QR code displayed.
    3. Immediately enter the 6 digit code generated from your application without refreshing.

    If you have confirmed that your 6 digit code is being generated for the correct application, or you have already successfully enabled MFA and you are seeing this error, this may be caused by the clock on your authenticator app being out of sync. We recommend the Google Authenticator app, and Google recommends the following steps to verify that you have the correct time on your authenticator app:

    1. Go to the main menu on the Google Authenticator app
    2. Tap More  Settings.
    3. Tap Time correction for codes
    4. Tap Sync now

    If you're still experiencing any issues, please contact

  • How long does it take for users to appear in the dashboard?

    It generally takes just a couple of minutes for a user to appear in the dashboard. 

    You can check the debugger to verify that the users data is being sent to LaunchDarkly. If you open the debugger in an active tab and call variations on your users, you will see them appear in the debugger almost immediately. This is a great option to make sure that LaunchDarkly is receiving your user data without waiting for users to appear in the dashboard.

    You can read more about the debugger in our documentation here.

  • I am unable to connect because of a mismatched origin header
    We take the security of your data at LaunchDarkly seriously. One of the protections we've implemented is validation that the Origin header for any API request authenticated by session cookie matches the expected Origin header (namely This is just one way that we help to prevent CSRF attacks. (Note that we do not require origin matching when authenticating via Access Token, so this does not affect normal API usage.)
    If the Origin header does not match what's expected, we return an error. And since our application relies heavily on interaction with the API, the application will not function properly.
    Known causes
    Any browser extension that intentionally changes the Origin header will cause this problem. For example, the Allow-Control-Allow-Origin: * Chrome extension is known to change the Origin header to and will result in the problems described above.
See all 11 articles


  • Rules targeting users by attribute are not working

    Everything works as expected when you target users individually, and users appear to be receiving the correct variation based on the default rule. So why aren't your rules targeting users by attribute working as expected?

    The SDK will only evaluate flags using the user object you provide it. The SDK does not use the attributes shown on the dashboard, and user attributes are not synchronized across SDK instances. The only information that is synchronized is flag configuration related data. You will need to provide all applicable user attributes for your configured targeting rules to apply.

  • Java SDK: How do I use the SDK behind a HTTP/HTTPS proxy?

    The following example shows how to configure your SDK to connect to LaunchDarkly through a HTTP/HTTPS proxy.

    LDConfig config = new LDConfig.Builder()
        .proxyUsername("USERNAME") // OPTIONAL
        .proxyPassword("PASSWORD") // OPTIONAL
    .build(); LDClient ldClient = new LDClient("YOUR_SDK_KEY", config);


  • JavaScript SDK: Events blocked by DNT or Adblock

    When you evaluate feature flags, the SDK queues up an analytic event to send back to LaunchDarkly. The events endpoint is used to send these events. If you are working with the JavaScript SDK, enabling your browser's Do Not Track setting or using Adblock will block all requests to 

    Rest assured that this does not impact your user evaluations - your users will continue to receive the correct variation for the requested flags. This only impacts the ability to send information back to LaunchDarkly.

  • Does the LD SDK support using Postgres to cache feature flag configurations?

    Not currently, though we have a store abstraction that you can extend with your own storage backend like Postgres. You can read more about what caches we support here:

  • I am getting a JSON parsing exception with the Java client


    Json parsing exception: java.lang.IllegalStateException: Expected BEGIN_OBJECT but was….ExceptionType:

    Make sure your build tool is bringing in the proper version of Gson. The LaunchDarkly SDK may have problems with versions earlier than 2.2.4. To enforce the proper version add this dependency:



  • I am getting SSL exceptions when calling variation() in the Java client

    Make sure your build tool is bringing in the proper version of the Apache http client. The LaunchDarkly SDK may have problems with versions earlier than 3.3.6. To enforce the proper version add this dependency:

    1. <dependency>
    2.  <groupId>org.apache.httpcomponents</groupId>
    3.  <artifactId>httpclient</artifactId>
    4.  <version>4.3.6</version>
    5. </dependency>


  • 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 in iOS SDK flag evaluation

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

    • The iOS SDK utilizes a streaming architecture to keep itself in sync with your configurations on the dashboard. If any change is made, these changes will be picked up by your iOS users the next time they get online.
    • When the SDK receives any updates from LaunchDarkly they are cached to Core Data, so that the SDK can still evaluate flags even when offline.
    • When a user first installs your app, until the first stream is established with 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.
    • When a current user uses the app while offline, or if variation calls are made before the SDK has has finished initializing, then the SDK will continue to serve variations using the old state, and you may see these events show up occasionally in your dev console after making changes.
    • If your SDK If you need to change your user, or you want to wait until the SDK has finished synchronizing with LaunchDarkly, you should use the userDidUpdate delegate to wait until the feature flags for the new user have been received.
  • 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.