Our customers often ask us whether they should develop their mobile apps natively, or whether they should rather be using cross-platform technology. This article explains the pros and cons of each and should help you in your decision-making process.
A native app is an application developed solely for a specific platform. This means it adheres to the platform’s specific requirements and most importantly, it can make use of all the device’s hardware and software features.
Developers create these apps using the platform-specific languages (Swift or Objective-C for iOS and Java or Kotlin for Android) which means the apps are specialized to be only for the intended platform. These developers then have access to the native APIs and design features the users are accustomed to. This amounts to better performance, consistency and a great user experience.
High Performance and Great UX
Native apps will have the most optimized experience for the OS they were written for. The developers follow the platform-specific design guidelines which results in an app which provides excellent UX, and integrates seamlessly with the platform. They can be fully customisable with ease because the developers have access to all the features of the platform.
The application has access to all device’s hardware and software features as well as the native API’s. This means the app can make use of all the native applications, services, and hardware elements (Bluetooth, GPS, NFC, Biometrics).
Apple and Google always feature native apps on their store and developer pages. This encourages developers to code native apps instead of cross-platform in order to earn more revenue, downloads and exposure. There are reports that show that being featured on the App store can increase downloads by 800%.
Development resources and support for native applications will always be the most recent, active and stable. The native app developer will always have the largest community, knowledge, and solutions due to an ample number of forums to source from. Experienced native mobile developers will also have more specialized skills and lower-level platform knowledge due to in-depth working, within the native APIs and functionality sets. Tooling and it’s availability is also simpler and optimized to use with the platform’s development. Issues will be quicker to debug and troubleshoot (especially lower-level issues) using the supported and recommended tools provided by the platform owners.
Having a native app, comes with the dilemma of maintaining multiple codebases. This comes with the problem of paying multiple developers to work on the different code bases. Although development on a platform may be quicker than the other, even multi-platform developers, may need to work twice as many hours to get both apps developed. Each platform has its own challenges with specific hardware and software limitations, which also adds to the development time. To add to this are the development accounts subscription fees for Android ($25 once off) and iOS ($99 per year).
Maintaining multiple code bases and platforms
Since there are usually multiple development teams, uncoordinated feature updates and support (bugfixes and changes) may consume a lot of manpower and time. In the case of new feature work, both teams will need to code the features separately as code is not reusable between platforms.
A cross-platform app is an application compatible with different mobile platforms. This was normally developed by using web technologies, but relatively recently Flutter and React Native started making inroads.
These new frameworks are being showcased by big companies like Google (using Flutter) and Facebook (using React Native). They are known as ‘native cross-platform’ which is the middle ground between full native and hybrid cross-platform. Hybrid cross-platform are frameworks such as Ionic, PhoneGap and Cordova which use old school web technologies.
Cross-platform frameworks offer to bridge the gap between platforms to reduce the amount of written code which could make the process quicker than native development. It is intended to also provide a performant and native UI (or as close as possible) so users get the experience that they expect from their mobile platform.
Lower Initial Cost
Because cross-platform applications share a big chunk of the same code base, depending on the complexity of the application, it could be much cheaper to develop. Only one team may be required to develop an application which can be distributed to multiple platforms. It can reuse some resources across platforms too, which may bring down the cost even more. A new project’s budget may be able to reach much further if the application is released to the market as soon as possible. The project can then be fine-tuned and reworked based on the early feedback.
Simpler Platform Consistencies
UI differences, including navigation and animations, are handled by the framework by default. With native app development, it is easier for more inexperienced developers to implement UI inconsistently, whereas a cross-platform framework may hide this complexity so less effort is required to achieve a more coherent brand identity in applications on all platforms.
A large portion of code is reused across platforms which is why you can have a single codebase that can be built for different devices/platforms as opposed to multiple codebases for the same application. Sharing code could save time since the new code doesn’t need to be (re)written per platform.
As mentioned above, the application has one big codebase. Although there will be cases where handling platform differences will need more time and effort (because of writing extra code to handle platform specific issues), a single codebase could speed up the different stages of development by saving time and money by only maintaining one codebase.
Easy App Support and Maintenance
Since there is only one codebase, it’s easier and cheaper to make trivial changes, be it new features or bug fixes, as opposed to native applications where it needs to be done for all the platforms.
Wider market reach
Instead of selecting one platform based on personal preference or because of a limited project budget, you can target multiple platforms and increase your market reach. This can lead to increased revenue and increased exposure. By using analytics you can then determine which market to target if needed. Another option is to target one platform while using a cross-platform framework which will allow you to focus on getting a single platform ‘perfect’ and then get that out. After which you can get the other platforms out with minimal effort.
Having one development team reduces the workload of the developers considerably. This being said, it's still a good idea to have developers that are familiar with the platforms you are targeting. They can help with any platform specific problems and with deployments to the relevant app stores.
Low App Speed
While cross-platform applications are theoretically fast to develop and deploy, there are certain situations where they are somewhat slower than their native counterparts. It’s not usually noticeable with consumer applications since the average user doesn’t notice if the display is scrolling at 50fps instead of 60fps, but if you are developing a complex video app or mobile game, it won’t work as efficiently as native technologies.
Cross-platform applications don’t have access to all the native APIs. They also have limited access to OS features and often won’t work without an internet connection.
The limitations of the framework will always be the lowest common denominator.
At times access to new native API features may be delayed, may prove less than ideal to use, or may even be a permanent limitation. Some may require hooks or will have to write native libraries in order to work around these limitations.
It is a lot more work, compared to the rest of the cross-platform development, to make the UI adhere to Apple’s Human Interface (HMI) guidelines and ignore Google’s. To simplify this, you need to use a unified UX. This is not easy of course, but a necessary initial requirement to ensure that users on all platforms are happy. When this is attempted, the initial time saved by using a cross-platform framework could be overshadowed by the huge amount of time required to adhere to the platforms’ HMI Guidelines. This will also normally require a developer that understands the specific platform’s UX guidelines.
Although cross-platform frameworks are aimed as being faster, cheaper and simpler to maintain, this is not always the case. Plenty of cross-platform frameworks have come and gone but have not found a solid footing in the mobile development space.
There are overheads such as having to train existing mobile developers to make use of the new frameworks or having to train non-mobile developers to learn a framework abstracted from native tools. The latter may eventually prove to be more expensive as expertise and advice from native mobile developers would still be required for writing platform specific workarounds, and to guide developers unfamiliar with the different platforms.
Adding an additional framework layer on top of native development may even prove to slow down development and troubleshooting when lower-level issues surface, or even with simple platform bugs.
This means that developers are forced to work with the overhead, complexities and issues of the cross-platform framework layer instead of being direct to the point and simply making use of the basic familiar native tools supported by their much larger native development communities.
There are always trade-offs when choosing between native or cross-platform frameworks and decisions regarding which tech stack to use will possibly have uncomfortable grey areas.
If your requirement specifies that there is a manageable amount of complexity, with the main driving factors being code reuse, insufficient staff or skills, and time to market, then cross-platform may be the better option.
Pure native will always provide the best and cleanest upgrade paths, best performance with the latest up-to-date tooling and releases. You should decide on native if there is complexity in implementation and specific dependencies on native frameworks. This is particularly important if you are developing mobile applications that are geared towards cutting edge technologies or applications where performance is paramount. For example, most of Global Kinetic’s banking and financial clients choose to develop natively.
Applications expecting a long lifespan can also consider an underlying native core with some outer features built through cross-platform frameworks and tools.
Ultimately the success of the project will depend on the team. Once the team has selected the correct technology, the team's mix of culture, structure and motivation will determine the success and quality of the app. Neither of these technologies is a magic bullet, and care should be taken with both, specifically managing the risks inherent to that platform.