Native vs Hybrid Apps

Tech Guide to Choose Wisely for a Badass Mobile Product.

If you start reading this guide, you’re probably looking for some insights on how and when to build a mobile application for your business. Everybody knows what a mobile app is. Mainly because more than 3.5 billion people own a mobile phone nowadays, and those cell phones host at least a couple (if not a crowded bunch) of apps with multiple purposes. To go past the obvious hardware choice, we should also take into consideration other mobile devices (such as tablets or wearables like smartwatches) that can be home to mobile applications too.

Possibilities are almost endless when it comes to mobile app development. But it’s important not to get caught in the spur of the moment. Mobile applications can be the right move for your project (or not). For B2C geo-based services like Uber, the choice seems pretty clear. But in general, for a B2B business, it looks like a web technological core with a complementary mobile app (that you can even add later on) will do the trick. It’s a wonderful and complex world out there, and at eagerWorks, we want to make sure you make the right decision. Let’s dive into the mobile universe to figure out how much mobile app development can take your business higher.

Mobile Apps: A Down-to-Earth Definition

Let’s recount some basic facts about mobile apps. You’ll probably know some or all of them, but it won’t hurt to start from scratch, so we can all be on the same page.

• What they are. A mobile app is a software unit that functions on a portable electronic device; from smartphones and tablets to smart TVs and smartwatches. It runs on what it’s called an operating system (OS). The most known and used OS in the global market are Android by Google and iOS by Apple.
• Where to find them. Most mobile devices are sold with pre-installed apps like web browsers, calendars, mapping apps, and (of course) the marketplaces where you can find a huge number of other apps to download from an application distribution platform. These platforms started to appear in 2008, and they are usually controlled by the owner of the mobile operating system. To follow our previous examples, let’s name the big ones: App Store and Google Play.
• How much they’re worth. When it comes to cost, some apps are for free, and others have a price. For the latest ones, the profit is generally split between the distribution provider (up to 20–30% of the profit) and the app’s producer. In 2020, it’s forecasted that mobile apps will generate $188,9 billion in revenue via marketplaces and in-app advertising.
• For what you’ll use them. There are a lot of different types of mobile apps with very diverse purposes. The most popular category is gaming (according to a recent study, 33% of all downloaded apps are mobile games), but not everything is Candy Crush Saga or Angry Birds. You can find apps for productivity like Trello or for educational goals such as Duolingo, M-commerce apps like the one from Amazon, entertainment apps for streaming (hi, Netflix mobile), apps to find trip accommodation (Airbnb) or to move around cities (Uber)… And we can go on like this, thinking about apps’ reasons to exist, to infinity and beyond.

After scratching the surface of the mobile app world, let’s walk you through some important (and deeper) points you need to consider before going mobile.

(A Lot of Data About) Why and When You Need to Go Mobile

Right now, almost 7 billion people worldwide are using mobile devices, and they are using them heavily: typical mobile users check their smartphone an impressive amount of 63 times a day. It seems like our mobile phones are always with us, from the moment we wake up till the moment we call it a day ( 87% of those typical users check their phones at least one hour before sleep).

Now, what do all these numbers mean in terms of mobile applications? Well, a lot, considering 90% of our time on smartphones is consumed on apps. An average American app user has around 100 apps installed on their devices, and by 2022 the consumers’ spending will increase by 92% ($157 billion), hitting the yearly amount of 258 million mobile app downloads.

Having all that said, if building a mobile app is what your business needs, you’ll be able to reach billions of people that are there and nowhere else (or perhaps they are elsewhere too, but not that deeply engaged), meaning an application can take you to the top fast enough. If you build something exciting and fresh (e.g., that kind of app that gets featured in App Store), you have quite a chance to compete and even to outrival the most prominent players in the market just with one shot.

Another thing that makes going mobile appealing is the vast universe of sensors and new technologies for smartphones. You can reach unthinkable innovation levels with an app that makes the most out of them: artificial intelligence, geolocalization, augmented and virtual reality, wearables, integration with smart home appliances, mobile payments, biometrics (facial, voice or fingerprint recognition), out-of-this-world cameras… Everything that the nearest future holds.

Of course, going mobile has its downsides. Its unprecedented impact sometimes leads people to take the wrong patch and choose to turn their ideas into apps without thinking it through. A lot of times, you can validate your product concept via responsive web development, an option that requires less fuss and time, and go mobile later. Other times, building a mobile application is (simply and straightforwardly) a bad choice for your project. Some products are not meant to become an app due to UX reasons. For example, an educational platform that requires various types of learning materials to be handled at the same time, or some informational sites that users tend to access directly from their computers — and therefore it’s improbable for them to give that extra downloading step (certainly a usability barrier) an app claims for. An application is ideal for a service you frequently use, such as Uber, Instagram, or DoorDash; but don’t even give it a try if your service is going to be used twice a year.

