Improve mobile app performance with SDK abstraction

This article was updated on June 30th, 2021

User engagement has shifted from primarily web and in-store experiences to mobile apps, which has led to increased customer interest in usability, personalization, and security. Marketers and product managers wanting to capitalize on the transition to mobile have worked with developers to implement tech platforms for functions such as mobile advertising, messaging, governance, analytics, and attribution directly into their app source code through SDKs. This has become so common that the mobile tech platform landscape has ballooned to over 8,000 solutions, and the average enterprise app now contains over 14 separate SDKs, all in an effort to provide richer product insights and innovative user experiences. 

While this focus on better mobile experiences is a good thing, adding individual SDKs into the app code can create serious complications for both developers and users alike. SDK implementations can take precious hours away from core development work, not only in the initial deployment, but also in the ongoing maintenance work required.

Once implemented, third-party code can lead to excessive TCP network time and slow TLS handshakes, which can have significant impacts on CPU time/usage, network behavior, and client-side performance. Determining the performance impact of third-party SDKs versus native app code can be challenging and time-consuming, and can result in PMs attributing poor engagement metrics to deficiencies in the native app code instead of the offending third-party code. But, identifying third-party code as the likely culprit behind an issue is only half the battle; you still have to test each third-party library individually to find the real cause. 

Luckily, there are ways to get a granular understanding of how third-party code is affecting your mobile app performance. Application Performance Monitoring (APM) tools make it possible to view CPU time by dependency, identify issues from SDK network calls, and more — check out the top-reviewed APM tools on G2 crowd here and top mobile app testing tools here. 

Once you’ve identified which vendor SDKs are impacting app performance, instead of implementing a stopgap fix that will require continued maintenance (and hoping that none of your other SDKs suffer the same fate), a Customer Data Platform (CDP) can be used to get all of the functionality of these tools without the third-party code. A CDP functions as a single point of user data collection, ingesting real-time data via an API connection or a client-side SDK.  This data can then be forwarded to all of your team's tools with out-of-the-box integrations. Using a CDP, you’re able to remove third-party vendor implementations that are negatively impacting your app, simplify event collection, save implementation time, and improve your mobile app’s overall performance. 

This is how it works with mParticle:

1. Install the mParticle SDK; Start Defining/ Collecting Events

mParticle collects customer events, attributes and insights from across sources with APIs and client side SDKs. Here is a sample of how the mParticle iOS SDK is initialized:

Detailed instructions on how to implement the mParticle iOS, Android, and Web SDKs are available here. 

Once the mParticle SDK is installed, you’ll be able to verify your installation by going to the Live Stream in the mParticle UI and watching new session events come in as you launch your app.

2. Validate incoming customer data

Addressing data quality at the point of collection guarantees consistency throughout the rest of your data pipeline. Better data quality enables business teams to control costs, get to market faster, and deliver more accurate user experiences. Once you’re collecting data through the mParticle SDK, Data Master enables you to validate data being collected from your properties against an established data schema, and Smartype (open source, built on Kotlin) references that data schema and provides auto-complete in your IDE of choice as you develop. 

After data points have been collected and validated against your schema, they’re tied to unique user profiles using mParticle’s Identity API, allowing non-technical teams to access a unified view of a customer’s engagement.

3. Connect outputs within mParticle

Next, it’s easy for non-technical stakeholders to begin forwarding that customer data to any of our integrations in just a few clicks, without any developer support. 

Here’s an example of what it looks like to connect the Amplitude event integration in the mParticle UI:

Although mParticle allows you to collect your data once, you probably wouldn’t want all of your customer data being sent to every output. Once an integration is connected, Data Filtering makes it possible to control which events and attributes are being forwarded to each downstream tool in the UI. Non-technical teams are able to control costs by prohibiting unnecessary data from being shared, support regulatory compliance by filtering data based on user consent, and test new tools by sending limited data points to a new vendor during a trial period, all without developer support.

You can access mParticle’s full documentation on setting up event integrations here.

4. Remove SDK’s identified as causing most harm

After you’ve set up connections in your CDP and are forwarding high quality customer data to the tools throughout your growth stack, you’ll be able to re-evaluate the SDKs installed in your app. Certain third-party SDKs may have significant CPU impact, and every vendor SDK installed in your app is more third-party code to maintain over time. Reducing the number of SDKs in your app by abstracting those tools with a CDP will improve mobile app performance while also saving hours for your dev teams, allowing them to spend more time on core development.

Learn more about how you can get started with mParticle in our documentation here.

Read more about how CDPs benefit engineering teams in our Complete Guide to Customer Data Platforms for Engineers.