August 9, 2017
Sometime around 2010, apps became the “Next Big Thing” – for everything you could hope to do in life, there was “An app for that.” Everywhere you looked, there seemed to be an advertisement for an app. I remember one trip through the security line at Miami International Airport. On a billboard to my right, American Airlines claimed that their app could check me into my flight, show the gate number, and present my boarding pass. Above my head on a monitor, the TSA claimed their app could list the type and amount of liquids allowed in my carry on. As I approached the Xray machine and took my shoes off, in the bottom of the bin, Zappos claimed their app could give me a brand new, better pair of shoes. From where I was standing, I could see three different advertisements for apps, and I realized that we’ve fully arrived in the “Age of Apps.”
As apps went from hot new (and highly hyped) technology to part of the fabric of our everyday lives, there has been a lot of talk behind the scenes about the best way to build these apps. For all the debate, there’s no universal answer. Part of the reason is that the platforms are fractured: some people use iPhone, while others use Android… some people use Roku, while others use AppleTV, Amazon Fire, or Xbox. All of these different platforms are built on different technologies, which require separate code bases and development languages. Putting your app on two or three different platforms (some of our clients run on up to 30 of them) directly multiplies the development cost. Is there a way to write one single set of code that runs across all these devices?
Many solutions have sprung up to address this need. There are mobile solutions, and there are solutions that also encompass set top boxes and gaming systems. In theory, a developer can write an app in a single language (HTML, C++, Javascript, C#), then compile it to run natively on multiple systems. Seems like a great option! Unfortunately, it’s not the silver bullet that many people are promising. Like most things in engineering (and life), this approach comes with some compromises. The following areas can suffer from a cross-platform approach:
First compromise: user experience, which has evolved drastically over the past ten years. In the past, the holy grail was to create an app that was identical across all platforms. More recently, the trend is deference of and adherence to the norms of each native platform. So we’re moving from the world of “one to rule them all” to “to each, its own.” If your brand is arguably bigger than the platforms, you’re operating on (Facebook), or in a completely different universe (game engines) it makes sense that your experience may be so unique that it overrides the platform it runs on. But very few publishers fall into that category. Most apps benefit by feeling at home on and fitting into the platforms on which they run. The best way to do that is to use the native tools given on each platform. Write once, run anywhere apps tend to have challenges when it comes to playing nicely with platform defaults because they’re not first-class citizens. Using their own interfaces, instead of the ones provided by each platform, can create the feeling that something’s “not quite right.” This will undermine user trust, even if subconsciously. We want the app to work how the user expects it to, and we can accomplish that best by leveraging the platform-native toolkits.
Second compromise: performance. Everyone will agree that a faster app is better than a slow one. Studies show that speed boosts conversions, and slowness increases churn. Why is that? Every moment that a user waits – watching a spinning activity indicator – brings them closer to set-top-box defenestration. Their impatience boils over into anger. If another app can provide a faster and smoother path, users will naturally gravitate to it. Hence, every publisher wants their app to feel as snappy and responsive as possible. To do that, we want to program close to the metal. We want performance tuning and code optimization. These processes are much more difficult in non-native, cross-platform environments because many of them sit one level above the native SDK. They require plugin after plugin, in non-native languages, to replicate core functionality of the operating system. It’s harder to use the typical tools and techniques to make things faster, and they forgo much of the streamlining the platform owners have done themselves. This one-two punch against performance makes the app feel bloated and slow.
Another compromise and this one is a big one: cost. It’s really tough to accept because very often the cross-platform approach is pitched as a way to reduce costs. Then, by the end of the project, publishers are left holding their heads as their spend soars far beyond budget. The reason is that adding a cross-platform solution adds complexity. It doesn’t remove the need for engineers with expertise in each platform, but it does add the need for engineers that understand the cross-platform framework (almost always, a more niche skill set). The code is more complicated, the number of people you need to work on it increases, yet the number of people who can understand the system as a whole decreases. Going this route, we could easily end up paying more for lower quality. It’s possible to save money, but the end product is far inferior to its peers. And it’s not just the upfront cost that’s of concern – maintenance costs over time will be higher as well.
Last compromise: publicity. By publicity, I mean things like getting featured in the App Store. Each platform has specific features that set them apart, and they’re in a fierce competition to win over viewers. The owners of these platforms love it when publishers make use of them. They’re far more likely to feature your app when you implement the shiny new API they spent so much time developing. Cross-platform apps tend to have a lowest common denominator feature set. It becomes more of a challenge to add in these bells and whistles that Roku, Apple, Amazon, and Google love so much. Even platform exclusivity itself is something that they prize and will help get your app featured. By releasing too many different platforms at once, with an identical feature set, you drastically reduce the chances of getting your app attention. On the other hand, native implementations that work great and show love to the creators of their ecosystem are much more likely to get the spotlight of the store in which they reside.
Is there a right time to use cross-platform solutions? Perhaps – when user experience is not a priority. Imagine a company developing an internal app for their global sales team. The sales reps have to use this tool, whether they like it or not. Maybe it’s worth it to save money because the end user can’t choose a competitor’s app over yours. You could also imagine an app that would be installed to showcase a product in showrooms or in a retail environment. The consumer may not even interact with the app. The installer is expected to be able to go through a complex installation process. Again, there is no choice. Last, maybe you have a massive engineering team that can maintain one of these cross-platform libraries and feels that doing so will give you an economy of scale while creating a unique user experience to differentiate yourself. Facebook? Yes. Almost everybody else? No.
When is the right time to use native solutions? When you care about the end user, and you want to do the right thing by them. When you want the highest level of quality, you can get, without compromise. When you see the code as an investment that your business is built on. When it’s important to be in the good graces of the platforms you develop for. Thankfully, at Float Left, this applies to all of our customers.
Ultimately, we can debate it all day and into the night, but we can also look to history for answers. Because, in fact, this debate is not new. It happened in the 90’s with another “write once, run anywhere” solution: Java. Sure, there are have been a lot of publishers over time that used Java. But I’d be surprised if you can (with a straight face) name a single Java app that is great, that inspires, that creates an emotion. I use a similar metric for apps… I’m chasing something truly great, something amazing, something that has the potential to change the way people think about this medium. The fact is, practically all of the best apps, that people love the most, were built natively.