One of the biggest social media stories of the past few years has been the avalanche of TikTok and how mainstream players like Instagram are struggling with it. As I’m personally most interested in mobile apps, what I found most intriguing was how Instagram’s huge tilt towards Reels hasn’t impacted a large chunk of their user base running on Android. “Unless you have a really good phone, it takes absolutely forever to create a reel,” says one of the thousands of one-star reviews on the Play Store written in late 2022. “As a small company, I can. I can’t create even the simplest reels without seeing the message “Sorry, something went wrong.”, complains another user who owns a relatively modern Google GOOGL Pixel 5.
Meta META is not alone here: the whole $8 blue check for anyone debacle that marked Elon’s early days on Twitter was only visible to people with iPhones.
Features aren’t the only issue; there is also speed. Our own research shows that the overwhelming majority of Android versions of popular apps experience 10x to 100x longer wait times in key user flows. And speed matters: According to Dimensional Research, 36% of surveyed mobile users would hold a slow, unresponsive app against the brand that spawned it, and for 96%, speed is the deciding factor in deciding whether to delete an app or not want to keep. And if you want to know how slow is too slow, Mozilla says anything over 50ms will be noticed.
The discrepancy (both in performance and functionality) between iOS and Android apps is not only one of the least noticed phenomena in technology and a real problem: the market share of Android phones roughly matches that of iOS phones, which means a significant number of users are not getting the best possible experience from their apps. This problem is especially acute for users who cannot afford high-end Android devices, as well as underrepresented groups and those living in developing countries.
This discrepancy has wider implications for society as a whole. By failing to provide a consistent and quality user experience across devices, we fail to create shared cultural experiences that can unite us in the face of global challenges. In today’s connected world, it’s more important than ever to come together and work toward common goals.
There is a complex intertwining of technological and socio-economic factors here that are difficult to map accurately. Technology often intersects with privilege, and solution-oriented attempts to address the problem through purely technical or business means have repeatedly failed.
For example, most mobile developers would point out the architectural differences that typically help iOS apps run faster and smoother. Apple’s AAPL proprietary silicon beats anything on the open market, and iOS is tightly optimized to run on it. Both Android and iOS developers recognize that the latter offers a better way to manage memory usage and shut down memory-hungry apps more aggressively.
They would also point to other technical factors at play, such as an overall larger selection of Android phones that includes more low- and mid-range phones with smaller storage, weaker processors, and slower connectivity options. However, I think these explanations are somewhat misleading.
First, writing mobile apps is a complex endeavor that often doesn’t provide proper tools to achieve the stated goals. Modern mobile apps, even when built by lean teams, are made up of code written by thousands of engineers. After all, third-party libraries are popular, well-known, and affordable. It is often nearly impossible to find a way around and understand such code. Without tools like ours, dozens of parallel threads executing a variety of execution paths triggered by user actions, interrupts, and scheduled and unplanned 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 experienced it firsthand on Snapchat, as I was often the only person with Android at large tech meetings. Despite Android’s somewhat geeky image, the big tech houses are all iPhone. The top-rated engineering schools are completely iPhone-dominated. Surrounded by them, executives who also use iPhones tend to assume that all wealthy, paying customers use iOS. There is no shortage of market data to back up this argument.
The most recent, most graphic example of this bias was Elon Musk’s very public dispute with his own [ex-]Android engineer. I would like to highlight some notable details about it. First, it didn’t help that Musk’s offered understanding of the technical issues at hand wasn’t brilliant. But the company’s Android engineers also didn’t seem to understand how much the app’s sluggish performance was hurting Twitter’s business goals: if it’s slow to show tweets, it’s slow to show the ads too! Second, during the argument, the engineers first suggested that the app “works well,” and then cautiously suggested omitting a few features (much parity?) to improve the situation, while implying (as many engineers often do ) that a major overhaul would solve the problem by getting rid of the legacy stuff.
This is just a public example of a broader problem, which is also not very new. Let’s go through some traditionally suggested solutions.
1. Let’s do a clean paraphrase as suggested above. What sounds like a good idea often turns out to be an extremely annoying nightmare that lasts several months. It also tends to affect the day-to-day relationship between the engineering team and everyone else: product, sales, etc. Such paraphrases tend to negatively impact companies’ ability to execute their strategic plans as planned. New features are deprioritized and postponed “since we’re rewriting everything anyway.” And the worst thing is that there is never a guarantee of a good result. As a good example, let me remind you of Discord’s efforts to rewrite their own Android app in React Native to achieve feature parity with their pre-existing React Native-based iOS app. Customers were unimpressed.
2. Or do we limit the number of features – just like Twitter’s Android engineer who suggested we omit features to improve speed. Twitter Blue arrived on Android a few months late, while tweeting from the platform became noticeably slow. I don’t think there’s a right way to go here, to increase this very inequality that we’re trying to overcome while limiting growth.
3. Let everything be. Assuming the app is fine (after all, people use it!) and only responds meaningfully if users support it en masse. Those who choose this route often pay heavily for APM/Observability tools and think they have invested enough even though their mobile engineers aren’t using them. I would not have written this column if I had agreed with this approach.
First, by the time you need observability, it’s usually too late and users are already upset. Second, these tools can only produce meaningful results if you feed them your users’ data. But even then, they usually have trouble explaining the slowdown. The variety of tools that emerged with the advent of backend server APIs were never intended to deal with the multithreaded maze of execution on mobile devices. They just instrument system calls, which are everything on the backend, but just a drop in the bucket on the client side. For example, one of our customers struggling with a molasses-like app launch that took seconds was curious as to why the legacy tools would claim their app launched in just half a second. We applied AI-assisted tools to demonstrate that the APM tool assumed the app was launched when it sent a system call of a logo animation rendition (something a user shouldn’t see at all). By the way, the customer’s app was on iOS. That’s how they knew the dashboards were wrong.
Now let me suggest a few steps that I think are worth implementing here.
1. Start mapping the key user flows and introduce metrics to improve performance. Don’t forget to commend the engineers involved in the project for each improvement and always make it clear how important it is to the overall business.
2. While not all performance monitoring tools are equally useful, analyzing the code and optimizing performance must be a priority. Careful investigation will help you identify performance and UX tweaks that improve performance where it matters—all without rewriting the whole thing from scratch.
3. As mentioned above, this problem is far from just technical. In many organizations, especially in the US (and some other countries), there is always a certain level of Android blindness, especially at the managerial level. This can only be overcome by diversifying your mindset and having a strong, functioning open mic culture inside.
The last point will certainly be the most important. Always having someone high enough in rank who can say, “Wait, our app works like crap on my phone. There are many more like me. And at the end of the day, you don’t have to fire anyone for tweeting.
