Cross-platform Native Mobile Development

The rise of cross-platform tools & why Xamarin is a worthwhile investment for your organization.

The developer’s pipe dream: to write code once that runs on all the platforms out there, adapting and adjusting to the platform’s capabilities on-the-fly without intervention. The good news is that it’s usually easier to think in terms of mobile vs. non-mobile platforms when selecting from the plethora of solutions out there.

A widespread misconception is that cross-platform and native do not go hand-in-hand, i.e., if you are after cross-platform, you are not building native solutions. But native could mean a lot of things, so it is a matter of perspective. By native do we mean the machine code that runs at the hardware level, which contributes to the performance of the application, or do we mean the look-and-feel of the application? Ideally, a truly native solution would cover both the application’s performance and its look-and-feel. It’s as if you’ve developed the application using the platform’s intended technologies, technologies that are native to that particular platform.

Now you might think that if the cross-platform solution does not use the platform’s native technologies, then it’s not native, but that is far from the truth. Over the years, compilers have become very smart and efficient at generating the machine code, and sometimes you can achieve performance that is better than the platform’s intended technology stack!

So then what makes a solution native? From our perspective, it’s the native look-and-feel plus performant compiler-generated machine code, regardless of the chosen language or technology stack.

Cross-platform Native Mobile Development

At CauseLabs we like to think of the current state of mobile development as it pertains to “business apps” in three different ways. Such “business apps” have certain user interface needs and are expected to present familiar interfaces that users are accustomed to. Apps with fully customized non-native look-and-feel user interfaces (like the majority of the gaming apps out there), are not relevant to this discussion. Such apps already use optimized technology stacks, like Unity or cocos2d-x that guarantee they’re pushing the limits of the hardware they’re running on.

The Silo Approach

This is the oldest and the most widespread approach. The developer is using the platform’s original technology stack: for iOS, you’re using the iOS SDK and Objective-C/Swift; for Android, you’re using the Android SDK and Java. Your solution is “siloed” from other platforms, and in most cases you’re hardly sharing any code.

The advantages are numerous. Your solution is native in every possible meaning of the word and the platform is mature enough for you to easily find help and code samples. Also, you’re guaranteed to have invested in a technology stack that will only die if the hardware platform itself fails. The main disadvantage is code sharing: your codebase is siloed from other platforms. Unfortunately, this can have a ripple effect: multiple codebases usually mean multiple teams, which can lead to subtle implementation differences, which in turn can result in the same app functioning differently on different platforms. It’s not that multiple teams (or a team per platform) is a disadvantage in itself, since your release cycle will most likely be the fastest, but it tends to distract from absolute feature parity.

The Write Once, Run Anywhere Approach

This is probably the second most popular approach. Mainly because it leverages web technologies in building mobile apps, and there’s no shortage of web developers out there! Some of the most popular technologies include Apache Cordova (PhoneGap) and Appcelerator Titanium. The main advantages here are code-sharing and the number of familiar web languages out there to choose from.

The disadvantages, however, are numerous: you’re usually faced with limited native API access and slow performance, both of which result in a poor user experience (plus, you’ll probably end up with a non-native look-and-feel). In our opinion, this “interpreted” web-app approach should only be used as a last resort, only when you’re unable to use any of the other approaches.

There’s a new player in town too! Facebook’s React Native has been slowly gaining traction. It still uses web technologies, such as JavaScript, but they’re after that native look-and-feel we all love. It’s still in development and lacks in performance when compared to natively compiled apps. But that will probably change as optimizations are added and the stack matures.

The Xamarin Approach

This is our favorite of the three when it comes to cross-platform mobile development, and it’s not because we’re C# experts. It’s simply because Xamarin covers the native definition we provided earlier: the native look-and-feel plus performant compiler-generated machine code, regardless of the chosen language or technology stack.

What’s really unique about Xamarin is that they are truly all about code-sharing. Originally, you would be building the user interface separately for each platform your app supports, using familiar tools if you’ve used the siloed approach before.

But that is no longer the case with Xamarin.Forms, a library that abstracts away your user interface, allowing you to share the app’s logic and its user interface, while still keeping its native look-and-feel.


Cross-platform native mobile development has come a long way and the tools keep getting better. This is especially important because you’ll hardly come across a mobile app that is not available on multiple platforms. We recommend learning Xamarin for two reasons: one, Microsoft is heavily invested in the platform, and two, it keeps improving and that gets all us developers closer to accomplishing our pipe dreams. We also recommend looking into React Native if you’d rather use web tech. It has become the closest contender out there to Xamarin. Happy coding!🔧 💻 📱 🎉