Building Kalido for the whole world, Part 2: Overcoming technical barriers
This is Part 2, the story of the technical barriers we’ve had to address to make Kalido useful for people with varying access to devices, data, and infrastructure around the world. This post is a bit more technical than the last, but we didn’t think it would be useful without the detail. If you missed Part 1, catch up on it here.
Compatibility
This is a very Android-specific topic, because iOS users tend to keep their software up to date, and Apple has an exceptionally good record of legacy device support. Android users, however, often can’t update because their carrier or manufacturer hasn’t released an update, and may never release one in some circumstances. So, support for older devices matters, but you’ll only get a real feel for your particular threshold by watching the numbers of uninstalls from old devices in your Google Play Store Console, and paying special attention to the inevitable emails from users telling you that their [insert device here] won’t run your app.
We still get the odd request to support Nokia (which even Nokia no longer supports) and Blackberry phones. And of course there are always a few Windows Phone users. If we had an unlimited budget, we would support every platform, because our goal is a world where everyone can use Kalido. But since we’re a small startup, every dollar counts, so doing this is a luxury we don’t have. Even within the worlds of Android and iOS, we are constantly making tradeoffs about how many older OS versions we can support while still delivering a good experience. For Kalido, most of our users tend to have phones that are at most a couple of years old, allowing us to focus on just Android from Kit Kat onwards. We will probably move to Lollipop soon, to take advantage of improvements in user data privacy, and interface enhancements. For iOS, we aim to only support the two most recent versions.
Size
App sizes vary widely across geographies and platforms, but we’ve observed that especially for Android users, if an app is <10MB, people will often just delete it and download it again when they need it. If it’s >20MB, they will often refuse to download it because it costs too much in a world where every MB of data matters. And even though iOS users usually don’t care about app size at all, we have to be extremely careful when we add third party elements to our overall technology stack, as their libraries can become bloated without warning, and are often large to start with. As discussed in a previous post, one of the first things we had to do to drive growth in India specifically was to optimise our own code, drop some external libraries, and implement chipset-specific APKs to drop the size of Kalido for Android from 35MB down to a svelte 16MB.
Latency
Not paying attention to latency can kill an app startup early. Kalido’s first prototypes were built by talented developers used to having incredibly low latency due to working in environments like the Bay Area in the US, and being physically close to their US-based servers. We, on the other hand, were constantly working from places like Johannesburg, Delhi, and Hong Kong, and suffered every last millisecond of latency from the laws of physics as they apply to long transatlantic cables. So, things that felt instant to our American developers often took seconds for us. And because they were used to working in free, high-bandwidth environments, the need to optimise every last kb of data transmitted was not clear.
We now work with a team of brilliant South African developers, who are keenly aware of how much data can cost, how high latency can be, and how unreliable mobile data connections are. As a result, Kalido is now substantially smaller (as discussed above), faster, and respectful of bandwidth. The experience on EDGE may never be decent, simply because of how much data Kalido has to crunch to get you good matches in a beautiful feed, but we still do our best. We also think a lot more about which calculations should be done device-side versus server-side to balance the tradeoff between using superfast servers with lots of memory that can take >250ms to deliver an answer, and slow devices with constrained batteries that can deliver an answer nearly instantly, if the data is stored locally. And of course, we can only do device-side calculations when pushing data to your device wouldn’t violate someone else’s privacy. You may never notice it, but the entire user experience of Kalido is designed around these kinds of constraints.
These are just some of the lessons we’ve learnt, as we continue to build and improve Kalido, and ensure it’s user-friendly for the whole world. To see some of the other lessons we’ve learnt, check out some of our other posts. And if you’re curious about why we’re doing all of this in the first place, you definitely want to read a post very close to our hearts: The Kalido Vision.
