Choosing the right mobile technology for your business

Which mobile technology is the right one for my business?

💡

So you own a business or you are starting a new one and it's time to move to a mobile solution that will sky rocket your revenue. You have a clear vision of what the MVP (Minimum Viable Product) will be, you also came up with a blueprint of the different screens involved and some designs as well that will guide you on how it will look. But there is one problem... you are not a mobile expert and know nothing about the different technologies to bring your app to life.

Mobile Technologies

Over the years, Since the creation of smart phones, the Mobile industry has evolved and grown incredibly fast. Even though there are plenty of technologies to choose from, pretty much all of them end up in the creation of either an iOS or an Android app as a product outcome. Let's go over some of the most popular technologies in the market.

Native Apps

When we talk about a native app or native development we mean that the technology to be used to implement our solution, corresponds to the native platform at hand, and it will only run in devices that correspond to that platform.

iOS: for the development of an app that will run in Apple devices, the technology to be used will typically nowadays be the Swift programming language for most apps, although C is compatible and Objective-C (deprecated) implemented apps still have a great portion of the current market
Android: For the development of apps that will run on an Android device, the technology to be used was initially Java but Kotlin has gained popularity over the years and both programming languages are suitable for creating native apps.

Hybrid Apps

One code to rule them all

Hybrid app development has become increasingly popular over the years. The goal with this approach in a nutshell is that with the chosen hybrid solution, we can implement a single codebase that can produce apps for multiple platforms.

So the main difference Is that while we need one codebase for each platform in native development, we only need one codebase in hybrid solutions.

React Native: Developed by facebook, It consists of three layers that compose an app, Javascript, Bridge and native. The Javascript layer uses the React library to build mobile style components
Flutter: Solution developed by Google. It consists of four layers, the framework layer that provides widgets, animations, render objects, gestures. The engine layer, responsible of rendering the UI and executing low level operations. The platform layer, interacts directly with the native platform apis, sensors, camera.
Xamarin: Microsoft's .NET hybrid solution, similar to Flutter, it offers native like performance

So which one to choose?

Well the answer is easy right? just go for the hybrid solution... , it will allow me to work on a single codebase and deploy my business in all the popular platforms (iOS and Android). Well... it's not that simple.....

What does hybrid really mean?

Well hybrid means literally hybrid. Apps that come out of any kind of hybrid solutions will consist of at least two layers.

Cross-platform part: This is the part that will involve a single codebase. It is usually based on some web technology well known by web developers that will eventually be translated into "native" components.
Native part: Ultimately each platform only understands the binary code for their architecture to be able to run an app, so every codebase has to be compiled for each platform which means that every hybrid solution needs its native side for every platform it supports.

So in reality when choosing a hybrid solution for your app, you are not really avoiding the native side of it, instead think of it as an abstraction on top of native code, that will allow you to implement some screen, and that screen, will be translated into an Android activity or a viewController in iOS under the hood, which are the native components in charge of presenting a screen.

Very nice but you still haven't answered my question.....

Totally right, let's go over the things you need to consider when choosing the right solution.

Developers expertise

Learning curve: Developers don't just grab any technology and start coding, each technology has a learning curve and some are steeper than others. Also similar to a Medic, developers tend to specialize in a certain technology. If you ask a cardiologist what's wrong with your eyes, he may have some idea on the subject but he clearly won't be an expert, same thing with developers, there is no way a dev will be an expert in every programming language or platform.
Code quality: Another important factor is how well the codebase is architected and structured. Good practices, design patterns and unit testing will increase the chances of a codebase to be maintainable and scalable over time. This is important in every codebase and only senior and experienced devs will push to follow this principles. So more important than what technology to choose, is how maintainable your codebase is. If after 3 years of bad code practices it becomes more expensive and time consuming to add or modify a feature than the revenue it will provide because the code is super hard to understand, then the technology becomes a secondary concern. That said, Hybrid technologies need extra consideration in code quality, since there will be features that you will want them to be displayed one way for a certain platform, and different for the rest, so if you don't pay close attention to good practices, you will end up with bad code like conditionals all over the place like the following code snippet.

