Mobile App Development Process at Rosberry — Things You Need to Know
The main thing every client should remember about mobile app development is that it usually requires a good deal of time and money.
In most cases, a mobile application is an auxiliary tool. You should start thinking about having it in place if you are sure that users will get a clear-cut set of functions they will use with unfailing regularity: newsfeed, communication, data retrieval, etc.
Use frequency is very important as app download and installation, as well as sign-up and profile creation, take lots of time and the app itself requires certain storage space on your smartphone. If the service implies a one-time or occasional use, you’d better opt for a website.
Making a decision to develop a mobile app you should clearly see and understand the feature-set as well as the value it will bring to the users.
Another constraint our clients are not usually aware of is the price tag. App development is a costly process, so already at the initial stage, you should gain perfect insight as to the size of the target audience and possible monetization options. A good app should not only cover the development expenses but also generate profit. So, the first friendly advice we give to our clients is to start with the so-called MVP (minimum viable product).
An MVP is an app with the core functionality which could meet the basic needs and expectations of the prospective users.
An MVP approach definitely mitigates lots of risks: you invest piecemeal, the development timeline becomes shorter, you get the users’ feedback faster. Moreover, opting for an MVP you can pilot test the development team and understand if it comes up to your expectations.
After launching an MVP you can get a better idea of future updates and enhancements, complementing the app with the features the target audience really wants and needs.
Being about to start a development project you should remember one thing — the more involved you are into the implementation, the better the final product will be. In our case, each and every client always becomes a Rosberry team member which makes the whole collaboration even more transparent.
That said, here is the process you will be a part of:
- Discovery & Inception
- Visual Design
1. Discovery & Inception
At this stage, we define and describe the target audience, write the app use case scenarios, develop a Customer Journey Map from the moment a user learns about the application, and to achieving their goals. All this lets us both understand the needs of the future users to the greatest possible extent and also flesh out a so-called Project Roadmap.
A Project Roadmap is the description of the long-term app functionality development vision — some kind of a high-level plan with the preliminary milestones in place.
Moreover, at the Discovery & Inception stage, we come across a huge number of interesting business, organizational and technical tasks, as well as functional features of the application, which our clients have neither suspected nor thought about. Thanks to the collaborative work the designer, the product owner, and the client understand what they will get in the end. They understand it in every way: functional, time- and cost-wise.
The key figure of this stage is of course a UI/UX designer. S/he works through the navigation lays down the basic elements of each screen and their arrangement. As a result of this we have the app wireframes but without the visual content: colors, icons, animations, fonts, etc. Elaborating the wireframes we focus on the logic itself — the way a user will interact with an app.
3. Visual Design
Upon completion of the wireframing stage, a UI/UX designer gets down to the visual design. S/he defines the color scheme, chooses fonts, draws icons, picks out and processes photos, thinks through the animations, and micro-interactions. In the end, a client gets a whole bunch of mobile app screens ready for development.
Documenting as the next step mediates between the design and coding stages. The key players of this stage are a developer and a tester. Together they describe the whole app functionality as presented by stories and scenarios through the lens of how the programmable product should behave. The BDD methodology (Behaviour-Driven Development) which is the mainstay of this approach, allows to optimise both the future development and testing processes.
To better understand how to use the app, as a user, I want to be onboarded.
A user sees the first welcome slide with an instruction.
Given: a user has never launched the app
When: the app is launched
Then: a user sees the welcome slide
A slide indicator is in position one.
Besides, BDD-scenarios provide for more accurate project estimation and the resulting estimate can really be considered final.
Of course, some people might think that the BDD-methodology is too detailed and even redundant. However, our long-term experience shows that it is the in-depth scenarios which could guarantee a stable development speed, meeting the deadlines and process transparency. Thanks to the documents written in plain language a client always knows what we are doing and how the app will behave and work. Moreover, if a client has his/her own development team a kick-off period will be shorter and the work itself will require less design support hours.
In most cases development happens to be the longest stage. Its goal is to vitalise the design through coding. Its timeline depends directly on the project scale and complexity, in other words on the functionality we worked out and approved at previous stages for Version 1 of the application.
As you might probably know, there are two main operational systems in the world for smartphones: iOS for Apple devices and Android for the rest of them (Google Pixel, Samsung, Xiaomi, LG, Sony, etc.). If you decide to develop an app for both platforms, a project might require at least 2 developers who are going to code one and the same app using a platform-specific language: Swift for iOS and Kotlin or Java for Android. Such kind of apps are called native. However, nowadays there is a number of so-called cross-platform solutions allowing to use one framework to develop apps which could be launched on both platforms using one code-base. Of course, each approach and technology has its own advantages and disadvantages, so you’d better make your choice based on at least two criteria: possible technical constraints and the budget you have.
Whatever technology you choose, a mobile app would in any way suppose hefty data exchange. All this data should be stored somewhere and in addition to that you have to manage it. Accordingly, one has to create a server-side of the application as well as an admin-panel which would ensure an optimal management over data and user flows. As a rule, an admin-panel is also hosted on a server. At the same time a client has an access to it either through a website or a mobile app. All the questions and issues related to the server-side at Rosberry is under the supervision of web and backend developers.
5.2 Development Team
Usually it consists of 6 people.
- Product Owner
Manages the whole process, communicates with a client, and helps in every way possible.
- UI/UX designer
Is a part of the project up to its completion. A designer ensures that the app is built in the way it was initially conceived together with a client.
- iOS developer
Develops the app for iPhone, iPad, and Apple Watch.
- Android developer
Develops the app for Android-based smartphones.
- Backend developer
Develops a server-side so that the app could exchange data via the Internet.
- QA engineer
Thoroughly tests the product during the project so that it would work properly on all types of devices.
5.3 Development Process
Since in most cases the development process takes a lot of time, it would be reasonable to cut it into logical timespans. In Scrum terms (we use this process framework at Rosberry to manage development), those timespans are called sprints.
Each sprint takes two weeks. Once every two weeks our team gets together and demonstrates the work result to both the company and a client (video presentation). It’s the kind of self-assessment which is also important for a client to be sure that everything is going on as planned and agreed. Also once every two weeks a client gets a so-called app build on their smartphone to test it.
Upon completion of the development process and preparation of the app for its release on the App Store and Google Play, Rosberry QA Department is usually busy conducting a regression testing.
All the app functionalities are tested on different smartphone models which make an ever-growing Rosberry device fleet. This type of testing ensures a proper quality level of all the apps developed at Rosberry and also allows to offer certain free guarantee periods.
7. App Launch
App launch is not the most complex, but a very important stage of the project. On completion of the development any app should be sent to the App Store or Google Play for review. Nowadays this review process usually takes 1 to 3 days. But Apple is more scrupulous about uploading of apps to its online store, so sometimes the review might take more time.
All the apps developed by Rosberry have a free guarantee period of 40 business days. Right after the release we pay special attention to the users’ feedback and fix all the possible issues if there are any. Most often than not at this stage, even if the issues surface, they are not numerous and not at all critical.
8. Updates and Enhancements
No app can live a long life without updates. Right after the release you have to carefully monitor the users reviews and feedback, add more features, constantly enhance the interface, support new operational systems and so on. Almost all our clients have been with us for long — over 5 to 8 years. Our experience shows that on average an app requires at least 1 update a quarter to be up-to-date and interesting to the users.
A client come up with an idea — we estimate it → put a certain scope together → make this scope a part of our schedule → develop and launch the updated app.
A client offers us a list of tasks on a regular basis, we carry the work out and 1–2 times a month issue an invoice for the scope covered. We work this way with all big clients, whose projects require permanent attention.
Cost & Price
Development cost in almost all companies is estimated based on the amount of man-hours. For example, if you want to develop some app functionality, say, a UI/UX designer will need 2 man-hours for the design, a developer — 8 man-hours for coding and 2 man-hours will be needed to test the app. To finally figure out the cost, the sum of the man-hours should be multiplied by an hourly rate a company charges.
At the same time you have to remember that if any functionality requires 8 man-hours, it does not at all mean that the work will be done within one working day. Usually a developer at a company works 4 to 6 hours a day over one and the same project. Additional time is needed for the so-called code review — a code quality check by another developer.
Also the functionality implemented should be tested, all the bugs found should be fixed and the app tested again. Only after this the work could be considered done.