Stages of Mobile Application Development

Before you start development, please tell me, are you ready?

This is not going to be an easy journey. There will be ups and victories, but stress and worries cannot be avoided either. Even after seeking help from Brander, you can't be indifferent and passive in such a large-scale project. We advise you to weigh the pros and cons before starting a project. This article will help you look a little into the future and prepare yourself for it. The good news is that in the future, you have an app!

Getting to know the inner workings of a business is just as important as having terms of reference. We are developers, but we have to realize the details. For us, it is the specifics of the client's business. We keep our main focus on the following points:

1. The future mobile app should solve the client's pain. If you are not aware of the consumer's problems, we have a lot of work to do. Depending on what our marketers learn about your customer, the goal of the project may change. It may not be global, but a change in focus may be necessary.
2. When the "competitor" variable remains unknown, the work goes with a bang and a squeak. The reason for this is the constant internal question: "What if it doesn't work?". After spending a few days studying the competitor and his methods of work, the question closes by itself. Setting goals for an application without knowing the capabilities and plans of competing companies is a brave, but foolish, act.

The customer should have a clear answer to the question of why he needs the application and how he plans to use it. We recommend stocking all the answers in advance, without wasting the parties' time on unnecessary discussions.

We are not lazy to do the work of getting to know your business, so further development becomes many times easier. The stage of preparing the terms of reference begins. With this document we will close all questions of the client about the order in which the work will take place, how long it will take and how much it will cost. Brander belongs to the TOR fan club, so we have a short list, from which it becomes clear what a TOR is and why it is necessary for the project.

The list itself:

1. We study the company's experience. If the application being developed is not the company's first product, you need to check the systems within the company. If the application and website need integration in the future, it is our responsibility to know all the development details. The business analyst forms suggestions based on applications of similar functionality and required actions. We will then take the strengths and discard the weaknesses in the project.
2. Design. The client voices his wishes on the appearance of the application, and we note for ourselves how comparable it is to the stated functionality. Don't be upset if you have to choose another design. Don't worry, radical changes in the work plan will be avoided if you stick to the balance.

Scenarios. We will plan several groups of scenarios for users. This will give an understanding of how the application will be handled by a representative of your CA. Such preparation allows you to look deeper into the functionality and technological potential of the application.

4. Target audience. In the terms of reference, we give the audience a weighty focus. The marketer and business analyst get to know the audience's peculiarities, its habits, right down to the customer portrait. Awareness of such nuances critically reduces the possibility of a fail.
5. Technology. It would be strange if we didn't discuss this point in the terms of reference. There are native and cross-platform applications. The former are developed separately for Android or iOS, the latter have a single code for both systems, but lack unique features.
6. Final stage. Being in the final stage, the terms of reference are repeatedly checked by our specialists and verified with the client. Sometimes it happens that during the development process, details are lost behind the global picture. The final stage of the terms of reference allows you to avoid mistakes.

A prototype is not yet an app, but it's no longer the absence of one!

We have some weighty ways on how to make a prototype that a client will love with all his heart and integrate into his business afterwards.

Navigation

It's best kept at the bottom of the screen, just like the controls. It will be easier to navigate from there, the client won't get confused, and even at the prototype stage will understand how the product should work.

Logo

The client may not understand design, but they can immediately see if its basic principles are not followed. Having analysed hundreds of clients, we have come to the conclusion that the logo on every page of the application pisses off clients the most. We recommend limiting yourself to the start screen and the contact item.

Unobvious

You shouldn't place elements too close to each other, tooltips should be readable and noticeable. If navigation buttons are close one to another, the user will press several buttons at once.

Screen Position

Customers often don't ask this question, but Brander doesn't forget the remark. Will your app be vertical or horizontal? Maybe both? Don't forget to specify this at the prototype approval stage.

And here comes the sweet spot!

Once the TOR and the initial prototype are approved, our coders take over. The process is divided into two camps: Front-end and Back-end, client and server side.

iOS

Applications for iOS devices are written using Apple's guidelines, as well as new frameworks and APIs. Namely, either UIKit or the newer SwiftUI can be used to write the GUI, depending on the project. In terms of interacting with the device's sensors and gauges, the CoreLocation system framework is used to get the user's geo-position as well as navigation. Maps are displayed, both standard iOS and Google Maps. For more accurate navigation inside buildings, where geo-position may not be determined accurately, we propose to use BLE technology to accurately determine the user's position and navigate to the final destination inside the building.

As for working with the latest augmented reality technologies, we use the ARKit framework to interact with the surrounding world, which allows the camera to map additional objects into the surrounding space and interact with them.

Due to the increasing need to offer the user quick access to key application functionality without direct installation (for example, to order a cup of coffee via QR in an establishment), our portfolio includes projects that use AppClip to provide such capabilities.

To address the issue of user data security, a combination of encryption and secure data transfer methods are used on both the mobile app and server side. In addition, biometric access (Touch ID and Face ID) is used to further protect the applications.

Various payment methods, interaction with Wallet — this is something that has already become commonplace and is almost always present in our applications.

It is also worth noting our experience in creating apps for Apple Watch and desktop apps for macOS.

Android

Programming languages:

• Java;
• Kotlin;
• Dart.

Frameworks:

• Android SDK;
• Flutter;
• Compose UI;
• Android Support Library;
• Firebase;
• Google Maps SDK.

Dependency injection:

• Dagger2;
• Koin;
• Hilt.

Data storage:

• Room;
• SQLite;
• Content providers;
• Shared Preferences;
• REST API.
• Version control — Git.

Other tools:

• Gradle;
• OkHttp + Retrofit2;
• Glide/Picasso.

Front-end

Each element is prescribed separately in the code. The developer of this camp wants a full list of feedback from the client: whether they use the camera, geolocation, access to personal data. They are responsible for implementing user scenarios as well as the usability philosophy. They are the ones who screw on swipes and scrolls that are pleasing to the eye and fingers.

Back-end

How fast your app runs will reflect its popularity in the future. Studies show that more than 70% of deletions are due to slow performance. It is precisely the back-ender's responsibility to establish communication between the application and the server side. This is often the most time-consuming and costly process.

Once the app is ready, it needs to build a comfortable home in the App Store and Play Market. This stage is less stressful than the previous ones, but there are problems here too. Let's imagine scary messages like "Your app does not comply with shop policy", "Content is not copyrighted and violates the rules". Why introduce them? They can come to your inbox and ruin your mood. We promise to keep your spirits up. To that end, the traditional dub check of work done, and shop policies happens before launch.

We hope we have been helpful. This article is aimed specifically at taking care of the customer and explaining the workflow. Our team believes that this knowledge is vital not only for developers, but also for those who pay developers for their work.

Thank you for your attention!