If you turn to the documentation of the world’s largest IT companies, you will find that each of them sees the general mobile application development cycle in its own way. Although it seems to be one and the same process, with a lot of typical standards and management methodologies, it would seem that everything should have been brought into a single format long ago.
But it seems not. It is all much more complicated. Let’s try to make sense of this diversity.
Approaches to planning mobile application development cycles
The main problem is not so much what steps should be taken in the process of developing any (including mobile) projects, but rather the existence of different points of view on this process.
The latter depend more on the management level at which the planning is carried out than on the methodology.
A few examples to illustrate. Perhaps someone immediately realises that this is the plan they have been missing and immediately starts to implement it. This will probably mean that the plan is fully in line with your level of planning and the methodology you have chosen.
So let’s start with the IT market leaders.
How Microsoftviews the mobile application project lifecycle
By the way, Microsoft owns the largest IDE systems for cross-platform development, including Visual Studio (a suite of software solutions — code editor, IDE, testing environment and virtualisation environment), Xamarin (a dedicated platform for building mobile applications for Android, iOS and Windows), the .NET programming language (with its associated .NET Framework) and others.
In its developer documentation pages, Microsoft recommends the following approach to building the mobile development lifecycle:
- Inception — the formation of the basic idea or concept. At this stage, developers need to determine what the value of the application will be, both to the end user and to the developers themselves. It is also necessary to find out what mobile devices the software will be compatible with, what competitive advantages it will offer (whether there are analogues, what their strengths are, what your application can do to surpass them, etc.), as well as what infrastructure requirements (if any) will be imposed. In fact, at this stage the team needs to identify who will be the subjects of the interaction and what the use cases will be.
- Design — at this step you need to describe and think about the model of interaction with users in detail. Since it happens directly with the graphical interface, this is where you should concentrate your efforts. But here you need to take into account the peculiarities of platforms and the requirements of their vendors. For example, there are official guidelines for Android, iOS and Windows. The elements of input and output, navigation, placement of the main content, transitions between the main screens and much more must be considered. Almost all vendors offer typical interface layouts in their IDE systems. In addition, you can look for implementation options from competitors (no one will judge you if you take the best ideas and apply them in your project). Pay attention to the location of interface elements in different screen resolutions (tablets, smartphones) and positions (vertical and horizontal), to the presence and placement of camera and sensor blocks on the front of the device, to the system of notifications and widgets. All these are also elements of interaction with the application. You can first sketch the application layout schematically, test it, and only then move on to greater detail.
- Development — the stage of writing the backend and missing parts of the frontend, i.e. all the code that is executed after the user interacts with the application. Some of the functions and basic concepts can be written in parallel with work on the interface layout (experienced developers are very likely to be able to determine the paradigms that will be present in a particular application project).
- Stabilisation — this is actually the stage of testing and polishing all the previously created elements: backend and frontend. Again, some of the test elements can be written in parallel with the main code. This will save time and effort later. To reduce the range of potential problems, releases should at least be divided into alpha, beta and final releases. In reality, each new build may have new problems and improvements, so the cycles of subsequent releases can be endless.
- Deployment is the stage of releasing a public version of the application in which all the main functions and interface elements are stabilised. At this stage, the application should be signed and uploaded to the marketplaces of the relevant services (vendors). Each platform may have its own nuances and requirements for code design, provision of registration data, payment of fees and more.
What features Microsoft advises you to look out for:
- Multitasking.
- Hardware and resources used (not just software, but also hardware: on Android systems, you need to consider the variety of screen resolutions and form factors).
- Operating system limitations and requirements (e.g. running in the background, list of permissions required from the user, starting its services, access to special data stores, API features, etc.).
Microsoft’s lifecycle of a mobile application project is not bad. But this isnot the only possible point of view.
How developers view the mobile app lifecycle (in general terms, without going into iOS and Android specifics)
So ordinary programmers have only one way to go….
It’s funny and not far from the truth. You should understand that the only annoying factor in writing code is deadlines.
Because mobile applications run in a specific software environment, they have specific requirements: memory consumption, battery charge, rights to run system tasks, privilege escalation, need to access physical hardware (sensors, buttons, etc.). But even these are not particularly critical. The main issue is the management of active processes.
The lifecycle of any mobile application is tied to the fact that it has the user’s attention, i.e. foreground work. When the active state is lost, certain processes dictated by the operating system itself take place and nothing can be done about it. That’s why developers break application cycles into different states:
- Foreground (whether the application is active or inactive).
- Background (whether the application is transitioning to a service state or not).
- Notification handling (whether to continue interacting with the user as a service via notifications, widgets, etc.).
- Suspended by the operating system (to save power and for other reasons).
Each of these states has its own code and specific requests to the operating system API. Smooth and correct transitions without data loss are key to success.
You can read about application lifecycles in the technical documentation for the selected platforms — Android and iOS.
How managers (project managers) view the lifecycle of a mobile application development project
Classical management theory recognises a linear approach. But if we transfer the question to the level of management methodologies, we get a familiar cascade model (waterfall):
- Creation of project (application) requirements.
- Analysis and planning.
- Interface development.
- Code writing.
- Testing.
- Implementation and support.
The last stage can take an infinite amount of time.
How experienced project managers recommend building the application lifecycle:
- Formation of the main idea, the concept. This is a kind of abstract level of planning.
- Building and agreeing the framework of the project. This stage also improves the general understanding of the final functionality of the application.
- Choice of technology (frameworks, server-side implementation and other tools).
- Design and appearance.
- Direct development (backend + setting up the interaction with the frontend).
- Testing.
- Launch (upload to marketplaces, etc.).
- Support.
Some project managers and experienced customers recommend adding the following steps:
- Analysis — this is where ideas are justified and tested.
- Writing the terms of reference (as development is often done by external agencies or teams).
Even within teams, there may be specificities depending on the project management methodologies used (top 10 best):
- Creation of a task pool.
- Risk planning.
- Managing stakeholder expectations.
- Create a list of user stories.
- Selecting goals for the next sprint.
- And so on.
Experienced designers are well aware that the point of design development can also be broken down into components:
- Prototyping,
- concept testing,
- Layout drawing,
- Layout (converting layouts into real code)
- Testing again,
- Setting up interaction with the backend.
Within a project, you may need to manage requirements, source code (front-end and back-end), testing, resources consumed (especially for high-load distributed web services where a large number of virtualisation containers are leased), and additional features (helpdesk, reporting, etc.).
When there are many projects, it is necessary to manage not just one, but several project portfolios.
In lieu of conclusions
As you can see, there is not and cannot be a single universal approach to mobile application lifecycle planning. It all depends on the perspective, level of planning and methodologies used. Of the common features, we can only highlight the beginning, immediate implementation and completion — these stages can be found in any project.
You should always bear in mind that even simple plans can have complex and hard-to-implement sub-items, such as developing client and server parts, setting up integrations, load balancing and much more.
Some mobile applications may take just a week or two to develop and launch, while others may take years and involve a large number of specialists, including outsiders to the core team.
To keep track of all the projects, tasks, discussions, plans and deadlines, you need to keep track of everything. That’s why we created Projecto.
