When developing applications for a mobile device, it's nice to keep in mind that not all users may have a reliable internet connection (e.g. not all areas have the same coverage)

We should ensure that our apps remain reliable even when the internet connection is limited or unstable.

Testing often happens on a simulator/emulator running on a device, such as a computer or a laptop, with a good internet connection. How can we replicate a "bad" internet connection?

Network Link Conditioner

Apple provides an additional suite of tools as part of the Xcode development environment. One such tool is Network Link Conditioner, and as the name suggests, we can use it to mimic the desired conditions our network should have.

In this blog post, we are going to focus on how to use this Apple-based solution. There are other options for different operating systems, e.g. netem for Linux, which we won't cover here.

How to install and use it

Installation is easy enough:

• download the "Additional Tools for Xcode" from the Apple Developer download page
• open the Network Link Conditioner.prefPane file within the Hardware folder from the .dmg file.

You should see a new entry within the macOS System Preferences.

Select your desired profile, then enable the link conditioner.

What profile should I use

A profile defines the speed limits (both in upload and download), the percentage of packets dropped and the delay between requests. Here's the list of all pre-made profiles we can use. There is also an option to specify a DNS resolution delay.

	Bandwidth		Packets dropped		Delay
Profile	Up	Down	Up	Down	Up	Down	DNS delay
100% Loss	max	max	100%	100%	0ms	0ms	None
3G	780kbps	330kbps	0%	0%	100ms	100ms	None
DSL	2mbps	256kbps	0%	0%	5ms	5ms	None
Edge	240 kbps	200 kbps	0%	0%	400ms	440ms	None
High Latency DNS	max	max	0%	0%	0ms	0ms	3000ms
LTE	50mbps	50mbps	0%	0%	50ms	65ms	None
Very Bad Network	1mbps	1mbps	10%	10%	500ms	500ms	None
Wi-Fi	40mbps	33mbps	0%	0%	1ms	1ms	None
Wi-Fi 802.11ac	250mbps	100mbps	0%	0%	1ms	1ms	None

These profiles have different use case scenarios with the possibility to create custom ones, if needed. We'll use "Very Bad Network" and "100% Loss" for our testing.

Two case study

Multiple taps on a button that makes network requests

Imagine a view with a button that makes a network request. When done, we move to a different screen. This network request is usually fast; the user might not have to wait before jumping to the next screen.

Ideally, we should deactivate this button immediately after the user presses it, just before making the network request. A second tap, while we are still processing the first request, won't be initiated.

However, forgetting to deactivate a button can very well happen. Manually testing the app might not be enough to catch this issue when network requests are fast.

We can use the "Very Bad Network" profile (or a custom one that provides enough delay) to test the app in all those "idle" moments where blocking network requests are occurring.

Optimal condition	Poor condition

Testing for momentary network loss

One of the things that can happen to a mobile phone connection is to drop.

It's not very difficult to lose connection due to poor network coverage (e.g. getting into a tunnel while travelling on a train), so it would be good to test how our app reacts during random network losses during crucial operations.

For these cases, using the "100% Loss" helps make these network requests fail when required.

Usage on an actual device

If we need to perform tests on a physical device, we can use Network Link Conditioner on iOS. However, the setup process is more complex and requires activating developer mode on the physical device.

This process starts by connecting your device to your Mac and opening Xcode. From there, select Devices and Simulator from the Window tab. Now, click on your device and enable it for development.

What we did will make the "Developer mode" option available from the "Privacy & Settings" section of the Settings menu. Enabling that will inform you of the risks involved and will require a restart.

You should now see a new Developer page within the Settings; Network Link Conditioner lives there.

Closing

While this testing methodology won't probably be required every time, I find it a nice final check before approving a new feature.

Moreover, reliability testing on networks under less-than-ideal conditions can offer helpful insights in regards to user experience.

👋