We suggest you to be careful and make a sensitive assessment of your needs and resources before going mobile. Building an app can be a golden shot in some cases, but it is also much more expensive than web development, as it is more complex and therefore takes in comparison a considerable amount of extra time. In most cases, you have to code in two different technologies (iOS and Android), there’re APIs involved (communication to an external server), and stores’ revision and approval processes can take up to one month. Another thing you have to take into consideration: updates. You’ll have to keep your versions up to date, otherwise, you won’t be able to upload your product’s new releases to the stores. 79% of mobile users abandon a digital product only one day after downloading it — which means that you can’t do this without proper analysis, and at eagerWorks, we can definitely help you with that too.

If after a thoughtful study, your smart weapon of choice still is a mobile app… Your journey is about to start.

Mobile App Development Kick-Off

First of all, we strongly advise you to embrace the Lean Startup approach. At eagerWorks, we have plenty of experience in this methodology that brings the best of customer and agile development to optimize processes and achieve (with the lowest cost possible) desired, useful, clean-cut products. In this sense, mobile applications are not the exception, and you are not going to regret following the Lean commitments towards sharp apps satisfaction: assume, validate, develop, measure, and pivot. Learn more about Lean Development in this article we wrote about crafting success with Eric Ries ‘ cosmovision.

Now comes the crucial moment for a mobile project: choosing between native or hybrid app development. This instance feels like The Matrix red-blue pill dilemma, but without the political-philosophical connotations. There’s no wrong alternative here if you know what you want and need precisely. Native apps are built using the specific language and tools of the platform, therefore relating directly to the device, meaning there are fewer layers between the message and the receiver. On the other hand, hybrid apps are a blend of native and web technologies, which makes them dependent on the potential of the internet browser. These differences impact on certain attributes such as performance, speed of development, and cost management, and the question itself depends on what is suitable for every case scenario. Luckily, we are going to help you figure all this out and make the right decision.

Choice #1: The Native Pill

As stated previously, native applications are written in the native development language of the OS. For example, native iOS applications’ code of preference is Swift, while native Android apps can be developed with Kotlin. As they are coded implementing the default solutions of the platform, the device’s functionalities (sensors, cameras, address books, you name it) and native UI controls and layouts are accessible at their fullest with incredible ease. Due to this “closeness to the core”, native apps tend to perform better, although the cost to pay in terms of time and resources tends to be higher. If you’re planning to play the “cool as hell” card and come up with something pretty new in the market, native is also your best choice: it’s highly probable that you wouldn’t have that much support to make an innovative app hybrid.

One important thing to consider is that any app coded in one platform’s language can’t run on another operating system. This means that you have to develop separately for each platform. If you want to release your app both in iOS and Android to reach a larger audience, you’ll surely have to spend a larger budget as well as subject your product to each respective market store’s set of rules. In the case of economic restrictions, some businesses prefer to build their iOS version solely first because it’s easier to develop and monetize. Others go for the Android opera prima because they require a more significant volume of users. We invite you to navigate each case in more detail.

• iOS Development

Let’s jump into the pool of one of the strongest players in the market: Apple. Its operating system, iOS, is the pillar for iPhones, iPads, and iPod Touch hardware. Known worldwide for being tech-elitist as well as design and security-obsessed for excellence, this company created Swift as its open-source programming language to build apps for their own mobile devices. Assuming you’re going for iOS mobile development, these are the facts you should consider:

• Having a Mac computer running the latest version of Xcode is a prerequisite. Xcode is the Integrated Development Environment (IDE), a.k.a. the graphical interface to design, develop, and debug for both Mac and iOS apps, a program that only runs on Mac OS X. It includes the iOS Software Development Kit (SDK) and specific tools, compilers, and frameworks.
• iOS is the choice for better monetization. It has a more engaged user base than Android, and demographic studies conclude that in general iOS users have higher incomes and spend more on app purchases compared to Android users.
• Swift has a cleaner code syntax (a beautiful example of this statement is that the typing of semicolons is unnecessary) that contributes to APIs readability and maintenance. In this language, protocol extensions translate into potent generics, bringing simplicity and to the point iterations. In a nutshell, iOS development can undoubtedly be more straightforward than Android’s, which means (yup, you got it) faster results.
• iOS testing is a piece of cake compared to the usual efforts required for Android testing. As the variety of screen sizes and layouts is much smaller in iOS devices, there are fewer possible scenarios to test, and the chances of bugs tend to decrease considerably. Moreover, as iPhone users are much more loyal early birds (+80% of them are up to date with the latest version), if everything runs properly on the newest device, a massive percentage of the work is already done.

