In a world focused on mobile apps, you’re probably guessing that building one is a straight forward activity. If you’re serious about it, you’re off for a long journey. Read on to discover a few of the choices you’re bound to make to get it off the ground.
Many companies have already started the mobile App development journey. And this journey, or more specifically, the platform you will choose to develop on, is almost like betting for any sport: you may have a good intuition of who will win, but you never know for sure.
The market is full of options, and the choice needs to take into account these factors: end user-experience, developer productivity, team learning-curve and platform (platform cost, eco-system and “survival” probability).
So, let’s introduce the types of options available for mobile development:
- Mobile Web App
These are not real Apps. These are websites, written in HTML/CSS/JavaScript and run over a browser but try to look and feel like native apps.
Pros |
Cons |
|
Cost: The development cost is the lowest possible, because you develop once and all target devices should be covered.
Maintenance: Usually the deployment is easier and it needs less updates, because the app only launches a frameless browser.
|
Offline: The application can’t run when you’re offline.
Performance: the performance of the app is completely dependent of the internet speed and the available hardware, so the user-experience can suffer from that.
Device Features: the app can’t access device specific features like: GPS, notifications, running in background, accelerometer information or complex gestures. |
- Native Apps
These are the real Apps. They are developed specifically for the target OS’s and devices, using the tools and platforms provided by the OS’s manufacturer.
So, if you want to build an Android app, you should develop in Java using Android Studio IDE and Android SDK/NDK. However, if you want to target iOS, you should use Objective-C or Swift programming languages, Xcode IDE and iOS SDK. We could go on.
| Pros | Cons |
|
User-Experience: You’ll never have a better user-experience and responsiveness unless you go native.
Device Features: You’ll have access to all the device/OS specific features, both online as well as offline. |
Cost: Unless you’re a million-dollar business, with lots of resources to spend, it’s hard to go native. You need to have dedicated teams for each OS, writing unshareable codebases.
Platform-Independence: Whenever you bet in a new OS (ex: Windows Phone), you may end up with a low user-base or even a discontinued platform. |
- Hybrid Apps
Hybrid apps are part native apps, part web apps. These apps are developed using the same technologies used by web apps (HTML/CSS/JavaScript), but they are wrapped up so that they live in the device, can run offline and access the device features. The most notorious hybrid app development platform is Apache Cordova (formerly known as PhoneGap).
| Pros | Cons |
|
Cost: Like web apps, when a hybrid app is developed, all major target OS’s are covered, so you have a single shared codebase.
Device Features: You’ll have access to all the device/OS specific features, both online as well as offline.
|
User-Experience: Due to the use of web technologies, it’s not easy (and sometimes even possible) to have a user-experience comparable to native apps;
|
- Write once, run everywhere
This kind of apps are what everybody dreams for: single codebase, native performance and UI. Platforms like Xamarin Forms promise to share nearly 100% across all supported OS’s: iOS, Android and UWP (Windows 10 and Phone 10). These platforms achieve this kind of features by compiling (or transpiling) the source code to each native target OS.
| Pros | Cons |
|
Cost: Single shared codebase across the supported OS’s.
Performance: You’ll have the native responsiveness.
|
User-Experience: You’ll have a limited number of controls available, because you’ll have the “least common multiple” of all supported OS’s.
|
When the time came, Processware had to put all these options into consideration, and decide what platform would better serve the following requirements:
-
Cost effective (one codebase for all OS’s): this would eliminate native development:
-
Dependent of device features (like GPS and Bluetooth): this would eliminate mobile web apps;
-
Performance sensitive (both network and UI): this would give Xamarin a head start from Cordova;
There was also another reason in favour of Xamarin, due to the fact that all development is done in C# programming language. For many years, Processware developed his mobile App, called xClient targeting Windows CE and Windows Mobile. This App was also entirely written using .NET (Compact Framework) and C#, so it was really appealing the fact that we could reuse some of the background components and libraries.
In mid-2016, Processware started developing its new App, called #Client (reads as sharp-client), written using Xamarin Forms platform. In practice, the App was rearchitected from scratch, so the code reuse between xClient and #Client was limited, but the simple fact that we used the same familiar tool set we use daily, like Visual Studio, .NET Framework, C# and XAML, turns the learning curve into a walk in the park. And we can tell you, the shared codebase between iOS, Android, UWP (covering Windows 10 and Phone 10) isn’t a myth.
In the next few weeks, we’ll post another article describing the lessons learned on using Xamarin Forms.