if platform == iOS {
  // Display something specific for iOS
} else if platform == Android {
  // DIsplay something specific for Android
}

To summarize, developer's expertise is crucial. In my experience it is more valuable to be asking yourself how well architected and maintainable my solution is, over the technology it is implemented in. A codebases for each platform that is properly taken care of over time, and is easy to change may be way better than a single unmaintainable codebase

App complexity

There are many different types of apps and they all require different items to consider. It's not the same thing a video game than an e-commerce app. One will require GPU usage, fast responses and efficient memory management, while the other one may focus more on usability and security if dealing with payments.

So it may be a poor decision to go for a hybrid solution to implement a racing cars game since the efficiency will never be as good as implementing it in native code or C. On the other hand if my app is a super simple listing menu to display meals for my restaurant, then going for a hybrid solution sound like a better choice.

Your Market Strategy

Here is where you have to consider the platforms you are interested your app to be run on. If you are sure that your app needs to run in iOS, Android, Apple TV, Xbox, macOS, Web... and who knows what other platforms, then it would be extremely hard and expensive to find a team that has expertise in every native platform, then hybrid would be king here. On the other hand, if iOS and Android smart phones are good enough for you, then finding a native iOS and Android dev or even one that does both (rare) doesn't sound so crazy.

Bare in mind that the more platforms you support with the same hybrid codebase, the less customizable they become. Let's say you want to implement a list of items using a hybrid tech for iOS, Android and tvOS. The hybrid solution will come bundled with default implementations for each platform and the idea is that you don't have to bother about how this list is displayed in each of them, they will have the Look and Feel of the corresponding platform it is deployed on. If you decide you want to change this default implementations and start modifying how the list will look like in each device size or platform, then very quickly your code will become a platform frankenstein and you may be better just going native. On the other hand if you decide to take advantage of those built in implementations, then by all means hybrid can be a great idea

How do companies think?

Based on my experience, I think Hybrid solutions have become more and more robust and efficient over the years, there's plenty of documentation and tutorials out there. Pretty much all you can do in a native solution, you can also do it in a hybrid one as well, but there are those cases where you actually need to get out of the standard and that's when you will have to get your hands dirty and build your own bridge between the native and the hybrid parts. So from the technical perspective, hybrid is a good option for simple, standard solutions, On the other hand, native will give you that freedom to do anything you want as long as it is supported by the platform

Many times Companies tend to go straight to hybrid because they think that it's always going to be cheaper. The simple math they do is that with a single codebase, they would need fewer devs and still be able to have their product in multiple platforms. Unfortunately, this is not so straight forward, depending on all the variables I mentioned above, the cost of their product won't depend primarily on wether they go hybrid or native, The primary concern should be having a clean, maintainable and scalable codebase that is easy to change and adapt, without this, all codebases of all technologies become increasingly harder to understand and maintain bug free, eventually having to throw them away and start over.

Sometimes you have to see the whole picture from different perspectives and make a decision.

For example maybe your goal is to build your product in multiple platforms but your app will have some complex and non standard features that will require some native development, but your budget won't allow you to get native devs for each platform, so now you have to decide on a trade off. Either you go hybrid and simplify your product to avoid any native development and support all platforms at once, or you go native with one or two platforms at first, and when you see your product growing and have budget for more devs, you go for the rest of the platforms.

Another popular option is to build a hybrid MVP that will only take you a couple of months of development, sell your idea, get investment and when you know your idea is feasible, start over in a more robust native solution from scratch.

Conclusion

Don't decide on a mobile technology as the first thing. Make sure that whatever technology you choose, the codebase will be the heart of your product, and you will need capable and experienced devs to maintain it. That's what's going to actually reduce or maintain your costs in the long term. Once you have that clear, Sit back, see the big picture and make your decision.