Now that we’ve gone through some key points of iOS development, it’s time to tackle its well-known nemesis.

• Android Development

Contrary to popular belief, Android was not only created by Google. This open-source mobile operating system was developed by an association called Open Handset Alliance in which the tech giant takes part along with other 83 firms. The common assumption is based on the fact that Google is its commercial sponsor (so, yeah, let’s simplify and say it’s Google’s child). The programming language that serves to develop native apps for Android is Kotlin. If you gravitate towards this mobile development option, keep the following points in mind:

• One of the best things about Android is that you can develop in any operating system (Windows, Linux, macOS). Its official IDE is Android Studio, which dethroned its ancestor Eclipse due to its great functionalities, cross-platform attribute, simple packing, and outstanding debugging.
• Nowadays, there are 2.5 billion active Android devices. Despite Apple iOS holding the largest market share in the United States, Android continues to be (by far) the world’s leader with an 87% share of the global market, dominating entire continents like Asia and Africa. Its user base is immense compared to iOS’s. If you are thinking about a significant number of potential users, there’s no question here.
• There are so many Android devices out there from different manufacturers, with different screen sizes, layouts, and resolutions, that testing is quite a challenge. If you want to be sure that your product’s features work perfectly across all of them, well, get ready to invest a lot of time and effort. On top of that, it’s usual for Android devices to use only older Android versions. That means it would be necessary to test the Android API with multiple versions: to test only on the latest one surely won’t be enough to achieve a satisfactory outcome.

So, this is what you get when you take the native pill. Native development has its upsides and downsides, but you should choose this option if your app needs to run smoothly even in older devices, or if you are planning to create a product for which UX/UI design is a demanding king, like in games, AR apps or audiovisual editors.

Then, in which cases should you consider picking the hybrid way of developing? Let’s move on.

Choice #2: The Hybrid Pill

As their name states, hybrid apps are the merge between two worlds: native and web. Their heart is coded in a web technology (such as HTML, CSS, or JavaScript) confined within a native application thanks to embedding solutions like Apache Cordova or Capacitor. These cross-platform runtimes allow you to have a native shell application that operates like the platform’s web view component in which the web app is loaded. This way, instead of having an app that has to be shown in the user’s browser, you own a native app that can be directly placed on stores for sale; invisibly embedded browser aside. The magic ingredient: cross-platform runtimes’ plugin systems which admit the apps into the complete universe of the mobile device’s capabilities, transcending the limitations of a web-only app.

The brightest side of hybrid development is cost. First of all, coding for both platforms (iOS and Android) at the same time makes the whole deal much faster. And have we mentioned that all this happens with just one programming language? Yes, you’ve got it, less money invested. This is great if you want to test an idea: if it turns out to be a success, you can always migrate everything to native later. Downsides? Most of the time hybrid apps are less performant than native ones, especially in old devices. Also, debugging a hybrid app can be tricky when you are working with native access to the device’s camera or Bluetooth, for example. Another thing to take into consideration is that similarly to web-only applications, UI libraries have to be recreated. This is when cross-platform frameworks come to the rescue, providing a lot of solid UI components (pretty much like native ones). Let’s have a look at two of our favorites.

• React Native

This open-source mobile application framework created by Facebook was launched in 2015 and loved since. Keeping the story short: Mark Zuckerberg regretted leaning too much on HTML5 for developing Facebook mobile apps, Jordan Walke heard him, created React, and three years later voilá, the social network solution for great mobile experience was available for devs to use. React Native combines native development with React (a JavaScript library for top of the class UI) and, as its bold claim states: “Learn once, write anywhere”, you can use it to work on Android and iOS existing projects or to create a brand new mobile app from scratch, reusing the same code and keeping the native components of each platform. Let’s emphasize some RN characteristics:

• Development velocity. With RN you’ll work fast due to a couple of significant reasons. First, you’ll have the vast JavaScript package ecosystem at your feet, which means you’ll count on lots of ready-to-apply components for all the functionalities you can imagine (which translates into time and money saving, duh). Secondly, you’ll have the support of a growing community and one of the strongest tech companies in the world. Facebook introduces updates constantly, offering new and practical solution tools.
• Hot reloading. This also impacts on the shorter development time we mentioned before. Developers are able to implement new versions and make adjustments while the app is running, which makes changes to JavaScript code visible in a matter of seconds without rebuilding the native app. You’ll save time compiling and prevent risks of losing the state of the app while messing around. This is a productivity jewel.
• Declarative simplicity. React Native is your best friend when it comes to creating interactive mobile UI. Instead of the sequential way of native development (that requires an order of implementing actions), RN uses declarative programming which makes the code more predictable and easier to track bugs.

