Every good mobile engineer has questions that they wish they could answer, if they only had the time. One of those questions, related to concurrent network calls, goes something like: “How many calls can my app do and not impact app performance?” Until recently, no one had actually measured to figure it out — then we did!

Hop in the time machine with us and we’ll explain how it happened . . .

Timehop is a nostalgic social networking app with tens of millions of downloads on iOS and Android. We worked with the Timehop team to understand how technical choices impact users’ experiences within their iOS app, and identified suboptimal areas to focus and improve upon. For purposes of this calculation, we focused on 3 days in October during which we collected data globally from over 7.5 million experiences, spread across over 2.5 million devices.

Let’s start with the common culprits.  SDKs are often the primary hunch for the cause of suboptimal experiences on mobile.  Knowing the hunch, most app developers still initialize *all* their SDKs on startup (somewhat of a standard practice).  Like all apps, Timehop embeds a lot of SDKs; 47 to be exact, ~16 from 3rd parties vendors.  (Please note that SDKs are not limited to 3rd parties, like analytics, ads, Google, FB, Twitter and the like, but are also many of the libraries that we use out of the box, like Bolts, Appirater, and SocketRocket). Starting the app with this many SDKs obviously impacts the quantity of network calls that occur during start-up.

When initializing the app with all of these SDKs *plus* your own 1st party network calls, you’ll get a logjam, and many of these calls (3rd or 1st party) will block your app from progressing. In Timehop’s case, we focused on startup time and a very slow benchmark of 5 seconds.  We figured-out that the number of slow startups increased to 6% with ~6 concurrent network calls.  The number increased to 13% of startups with 10+ concurrent network calls.  Getting a bit more granular, we helped Timehop sort out that a user with any network call of over 2.5 seconds during startup correlated to an increase of +27% chance of that user leaving the app.

Further, we found that 3.3% of users were experiencing a slow startup (over 5 seconds), and 2.9% had a stall (e.g. what amounted to a freeze from the user’s perspective) at startup. We were also able to pinpoint that Mixpanel and StatHat were the primary sources of HTTP errors during startup. Timehop has been able to take this info, tweak their startup, and reduce user churn as a result.

The moral of the story? With a little time, good technology performance becomes good business.

You can’t change how many, or how fast, network calls occur, BUT you can control how well you have built your app. Embrace.io cures app blindness.  We make your app’s performance visible for each user and segment, leading to better user experiences, and improved business outcomes.

We are here to help. Let us know how we can for you.