January 22, 2018
January 22, 2018
I’m not joking. Most of us work on products that are available on multiple platforms: web, iOS, Android, sometimes even desktop! The fact that every platform is developed “natively” by a separate team, in a different technology, and in complete isolation from the others, doesn’t mean you’re not making a cross-platform product. It just means that you’re doing it in a really inefficient way (if you want an idea how to do it better, you can read Patryk’s post on building cross-platform teams).
As you can see, this whole cross-platform thing is not really a niche fad that we can just ignore and wish away. So, instead, let’s dive a bit deeper into what it is and dispel some misconceptions that seem to be really popular.
This one’s a dismissive opinion that people use as a basis to claim later that there’s virtually no difference between cross-platform apps and web apps and that performance is terrible.
While it is true, that solutions based on webviews suffer from performance limitations and have trouble imitating “native” user experience, they form just a subset of choices for cross-platform development. Apache Cordova / Adobe PhoneGap and Appcelerator / Titanium are I think the most popular ones in this genre.
There’s however a lot of different tools that don’t suffer from the webview tax and have comparable performance to natively developed applications.
Nothing farther from the truth. There’s a bunch of small sub-myths here:
Here are a few choices that you can use instead:
Finally, you can also go cross-platform with native code, how crazy is that? For example, Kickstarter adopted a similar, RX-based architecture in both their iOS and Android applications and it allowed them to share a lot of _knowledge_ between the teams. Even if the code is not shared, it still makes it much easier for developers to switch between the two teams.
Well, kind of. Maybe. It doesn’t matter. Again, we’ll have two split such statements into two different, smaller, myths.
This one’s really popular among developers. We like to take pride in our work, craft beautiful animations and obsess over details. However, a lot of times we forget what’s the value of the application. It’s what it allows the user to do, not how.
If I have an ugly application for health monitoring that increases my chances of fighting cancer, I don’t care whether “the navigation transitions don’t feel native”. What I care about, is my health.
I think as developers (and even more so, designers!) we overestimate the value that “real users” pay to those details we like obsessing over. Of course, there is a lot of cases where the user will get annoyed by the lag between tapping a button in a webview-based product, but most of them won’t care (or even notice) if you choose a “wrong” button tap animation in your React Native app.
In theory, yes. To quote one of the conference talks I’ve seen this year: „You can’t paint a picture of Morgan Freeman that looks more like Morgan Freeman than Morgan Freeman.” The native apps are the „gold standard” of mobile applications nowadays and you can’t be more native than native.
In practice, however, the main factor that influences the final quality of your app is your team and its motivation. If they focus on creating the best possible user experience, it’ll be great, no matter the technology used. If they don’t, going native won’t change much.
My favourite example is when Microsoft rewrote their Skype application in React Native. Obviously, I don’t know what were their reasons and how they judge this decision from their point of view. However, I use Skype a lot, both before the rewrite and after, so I have a very good perspective on the user’s point of view.
The most surprising changes were that both performance and user experience improved enormously. How can that be, you might ask, if the codebase changed from native to React Native? Well, I guess is that the team priorities have changed. The old version had a lot of performance issues on middle-range and slower Android devices. This led to crashes, lack of responsiveness, overall horrible user experience. When rewriting I assume a lot of effort was paid to make sure that application feels fast for all the users, not just the ones on the newest phones. This led to a dramatically better product.
(Yes, I know that the new design is… surprising. Yes, I haven’t met anybody that likes it. No, I don’t really care.)
No, of course not. I’m not saying „native apps” are becoming obsolete, just that they’ll become more like artisan crafts.
They might be higher quality, more customisable, but also more expensive and that’s the bottom line for a lot of businesses. Once cross-platform solutions get good-enough (arguably I’d say the time is now-ish), most of the businesses is going to move towards them.
The same way hardly anybody creates custom-made blogs, or writes their own ecommerce platform, mobile development will commoditise. We’ll have off-the-shelf products that we can use to jump-start our applications. And, guess what, they’ll be cross-platform!
Native apps will still be around, the same way cobblers are, but less companies will need them. The same way most people buy their shoes from a factory. Or get their music as a digital download, instead of a vinyl record.
Finally, native development will always be a better choice if you bill hourly!
If you liked this post, why don't you subscribe for more content? If you're as old-school as we are, you can just grab the RSS feed of this blog. Or enroll to the course described below!
Alternatively, if audio's more your thing why don't you subscribe to our podcast! We're still figuring out what it's going to be, but already quite a few episodes are waiting for you to check them out.