If you need to understand mobile app development, you’re in the right place. This guide is for anyone who isn’t a mobile app developer but needs a better understanding of the topic. You might have a great idea for a mobile app, be a start-up founder with funding moving to the next stage, or work for a company that wants to innovate with a new app.
Whoever you are, this guide will summarise the different aspects and considerations involved in app ideation, design, development, running it and commercialisation. Not every section may be relevant to you personally, so just browse the menu and skip through to those that are.
We’ll break down what’s involved in a successful mobile app development cycle:
Why has developing a mobile application become so common? How mobile apps have changed consumer behaviour, expectations and even workplace processes.
Mobile app basics, the apps market, common mistakes to avoid at the ideation and pre-development stage, how to decide between in-house and agency development, tech stack choices and strategy, selecting a mobile app development company, costs to expect.
Common development methodologies, mistakes to avoid during the development process, the development phases.
Keeping your app running – maintenance and costs, mobile app promotion, commercialisation, mistakes to avoid after your app has been launched.
As you can see, we’ve got a lot to get through. It is a complete guide to mobile app development in 2021. So let’s get started!
We’re going to start with some basics so just skip ahead if you’re more advanced but make sure you don’t miss the common mistakes section! And there’s still plenty of interesting statistics and information on the development of mobile apps, the market for them and just how much they now pervade our lives as consumers, stakeholders and professionals.
It’s a basic question but with the intersection between mobile apps and mobile compatible or responsive apps and websites increasingly blurred, one worth briefly answering.
A mobile app is a software application designed specifically for use on smartphones and tablets. These devices run on different operating systems (OS) to laptop and desktop computers so mobile apps are designed to run on the Android and iOS (iPhone) operating systems.
Android is the most common mobile OS in 2021, with around 72% of the market, followed by iOS with 27.47. The market has consolidated over the past decade leaving only 2 dominant players, simplifying things for mobile developers and those behind mobile app projects.
It’s important to note the worldwide market share of iOS vs Android isn’t reflected in the number of mobile apps developed for each operating system. That number is much closer, with 3,482, 452 Android apps available on Google’s Play app store to 2, 226, 823.
That’s because iOS has a slightly higher market share in more developed economies than the worldwide average. And in the UK and USA, iOS has over 50% market share, ahead of Android.
Market intelligence also often tells app owners consumers who own Apple mobile devices running are a higher income demographic than those with Android devices. That makes iOS a more important market to develop mobile apps for than its global 27.5% market share might initially suggest.
20 years ago the question was “why develop a website or software solution?”
Mobile apps have had a massive influence in changing consumer behaviour patterns, business models, and processes across sectors and industries over the past decade. We’ve become so used to using them for everything from opening the smart lock on the office door, dating, booking a dog walker, ordering food, shopping and consuming media to checking in for a flight, we forget they barely existed a little over a decade ago.
The Android Instagram app was launched in April 2012 with Tinder appearing the same year. That’s not even 10 years ago. Uber launched around the same time, in 2011. Food delivery apps like Deliveroo and Delivery Hero started to appear around the same time.
Within just a few short years we’ve become so accustomed to using apps we find it strange when a business or service doesn’t have one. As of 2021:
The success of mobile apps is a combination of the fact the smartphones they reside on are permanently within reach, and that they offer a quick, convenient way to get things done.
The new format was also harnessed to create entirely new business models and ways of doing things. What % of the class of 2040 will only exist because their parents met on Tinder or another dating app? Within another decade, what are the chances real-time translation apps will have all but entirely broken down language barriers in professional and professional communication, opening up a whole new world of cooperation and collaboration? I’d say pretty high.
Within another 10 years, the businesses or processes that don’t have a mobile app will be the exceptions rather than the rule. And we’ll almost certainly have a new generation of hugely valuable, quickly growing app-based businesses none of us has heard of yet.
The rate of growth in the mobile apps market is picking up not slowing down.
Not all mobile apps are developed because the aim is to directly commercialise them as an app-based business. Apps are also developed because their use will achieve efficiencies and generating a return on investment that way.
For example, we’ve already mentioned airline apps that include mobile check-in and boarding cards. Their adoption has reduced the amount of time needed to check flight passengers in, reducing staff costs. They are also more convenient for most passengers than having to print and carry a paper document, helping improve customer satisfaction.
An app can even have a non-profit business model for a charity or foundation. For example, the World Wildlife Federation’s (WWF) mission is “is to conserve nature and reduce the most pressing threats to the diversity of life on Earth”.
The charity sees raising individual awareness and behavioural change as key to it achieving its mission. It runs several apps to that end like My Footprint, which sets “every day challenges on food, energy and nature to help stop climate change”.
Before you actually start developing a mobile application there is plenty to do. The first step is to determine if you really should develop it at all. If the answer is still positive, you have another long list of considerations and decisions to make before development starts.
Before committing the time and money required to develop a quality mobile app that stands a fair chance of commercial success, make sure you are not about to commit one of several common mistakes. If you carefully avoid these pitfalls, you’ll already be well on the way to a successful app, whatever its goals are.
The number one reason why mobile apps fail to take off is that they don’t add any value. Not every app needs to be 100% ground-breakingly original to be a success but there’s also no point in developing one that does nothing new.
Carefully consider what added value the app you have in mind will offer users compared to what’s already out there. What are your apps selling points? What does it do the most similar existing alternatives don’t? Are these features or functionalities enough to convince users to switch to your app? How quickly and easily could larger competitors replicate anything new your app does that gives it a competitive advantage?
Does it make sense to build your own app from the ground up? If it’s a general utility app for something like making bookings or other functions many businesses have, there are almost certainly apps that have been developed by someone else you can white label for the same result at a fraction of the cost.
Lot’s of new businesses fail because the founders are convinced they are solving a problem that turns out not to be much of a problem at all. Or they offer something new they think will be a hit but just doesn’t catch on.
Market intelligence company CB Insight says 42% of startups fail because there is no market need for their products, apps, or services.
When we’re enthusiastic about something it can be easy to lose objectivity. Make sure you validate your app idea before committing to its development. Creating a simple prototype or MVP and testing it with potential users is one way to do this but there are different techniques and approaches which can make sense for your particular app idea.
Our colleagues at UpTech have a great resource on how to validate app ideas pre-development.
We’ll go into this in more detail but developing a quality app isn’t cheap, even if it’s not hugely complex. And if it is complex, it can be very expensive. Even a simple app developed to a high level of quality can be expected to cost in the tens of thousands of pounds and cutting costs runs the risk of an amateurish product that will severely reduce chances of success.
Even if you have the budget to develop your mobile app to the highest standards it might not make business sense to do so. You need a business plan to analyse if the resources that will go into developing and running the app will generate enough value, revenues, efficiencies, customer satisfaction and engagement, learning outcomes, or any of the other reasons apps are developed, are justified.
How much will it cost to develop the app? How much will it cost to run the app, keeping it available and working for 100 or 10 million users? When are revenues expected to be generated? How quickly will they grow? If direct revenue won’t be generated how will return on investment (ROI) be measured?
Business plans always involve some level of guesswork. But not sitting down and carefully calculating all outgoings and incomings in realistic best and worst-case scenarios is asking for trouble.
Regardless of the kind of mobile app you plan to develop, its success will ultimately depend on getting it onto people’s phones by convincing them to download it. And then keeping them using it. That won’t realistically happen by itself, no matter how good your app is.
You need a marketing or promotional strategy and the budget to execute it at the scale your business plan estimates is necessary. If you are entering a competitive market or trying to establish a new one, that will be a major undertaking.
Even a company developing an app for employees to use or a business developing one for existing customers needs buy-in. That, in turn, will rely on a promotional strategy.
Developing and launching a mobile app is very rarely a case of just creating the app. You’ll probably need a promotional website and quite possibly a web-based version of the app too. Developing your app’s backend might also potentially be a much bigger project than its frontend.
Especially if successful, your mobile app will involve more work after it has been launched than is involved in the development and release. Mobile app development never really ends and you will have to keep on top of maintenance and continuous iterations to iron out bugs, improve usability and add functionalities.
When you are convinced you have a validated app concept, a solid business plan and the funding and promotional strategy to successfully launch it, you are ready to develop it. And the first big choice will be who are you going to trust to build it?
Mobile apps are usually either developed in-house by the direct employees of the organisation funding the app or outsourced to a company that specialises in mobile app development. Which is the better option in your case will largely depend on your circumstances.
Developing your app in-house might be a good option if:
Your organisation already employs experienced mobile app developers who have the appropriate tech stack and capacity to create your app.
If you don’t already employ mobile app developers you will have to build a team to develop your app in-house. That’s a serious undertaking and will usually only make sense if:
Outsourcing your app’s development and maintenance, at least initially, to a specialist partner, will probably be the preferred option if:
There are doubts about any of the above reasons why in-house development is a good choice.
The app will be just one part of your business and not the core revenue driver.
You want to keep your overheads down and have cash flow flexibility.
Developing and maintaining your app won’t involve enough stable workflow for a whole, permanently employed, team. Or it’s not yet clear if it will.
We’ve outlined some of the most common arguments why mobile app development might be best done in-house or outsourced to a specialised development partner but every case will be different. This article tackles the question in more depth – When Is Outsourcing Software Development The Right Choice For Startups?
The finer details of all the technologies and tools that will be used in your mobile app and its development (its tech stack) will probably be decided by your development team. But you have some big picture strategic decisions to take on technology before that point.
Mobile apps fall into 2 main technology categories:
Native apps are custom build for a particular operating system – Android or iOS. In the case of native iOS apps, they are also built for a particular hardware setup(s) – iPhones. This means they can directly access and make use of the mobile device’s processor and other parts of the hardware, like the microphone and camera.
By contrast, hybrid apps are designed to be compatible with mobile devices that run on both Android and iOS with minimal adjustments to the code, which is usually 90% identical for both versions. The downside to that cross-platform compatibility is hybrid mobile apps can’t use the device’s processor so instead rely on an internet browser.
Their access to the mobile device’s processor and more direct integration with the rest of its hardware means native apps perform better than hybrid equivalents. But advances in the hybrid app technology stack can mean the performance difference can be almost imperceptible for certain kinds of apps.
Developing native apps, especially if neither Android nor iOS users are to be ignored, also takes more time and is more expensive. The pros and cons of both options need to be considered strategically as part of a bigger picture. It’s not a simple question of:
“I don’t have the budget to develop two native apps so I’ll develop a hybrid app”.
“Native apps perform better so I’ll develop a native app”.
In practice, there are often competing considerations why native or hybrid app development might be chosen. This blog article goes into more detail on the choice between native or hybrid mobile app development.
Despite niche options that may be suited to specific circumstances, most mobile apps are developed using a handful of coding languages and frameworks and libraries based on them.
We recommend sticking to mainstream mobile development tech stacks unless there is a very good reason not to. Opting for a ‘shiny new’ alternative might sound like a good idea when pitched but more often than not proves a mistake.
The most popular open-source technologies benefit from large developer pools meaning you should be able to hire experts for years to come without too much trouble. They also have active developer communities that provide extensive documentation, can offer support if difficulties are encountered and keep improving the technology.
If you are not a tech company with a strategic reason to experiment with shiny new technologies, stick to the tried and trusted.
Until 2019, when it was replaced by Kotlin, Java was the official language for Android App Development. A majority of Android apps on the market are built in Java and it is actively supported by Google as well as a huge, active developer community.
Java’s drawback is that it is a complicated language and is made even more so when used with The Android Software Development Kit(SDK). Experienced Java developers will often, however, argue it offers more flexibility than Kotlin.
As of 2017, Kotlin is a secondary official Java language and Google instated it as the official language for Android App Development in 2019. It runs on the Java Virtual Machine and can interoperate with Java. Its strength is that it simplifies Java and is easier to learn.
The relationship between Objective-C and Swift in the context of iOS app development has similarities to that of Java and Kotlin for Android. Until the 2014 release of Swift, created by Apple specifically to be the new coding language for iOS apps, Objective-C was the default choice.
Swift was released by Apple at its 2014 World Developers Conference and was custom-designed for building software to run on Apple devices. But Objective-C wasn’t just replaced and is still supported by Apple. Both languages are used in contemporary iOS apps, often in combination, and have their different optimal use cases.
Over the past couple of years the faster, more secure Swift has overtaken Objective-C as the most used language for iOS apps. It quickly made up for earlier weaknesses compared to Objective-C and is still being improved. Objective-C is also still being supported by Apple but major future updates are considered unlikely.
There are still use cases for Objective-C and many legacy apps in the language. But with Apple promoting the use of Swift remaining Objective-C advantages will disappear in time. And there are serious question marks around how future-proofed a new iOS app developed in Objective-C rather than Swift would prove to be.
All three of Flutter, React Native and Ionic/Apache Cordova are popular, widely used technologies used for developing hybrid apps. Recently, Flutter and React Native have started to dominate as the choices for new apps, with Cordova losing some ground.
As a result, we would generally recommend going with either Flutter or React Native for most new apps in 2021, despite having a generally positive opinion of the Ionic framework/Apache Cordova combination. The recent trend suggests Flutter and React Native will dominate hybrid app development for the foreseeable future, making them a good strategic choice.
Ionic is a framework, or UI toolkit, based on either Angular, Vue or React and works in conjunction with Cordova, which provides plugins to access the hardware of the device the native app is running on.
Flutter is a software development kit (SDK) for multi-platform development and was created by Google, which means it has plenty of resources behind it. It uses the Dart 2 programming language.
For more details, you can check out our article Flutter vs React Native – Which to Choose, When?
If you decide you should outsource the development of your mobile app to a specialist partner the choice of that partner is the next big decision. Getting that choice right will be one of the biggest influences on the subsequent success of the app so it’s important to have a strong methodology for selecting the development partner you will work with.
The article linked to above offers a detailed blueprint for how to select the right mobile app development partner to build your app. Keep in mind that ‘soft’ factors can be just as important as tech stack, experience and price when it comes to IT outsourcing relationships that work.
Assess potential app development partners for compatibility with your project by considering:
Not every app development company specialises in every popular technology stack that can be used for mobile apps. If you plan to build a native app you should create a shortlist of agencies that specialise in building native apps. And vice versa if the strategic decision has been for a hybrid app.
Some companies might be equally resourced to build both hybrid and native apps. Others won’t be. The partner you would choose to develop a simple mobile app also may not be the best choice for a more complex, sophisticated project. And vice versa.
Even the best app development companies were new to the market at one point and a company being 10 years old isn’t a guarantee they’ll do a great job. But unless you are convinced by the personal background of those behind a new company, or have a trusted recommendation, there is less risk in going with a partner able to produce a pile of case studies and references on demand.
Prospective partners being evasive when asked for references, or those produced not quite convincing, can be a red flag.
Project and delivery management is just as crucial to the success of a mobile app development project as the quality of the coding. Especially if you won’t have an experienced in-house expert managing the project flow and communication with the development partner.
Make sure you ask plenty of questions about your potential partners’ methodology and get a feel for their communication standards.
An app needs to be tested at every stage of its development, including manual testing, automated testing, unit tests and code reviews. Look into the QA and software testing background and capabilities of prospective development partners.
And make sure you address the question of ongoing maintenance and support as well establishing the ground rules for the development of future iterations. It will be more efficient to establish a long term partnership with the development company to maintain and iterate on the original app than switching horses. Avoid room for misunderstandings by addressing terms for continued cooperation after the initial launch.
There are a lot of considerations to be mulled over and key decisions to be taken before the actual development of your mobile app can begin. But even if you are outsourcing development to a specialist partner you have confidence in, there is still plenty to keep on top of at this stage to make sure the process stays on track and results are optimal.
While there are alternatives such as the Rapid Application Development (RAD) model and our own hybrid model of ‘controlled agile’ (similar to fixed-price agile), software development projects, including mobile apps, tend to follow one of two core methodologies:
The waterfall methodology has fallen out of fashion but the linear model it represents was once the standard approach to developing software. It is based on the sequential phases of writing out all functionalities and requirements, and everything that supports them, in great detail.
Then the software is designed, implemented, tested and released, followed by maintenance. Each phase is completed before work starts on the next.
The waterfall methodology fell out of fashion as software applications became more complex. So many moving parts meant that it became almost impossible to account for every detail and aspect in advance. And trying to would often result in cumbersome software with poor UI.
Considerable sums of money were also regularly invested in ‘white elephant’ software that turned out not to be fit for purpose.
The agile methodology which currently dominates software development became popular as the antitode to these increasingly costly shortcomings of the waterfall approach. Agile project management SaaS Atlassian describes the methodology’s iterative approach to software development as delivering faster value with fewer headaches:
“Instead of betting everything on a “big bang” launch, an agile team delivers work in small, but consumable, increments. Requirements, plans, and results are evaluated continuously so teams have a natural mechanism for responding to change quickly.”
The agile methodology’s three core concepts of an iterative approach to development, short feedback loops, and a disciplined project management process are rooted in the principles of Lean development.
DevOps is another hugely popular software development methodology that is closely related to agile. DevOps is mainly associated with the automation of CI/CD (continuous integration/continuous delivery) pipelines. It can be easy to get confused between the two as they are often used almost interchangeably.
While it’s possible to get lost in the theory of what distinguishes Agile and DevOps, the latter practically simply means the extension of the Agile attitude and principles into IT operations – the specialists responsible for running software and keeping it available to users.
Closer collaboration between Devs and Ops teams, and releasing iterations in small chunks, helps avoid the danger of issues between how new software runs on a staging environment compared to the ‘live’ environment.
Most modern software development projects, including those for mobile apps, adopt an Agile methodology because it helps avoid costly mistakes by allowing for testing and verification of an app and its functionalities throughout the development process. This also, in theory, speeds up release times and reduces costs.
The problem with the Agile methodology is that intrinsically means it’s hard to budget for accurately as nothing is written in stone at the outset. That can be a problem if a project has a fixed budget.
Adopting the waterfall methodology is usually necessary if an app sponsor wants a fixed price offer for their app project. This can work if you have precise specifications for your app with every detail defined but is only usually advisable for relatively simple development projects.
We offer an alternative ‘controlled Agile’ hybrid methodology that goes a long way to offering the advantages of Agile while still sticking to a pre-defined budget. The software development process is broken down into sprints as in Agile but a fixed price is estimated for each sprint and locked in before work begins on it.
Flexibility is retained by the project sponsor and DevOps team agreeing on any adjustments to the functionalities, features and roadmap at the end of each completed sprint before work starts on the next.
These are some of the most common mistakes that can derail an app development process once it is underway way. Avoid them and you will be well on the way to a good, productive working relationship with your development team and a successful outcome.
The software and infrastructure behind your mobile app should be well documented. Make sure you avoid retrospectively documenting your app at the end of the development process as that invites gaps and rarely ends well. Instead, make sure detailed documentation is created as the project proceeds.
A lack of or poor documentation makes it very difficult for new developers who may work on your app in the future. That makes it harder to integrate new team members, switch agency or bring maintenance and development in-house at a future date.
Ultimately, poor documentation can cost a lot of time and money further down the road.
It’s all too easy to relax once development begins and leave the team to get on with building your mobile app. That can quickly lead to miscommunication and crossed wires that aren’t spotted on time.
Over-communication is always better than not enough communication and doesn’t have to be negative micro-management or involve too many time-wasting meetings that participants start to lose interest in. The Agile and DevOps methodologies build constant micro-communication and feedback loops into the development process.
Communication around business details like costs, when invoices are due, team staffing etc., are also vital to keeping everyone enthusiastically pulling in the same direction.
After over 20 years as an IT outsourcing and software development company, we can confidently state that successful project outcomes and sustainable partnerships rely at least as much on standards of communication as they do on technical excellence. So make sure those standards are maintained!
As the project sponsor make sure slow responses to questions and issues that rely on you don’t become a bottleneck to progress.
When does IT Outsourcing work?
(And when doesn’t it?)
It’s a bit of a cliché but has become one because it is absolutely accurate – successful projects are not those that don’t encounter problems along the way but that effectively deal with them when they inevitably come up.
I’m Scottish so will take the opportunity here to slip in a line from Robert Burn’s To a Mouse!
“The best laid schemes o’ mice an’ men / Gang aft a-gley.”
Which translates into today’s English as:
“The best laid plans of mice and men / often go awry (wrong)”
Make sure it is clearly defined how anticipated problems are dealt with and who is responsible. What’s the backup plan if a key developer breaks a leg halfway through the development process? Or receives a dream job offer and leaves the project at short notice?
And make sure unanticipated problems are reacted to quickly and in a constructive way.
Even if your mobile app is being developed to a purely Agile methodology which intrinsically means there is no hard deadline for completion (the app is released as soon as possible and then iterated upon) it is still crucial to stick to sprint deadlines.
Make sure everyone is committed to meeting deadlines and quickly react to any sign standards are slipping. One missed sprint deadline can quickly snowball down the project timeline.
What are the standard phases of the development process you can expect your app to go through?
This is technically in the pre-development stage but you should always verify an app idea by confirming the need and demand for it before investing time and money in realising the concept. For ideas on how to get proof of concept before commissioning your app, refer back to the ‘validate your idea’ section of the pre-development phase earlier in this guide.
Unless you are absolutely convinced you can define every detail of your app’s functionalities, features and design before you launch it (a very rare scenario) your first stage of development will be an MVP (minimum viable product).
An MVP is the version of your app with the fewest possible functionalities and features while still adding value for users. So you need to really boil down your ideas and ambitions for what the app will eventually do to the bare bones. An MVP should only include the features and functionalities without which the app adds zero value compared to its competition.
Or if there aren’t direct competitors, only include the features and functionalities without which it won’t offer any value.
MVPs can be defined at a design sprint or workshop involving all stakeholders (including users).
You can also create an interactive prototype that looks like the final product (at least in terms of basic layout and functionalities) and can be trialled with real users. There are plenty of tools and techniques to quickly and cheaply build an interactive prototype of your app’s MVP.
Use the feedback you gather at this stage to confirm or tweak your MVP.
Once you’re confident you have a validated app concept and defined MVP the main initial development phase can get underway. If you are working to a waterfall methodology, consider the previous step where you religiously detail every aspect of the final app. And this step the build phase.
Whether you are building an MVP or ‘completed’ app, this is the stage the pre-launch development is completed. It will usually follow a format something like:
If you’ve been developing your mobile app to an Agile methodology, the launch of your MVP is the beginning of the development process, not the end. Even if you’re confident your app is more or less complete at this stage because you’ve built it to a waterfall methodology and/or it’s a relatively simple product with no plans for it to be extended, you still need to keep it running smoothly.
If you have launched an MVP the next steps in the iterative development process will be:
If we consider a mobile app as a self-contained business, it often is but even if it has a support function the analogy holds, it’s obvious that the app itself is not enough for the business to run. Every business needs customers and every app needs users. And they need to know it exists and be sold on using it.
Getting a mobile application onto phones is the first step. The second is encouraging its use.
The best marketing and promotion strategy to achieve that will vary hugely depending on what kind of app you have developed. If your app is adding value for existing customers, you have the head start of an already open channel of communication and, hopefully, brand trust.
Or your app might be for internal organisational use. That’s probably the easiest kind of app to promote and get people using but should still not be underestimated as a challenge. You will still need an effective promotion and follow-up strategy.
The hardest kind of app to gain traction with on download numbers and ongoing engagement is a commercial app. You will have to make your voice heard above the noise of thousands of apps all competing for user attention.
The challenge will be slightly different if your app is entering an already crowded marketplace of competitor apps with the same target audience compared to if you are offering something relatively unique. But neither is an easy nut to crack.
In the first scenario, your job is to convince potential users your app adds value compared to existing rivals they may already use. And then the app has to deliver on that promise to stay on mobile devices and be engaged with.
In the second scenario, your job is to convince potential users why they need an app that offers what yours does. You have to communicate the problem you are solving or the utility you are providing.
Like any kind of marketing to an audience constantly being bombarded by marketing, getting mobile app promotion right is a real science. Some of the more common activities and strategies involved are:
A mobile app still needs at least a basic website it can be downloaded from, or which directs users to Google’s Play store for Android apps or the App Store of iOS. Unless there is a web-based desktop version of the app, that will often just be a single landing page.
But that landing page has to do a great job of convincing anyone arriving at it to download the app. The design and layout have to be optimised for conversions and the copy engaging and convincing. Arriving at a landing page formula that optimally converts visitors into mobile app downloads is almost always a process and an important one to approach correctly.
You’ll need to make sure your mobile app is highly visible in Google Play and the App Store so it is found easily by anyone searching for it specifically, or more generally looking for an app like yours. App store marketing has become a marketing discipline in its own right and you’ll need to make sure you have someone on board who can make sure yours is prominently placed.
If your app is commercial, especially if it’s in a competitive space like mobile gaming or e-commerce, you’ll need the same kind of multi-channel marketing campaign that would be necessary for any new business to gain traction quickly.
That might include everything from SEO and PPC search marketing and social media marketing to working with influencers, a PR campaign, guerrilla marketing techniques, rewards for users who invite new users and good old fashioned billboards and placements on public transport.
Your budget and app’s business model will heavily influence your marketing approach and mix of channels but whatever the circumstances, a well-run marketing campaign will be key to gaining downloads and users in the numbers you need.
Not all mobile apps are built to directly earn money. You might be building an app for a connected IoT device, like a smart fridge or central heating system, in which case the app is a functional part of the product. Or it could be a booking system for the customers of a plumbing business or hair salon.
These kinds of apps earn a return on investment indirectly by improving the overall quality of a product or making things more convenient for customers. But you can also this kind of app to upsell to customers by pushing information on offers, new products and services etc. Even if the app is not a ‘business’ itself it is a direct communication channel with its users. That is a hugely valuable quality that should be made the most of.
For mobile apps developed to directly generate revenues, the main monetisation models are:
If your app is free to use and offers added value, users will tolerate some level of in-app advertising. You can either sign up to one of the big mobile ad networks like Google’s AdMob or try to go it alone with direct agreements with advertisers if your app is popular enough. But be careful you don’t violate Play and App Store policies. They take a non-negotiable 30% cut of all revenues generated by apps downloaded from their stores.
Ad tech platform Smaato has a useful guide to in-app advertising.
Free apps that monetise through in-app ads can also offer users the option to pay a small fee for an ad-free version which can become a solid source of revenue.
Freemium apps work to a model that allows anyone to use a version with limited functionality for free but need to pay if they want to use the full functionality. For example, a fitness app might offer one or a limited number of exercise programmes for free and charge for more to be unlocked. Or for other value-added functionalities and features.
Most mobile games operate a freemium model that means they can be played for free but paying for add-ons through in-app purchases accelerates progress or unlocks new levels.
To make money from data an app has to have a lot of users. But there are examples of very successful data licensing business models from apps like Waze and Foursquare.
E-commerce apps monetise by selling products in almost the same way as an e-commerce website would. An app simply offers shoppers a version of the main website that is more user friendly
That brings our complete guide to mobile app development in 2021 to its conclusion. You should now have a strong general overview of the mobile app market and the stages involved in deciding to develop a mobile app, the pre-development phase, development and then launch.
I hope you now have the foundation you need to avoid the most common pitfalls of app development and now have a checklist of everything that has to be considered and decided throughout the various stages of the process.
And if you’d like to talk to our experts about an upcoming mobile app development project, we’d be delighted to hear from you. Just drop us a line for a no-obligation chat.