Need for Speed — Native App Performance


There’s no doubt­ing we live a fast-paced life. Technology op­er­ates at speeds that were unimag­in­able 30 years ago, and our ac­cess to that tech­nol­ogy has ex­po­nen­tially grown along­side it. Going back (almost) 30 years ago to 1992, IBM in­vented the world’s first smart phone. In 1994, this trend set­ter hit the mar­ket and opened up the pub­lic’s eye to the pos­si­bil­ity of timely in­for­ma­tion ac­ces­si­bil­ity.

Then, at the turn of the cen­tury, when smart phones and the in­ter­net merged, this pos­si­bil­ity started to be­come a re­al­ity. With this re­al­ity hit­ting the mar­ket, and the main­stream au­di­ence start­ing to buy in to the world of pow­er­ful smart phones, dif­fer­ent ap­pli­ca­tions of the smart phone started to emerge. Suddenly, a phone that was­n’t just suited to the pro­fes­sional mar­ket space, but it could be adapted to be used by any­one which is where we saw apps (or ap­pli­ca­tions) take cen­tre stage.

So, what makes a good app?

Before you con­sider those fac­tors, be sure you’ve read up on the 10 steps to take be­fore start­ing an app. Sure, the abil­ity to jump onto a cloud-based web ap­pli­ca­tion via a browser mo­bile app works well, if that web ap­pli­ca­tion is mo­bile re­spon­sive, but the ben­e­fit of a na­tive app is that it does it faster. Speed and ac­ces­si­bil­ity are the two as­pects that shine bright­est in a na­tive mo­bile app as op­posed to one that is­n’t.

Refresh: A na­tive app is de­signed specif­i­cally for the op­er­at­ing sys­tem of the mo­bile de­vice (i.e. iOS, Android, Windows OS). It has the abil­ity to ac­cess other apps on that de­vice, such as Facebook ac­cess­ing Photos to up­date a sta­tus.

You’ll also find our Guide to Creating a Successful Software Product help­ful for kit­ting your prod­uct up with the es­sen­tial sur­vival skills, avail­able for free down­load.

So how do we mea­sure speed?

Physics tells us that speed is the dis­tance di­vided by the time, but what dis­tance are we cov­er­ing? Apps are in­tan­gi­ble - we can’t lay out a mea­sur­ing tape and watch the app travel from point A to point B. In ac­tual fact, your app is go­ing to many more places than one at any given time. When it gets there, what is it do­ing? Is it still per­form­ing as fast?

Below I have listed out a few ways we can quan­tify the per­for­mance of our na­tive apps with re­gards to speed, or in other words, load­ing times.

Time to First Byte (TTFB)

This is the mea­sure of how quickly the app launches when opened on a de­vice from be­ing fully closed (not par­tially open for back­ground re­fresh­ing). For ex­am­ple, when open­ing an app such as Instagram, and you get the white screen with the logo pre­sented first and then it flicks to the feed, this is an ex­am­ple of TTFB.

If you open an app that is al­ready open in the back­ground, there­fore tak­ing you back to where you left off (and if you are like me, have about 20 apps open at once), the load time met­ric would not qual­ify here.

Best prac­tice says that aim­ing for a TTFB of <3 sec­onds is ideal, and that may be the case when we look at the met­rics from the server’s point of view. But Time to Load, our next met­ric, is where this can be a lit­tle de­ceiv­ing.

Time to Load (TTL)

TTL is the mea­sure be­tween load­ing a fully closed app, to the mo­ment when a user in­ter­acts with it. This is re­ally im­por­tant when we are look­ing at the dif­fer­ent kinds of de­vices users are ac­cess­ing your app from, and com­par­ing that to your server’s re­ported TTFB. For ex­am­ple, your app is op­er­a­tional on iOS, and its TTFB is trend­ing pretty well ac­cord­ing to best prac­tice time, but the TTL rat­ings are not re­flec­tive of this; in fact, they are quite skewed.

A deeper dive into the skews of data, you see that cer­tain de­vices are lag­ging in load time here, even though it seems that their op­er­at­ing sys­tems are up to date. When cre­at­ing an app, it is cru­cial to con­sider not just the op­er­at­ing sys­tem, but the model of that de­vice(s). This is where mar­ket re­search is crit­i­cal. Having an un­der­stand­ing of which de­vices and mod­els your user base means you can be proac­tive about de­vel­op­ments.

Here’s a hint! If you are us­ing an­a­lyt­ics pro­grams to fil­ter user be­hav­iour data (if you aren’t al­ready, now would be a great time to start), the model of de­vice is usu­ally a fil­ter op­tion. If it does­n’t give you this level of de­tail, it will most likely give you a screen size which is per­fectly as­so­ci­ated with the de­vice model.

Total Availability (TA)

Hands up if you have been scrolling through so­cial me­dia in the very early hours of the morn­ing? I would say most of us have, at some point. Wouldn’t it be dis­ap­point­ing if dur­ing those late night scrolls, the app crashed?

Crashes (otherwise known as down­times) and up­ti­mes are mea­sures we would use to un­der­stand Total Availability (TA). Better per­form­ing apps demon­strate the ra­tio be­tween up­time and crashes pos­i­tively skewed to­wards up­time.

One of the biggest things we need to con­sider here is the amount of time users leave apps open for back­ground re­fresh­ing. When this hap­pens, the server strains with the load. Established apps such as Facebook com­bat this with en­sur­ing their TA ra­tio is pos­i­tively skewed to­wards up­time.

Reaction Time (RT)

What’s your re­ac­tion time? How quickly do you re­act when some­one throws you a ball? If you’re any­thing like me, then it’s not great (hahaha). Optimally speak­ing though, we want to be quick on the mark like any co­or­di­nated ath­lete. Do our apps work the same? Ideally, we al­ways want our apps to be re­ac­tive and ag­ile, but this is­n’t al­ways the case.

Reaction Time (RT) mea­sures how quickly the app re­sponds from a user in­ter­ac­tion. If I want to post a photo on Instagram, my app should bring up my pho­tos in­stantly once I click the plus but­ton. If it does­n’t, I as­sume the ap­p’s not work­ing and will prob­a­bly try again later, or not at all.

The ex­am­ple apps I used in this blog have been well es­tab­lished in the mar­ket for years now, and as much as these met­rics are im­por­tant to them, they were so much more im­por­tant when they were first re­leased into the wild (so to speak). Generally speak­ing, peo­ple are im­pa­tient (sorry!), es­pe­cially when it comes to apps on their mo­bile.

If you are think­ing about cre­at­ing and launch­ing an app, amongst all of the other data points you will be gath­er­ing such as sub­scrip­tions and users, heav­ily con­sider these speed as­so­ci­ated dat­a­points.

Apps have the po­ten­tial to go vi­ral with a pos­i­tive user group to sup­port them. This won’t hap­pen if they are slow, un­re­spon­sive or crash­ing out. There are plenty of ways to com­bat this - start­ing with mea­sur­ing these time sen­si­tive data points is a per­fect place to ac­cel­er­ate that vi­ral suc­cess.

We’re al­ways on the other end of the line if you want to start cre­at­ing a suc­cess­ful ap­pli­ca­tion — con­tact us here for a chat.

Discover Software


Alice Spies

KPI mo­ti­va­tor and res­i­dent head chef

Get cu­rated con­tent on soft­ware de­vel­op­ment, straight to your in­box.

Migration vs Rebuild

12 November 2018

The top tech­nol­ogy frame­works you can use to build a mo­bile app

21 January 2020

How does end of life soft­ware im­pact you?

10 November 2020

Your vi­sion,

our ex­per­tise