Thread by @championswimmer

If you product is primarily a mobile app, and you care about giving mobile users a great experience - read on

I have been working/consulting on a bunch of mobile apps, some with over 100M users, and I want to talk about lifecycle management, from a product PoV.

A thread 🧵👇

Let us start with an important fact - most of your power users will be having 12-15 commonly used apps on their phone.

If your users are heavy mobile users, they will have some form of social media addiction - TikTok, Instagra, Snap or Twitter.

The current state of mobile internet users is that they spend a TON of time on their screens, but they switch apps very fast (EXCEPT for the doomscrolling apps).

Attention spans have grown increasingly smaller.

This is from 5 years ago btw

venturebeat.com/2016/07/11/you…

So why all this preamble? Well because I want to bring you to this very important truth about your mobile app

You are most likely losing 15-20% users at least once during each app session - who drop off to other more addictive apps - because of long loading and lifecycle bugs.

Before we go further, let's just validate the fact that how big a problem loading times are. Everyone knows the basics

low loading time = good
high loading time = bad

But a few surveys and statistics that puts the real numbers in perspective

blog.hubspot.com/marketing/page…

Before moving on, one final article I will link to -

marketingdive.com/news/google-53…

more than half of the users cannot tolerate >3sec wait times. Website or app, the users are the same - so the behaviour applies to apps too.

But there is a slight difference....

In a website, a drop-off is a full-and-final drop off. Either someone

- types a new URL in the bar
- swipes away the tab
- goes to a different app than the browser and your website becomes one of the 99+ ghost tabs on their open tabs list

But for apps, the behaviour is slightly different. When a screen of your app takes more than 3 seconds to load, the user quickly goes to TikTok/Instagram/Snapchat/Twitter to doomscroll for a while, or the browser to continue reading that article...

...BUT THEY WILL COME BACK!

And that is where *almost all* apps (especially up and coming, new but popular apps) completely drop the ball.

What happens when your screen started loading, but the user went to a different app, and came back 2 minutes later?

Yeah. Exactly.

There are 2 primary reasons why this happens.

1. Managing lifecycle is hard. REALLY BLOODY HARD. At the most senior of mobile developer interviews, people screw up explaining managing state across lifecycles.

2. Your QA team doesn't leave the app to check their TikToks.

Now that we are where we are, how do we go about fixing this.

This is a multi-stage fix. You cannot dictate your mobile development team to suddenly "fix all the lifecycle bugs", or ask QA to just interleave TikTok browsing from tomorrow's regression test cycles.

1. Product Analysis

First we need to figure out, for our particular app, where all does this happen ?

There are 2 reasons which need to overlap. A screen needs time to load. And it is not part of an unfinished task flow.

What is an unfinished task flow? A task that involves <5 steps, is supposed to be done within a <5 min window, and if left midway, defeats the purpose with which the user started that task

eg. placing a shopping/food order.
eg. selling/buying a stock
eg. posting a reel

Steps in the middle of such flows, even if they take >3sec, heck even >10sec, will not distract the user to a different app.

Primitive human behaviour detests unfinished business, and you can rely on that for these use cases.

What are non-unfinished task flows though? Where the urgency is missing and/or the task can be resumed later, and/or the cost of failure of the flow is low to the user.

eg. checking stock portfolio
eg. shopping for non-essential items
eg. exploring feed / stalking friends

Take a stroll through these flows in your app. See all the steps where loading screens are >2sec in length.

Best is to make a global loader component, and log all the durations loader was visible along with the from and to destinations, then do this analysis.

2. State and Performance Analysis

Once the above analysis is done (and you have triaged which are the most essential gaps to plug), comes actually figuring out what gives away, and how to fix it.

a) first ofcourse is the question, why tf would any screen take >3sec to load

I will stick my neck out on this, but if there is any page on your app, that when opened (even w/o cache) is a blank page with a loader for >3sec, you have serious architectural issues

No server calls are supposed to be >200ms. No screens take >100ms to parse + render.

Rethink the product flow, insert a cache + BFF in the server call, reindex your tables. Do whatever it takes, but this shouldn't happen.

But let's assume (as it will happen), that in a 6 month time frame, you cannot fix the product flow / backend architecture

Now comes the other side of the equation

b) If someone drops off the app after they see loader for 2sec and come back to the app after a while (while = 30sec~2hr), how well can you resume the flow?

2 hour might sound outrageous, but Gen Z can get stuck in metaverse for hours

Even after a 1 hour doomscrolling break if your user comes back and can pick up where they left, you can get them to complete the flow they were on.

There are 2 particular 'bugs' to handle here. One is a behaviour carried over from browsers - people go to another app for 30s ~ 5 min and come back expecting your app to have loaded the screen meanwhile

Most apps either
1. start over loading
2. show undefined state
3. go back

Users expect the behaviour they see in browser tabs. If it is taking a while to load, they do other things and come back to see fully loaded and working website on that tab.
Give them the same experience.

The other 'bug' is when someone drops off due to loading, roams around 4-5 other apps, and then comes back to your app. They might not resume your app from the recent apps list, but directly open the app from launcher.

If in this situation your app can render the same screen (with the entire state) the user had left mid-way loading, 30 min back, there's a high chance they continue doing what they were doing (which might be desireable for your product).

Achieving this is a little harder. Obviously bug #1 must not exist, as a pre-requisite for bug #2 to be fixed. In addition to that, if the user has wandered across multiple apps, and the device has slept for a few minutes in-between, the OS might have had killed your app.

Resuming a flow from a process-killed state is not impossible. Try it with the Twitter app.

Scroll your feed a bit. Then kill the app (or even restart your phone).

Reopen Twitter (even without internet). You'll see the feed open at the exact same scroll position 🤯

3. A dev+QA culture that prevents this

Finally, this is not a one time fix. It something you do not want happening in your product ever. That will need culture shift at product, dev and QA teams.

a) App cannot be made in a sandbox different from real world conditions

Your team must be using the app on the same devices majority of your users are on. Same screen sizes, same RAM sizes, same internet speeds.

b) Test for harsher conditions

Simulate slow network conditions for example
browserstack.com/guide/how-to-s…

Simulate 15-20 background apps open

c) Respect anecdotes from your team

If non-technical people from your team murmur about "app has a slow splashscreen", do not let your developers hit them back with Firebase Performance console screenshots showing average startup time < 3sec. Dig deeper into their story.

d) Do user testing, often

Give the app to use to a user, and observe what they do. Do this both with new users who have never used the product (or do not use often), and also with seasoned users. Do this as often as feasible. Do this with diverse user profiles.