Does Cross-Platform Mobile Tech Save Money Over Native?

By: Ethan Campbell

One of the duties we have as mobile technologists at Aptera is to constantly evaluate the tool-sets available for use in implementing mobile solutions. One of the questions we are commonly asked is whether or not a project can be implemented with the use of a cross-platform tool-set. The answer is usually, yes, it’s possible. However, whether or not they reduce development effort is a different question and requires a bit of analysis upfront. Before we get into things, we do have a bit of a disclaimer. For the purposes of this article we are only going to be contrasting native development with what we see as the most viable leaders in the cross-platform toolset field: Xamarin,  React Native, and NativeScript. These platforms use C# or JavaScript to call into the native iOS/Android APIs, as opposed to HTML5-hybrid platforms (Cordova, Ionic, etc.) which render controls within a browser. We do not leverage those tools due to concerns over security, speed, user experience, and platform decline. A simple Google search for “Cross-Platform vs Native Mobile Development” will yield article upon article that focus largely on platform capabilities and features. Our opinion is that those comparisons are largely irrelevant now as the main industry platforms are mature enough to do almost everything a native solution can do. Xamarin, React Native, and NativeScript can all interact with the device’s camera, geolocation APIs, Bluetooth and KeyStore/Keychain APIs among others. Comparing cross-platform vs. native tools again wouldn’t be providing anything new and it certainly wouldn’t address the underlying question of whether a business can save money by using cross-platform tools. What we’ve discovered in practice is that there are many cases where the design and/or functional complexities cause more development effort when using cross-platform tools than if we’d simply developed natively.

Building Tools to Build the App

To use an example, ideally a Xamarin solution using a shared portable class library can share roughly 90% of the codebase between iOS and Android if the app design, UI, and libraries leveraged are all out-of-the box. However, if your design “polish” calls for customized icons within text boxes, slide-out trays with spring effects, buttons that pulse when pressed, overlapping control elements, calendar/color pickers, or any other element/function that isn’t available right out of the box, your development team is probably going to spend time overcoming those technical hurdles. Native developers have these hurdles too, but the difference is that the native development community is bigger and makes thousands of custom open source libraries available via dependency managers like Cocoapods and Maven which offer drop-in solutions that can often times be looked up, pulled down, and integrated into the project in less than 5 minutes. Xamarin cannot easily leverage this deep repository of ready-made solutions so developers must rely on the much smaller Xamarin community for these libraries or custom build their own. This additional development may not impact the 90% figure we quoted earlier but it does add an additional development line item which can quickly eat away at the cost savings of going cross-platform.

Thankfully, React Native and NativeScript can leverage Cocoapods and Maven fairly easily in their solutions via a bridging mechanism (or “plugin” in NativeScript) which allows us to call into those native libraries. However, the cross-platform developer is not absolved of understanding native functionality and languages as all code samples and API definitions for these libraries are written in the native languages (Java, Kotlin, Swift, or Objective-C). Additionally, the bridging file for a React Native app must be written in Objective-C which will require a developer to spend time learning the basics of another language (or possibly three). Again, this may not affect the code-sharing percentage but is still another development cost that eats into the cross-platform savings figure.

Another cross-platform challenge we’ve experienced is when the UI for Android and iOS need to be different or the design complexities themselves are beyond the capabilities of the cross-platform tools and dictate that the developer implement separate UIs for each platform. Clearly this negatively impacts our code-sharing percentage but it is a sliding scale depending on the number of screens being written twice.

So, have we successfully discouraged you and your team from using cross-platform tools like Xamarin, NativeScript, and React Native? I sure hope not. These are all quality tools that we currently develop with quite often here at Aptera when we determine that an app design falls to the left of the “native development tipping point” which is illustrated in the chart below.

Development effort by platform
Simple designs are very quickly and cost-effectively implemented using cross-platform tools but there is a point at which the complexity causes the pendulum to swing the other direction in favor of native tooling, which is nimbler when jumping complex design and functional hurdles. So how do we determine if we’re going to cross the tipping point? Our mobile app discovery process takes a disciplined approach where we consider design complexity / UX, additional third-party tooling, and functional complexity. Based largely on these factors, we will then determine whether to go native or cross platform and then which tools best suit the development team while accomplishing the project goals. Interested in taking the next step to determine where your app design sits? We’d love to work with you and determine which side of the tipping point you are on. Contact us today.  
Ethan Campbell headshot

About Ethan Campbell

Ethan is a Sr Software Engineer for Aptera Software, specializing in mobile technologies. He has been developing enterprise solutions since 2000. As an avid mobile development enthusiast, he loves to study new mobile technologies, languages and industry trends.