Firefox's console in its Network tab also has a way to choose what tier of bandwidth you'd like: GPRS, 3G etc. Thought it was worth mentioning

I find Firefox and Chrome's network-limiter feature to be "unrealistically unreliable" insofar as it limits data transfer bandwidth, and simulates some kinds of latency issues, but doesn't seem to implement things like DNS suddenly stopping working for 5 seconds, or sporadic network drop-outs, or how some things will arrive out-of-order, or an entire web-page blocked by a single synchronous <script> from one particular external host.

I agree. It needs to simulate a phone right on the edge of connectivity, with the random 5 second dropouts, followed by 50 Mbps but downstream only, followed by another dropout, followed by 1kbps up and down, etc.

That's the way real networks behave, and what real users have to manage with.

> it's perfectly possible to simulate arbitrary levels of bandwidth/latency with a variety of tools even while having a fiber connection.

Yes it is perfectly possible, but it’s very difficult. Having just gone through this process I can attest that this is not something the average “app developer” is going to be capable of doing, at least on Linux and Windows.

The raw tools are there, but they are complicated, poorly documented, and require network engineering knowledge on top of software development knowledge.

Probably there is some nice package to wrap up the whole “generate a virtual network and add latency + packet loss between these two end points”, I just never found it.

> Probably there is some nice package to wrap up the whole “generate a virtual network and add latency + packet loss between these two end points”, I just never found it.

Linux has a built-in command: trickle

https://linux.die.net/man/1/trickle

https://stackoverflow.com/questions/10328568/simulate-limite...

trickle is clever, but when I've tried to use it for "use no more than this" bandwidth shaping (basically going for "rsync --bwlimit" but for a set of "related" rsync processes) the arguments given had very little to do with the amount of bandwidth actually consumed. (We found another way but definitely look at tc instead.)

It's not that they won't be "capable of doing" it, it's that the effort required will be more than they care to put into solving a problem they can't sympathise with and/or isn't a requirement handed down from their boss. App developers have to jump through all sorts of technical hooks to get certain things done, but since their jobs depend on it, they power though. If "work reliably even in shit network conditions" was a baseline requirement that their jobs depended on, you bet they'd find a way.

As for how hard it actually is: iOS has already been explained, the Android emulator has network latency and speed simulation right in the GUI, as do most web browsers. And there's alway the option to switch your phone to 2G only in the settings and/or go into the basement or elevator.

>If "work reliably even in shit network conditions" was a baseline requirement that their jobs depended on, you bet they'd find a way.

This is the real problem - there are deadlines and most projects don't even consider working in questionable network conditions. Developers aren't going to put in the extra effort when it doesn't contribute to the job they are asked to do.

I have had to deal with poor App/Play Store reviews for both of "It doesn't work on the train while I'm commuting in the morning" and "It doesn't work at the event when there are 100,000+ other people there" flaky network related problems.

I always at least _ask_ in the requirements gathering stage for a new mobile app: "how much effort do we want to dedicate to app performance/reliability under marginal network conditions?"

As it turns out, pretty much all mobile app owners are as apathetic about that as most mobile app developers. (On the other hand, once you've got a reputation for being able to handle those sorts of flaky network edge cases, you get more and more work for the sort of apps that benefit from them. The downside of that is it's never the flashy resume-building-apps that come to you for this.)

> Yes it is perfectly possible, but it’s very difficult. ...

shrug

Disagree, it's no harder than any other linux subsystem, you can use `tc` or you can attack it a different way by using virtualization then messing with it at the vde layer. I've added storage and network random latency for testing code before, took a day or so to get working perfectly, but now it's in a shell script.

Hm, alternatively.... you're right, it's very difficult. You should hire a software engineer, such as myself, to do it for you. ;-) ;-)

Like parent said, Network Link Conditioner is exactly that tool. It's even built directly into iOS (though only visible in settings once "used for development" via XCode).

Both Firefox and Chrome dev tools also have built in throttling of network connections. https://blog.nightly.mozilla.org/2016/11/07/simulate-slow-co...

The tools exist and they're easy to use. Most people just don't bother.

Linux has been explained to death in the replies, but on Windows you can use clumsy[1] - it's as simple as it gets.

[1] https://jagt.github.io/clumsy/

> For example, Macs have long had the "Network Link Conditioner" tool as a free utility included with the Additional Tools for Xcode package, which then allows simulating configurable bandwidth, latency, and packet loss.

Well, I sure wish Apple would make use of that functionality themselves once in a while.

It's frustratingly impossible to enqueue an iMessage message while out of signal and have it be automatically delivered once back in cell coverage. Bizarrely WhatsApp, a third-party application (with all the background execution restrictions that go with that), manages to do just that!