[MUSIC PLAYING]
- So, your shiny new app is ready to be
submitted to the App Store.
You've gone through the long and tiresome process
of feature definition, design, implementation, and of course,
testing, Because you know your potential users deserve
the best possible experience using your app.
Yep, you're good to go.
Or are you?
There's one type of test that is too often overlooked,
but shouldn't be, especially if you're aiming at users
from developing markets.
When you're working on your app, you're
probably using your home or office Wi-Fi.
Or, since you're familiar with the importance of testing
your app in various network conditions,
you're also testing it with your carrier's high speed
mobile network.
Either way, at least some of your users
are bound to be using your app in a significantly
worse network environment.
The last thing you want is for one of your users
to be the first to test your app in a poor network condition.
If a user using your app will attempt
to use it in a low connectivity environment,
bad things may happen.
What can possibly go wrong, you ask?
Well, your requests may time out.
Responses may get lost.
You may encounter race conditions
you've never considered before.
Your UI may get stuck.
And your user may be not so forgiving for the bad user
experience your app provides.
Since we all want our users to have the best
possible experience using our apps,
it's worthwhile to put effort into simulating
these difficult situations to make sure we're
doing the best we can.
Once we put ourselves in our users' shoes,
we can take actions to improve these use cases.
Apple offers a great tool for testing apps in varying network
conditions.
It's called Network Link Conditioner,
and if it's not part of your regular testing routine,
it definitely should be.
You can use this tool to simulate various network
conditions in a simple way.
On your iOS device, go to Settings, Developer,
and press the Status Row on the Network Link Conditioner
section.
There, you'll see a list of all the existing presets.
You can see a detailed description of each of them
by selecting the relevant row.
If you don't find exactly what you're looking for,
or you have a specific scenario you'd like to test,
you can set up a new configuration
with specific values for each of the fields.
Once you've selected the relevant option,
don't forget to turn on the Enable switch on the top row
to really simulate that condition.
Otherwise things may look like they're running smoothly
when they're really not.
Also very important, don't forget
to turn off this option when you're done testing.
Let's look at some examples for major issues
that can be prevented by testing your app in non-ideal network
conditions.
Let's say your app is a game that can be
played on various platforms--
iOS, Android, and web.
And your app loads the user updated game score
from the server in every app launch,
since it may have changed since the user last
played the app on this device.
Since it's a very small piece of information
and since it's always fetched from the server on app launch,
without thinking too much about it,
you made this fetch synchronous.
Which, of course, is something you should never do.
Everything looks great when you test your app
on your Wi-Fi or even your high speed mobile connection.
But when you test it on a very poor connection using Network
Link Conditioner, you notice that the UI
becomes unresponsive from the time
the request for the updated score is sent to the server
until the response is returned to the app.
You didn't notice this delay when
you were using your high speed network connection.
But now that it's a few seconds or worse,
it's hard not to notice it.
Good thing you tested your app properly
instead of having one of your unfortunate users
encounter this bug.
So you change your score fetching logic
to work asynchronously, as it should, and run the test again.
It takes the score some time to be displayed--
the same few seconds delay you saw when the display got stuck
before--
but the user can use the app freely during this time.
You move on to checking the user profile screen.
But unfortunately you see a blank screen.
You wait a little for the screen's display to update,
but nothing changes.
It turns out that the request timed out
and there is no retry mechanism or an indication
to the users, who may find themselves
staring at a blank screen without knowing why.
By supporting some kind of retry mechanism,
you can make sure that the page loads
in the event that the user is in an area with poor connectivity,
or at least display an appropriate error message.
These were just two relatively simple examples
of things that can go wrong when using poor network conditions.
Notice that the same problematic scenarios
can be encountered when your server is heavily overloaded.
If your timeout is set to 30 seconds
and the server only starts handling requests
after 40 seconds, the same issues will occur.
So it's definitely worth testing.
I hope you found this short tip helpful
and will include it in your testing routine.
I'm Rony Rozen, for Route 85, thanks for watching.
[MUSIC PLAYING]