Android Vs iOS: Polarizing User Experience

One of the biggest social media stories of the last few years is the avalanche that is TikTok and the ways incumbent players like Instagram have struggled to deal with it. Since I'm personally most interested in mobile apps, I found it most fascinating how Instagram's big lean into Reels has failed to affect a huge chunk of their user base that is on Android. "If you don't have a really good phone, it just takes absolutely forever to make a reel," says one of the thousands of one-star reviews on Play Store written in late 2022. "As a small business, I can't even make the most basic of reels without seeing the "Sorry something went wrong." message," complains another user who owns a relatively modern Google GOOGL Pixel 5.

Meta META isn't alone here: the whole $8-blue-check-for-anyone debacle that marked Elon's early days at Twitter was visible only to people with iPhones.

Features aren't the only problem; there's also speed. Our own research shows that the overwhelming majority of the Android versions of popular apps have 10-100x times longer wait times on the key user flows. And speed is important: according to Dimensional Research, 36% of polled mobile users would hold a slow, unresponsive app against the brand that spawned it, and for 96%, speed is the crucial factor when deciding whether to delete or keep an app. And if you want to know just how slow is too slow, Mozilla says anything above 50ms will be noticed.

The disparity (both in performance and functionality) between iOS and Android apps is not only one of the most underreported phenomena in tech and a real problem: the market share of Android phones is roughly equal to that of iOS phones, meaning that a significant number of users are not getting the best possible experience from their apps. This problem is particularly acute for users who can't afford high-end Android devices, as well as for underrepresented groups and those living in developing countries.

This disparity has broader implications for society as a whole. By not providing a consistent and high-quality user experience across all devices, we are failing to create shared cultural experiences that can help to unite us in the face of global challenges. In today's interconnected world, it is more important than ever to come together and work towards common goals.

There is a complex entanglement of technological and socioeconomic factors here that are hard to map accurately. Tech often overlaps with privilege, and solutionist attempts to address the problem with purely technical or business means have repeatedly failed.

For example, most mobile developers would point out the architectural differences that usually help iOS apps run faster and smoother. Apple's AAPL own silicon beats anything available in the open market, and iOS is tightly optimized to run on top of it. Both Android and iOS developers acknowledge that the latter offers a better way of managing memory use and shuts memory-hogging apps down more aggressively.

They would also point at other technical factors at play: e.g., a wider overall variety of Android phones which includes more low- and mid-range phones with smaller memory, weaker processors, and more sluggish connectivity options. However, in my view, these explanations are somewhat misleading.

First, writing mobile apps is a complex undertaking that often doesn't supply suitable tools to achieve its stated goals. Modern mobile apps, even if created by lean teams, consist of code written by thousands of engineers. After all, third-party libraries are popular, well-known, and affordable. Finding a way around such code and making sense of it is often near impossible. Without tools like ours, dozens of parallel threads running multitudes of execution paths triggered by user actions, interruptions, and scheduled and unscheduled system calls create a 4-dimensional maze that can defeat anyone on one platform, let alone two.

The second real reason is the lack of diversity in mobile development. I've experienced it firsthand at Snapchat, frequently being the only person with Android in big engineering meetings. Despite Android's somewhat geeky image, the big tech offices are totally iPhone. The top-rated engineering schools are completely iPhone-dominated. Surrounded by them, executives, who are also on iPhones, tend to think that all well-to-do, paying customers are on iOS. There's no shortage of market data to support that argument.

The latest, most illustrative case of this bias was Elon Musk's very public spat with his own [ex-]Android engineer. I want to highlight a few remarkable details about it. First, it didn't help that Musk's proffered understanding of the engineering issues at hand was not brilliant. But neither did the company's Android engineers seem to understand how much the app's sluggish performance was affecting Twitter's business goals: if it's slow to show tweets, it's also slow to show the ads! Secondly, during the argument, the engineers first suggested that the app 'works fine,' then gingerly suggested dropping a few features (parity much?) to improve the situation while implying (as many engineers often do) that a big rework would solve the problem by doing away with the legacy stuff.

This is just one public example of a broader problem that's also not very new. Let's go over a few traditionally suggested solutions.

1. As suggested above, let's do a clean rewrite. What sounds like a good idea often turns out to be an extremely disruptive, multi-month nightmare. It also tends to throw a giant wrench in the day-to-day relationship between the engineering team and everyone else: product, sales, etc. Such rewrites tend to negatively affect companies' ability to implement their strategic plans as scheduled. New features get deprioritized and postponed “since we rewriting it all anyways.” And worst of all, there's never any guarantee of a good result. As a good example, allow me to remind you about Discord’s effort to rewrite their own Android app in React Native to achieve feature parity with their already existing React Native-based iOS app. Customers were unimpressed.

2. Or else, let's limit the number of features – just like that Android engineer from Twitter who suggested dropping features to improve speeds. Twitter Blue came to Android a couple of months late while tweeting from the platform became notably slow. I don’t think increasing that very disparity we’re trying to overcome while limiting growth is the right way to go here.

3. Leave everything be. Suppose the app is okay (after all, people use it!) and only meaningfully reacts if users raise it with support en masse. Those who choose this path often pay a lot for APM/observability tools and think they've invested enough, even though their mobile engineers don't use them. I wouldn't have written this column if I had agreed with this approach.

Firstly, by the time one needs observability, it's usually too late, and the users are already angry. Secondly, these tools can only provide meaningful results once you feed them with your users' data. But even then, they usually struggle to explain the slowdowns. The variety of tools that emerged with the rise of backend server APIs was never meant to deal with the multi-threaded maze of execution on mobile devices. They only instrument system calls which are everything at the backend but a drop in the ocean on the client side. For example, one of our customers fighting with a seconds-long molasse-like app launch was curious why the legacy tools would claim that their app would launch in a mere half a second. We applied AI-powered instrumentation to demonstrate that the APM tool assumed the app started when it sent a system call of a logo animation playback (something a user is not supposed to see at all). The customer's app was on iOS, by the way. This is how they knew that the dashboards were wrong.

Now allow me to suggest a few steps that I find worth implementing here.

1. Start by mapping the key user flows and introduce performance improvement metrics. Don't forget to praise the engineers working on the project for every improvement and always make it clear how important it is for the overall business.

2. While not all performance monitoring tools are equally beneficial, analyzing the code and optimizing performance will have to take priority. A careful investigation will help you identify performance and UX tweaks that will improve the performance where it matters – all without rewriting the whole thing from the ground up.

3. As mentioned above, this problem is far from being just technical. In many organizations, especially based in the US (and a few other countries) there's always a degree of Android blindness, especially at the management level. That can only be overcome by diversifying your hiring and having a strong, working open mic culture on the inside.

The last point will surely be the most important one. Always having a senior enough person who can say, "wait, our app works like crap on my phone. There are many more like me. Let's fix this" will pay off massively: in user loyalty and, ultimately, money. And in the end, you won't have to fire anyone for tweeting.