Defining and targeting mobile applications

Overview

This guide discusses best practices for defining applications in LaunchDarkly so that you can easily target specific apps and versions.

Within LaunchDarkly, an application is a resource that describes what you are delivering to a customer. LaunchDarkly automatically creates applications when it establishes a connection with a LaunchDarkly SDK that contains application information. After an application is created, you can build flag targeting rules based on application name, version, or other properties, such as whether or not a particular application version is supported. Together, these options help you streamline adoption, enable mobile feature flagging capabilities, and gracefully deprecate unsupported app versions. You can use LaunchDarkly to support all stages of the mobile application lifecycle.

This guide discusses how to create applications and use them in your flag targeting. Then, it provides an example of how this works in practice.

Concepts

You should understand the following concepts before you read this guide.

Contexts

A context is a generalized way of referring to the people, services, devices, or other resources that encounter feature flags in your product. When a flag evaluation occurs, LaunchDarkly uses the context attributes to determine what flag variation to serve. To learn more, read Contexts.

Targeting

To target is to specify that LaunchDarkly should serve certain flag variations to specific contexts that encounter feature flags in your applications. You can create targeting rules to describe the set of contexts. To learn more, read Target with flags.

Creating applications

An application is a resource that describes what you are delivering to a customer.

There are two ways to create applications in LaunchDarkly:

• The most common way to create applications is to use an SDK that supports application metadata. LaunchDarkly automatically creates an application when it establishes a connection with a LaunchDarkly SDK that contains application information. "Application metadata" refers to the set of application information you can specify in your SDK configuration. This includes an application identifier and name, and an application version and version name. To learn more, read Application metadata configuration.

• The other way to create applications is to use Engineering insights. As part of this feature suite, you can use the engineering insights deployment events API to send LaunchDarkly information about your deployments, including an application key. LaunchDarkly automatically creates an application for each unique application key it receives from any deployment event. To learn more, read Send events from your deployment pipeline.

In addition to creating applications, LaunchDarkly also automatically creates application versions if you include version information in either of the above methods. After the application versions are created, you can mark application versions as "supported" or "unsupported." For example, this allows you to consistently target all of the unsupported versions of your application, without needing to make updates to any segments or flag targeting when you deprecate a version.

To view or update your applications and application versions, navigate to Account settings and click the Applications tab. To learn more, read Applications and application versions.

Understanding application and environment information

Your mobile targeting is not limited to just the name and key of the application and application version. LaunchDarkly mobile SDKs can also automatically provide additional data about each mobile application and the environment where it is running.

When you enable the collection of this data, LaunchDarkly automatically adds it to an ld_application context and an ld_device context. The mobile SDKs include both of these contexts in each flag evaluation. To learn more, read Automatic environment attributes.

To target mobile applications and devices you must both use a supported mobile SDK, and configure your SDK to enable collection of environment attributes.

After you create applications and enable the collection of mobile application and environment data, you have access to a wealth of information about your mobile apps. You can use this information in your flag targeting rules.

For each mobile application, the information you have available includes:

• Application key
• Application name
• Application kind
• Application version name
• Application version key
• Application version support status

The application kind is automatically set to mobile, browser, or server, depending on the kind of SDK that LaunchDarkly establishes a connection with when it creates the application. The values in the other application fields are set based on information you provide during your SDK configuration.

For each device, the information you have available includes:

• Device manufacturer
• Device model
• Device operating system

To learn more about the specific ld_application and ld_device fields, read Understanding the automatically added environment attributes.

Creating flag targeting rules based on application information

If you are working with one or more mobile SDKs, have enabled collection of environment data, and have applications in your account, then you can add mobile targeting rules for your feature flag. After LaunchDarkly has evaluated flags for contexts with mobile application and environment information, the attributes from the ld_application and ld_device contexts are available when you create mobile targeting rules.

From your flag's Targeting tab, create a mobile targeting rule. The template for each mobile rule includes clauses for applications and devices, and automatically recommends targeting based on version support status. You can adjust each mobile targeting rule as needed.

Example: Targeting mobile applications

This section provides an example of how targeting mobile applications can work in practice.

Suppose you're an application developer for a hospital chain, Global Health Services. Doctors and nurses use your application on various devices and in various locations. You would like to capture information about the application versions and mobile devices that your customers use, so that you can:

• provide specific features based on location, device, job function, or other attributes
• prompt your customers to upgrade their apps when needed, and
• provide a gracefully degraded experience if they continue using unsupported app versions.

Here's one way to approach this situation:

1. Configure your SDK. Define some basic information about your application, and ask LaunchDarkly to capture details about the application and device that each customer is using.

   Here's how:

   Example SDK setup, Android SDK (Java)

   Example SDK setup, iOS SDK (Swift)

   LDConfig config = new LDConfig.Builder(AutoEnvAttributes.Enabled)
       .applicationInfo(
           Components.applicationInfo()
               .applicationId("ghs-android-app")
               .applicationName("Global-Health-Services-App-for-Doctors")
               .applicationVersion("1.0.0")
               .applicationVersionName("v1")
       )
       .build();
   COPY

   To learn more, read Application metadata configuration.

2. Publish your applications to their respective app stores.

3. Create targeting rules for the flags used in your application.

   For example, you may want to enable an extra feature if the device model includes "Pixel":

   

   As another example, you may want to show a splash screen advising customers to upgrade to the latest version if their application version is unsupported:

   

   To learn more, read Mobile app and device targeting.

4. Continue development on your application. For each new version, remember to update the application information in your SDK configuration:

   Example SDK updated setup, Android SDK (Java)

   Example SDK updated setup, iOS SDK (Swift)

   // SDK setup for version 1.3
   LDConfig config = new LDConfig.Builder(AutoEnvAttributes.Enabled)
       .applicationInfo(
           Components.applicationInfo()
               .applicationId("ghs-android-app")
               .applicationName("Global-Health-Services-App-for-Doctors")
               .applicationVersion("1.3.0")
               .applicationVersionName("v1")
       )
       .build();
   // SDK setup for version 2
   LDConfig config = new LDConfig.Builder(AutoEnvAttributes.Enabled)
       .applicationInfo(
           Components.applicationInfo()
               .applicationId("ghs-android-app")
               .applicationName("Global-Health-Services-App-for-Doctors")
               .applicationVersion("2.0.0")
               .applicationVersionName("v2")
       )
       .build();
   COPY

5. Review your application usage.

   To view your applications, navigate to the Account settings page. Then click the Applications tab. Click the name of the application you're interested in. The application's Versions tab appears. From the Versions tab, you can review details on the devices using your application, and review the adoption of your application by application version.

   

   To learn more read, Viewing applications and application versions.

6. Clean up older versions.

   When you decide that version 2 of your application has been released for a sufficient period of time, you can mark version 1 of your application as unsupported. Any targeting rules that you have for unsupported versions will now automatically match v1. You don't have to adjust any targeting rules for flags or segments. To learn more, read Editing an application version.

   If you have feature flags that are only used in v1 of your app, now is a good time to deprecate them. Deprecating a flag hides it from the live flags list without archiving or deleting it. You can restore a deprecated flag if you need it, or find it to reference or update its configuration later. Deprecating flags can simplify your flags list, especially in situations where you have a long tail of customers using older versions of your applications. To learn more, read Deprecating, archiving, and deleting flags.

Conclusion

With applications, you can easily target specific app versions based on application, device, or version support status. This guide described how to create applications and use them in your flag targeting. Then, it provided an example of how this works in practice.