On Saturday 8th August 2015, I opened Xcode 6.4 and started work on the app Bandwidth Monitor. It would eventually be released to the iOS App Store on 10th April 2017.
I would never have dreamed that, more than ten years later, I would still be working on this side project and have actual daily paying users. The work on this project gave me the skills and experience needed for my professional roles as an iOS developer. For all that it made possible, I am grateful.
With eleven years of work behind me and the ten-year App Store anniversary coming up, I wanted to take this opportunity to reflect on the journey so far: where it started, how development and maintenance went over the years, and where things stand today.
This is a three-part series, so feel free to jump to Part 2 or Part 3
Part 1: Building an app for myself
I built Bandwidth to suit my own needs. I wanted to quickly know what was going on with my internet connection when websites or games wouldn’t load.
Early internet issues
Just like every generation, I’ll get to tell my kids I didn’t have it as easy as they did. I grew up on an 8K DSL internet connection, later upgraded to 16K — except 16K turned out to be unstable. After a lot of testing and calls with our ISP, we learned they had to cap our line at 13K to keep it stable.
Every so often, well-meaning support staff would “correct” us back up to 16K — probably while provisioning someone else down the street — and we’d be left wondering why the connection was acting up again.
It was during one of these troubleshooting sessions that I discovered our home router, an AVM FRITZ!Box 7490, had a built-in “Online Monitor”: a graph of upstream and downstream usage over the past 90 seconds.
A screenshot of the FRITZ!Box’s Online Monitor feature (Source)
I’d regularly pull up this page on my PC to get a sense of what was going on if things felt slow. The read was simple: if the graph was maxed out, the connection was maxed out too — and if our upstream was saturated, loading webpages or playing anything online became nearly impossible.
The fix was manual: find whoever in the house was hogging the connection, and get them to ease off.
2015: The first prototype
Checking the Online Monitor was a tedious process, however, since the router’s website was not optimized for mobile devices at all. Refreshing in your browser would put you right back at the start and force you to log in again. In a world which was shifting more and more towards mobile computing, this was a no-go.
So I decided to take my iOS SDK and Objective-C skills that I had acquired years earlier from jailbreaking my iPod touch 2nd Gen and create a simple app for this use case. At the same time, Swift had just come out as an alternative language, so it was a great opportunity to learn new skills all around, and build something for myself.
I got to work using the first version of Swift together with UIKit and Storyboards, targeting iOS 8. I used CocoaPods for dependency management at the time. All the symbols from the system frameworks still had Objective-C names.
commit a5833f84c9b140b50f22db466743ed57d79d79e0
Author: Sören Gade
Date: Sat Aug 8 16:50:41 2015 +0200
Initial commit
By 10th August, I had a version running on my own iPhone that I could use daily. Current toolchains don’t build the old app versions anymore, and unfortunately, I don’t have a screenshot from earlier than February 2019, around version 1.3.0. You’ll notice I had a much faster connection by then, yay.
Bandwidth Monitor v1.3.0 in 2019 and v3.2.0 in 2026
The app’s number one goal since its inception has always been to be quick to boot and be lightweight, so that you can get to the culprit of your slow internet connection as quickly as possible.
I was using the awesome third-party library Charts for drawing the app’s main UI graphs. To keep the app lightweight and since I wanted to learn networking on iOS, I built my homegrown network client on AFNetworking for requesting SOAP data from the network, and parsed everything using XMLReader-Arc.
This was the foundation of the app for a long time. Of course, the individual parts have been modified and upgraded over the years, and today none of those three fundamental libraries are still used. Keeping the app small with a fast startup time has remained my priority.
By September 2015, I was already migrating to Swift 2.0. This was part of a theme that kept repeating: the app never felt “finished” and ready to go. Something was always incomplete or broken, and I kept seeing places to improve the app where it wasn’t “perfect”.
2016: Preparation for release
I kept working on this app on my own throughout 2016, showing it to family and friends, but mostly keeping it to myself.
Another theme that’s held true ever since: I get bursts of free time for this app. Since it is a side project and not my main job, there are sometimes long stretches when I am unable to dedicate enough time to move the app reasonably forward. As a user, this can feel like nothing is happening with the app and trust me when I say, I understand.
In December 2016, I decided that it was time to prepare the app for App Store release anyway. I took the time to migrate to Swift 3.0, upgrade all dependencies to their newest versions, and adopt new APIs like haptic feedback.
The entire process took until March 2017, and, thanks to extensive feedback from friends and family, all the pieces were finally ready by then: the code was up-to-date, the app was stable enough for me to be happy, and the marketing metadata was ready for App Store submission.
Needless to say, the App Store reviewers were unfamiliar with what the app was doing, since none of them had a physical FRITZ!Box on their network to test. I had to provide a video and a detailed explanation — which felt really scary at the time — but I finally got approved after a few rounds. I was really happy and felt proud that the work I had put into creating this app hadn’t gone to waste.
2017: App Store release
On 10th April, Bandwidth Monitor was finally released to the public. It felt good to have finished the app and released it for everyone else to enjoy.
Little did I know that the real work starts after the grind: maintenance and feature requests. Once code is out in the wild, I started to realize all the use cases and edge cases I didn’t think of, and how much I still had to learn.