Different Options

When developing software, whether it’s for a fun project or a formal business project, a requirement can be met by many different options and technologies. After a while of looking at many, it is natural to think which is the best option for the requirement.

Let us consider the options for building a mobile application.

Sometimes the best option is determined by the compatibility of the implications of the option and the technical strengths of the development team. (I’ll cover implications a little later)  The first option to consider when building a mobile application are native applications, but it immediately raises a warning – when the code for a platform is done, the code will need to be transcribed to another platform.  Second, every native technology has its own implications. So to have a successful mobile experience in all native platforms, a developer for each platform is needed.

Even if there was a developer for each platform, is it worthwhile to develop a native mobile application for each platform instead of modifying a web page so it can be viewed in any device?  This is an important question to consider so here is a comparison chart for key characteristics.

Based on this comparison, it appears that a native application offers a wider range for creativity and service options. If the development team handles all the implications for every platform then it might be a good idea to develop a mobile app natively for each platform, considering that native applications have the best performance and assuming the business is willing to pay a higher cost.

Let’s talk more about those “implications”.

Implications

When dealing with software frameworks and APIs, each framework works naturally with the programmer at least interacting with (in others mastering) certain technologies or programming languages. This comes naturally if the framework is an extension for another technology.

For example, consider Node.js, a JavaScript runtime. When using Node.js, being a JavaScript runtime, the code will naturally be programmed in JavaScript language. Therefore, working with Node.js framework implies the programmer knows, or can at least interact with, JavaScript language. We’ll call these framework dependency implications.

Following are some implications for some mobile application frameworks.

There is another cost that is not visible at first glance.  Even though the different platform projects have the same core and logic, ultimately they are individual projects. Each project has a different language and application lifecycle and SDKs, so each project will also need its specialized maintenance. This can all add up.  If creating the application natively appears to be too expensive or the development team does not handle all the implications, another strategy can be used.

Using a cross-platform technology has become very popular as a hybrid solution for mobile development, so you can write one set of code that can be used on multiple platforms and can give the user a native experience. There are many cross-platform mobile app technologies, each with it’s own implications. The strategy is to pick technology that has an implication that the development team masters, plus another consideration. Since this is cross-platform, it is important to choose a solution that has a large percentage of transcribing code; the code that can be written once and run natively across the platforms.

My Experience

When I decided I wanted to develop mobile apps, my first thought was “What native technologies do I know?”

I had used Objective-C for an iOS application.  If I wanted to make a native android or windows phone application, I’d have to learn about project structure and app lifecycle and hope I could program in the language they used. Since I only knew one native technology (iOS) I decided it was better to invest time learning a cross platform technology.

I then thought “Now if I’m going to use a cross platform technology, what implications can I handle the best?”.  Xamarin was a natural choice for me, thanks to the language and application structure.  C# is one of the languages I handle the best, plus the structure was intuitive. An .xml page with its back end code, the application lifecycle was also C-like. I managed to learn XAML and the app structure and lifecycle quickly.

Later, I discovered that Xamarin generated native apps that shared 95% of the common code. I also got to an acceptable level of understanding in android and iOS native applications. Then I decided to test Xamarin’s generated native projects. It seemed that the native applications were greatly structured and coded. I thought “Wow. In theory, it is possible for someone to develop a full native Android app without knowing Java or the android app structure or even having the Android Studio”. Another plus for cross-platform technologies comes from the abstraction layer.  When using Xamarin, the code handles mobile events (like Swipe) in Xamarin’s way.

I can code once and use these events without even knowing how to do it the native way.

I decided it was a good idea to take full advantage of these generated projects and tried making everything in Xamarin, because some things are not implemented on the framework. For example, Xamarin has no radio button tag for iOS applications. Instead of modifying the generated iOS application and using Apple’s radio button, I decided to implement my own radio button in Xamarin, which rendered natively in iOS. This seemed like a good choice that would become an advantage, but I also found a disadvantage, when making a minimum change on a Xamarin project, it must be recompiled to see the changes on the device. This can be time consuming if one wants to test various changes.

Conclusões

I decided to use Xamarin to build mobile apps because it was cross-platform. So most code would only have to be written once. And the projects generated by Xamarin were native. This is not the case on every cross-platform technology. The fact that the final projects are native is an advantage since mobile characteristics can be used.

Still, I studied native projects for Android and iOS to be able to modify the generated projects if something can’t really be done on Xamarin (I realized Xamarin does not support everything for every platform). Again, this can be done because Xamarin generates native projects.

In other words, I take advantage of Xamarin to reutilize code and generate fully native platforms to the extent it permits me, but I also know how to do it without Xamarin in case I really need to modify a native project. Xamarin’s implications are my strengths in programming. This is how I determined Xamarin was the best option for me when it comes to developing mobile applications.

It is important to note that the best option is a balance between the technical strengths of the development team and the implications of the technology. Xamarin with native platforms background was the best option for me, but I have a C# background.  Another developer could have worked faster with Ionic if, say, the developer is a master in AngularJS.