Mobile App Development

Juan Pablo Balarini • 20 OCT 2020

The A to Z guidebook to Mobile App Development

post cover picture

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. 

 

 

 

 

 

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. 

 

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:

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

 

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:

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. 

 

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: 

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.

 

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:

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.

Stay updated!

project background