The process of building a mobile app - business owner basics
19.08.2020 | 11 min read
So you have an idea for a great digital product and you want to build a mobile app? Where do you start? Some CEOs and CTOs come from a web and mobile development background and will have a good idea of what technology they want to use, and the steps they need to take to launch their app into the world. Other business owners with a less technical background will seek out advice on the mobile application development process. If this is you, we hope you find the guidance below helpful.
The continuous growth of mobile technology
The mobile industry has been booming for the past decade, with the ongoing rise of smartphones, and all of their associated features - including, most significantly, mobile applications.
In the modern-age, most businesses know that alongside their website offer, they also need to optimize their business for the mobile market. Users are increasingly consuming information on the go and making purchases from their phone through the use of simple online payment systems.
And the mobile industry is only likely to expand further, with the rise of fintech and new strands of ecommerce, alongside a whole host of new apps. Technavio, a leading global technology research and advisory company has predicted that the global mobile apps market size is expected to grow by 497.09 billion dollars during 2020-2024.
But what are mobile applications?
Mobile applications, also referred to as mobile apps or simply apps, are computer programs or software applications designed to run on a mobile device - most often phones, but also tablets and increasingly smart watches. When a user opens an application, it runs inside the operating system until they close it.
Types of mobile applications
Native Mobile Apps
A native app is an app created specifically for a mobile device such as a smartphone or tablet and is installed directly onto the device. Users download these apps from an online store or marketplace such as The Apple App Store or Google Play. These native applications are built using the native device’s operating system APIs and SDKs and are coded using a language that is specific to the platform, such as Objective C/Swift for iOS and Java/Kotlin for Android.
These apps are very fast, as they are compiled with the specific operating system in mind, and run directly on it. They also come with their own development environments, which provide the perfect conditions for device testing.
Mobile Web Apps
Types of mobile technologies
Cross platform solutions
Cross platform frameworks work hard to deliver on their main promise, which is to use a single codebase in as many places possible. With the new wave of mobile frameworks, we can finally make this happen, and it has proven very effective. Using a single codebase for both platforms, significantly reduces development time and improves app maintenance - releases can be done simultaneously on iOS and Android. Due to this, it exceeds any other solution that is currently available, and provides the best time to market.
Flutter is the most popular open-source, cross platform framework for mobile development. It’s backed by Google and their team put tremendous work into recreatingMaterial UI components and Apple Design System elements internally, meaning there’s no need to write them from scratch. Because of its unique drawing system, UI heavy apps with beautiful animations are a perfect match with Flutter.
- React Native
React Native is probably the most recognizable mobile framework today. Proven in battle, used by Facebook and Microsoft, React Native has a lot of benefits. It makes great use of the existing JS ecosystem. Code can be shared with the web counterparts and it has a very strong integration with native components. If you’re planning to develop similar apps for web and mobile, React Native is worth considering.
When we don't want to make compromises, be it on performance, security or maintenance, we can build apps using native frameworks available on given platforms.
Sometimes we may be constrained to a feature-set that mostly relies on native solutions, and using a cross platform framework doesn't make economical sense. Native apps will always be the most performant, safest, and will require much less effort to maintain in the long term.
Methods of building a Mobile App
Mobile app development is, quite simply, the process of creating software applications that run on a mobile device - these can come in any of the forms described above.
Taking it back to basics, the most simple way to initially create a mobile app is to import a desktop-based app onto a mobile, but this of course can lead to problems further down the line, particularly if you want to add functionality requiring a typical mobile environment. Additionally, people are using desktop apps in a different way than they interact with mobile ones. Therefore, it is advisable to build directly for the mobile environment from the outset.
There are various ways to approach the app building process, and below we’ll describe just two of the most popular ones, used for brand new products - MVPs and Prototype apps. If you would like to reach more about other methods, take a look at our Mobile page.
Creating a Minimum Viable Product (MVP)
A minimum viable product, or MVP, is a product with enough features to attract early-adopter customers and validate a product idea.
The idea behind the MVP is simple:
- Small product = faster development.
- Faster development = faster idea validation.
- Faster idea validation = cost savings and the option of changing the direction of product development to match user needs at a relatively low cost.
If you would like to read more about the process of creating an MVP, you can do so here.
Creating a Prototype App
A prototype app is a visual mock-up of a real app which demonstrates its design and function. Prototype apps can take different forms, from wireframe sketches through to a real mobile app installed on your phone. They generate business value by allowing you to thoroughly test an idea before bringing it to market.
When is a Prototype App right for you?
- If you want to test your product - A prototype app can give you clarity about whether your vision works and what might need adapting. It can often save a significant amount of development cost further down the line.
- If you’re seeking funding - A prototype can be highly useful when it comes to demonstrating a product to investors and prospective shareholders.
- If you’re looking to iterate quickly - A prototype enables you to cycle through several drafts before developing your software, which can save time and money in the long run.
So what’s the difference?
While both an MVP and a prototype app can serve a similar purpose, an MVP is much more like a separate product itself, while a prototype is more of a draft. An MVP is a minimum version of the final product which can be delivered to the market right away. In contrast, a prototype app uses mock data and does not have a backend, which means it cannot be delivered to market.
The journey of a Mobile Application at 10Clouds
At 10Clouds, we work with a vast range of clients, from big corporates through mid-size companies with validated business models (scaleups), right the way through to startups which are at the very beginning of their product journey. Personally, I prefer to work with startups on building their first Minimum Viable Product (MVP), or working with them to conduct research prior to the main development phase.
But today, I wanted to give you an example of the journey of a prototype app, from the estimate to the first phase of development. It’ll be written from my perspective as a developer, but don’t worry - I won’t get too technical.
An introduction to the product
Our client here wanted to create a mobile app to present a very original digital product idea to partners and investors. Think about it as a clickable and animated mockup that can be used as a production application after connecting to the backend.
The Product Journey
1. It starts with a proposal: I found out about our client - a game-like social trading application geared towards Generation X users, when I was asked for a ballpark estimation. Of course, there was communication with the product owner prior to this, but it was handled by our sales team and was therefore not part of this story.
2. Understanding the context and estimating time and cost: When we get an app description, we usually spend some time asking further questions, sometimes meeting with the client, and then we make an estimation used in the proposal. Of course, we work in Scrum, so this estimation is only to show a time/money range that we would expect for this project.
3. Proposing the technology: During this phase, we also propose a solution that may be suitable for the given product. In this case, we recommended Flutter. It was a very new solution, but we felt that for an application that looks almost like a game, Flutter with it’s highly and easily customizable UI would be a good fit (spoiler: it was). After working on the proposal, my part is usually over; the sales team handles the rest along with our department heads, but in this case I also had the pleasure to be picked as a developer for this particular client.
Why Flutter? I would like to share a bit more with you on my reasoning for recommending Flutter. First of all, as mentioned previously, our client wanted to build an application with a lot of visual effects: particle effects, glows, gradients, shadows, animated backgrounds… and this is just the beginning. With the excellent performance of the Skia engine, Flutter is an ideal solution for applications like this. When building an app using Flutter, we get a blank canvas, and we have control of each pixel on the screen. The second reason was a more pragmatic one. I knew that the code created during this phase would be used later, so Flutter would be a better solution because, with one codebase, we could have both iOS and Android apps in the future. Finally, making one Flutter application is more cost-effective than having two separate native apps dedicated to iOS and Android.
4. Beginning the first stage of development
When the scope of work and all contracts are signed, it's time to start development. This first stage of Mula’s development involved a small team - myself (the software developer), the Scrum Master/Project Manager and the Product Owner and client. We also cooperated with two talented designers, and animators.
Creating user stories: We met to conduct a Backlog Refinement meeting where we created and tweaked user stories. These explain the ways in which end-users interact with different features of the system. Example: As a User, I want to see stock volume in the form of bubbles below a chart. Each user story has Acceptance Criteria - a set of rules that say what has to happen to consider that part completed. To measure team velocity, we estimated given user stories in story points.
Team contracts: Before the start, we usually also create a team contract - we specify how long each scrum sprint will take, how the application will be distributed, tested and so on. Since I was an only developer, this part was pretty quick, but in some projects, all those elements, along with Backlog Refinement and Sprint Planning, can take the whole day. Speaking of planning - based on requirements and risks, we picked tasks that we knew I would be able to finish during the two-week sprint period.
5. The core part of development
Once the above points were completed, the core part of development could begin. In a project as challenging as this one, every aspect carried something exciting. I don’t want to get too technical here, but just to give you some idea, during those three months, I had a chance to work with charts, game engines, Flutter animations (predefined and custom ones), massive data sets, and real-time refreshing. After each two-week sprint, we met each other, discussed results, applied fixes, and decided what I should do next.
6. The end of the first phase - but it's just the start of something bigger...
My journey with this client has ended for now after having achieved the goals of that first phase of development effectively and on time. But for them, this is just the start of something much bigger - and I hope that I might be invited to be part of their ongoing journey in the future.
A parting note
If you just started looking for a software house to develop your idea, I hope that this blog post gives you a small glimpse of what the product journey with 10Clouds looks like. From the content above, it may seem like everything is always bright and shiny, but in the real world, it usually isn't. During our work, there were some issues. Sometimes, I was stuck with a feature that I could not implement; sometimes, acceptance criteria were too vague.
But the main thing is that we managed to quickly overcome them with goodwill, discussion, and a shared vision of having a great product. These are all qualities that we pride ourselves on at 10Clouds.