The demand for mobile solutions has been constantly growing over the last few years. Today more people use their mobile device than their desktop. The challenge for companies is how to build a mobile solution that meets their needs but doesn’t kill their budget.

In this blog, I will provide a “brief” overview of some options for mobile development.  I’m using the word “brief” because this subject matter can easily span several books. In the future, I will post more details about each option.  For now, I will try to keep it brief!

As you can see below, there are several options that are available when developing a mobile application.  But not every option can easily fulfill an application’s needs.  Taking the time to determine the requirements of the application and the target audience (public, business partners, and/or employees) helps to determine which approach is best for development.

The landscape for mobile development has changed. Today there are more ways to build a mobile application beyond just writing Objective-C or Java. These options can be broken down into the following categories:

  • Mobile Web
  • Hybrid
  • Native

Each one of these options has its pros and cons and each requires a certain skillset. Let’s review each option in a little more detail.

Mobile Web

Mobile Web is the process of designing a website that will easily fit the form factor of a mobile device.  It uses the same technology as a normal desktop web application (HTML, CSS and JavaScript).  Web pages are loaded on a web server then they are download and rendered on the mobile device.

Mobile Web is a good platform for the initial marketing of your product(s) or business.  Today new data shows that 88% of the time users are using native mobile apps and not using their mobile web browser.


  • Quick to develop and update
  • Do not need to submit to the app store for approval


  • Need to have a good bandwidth to access the site
  • Advanced features, such as gestures and animation, can be slow
  • Limited access to functionality on the device (e.g.: CameraRoll, Touch ID, etc.)
  • Can be slow for large amounts of data and complex business logic



Hybrid apps usually use a product called Apache Cordova.  Cordova is an open source mobile development framework that allows developers to use HTML5, CSS3 and JavaScript to create and deploy applications onto mobile devices.  You can think of Cordova as a native application that contains a single WebView (e.g.: browser).  But instead of loading the web pages from a remote web server, it loads HTML, CSS and JavaScript from local storage that is bundled with the application.  Additionally, when the application needs to access platform specific functionality—such as the camera, geolocation, and contacts—Cordova offers plugins that exposed these functionalities to the WebView.

Note: Apache Cordova was originally called PhoneGap and was created by Nitobi Software. Adobe acquired Nitobi. Adobe kept the name PhoneGap but released an open source version of the software with the name Apache Cordova. Adobe PhoneGap uses Cordova but also provides addition development tools beyond the basics of Cordova.

One of the most popular hybrid frameworks out there is Ionic. It uses Cordova with Angular JS to allow for rapid development of mobile apps. It provides out of the box CSS themes to allow the application to have the look and feel of a native application. Some popular applications built with Ionic are: Untapped, iPic, Nationwide, JustWatch and more.


  • Ability to quickly and easily develop cross platform mobile solutions rapidly using existing HTML, CSS and JavaScript skillsets


  • To understand where this is coming from, you need to understand the architecture of a hybrid application.  Hybrids run inside a web browser.  Web browsers run the HTML and CSS rendering and JavaScript code in a single thread. Note: this is not 100% accurate but it’s enough to keep this blog short. For more details on how Web browser works checkout this great video and simulator by Philip Roberts. This means that only one process can run at a time (in sequence). When you deal with mobile application, features such as gestures, animation, and displaying large lists of data can become time consuming.  When you try to perform those functions in a single thread, you usually get sluggish/choppy User Interface (UI) performance.



We at Trilix categorize Native mobile applications in three ways:


JavaScript based frameworks

JavaScript base frameworks used JavaScript and CSS to build native UIs. You may be saying; what? wait! Isn’t that what hybrid apps are? The answer is “yes” and “no.”

  • Yes; they use JavaScript and CSS to help build UIs.
  • No; because hybrids use HTML to create the UI components in a browser.

These solutions use a combination of JavaScript and CSS to describe the UI, but the actual UI component is rendered as a native UI component. This means that when you create a TextInput field, it is rendered as a UITextField on IOS and an EditText on Android. That is why the word “Native” exists in React Native and NativeScript.  This allows for “most” of the UI process to happen on their own threads and leads to less bottlenecks that you can see on hybrid apps.

Note: I use the word “most” because there are some architectural details that prevent me from saying all the UI processing happens in their own thread.  It’s how a bridging technology works.  More on that in a future post.

Here is a list of some real-world application examples written with these frameworks:

  • React Native:
    • Instagram
    • Microsoft Skype
    • Airbnb
    • See more
  • NativeScript:
    • Daily Nanny
    • School Bell Weather
    • Towing
    • See more


  • Fast development time
  • Native look and feel
  • Native speed for Gestures, animation and large data lists
  • Large number of add-on modules for direct access to phone features (Maps, touch ID, etc.).
  • Similar skillsets used for web site development.
  • Business logic is easily written and updated (in JavaScript) and shared across all platforms.



  • Android development can be funky at times
  • Larger app size.
  • Need to rely on the community or yourself for add-on modules



Xamarin, from Microsoft, uses .Net, XAML, C# and F# to develop IOS and Android applications.  On IOS, the code is compiled to ARM assembly language (ARM is one step away from machine code). On Android, the code is compiled to IL (Intermediate language) and a Mono VM (Virtual Machine) is shipped with the application. The Mono VM is like the CLR on Windows.

Note: Xamarin started out as MonoTouch and was acquired by Microsoft in 2016.

There are 2 flavors of UI development with Xamarin.

  • IOS/Xamarin.Android: Each platform UI component has a corresponding C# wrapper. This allows you to use similar native UI calls in C#. With this approach, you can get around 70% code sharing between the platforms. Note: I use the word “similar” because Xamarin names the apis slightly different than their native counterparts (more about this in a future post).
  • Forms: Xamarin took native UI calls for each platform and created a generic wrapper for each one that allows the developer to write once/run everywhere. With Xamarin.Forms you can get around 98% of code sharing between the platforms. Note: I used 98% because depending on the application, you may still need to write native code to get the job done. For a list of some real-world application examples, check out the Xamarin customer showcase.


  • Full hardware support (no add-ons or plugins needed)
  • Backed by Microsoft
  • Native look and feel
  • Native speed for Gestures, animation and large list


  • App size can be large
  • Not everyone knows XAML
  • Some of the advance tools (profiler, inspector) cost extra
  • Android needs to run Java/ART (Android runtime) side-by-side with the MonoVM


Pure Native

Pure Native means using the language and IDE from the vendors that produce the platform.

  • XCode, Objective-C and Swift for IOS
  • Android Studio and Java from Android

The biggest challenge with Pure Native application development is time and skillsets.  You have to duplicate your work for each platform and used a different language for each platform.


  • Access to all features as the platform
  • Smallest code size
  • Best performance


  • Increased development time because you must recode for each platform
  • Difficult to find developers who can develop on both platforms
Share this: