Introducing automatic startup instrumentation

Understanding app startup requires looking at different phases, which can vary slightly between iOS and Android. Embrace’s SDKs consider app startup as consisting of two main parts: 

• Pre-main time: This is the initial phase where the system loads code into memory, executes initializers, and creates the app process.
• Main time: This part covers the app initialization logic that is specific to your application and controlled by the developer.

Whether an app executes a “cold” vs. “warm” launch significantly impacts how quickly it becomes visible and usable to the user.

A cold start occurs when your app starts from scratch. This happens if the app hasn’t been launched since the device booted or after an update. In a cold start, the app isn’t in memory, and no process exists, making it the longest possible launch type. 

A warm start happens when the app was already partially launched in the background or was running but killed by the system to free up memory.

The specifics on warm start differ slightly between Android and iOS. 

On Android, a warm startup means the operating system has partially launched the app in the background already, so the process exists when the user opens the app. On iOS, it refers to when a user resumes an app that the system previously killed due to memory needs; the app was launched before and is partially in memory, but the process no longer exists. 

Monitoring both types of starts is essential because user experience standards and benchmarks vary. For instance, on Android, Google Play console warns about cold starts over five seconds or warm starts over two seconds. On iOS, Apple recommends the first frame renders within 400ms.

Additionally, Android and iOS have a couple of operating system-specific nuances that emerge with the startup process and require more specific consideration. 

Starting with iOS 15, the system may execute what’s called “pre-warming”, which essentially primes your app in the background without a user needing to tap. This helps to potentially reduce the waiting time before the app is usable. 

Pre-warming executes the app’s launch sequence up to, but not including, the point where main() calls UIApplicationMain(_:_:_:_:. This allows the system to build and cache necessary low-level structures.

After pre-warming, the launch sequence pauses until the app is fully launched, or the system removes it from memory. Pre-warming can happen after a device reboot or periodically based on system conditions. 

Embrace is able to track and distinguish the pre-warm process. Every startup trace includes an isPrewarmed attribute indicating if pre-warming occurred.

Android Vitals provides aggregated metrics for app startup time and warns developers when their app launch has exceeded certain thresholds. While this is helpful, there are some limitations to its value. 

Firstly, Android Vitals in the Play Console give you summarized, aggregated metrics for your app. It does not provide context into each individual instance. With Embrace, you actually can drill down into every unique instance of a session startup and interrogate all the individual spans that make that startup happen. It also gives you the ability to add metadata, such as custom attributes and events, to further enrich your understanding of why an app launch may be longer than expected. 

Additionally, the Play Console only provides data from Android 10 onwards. Embrace, meanwhile, supports Android versions 5 and up, so customers with older devices and operating systems can still be tracked.

With Embrace’s automatic startup instrumentation feature, the SDK automatically measures cold and warm app starts and labels these as separate traces emb-app-startup-warm, and emb-app-startup-cold. As noted above, the SDK also distinguishes pre-warmup for iOS. 

The trace for startup is made up of a number of child spans that mark the individual processes needed to complete a full app launch. The specific child spans within these startup traces depend on whether it was a cold or warm start. 

For Android users, we also automatically add a custom attribute to all startup traces: emb-startup-activity-name. This attribute tells you the name of the activity where the app launch finished. 

By automating the measurement and tracing of cold starts, warm starts, and accounting for iOS pre-warming, Embrace provides immediate, deep insight into your app’s startup performance without requiring manual instrumentation. This allows you to quickly identify and address bottlenecks, ensuring your users have the fastest, smoothest launch experience possible.

To start monitoring and analyzing your app startup traces, check out our docs. If you’re new to Embrace, you can get started with your own account for free here.