The definition of mobile application development can be broad—encompassing all the processes involved in the creation and release of a mobile app—or specific, referring to the coding and deployment of the app. This article will cover both definitions of mobile app development and focus especially on defining mobile app development for people who make decisions around or are responsible for how the software itself is built.
To define mobile application development, we should start by defining mobile, which in this case refers to portable electronic devices such as smartphones, tablets, laptops, smart watches, e-readers, and handheld game consoles. By application, we mean not only the software native to those devices, but also the common operating systems, platforms, and languages that those devices support. As you'll learn, there are many different ways to approach mobile app development and many decisions to make.
Organizations spend anywhere from three months to nine months—or longer where required—developing mobile applications. The scope and features of an app all influence the timeline of the mobile app development process.
The mobile application development process begins with understanding why a mobile app might be a good solution to a problem or approach to an opportunity—and then deciding what to build and how. In the strategy phase, organizations will establish the app's objectives and measurements of success, analyze the market and the competition, research their customers' needs, and determine which users and use cases the app will serve. In the strategy phase, organizations might also begin to explore which mobile app development platforms would work best with their goals and requirements. It is at this phase that organizations also begin to consider the marketing around the app's release.
In the planning phase, organizations agree on four key details of the mobile app development process: the teams, tools, technologies, and timelines. By now, they have an idea of what type of mobile app they need to build, who will be building the app, and which platform or platforms they'll use. During this phase, organizations will lay out a product roadmap—decide which features will be built in what order and by when—set milestones, and design a project plan that will allow them to meet their intended release date. Knowing what resources and expertise are available along with understanding how to implement the technology chosen for the process are vital for determining that date and achieving the release.
The appearance, features, and function of the mobile app begin to take shape during the design phase. In this phase of the mobile app development process, teams will chart the user experience and create the user interfaces and the states of the app at various fidelities. They may begin with low-fidelity mockups to provide proof of concept or gather customer feedback at an early stage. Developers and engineers may help create prototyping or consulting on UX and UI decisions at this phase—keeping teams aware of the requirements and technical specifications of the platforms the organization has elected to use. This way, organizations when move to full-fidelity screens, they've designed an app that can truly be built.
The word development in this context sometimes refers to the full software development lifecycle involved in creating and releasing a mobile app. More commonly, though, development means this software development phase of mobile app development. We will define this phase more fully later in the article. For now, this phase is best described as the step in which teams establish the technical architecture and technological stack—including the front end, back end, and APIs—set development milestones, determine the development lifecycle for the app, and code the app.
Testing is a crucial phase of the mobile application development process. Without testing, organizations cannot be certain that their app will be secure, work the way that users need and expect it to, and function where they deploy it. During this phase, teams provide quality assurance, creating test cases to assess the usability, performance, stability, and security of the app on all the devices the app is intended to run on. Organizations will often stress-test the app to ensure that the application's architecture can scale to meet sudden heavy demand.
The final phase in the mobile application development process is release. Once the app is deployed, the organization provides support to customers using it and ongoing monitoring and maintenance to ensure the app is available and performing as it should. Marketing campaigns and motions to encourage adoption of the app often coincide with this phase. If the organization decides to make enhancements or alterations to the app that go beyond the scope of changes their development lifecycle is equipped to handle, they may decide to begin the mobile app development process anew.
This first task of the development phase is to establish technical architecture of the mobile application. Often confused with technical stack—which includes the front end, back end, and APIs—technical architecture is the rules and patterns that govern the development of the mobile application.
The technical architecture is often conceived of in three layers:
This is the layer of the app that the customer sees and interacts with. The presentation layer includes the user interface and all the elements of the app that make up the user experience.
The logic that governs workflows, data exchange, and operations resides in the business layer. Core aspects of the mobile app such as security, caching, logging, and exception handling are handled in this layer.
The data layer serves the requirements of the application itself, providing data utilities, data access components, and helpers or service agents. It's also the layer that validates and maintains data and supports data transactions.
Similarly, the technology stack—or tech stack—also consists of three pieces as mentioned. However, these pieces represent specific choices used to build and support the app rather than guidelines for its creation.
Corresponding closely with the presentation layer, the tools and languages used to code the front end of the mobile app depend heavily on the devices the app will be deployed to. There are many options, and most mobile devices have specific languages that are native to them.
The back end is the part of the app that includes the database and other similar objects that reside on a server and support the functions of the mobile app. Teams are less beholden to the devices when it comes to choosing mobile back-end technologies and can often find pre-built back-end solutions.
The app communicates between the back end and the front end through the API—which also enables the app to integrate and interact with other apps and services.
However, before teams can choose their tech stack—or even establish their technical architecture—they first need to decide what type of mobile app they're building.
When it comes to developing apps for mobile devices, organizations have several different types of mobile apps to choose from. In this case, mobile app type refers not to what the app will allow its users to do but how the app will be built.
Apps that are specific to a certain device or platform—such as Android or iOS—are called native apps. These apps run directly on the operating system of the device, use the languages and frameworks the platform provides, and are deployed through the store or marketplace specific to the operating system. Native apps typically have full access to all the features and hardware of the devices they run on.
Teams can code in app in the languages and frameworks of their choosing and then compile the code for each operating system the app is intended to run on using platforms like Xamarin. Cross-platform apps, as these are called, allow teams to run on many different devices and reuse a large portion of the code—though bridging the code requires more work than developing for just one platform.
Like web applications, progressive web applications run in mobile browsers and are typically built using JavaScript, CSS, and HTML5. What makes web apps progressive is their ability to provide push notifications, better touch gestures, and hardware interaction using advanced browser capabilities. There are no SDKs to help build progressive web apps, but they can be deployed without going through a marketplace.
A mix between native apps and progressive web apps, hybrid apps are essentially natively coded containers that run web applications. This combination allows the app more access to the features and hardware of the devices and run on more types of devices—all while keeping a single codebase. For all their advantages, hybrid apps typically do not achieve the performance that other types of mobile apps do.
The type of mobile app an organization chooses to build has heavy implications over the tools, platforms, frameworks, languages available to their teams, the distribution of the app, the number of codebases to maintain, which devices the app will run on, and even what the app can do.
As you decide which type of mobile app to build, it is helpful to consider who your users will be and what they need from the app. For example, if they use mainly one type of device or operating system, a native app might be best. Apps that don't rely on hardware sensors or GPS may be well-suited as progressive web apps or hybrid apps—but perhaps not if your users don't have good connectivity. If your users are members of your business or organization, you may want to consider a different mobile strategy. And of course, it all comes down to the expertise you have available within your organization or through a partner.
This chart outlines more of the differences and similarities between different types of mobile apps to help you consider which type of app you should develop.
| Native apps | Cross-platform apps | Progressive web apps | Hybrid apps | |
|---|---|---|---|---|
| Number of codebases | One per platform | One, but compiled for each platform | One total | One for the app, another for the container |
| Languages and frameworks | Native only | Team's choice | Web only | Web and native |
| Access to SDKs and APIs | Yes | Yes | No | Limited |
| Performance | Highest | High | Lowest | Low |
| Access to device hardware | Complete | Most | Very little | Some |
| Responsiveness to user input | Good | Good | Worst | Poor |
| Interactivity | High | High | Lowest | Low |
| Device resource use | High | High | Low | Medium |
| Requires connectivity | No | No | Yes | Yes |
| Cost to build and maintain | Highest | High | Lowest | Lower |
| Where the app is stored | Device | Device | Server | Device and server |
| Deployed through | Marketplace | Marketplace | Browser | Marketplace |
| Requires outside approval | Yes | Yes | No | Yes |
Once you've decided what type of mobile app you're going to build—or perhaps as you're considering which type—you'll want to evaluate mobile app development platforms. These are the app development platforms you'll use to develop, build, test, debug, manage, and in some cases even deploy mobile apps throughout their lifecycle. Most app development software includes front-end tools to build the interface, back-end tools to handle data, API tools, testing tools, and tools for collaboration and code analysis.
Most mobile application platforms aim to provide everything a developer needs to build a mobile application. This allows developers to avoid issues moving between different pieces of mobile development software—and dealing with issues that arise between them, such as code integrity, incompatibilities, and data loss. Mobile app development platforms also reduce the cost, time, resources, and expertise required for an organization to create a mobile app. While a few organizations choose to build their own platforms, many more opt for one of the many app development alternatives available.
The best mobile app development alternatives for an organization use vary based on what types of mobile app they intend to create, what languages they can code in, and what devices they want to serve. Some mobile app development alternatives include:
