Before You Get Into Cross Platform App Development — A Few Check Points
In app development, namely iOS and Android, there are two approaches to developing apps for both platforms: do it natively in platforms’ own development environments, or do it using a third party tool and then deploy to the two platforms. Which approach to choose from is a typical engineering decision that focused on the technicality of the choices, such as whether to use Xamarin or React Native, who’s got the best skills etc. But I would argue that before you dive into the details, here’s a few things that worth double checking
Having a common code base is a form of centralization. Centralization does not have a positive or negative connotation necessarily. It simply means there is one team working on the common code. And by doing so, you are expecting the apps maintain a common user experience cross platforms. Of course there will be differences between the apps for the two platforms. But the commonality has to outweigh the differences. Otherwise maintaining a common codebase will stop making any practical sense. And the team working on each platform will soon find it more of a burden than saving time, more restriction than empowerment.
Cross platform development assumes certain stability with the app. At early stage of a product life cycle, the features are not fleshed out. Lots of work are experimental to get product market fit. Planning for one platform is already filled with unknowns. Adding another one on top of it will dramatically slow down the iterations and increase the cost which will inevitably make any new features or experiments risker. This also means feature parity is either guaranteed achievable cross the platforms or not a critical piece of the app at the given stage. Imagine you are developing an app that will take the advantage of the augmented reality capability provided by iOS ARKit. If the feature you are using is the key element of the app, and is something you cannot do on Android using the Google’s ARCore, which is the counter part of ARKit on Android, then it makes no sense to pursuit cross platform development from the beginning. But if this feature is just another nice to have feature, it will be OK to have different implementations on iOS and Android.
Aim for product consistency, not cost saving. Cost saving can be a strong argument and often times will be the deciding factor. In reality, it is actually much more complicated than it looks. I have witnessed cases where projects were prolonged over some unexpected issues that should not have happened had the team done it in native environment. Unfortunately, very few companies/teams would admit their mistakes for taking the wrong approach and I won’t blame them: after all, there are so many variables and nobody’s taking both approaches at the same time therefore can not prove one approach is better than the other definitively. One implementation two platforms should save time and money. It sounds very appealing, but could very likely ended up as just an illusion.
It is worthwhile to reiterate the law of complexity from Larry Telser:
Complexity cannot be reduced, but can only be transferred. All processes have a core of complexity that cannot be designed away. The only question is what handles it: the system, or the user.
Tesler was talking about moving complexity between human and system. But it also applies within the systems. In the end, some of the complexity will inevitably be transferred to developers. The point is, if cost saving is the reason you choose to do cross platform development, then you are probably barking on the wrong tree.
A more foreseeable benefit is that it helps maintain a consistent product experience across platforms, which ironically, will help save effort for managing products on multiple platforms in the long run.
Lastly, coming from a design background, I admire the software industry’s capability of creating new tools. I came upon Andy Clarke’s blogpost, talking about his experience using web development tools:
It’s dangerous to believe with absolute certainty that the frameworks and tools we increasingly rely on today — tools like Bootstrap, Bower, and Brunch, Grunt, Gulp, Node, Require, React, and Sass — will be any more relevant in the future than font elements, frames, layout tables, and spacer images are today.
The biggest lesson I’ve learned over the past two decades is that techniques and tools come and go with increasing regularity, but the importance of learning how to develop meaningful markup and use CSS appropriately will be as important twenty years from now as it today.
I think his conclusion applies to the app development too: while finding new ways to do development more efficiently is important, we should be mindful not to be bogged down by chasing tools.