React Native has its cons too. The implementation of some native advanced features in bigger or more complex projects will still need iOS and Android developers with detailed knowledge of each separate platform. As it’s still a young technology, improving and changing fastly, it’s possible to find errors that will need custom solutions or workarounds. Also, let’s not forget that non-native code can make it a little bit difficult to confront device-related issues. Having all this said, we invite you to get familiar with our second selection.

• Ionic

This is another open-source mobile app SDK (software development kit) with pretty good support. It was built by the Drifty Co. crew in 2013 using AngularJS and the already mentioned Apache Cordova. But, later on, it metamorphosed into a set of web components, bringing one of its core values to life: with Ionic, you can code in the three major web frameworks of our time: Angular, React, or Vue.js. This flexibility goes even further because Ionic components can be integrated with no user interface framework at all using vanilla JavaScript.

From a single source, you can export your code to iOS, Android, and also to Progressive Web Apps technologies taking advantage of web programming languages such as HTML5, CSS, JS, and Sass. Hybrid mobile apps will be developed using these well-known UI helpers and then distributed on native app stores thanks to Cordova or Capacitor, as explained earlier. If we already have a web application that craves for becoming a mobile one, in most cases (as JavaScript is involved) it will be easy to reutilize the primary code.

Ionic developed apps’ performance can be slightly inferior to native apps’, but that’s not a problem except you’re planning to create a video game with complex graphics or a product with heavy-loaded resources. As it happens with React Native, Ionic’s youth (and consequently immaturity) makes it difficult for devs to find some solutions, although its community is also quickly rising, which makes us think that this issue is going to disappear in the near future.

No matter if you choose React Native or Ionic (or other hybrid technology whatsoever), to cut the long story short, it’s time to take the hybrid pill if you want to keep it simple. This statement can mean a lot of things: if you want to test an idea in full and fast motion that implies easy data processing (you’ll be able to work on the superior final version later on), if your app runs in a fairly small number of devices (probably for internal use) or if the application is a seasonal one, meaning it’s going to be utilized for a limited amount of time (a great example of this can be found in festival or conference apps). Leaving pills aside, now it’s time to take a closer look at the cost factor.

A Glance at Mobile App Development Cost

We have to be clear from the starting point: it’s not easy to calculate the exact cost of a mobile app beforehand. There are a lot of different things to carefully consider that would impact on the final price. Nevertheless, following the right process and making a proper assessment of desirable features can lead you to a fairly approximated idea of how much you’ll need to invest in your project. We can also help you with the maths.

First and foremost, it’s crucial to have a master design plan for your wished app. There’s no better kick-off than having features properly listed and mockups drawn at a certain level of details so that all stakeholders can see eye to eye. You’ll be solidly diminishing the possibility of forgetting core fundamentals or ignoring key information and valuable expectations from any player involved. Along with this exercise, you should also ask yourself the following questions:

• Operating system. What’s going to be the OS of my app? Is it just iOS, Android, or both of them?
• User segmentation. Who are the potential users of my app? Can I divide them into specific groups? How are their needs met by my product?
• User experience. How can I make my app attractive, accessible, and easy to use? How are the users going to navigate it? Are they going to login via email, social media, Single Sign-On?
• Functionalities. How is my app going to engage users? Is it going to have push notifications, newsletter subscriptions, a chat function? And how about other visual-demanding capabilities such as audio/video streaming, maps & GPS tracking, gamification? If it’s an e-commerce app don’t forget to consider features such as item lists, shopping carts, email confirmations, and payment options.
• Device features. Is my app going to work with the hardware at its fullest? The possibilities opened by mobile devices are endless: cameras, Bluetooth, geo-fences, AR/VR, in-device Machine Learning, accelerometers, gyroscopes, under-screen sensors… to infinity and beyond.
• And more. Other points to consider are backend/APIs integration, servers cost, admin web UI, and later maintenance requirements.

After gauging it all, you can only expect the sharpest app quotation possible with an assertive analysis on your side.

That’s (Not) All, Folks!

Diving into the mobile app matrix requires knowledgeable courage. That’s why we are here, to assist you in the pill-taking choice, if you have to. As described in this guide, never forget to start with the design stage. No matter the circumstances it will help you with the risk reduction and allow the client and the dev team to be on the same page. Another important reminder is to keep it Lean.

And don’t forget: if your app is simple (with few screens and low processing demands) and/or your budget is limited, go hybrid. If your app needs a kickass performance (due to video, real-time features, animations, etc.), its UX is king and/or you’re going for something innovative in the market (like ML or AR/VR), go native. Jump, one way or another, if mobile is the right fit for you; we have your back.

Originally published at https://eagerworks.com.