What companies would benefit from native app development vs cross-platform apps?
Recently I was asked this question and it got me thinking. This article is still an ongoing piece of work so any comments and suggestions are welcome.
I have worked in the last 10 years as an iOS native developer. I’ve had to manage my own memory in Objective-C with [retain] and [release] and got to work with Swift 5 and Autolayout. I also dipped my toes into Android, React Native, Ionic and have previously worked with C++, .net, J2ME and others.
Hence from my experience these are some types of companies that would benefit from doing things all native (iOS, Android or both):
1. Companies that already started with native apps a long time before and already have a significant codebase in native.
2. Companies for whom money is not a problem, but quality and performance is very important. They want the best there is and have no problem paying for that. Usually these are already large companies with a lot of sales and that have an important brand to protect. Ex: Banks, Automotive, Telecoms, Airlines, Electronics etc..
3. Companies that require a project that heavily uses some features close to the operating system. Examples: heavy use of video, or graphics, some types of games, fitness trackers or other apps that make constant use of sensors and run in the background. They also need to be the first that take advantage of a new feature in the OS.
4. Companies that require a large and complex project. If you have a project with a complex UI and with many features. Often these are companies that already have a cross-platform project but it has become so large that it is getting difficult to maintain and might already have performance issues that are causing a bad user experience. They already are paying for a team of developers to maintain the app so there won’t be much of an economy if switching to native.
5. Companies whose core service is through an app. Examples: Uber, Revolut, etc.. These are companies who cannot risk the app being broken or taken offline because of a change in the framework they are using. Moreover they require the app to work flawlessly, and be so good as to be featured in the AppStore or Google Play. Being in the top 5 apps is almost a requirement. Therefore it’s better to use the native tools that are guaranteed to be supported and that allow for a great user experience.
6. For startups that need an MVP I would recommend starting with a native app in only one platform Android or iOS, whichever is closer to their potential customers. After you test it in the real world and have gone through several iterations of build+validation and started to have traction and funding, you can now invest in a second app for the other platform, having the advantage that you already have the first. Going native will allow you to iterate faster because the development process is making use of better tools and better support. Otherwise if you would start with a cross-platform solution you will find at some point that it doesn’t scale, or it has become too buggy and unstable to support different UIs (iPhone, iPad, Android, watch etc) from one codebase and that you will be forced to rebuild native anyway.
What companies would NOT benefit from native app development vs cross-platform apps?
1. Companies that already have a working mobile website and want to reuse a lot of that code then it’s probably better to go cross-platform.
2. Companies that have a lot of programmers and know-how in a certain technology ( ex: Javascript, Microsoft technologies) and wish to leverage that. If you have many people with experience in .net, you might want to try Xamarin. Likewise if you have many people with experience in React or other Javascript frameworks, you might want to try React Native or Ionic. This still means you occasionally will need to find someone who can work with native but those can be outside consultants and most of the codebase can be maintained by using the know-how inside the company.
3. Internal apps that must work on many platforms and UI smoothness and beauty is not a concern, but resources in terms of people and time are.
If you need to make an app that you don’t think will be maintained. Examples are apps for conferences or promotional campaigns that will only be used for a period of time and are afterwards useless, apps for conducting studies or surveys.
If you have an app that should look the same way across all platforms disregarding UI guidelines. Examples: Many games are like that, made in Unity or other frameworks and have their own look and feel which is platform independent.
Frequent issues with cross-platform solutions:
Memory issues when scaling the app.
Animations and “snappiness”. Animations will not be automatically supported and actually more difficult to implement in cross-platform solutions.
Lack of proper tools — Often, there is no debugger and no performance measurement tools.
Uncertainty of whether that platform will still be supported in a few years. There have been cases of cross-platform tools that were either abandoned (Flash) or acquired and then axed (Parse). Even so, generally there seems to be a trend of people liking the newest cross-platform tools
A tendency to prefer the "new and trending" tools
Too small community. Programmers need other programmers to learn from or use their open-source code. If there aren’t many others then you will be stuck fixing some obscure bug or having to build something from scratch for that particular platform.
You still need access to native developers. Some parts will still have to be made native and often bugs will have to be fixed in the bridging platform. In RN there is a frequent issue of using open-source libraries that are not maintained or are buggy and some work still needs to be made on the native part to keep them up-to-date.
Many companies that started with cross-platform tools have ultimately abandoned them: Facebook, LinkedIn, Airbnb, etc..
Delayed access to having the latest and greatest of what features the OS can provide. New features released on Android and iOS must be adapted in order to be available using cross-platform libraries. This means there will be an unknown delay between their official release and being able to use them in your code.