The Economics of Native vs Hybrid Applications

This is a guest post from Michel Tobon, a senior front end developer who is passionate about mobile technologies and frontend frameworks.

 

“Write what you know”

-Mark Twain

 

How different is the economy of building a native vs a hybrid application? This piece is an analysis of that question, and not only focuses on architectural decisions I have made in my 12-year career, but it is also a bit of a memoir. I want to share the reasoning and experiences behind my decisions and insights into native vs. hybrid mobile applications.

I also want you to remember the quote above: “Write What You Know.” It will come in handy later.

The importance of the web

My University career was one of the first times I actually understood the importance of web applications in the industry. At that time, there was a very big difference between web applications for  and web applications for mobile. Your mobile site was still going to be used on a small device with no virtually no memory, slow connection speeds, and a very limited amount of data.

In one of my last courses at University, one of the case studies had the following requirements for an application:

• The application has to connect to multiple databases
• The application has to be accessible in multiple locales
• The application must run on both Windows and Mac
• The application must be mobile friendly

Some of my colleagues insisted the best solution was to just write the whole thing in Java. Our teacher – a Java senior for years – actually challenged this by stating:

“Sure, create the whole backend architecture with Java, connect data sources, aggregate data, collect metrics, etc., but create the front-end as an HTML, CSS, JS web application.”

Though surprising, his logic was quite sound. The complexities of building a desktop application (at the time) were quite high, and while a Java application would technically be able to run on any platform, maintaining the application and making sure that users are staying up-to-date with new versions is always complicated, even when you implement an auto-update feature.

However, technology was already moving toward a mobile future. At the time, Apple had already released its second generation iPhone, laptops became more accessible, Palm and Blackberry were creating devices that were rendering web applications in browsers. The industry had spoken: the world was meant to be mobile.

My introduction to hybrid

A few years later, I was working at a startup that focused on mobile applications and required apps to do tasks like authentication, using the camera, and using device GPS for location validation. 

Most clients asked for Blackberry applications specifically, and this company was proudly one of the main proponents of this technology. At the time, Blackberry released version 10 of their operating system, which included the introduction of WebWorks. WebWorks was one of the firsts attempts and an introduction to something that seems very obvious to a lot of us now: hybrid web applications.

I wanted to use WebWorks because I was and am to this day a Front-End Engineer, and I was way more comfortable building this application with web technologies than native ones. It was going to take me at least a month and a half to get comfortable writing good quality Blackberry-specific code, and more time to get the actual application built. Remember: Write What You Know.

Additionally, there were no other team members with working knowledge of Blackberry application development available, and our timeline was just one month to build it and one more to test it with the intended clients.

Initially, there were some hiccups. Management agreed to a proof-of-concept, and I spent two weeks writing the application. Seeing the app run on an emulator, management was not very happy. They were worried the application would not run, let alone scale.

The proof of concept had some issues, specifically:

• The first version of the emulator was not opening the data sources yet so the application was not connecting to our API, causing CORS issues
• The initial load of the application was almost 30 seconds
• The rendering of HTML5 elements was choppy

Management insisted that these challenges were never going to allow a web application to fully scale and serve mobile clients. They decided to start the application from scratch by moving a mobile engineer from another project and having them rewrite this application.

Then we received a real native device to play with and everything changed.

We were finally able to install and run my application, and management’s view of the project changed completely.

• The application loaded quickly
• The application’s use of the integrated GPS chip was near native
• The images rendered were crisp and perfect
• The CSS rules for responsiveness worked perfectly out of the box

In the end I can say that the application was a success, both personally and for the company.

Native vs. hybrid development cost

Now that you know my personal experiences with web, native, and hybrid, let’s analyze the economic differences between iOS, Android, and web technologies.

The salaries reported on Glassdoor for each of the three developer types are:

• Front-End Engineers: $116K
• iOS Engineers: $118K
• Android Engineers: $116K

In order to build a mobile application you would require either an engineer who writes and maintains a Front-End application with native capabilities (hybrid), or 1-2 engineers who know how to build and maintain an Android and an iOS application (native).

It is important to note that for the first case above, both platforms would be covered with the exact same code. Because of that, the development times for the final product would be equal to the development time of a single code base. If the product was to be developed in exactly one year, we could safely assume that the price paid in development had been around $116K.

In the second case, the development effort is doubled from the start. If the two developers would have built their respective applications at the same time, the total price would be around $234K USD. To maintain the smaller budget, the application would have taken roughly double the time to be delivered.

What if we just release the Android version first and the iOS version later, you might ask? That’s a risk that you have to analyze, considering which platform:

• Has a higher application competition?
• Has the biggest economic impact?
• Has the optimal capabilities to reach the target market faster?
• Represents the demographic that I am trying to target?

If you decide to build your application hybrid, these considerations go away because you can release your application simultaneously and have feature parity between both platforms, which in the long run will reduce your maintenance costs.

You built it, now ship it!

Another hidden cost of native versus hybrid applications is deployment. 

Traditionally, building, signing and uploading your application is a manual process. You write all of your code in your local environment, create the appropriate keys, and build a production binary of your application that you then have to upload to the respective store. This creates problems such as inconsistent deployments and lack of continuous integration or automated tests. 

That is where solutions such as Appflow come into play. Appflow is Ionic’s mobile DevOps platform for automating mobile builds and deployments. These types of CI/CD solutions allow you to follow best practices when developing applications. 

With a solution like Appflow, your application’s code is safely stored in your version control repository and you can add valuable safeguards to your process that are used in many large companies. These processes can be established in multiple locations of your development process.

Build: With CI/CD automations, you can apply build logic specific to the needs of your team and application. These include making sure that your code was reviewed, that your code style rules are correctly applied and enforced, and that you’ve accounted  for any vulnerable dependencies. 

Test: At some point you will need to implement automated testing. This ensures your application safely integrates with your backend systems and that given any data changes, the application continues to behave consistently. This becomes more difficult when using a manual deployment process.

Update: For mobile apps, you have to make sure that all changes reach production in all the target stores. Tools like Appflow make sure that you only have to worry about your business logic and not having to build, sign, and upload a new binary every time you make a code change.

With a more traditional CI/CD process, specifically with native applications, we run the risk of developers in idle states while binaries get compiled, signed, uploaded, and deployed. Every single hour of development that is not used on development-specific tasks has a strong economic impact on an organization. 

Because the code for hybrid apps is only web-specific code, these idle times are reduced greatly. Every time that you change your code, the web artifacts just have to be updated in the application but the application itself doesn’t really change. It will still continue to have the same dependencies and capabilities as the previous build and therefore you don’t need to stop the development process to build and test over and over again.

Write what you know

There are many more factors that can affect the economy of your product. While we’d all like to ensure we’re ticking every single box and accounting for every possible issue, it is the role of the architect to ensure we’ve ticked the most important ones – economy being a big one.  

As I’ve said, ‘write what you know’. What I know is that when it comes to creating the best mobile application for your business, there are seemingly endless means to an end. However, when it comes to creating the best possible application with minimal resources, hybrid development can be a game changer.