Aside from stability, there are few things that matter more to mobile customers than the performance of the application. The vast majority of customers expect apps to load in 2-4 seconds. Apps that take longer ultimately end up losing customers.
While developers often focus on speeding up their own code, optimizing their app as much as they can, there is often an overlooked area that can be slowing your app down and costing you customers: third-party software development kits (SDKs).
Enter Third-Party SDKs
When developing for iOS or Android, third-party SDKs are often a vital part of what makes a modern app. Whether it be additional features, network integration, advertising frameworks or analytics software, SDKs are an important part of the mobile development process that saves developers valuable time and money. Unfortunately, not all SDKs are created equal and some may be responsible for significant performance issues.
One common area where SDKs can cause these problems is during their startup routine. Because many SDKs add integration with third-party software or services, SDKs will often query information or retrieve resources online in order to properly function. If this process is not properly optimized, or if a user’s network connection is subpar, this can result in a significant slowdown when the SDK initially launches.
Even worse, some SDKs will intentionally slow down the launch process in order to make sure they have the necessary information. For example, because Android does not allow network communication in the main UI thread, many SDKs stall and won’t return control back to the main UI thread until they have received the information they need. While such SDKs may legitimately need the information they’re retrieving in order to function properly, when that retrieval process occurs during the launch of the application, it’s the user who ultimately suffers and, by extension, the app maker.
Unfortunately, this problem is far more widespread than many developers realize, with even well-known apps experiencing these issues.
The most obvious solution is to avoid loading third-party SDKs during that critical 2-4 seconds during which users expect an app to open.
First and foremost, by calling third-party SDK initialization only when those SDKs are actually going to be used, your app’s startup time is kept to a minimum. Equally important, however, is the overall performance benefit your app is likely to experience. For example, in large, complex applications, it’s unlikely that every single feature will be accessed each session. As a result, pre-loading SDKs that may not be utilized wastes resources and adds unnecessary overhead. In contrast, loading them on demand ensures your application only uses the resources it needs in response to the customer’s actions.
The Importance of Monitoring
Unfortunately, there are situations when an SDK is vital to the entire application’s functionality and may need to be pre-loaded—if not during launch, then shortly after.
In such situations, it is important to be able to monitor your application’s performance to find potential bottlenecks, not only with your own code but also with third-party SDKs. In fact, Google recommends that developers use tools to profile their app’s performance. While Google recommends the default, basic Android development tools, such tools may not show the complete picture.
In contrast, the Embrace platform gives you valuable insight into every aspect of your app’s performance, including third-party SDKs. This gives you the information you need to be able to identify potential problems, determine the best place in your app to call those SDKs and—if need be—identify SDKs that need to be replaced due to unacceptable performance. The end result is an application that meets and exceeds your customers’ expectations.
Take the Embrace platform for a test drive and see how it can improve your app.