Build a Mobile App From Scratch
I’ve been building mobile apps professionally for two years now, however I’ve only recently built an iOS app from scratch as a side project. This blog post is a summary of what I’ve learned and resources I used, I hope it will help or inspire you to get started on your own app.
Starting strong
Perhaps the most important part of the process is the beginning, this is where you’ll lay the foundations to ensure that the project is easy to come back to and a pleasure to work on.
Wireframing
With mobile apps I find it crucial not to develop blind, i.e you should have some idea of what you’re building and how it will look. To help with this you can do a quick sketch, either on paper or digitally. This helps inform what the entire app will look like. Below is a quick wireframe of the side project I was working on, an educational CBT app.
Here are some free resources to help you design a wireframe:
- Canva (free digital design resource)
- Adobe Color (free colour palette generator)
- Google Autodraw (free icon generation)
- Sketchize (free wireframe layouts)
- Miro (a free collaborative whiteboarding resource)
Planning
Once you have some idea of what you want to build then I suggest you break down the tasks you can think of into small manageable goals. This way you will avoid burnout and track progress efficiently. I recommend using Trello to track these tasks (easter egg: put 🎉 in the done column and drag a task in there).
Choice of technology
At this point you’ll probably know what you want to write your app in but you may not know how to architect your app or what the backend will look like.
Application Architecture
The architecture of an application is important, it ensures that all the applications you write will be consistent, easy to work on and easy to pick up again. There are several architecture choices when it comes to native development, these have the goal of avoiding bloated classes (especially ViewControllers in iOS and Fragments/Activities in Android) and spaghetti code. Here’s a brief summary of a few that we’ve looked into at Brightec:
(MVP pattern source)
The view represents a ViewController (or Fragment/Activity), the view is dumb (contains no business logic). The presenter addresses all UI events on behalf of the view (i.e what to display when) and calls the data methods in the model. There can only be one presenter for each view. The model represents the data portion or business logic of the app (the comms with the backend, processing data etc.). Here’s a great blog post if you want to go more in depth with this pattern. This is the pattern we mostly use on iOS at Brightec, it’s also the pattern I used for the side project.
(MVVM source)
The model again represents the business logic of the app. The view in this case again represents a ViewController (or Fragment/Activity). The ViewModel is where this architecture differs from MVP, it can be used across multiple views. The ViewModel exposes streams of data that the view displays. The view subscribes to data events which are updated in the ViewModel. MVVM leverages the separation of concerns of MVP but also employs the advantage of data binding. This cuts down on the logic in the view. Brightec uses MVVM in its Android applications. To continue reading about MVVM, there’s a blog post here
(VIPER source)
By far the coolest architecture name. The view is the same as above. However, the presenter contains the view logic to display data, which it receives from the Interactor. It also contains the logic for reacting to user inputs, which it requests from the Interactor. The Interactor mediates the interaction between the Presenter and the data. The entity is a basic data model. The Router contains all the navigation logic. This is a further abstraction to MVVM and MVP as it separates the display and data logic of the presenter. Further reading is available here and here.
Backend technology choices
I am no expert on backend/server development so this section is just my recommendation of free services to get you started if your application requires it.
Possibly the prominent free service you can use to get started is Google Cloud Platform (GCP). Google offers a plethora of services including serverless functions, dedicated services, databases, etc. We used a combination of Google Cloud Functions and Google App Engine for the backend of a Slack app we developed recently. GCP integrates with Firebase seamlessly. Firebase is a free collection of services that help developers build better apps. The services include; analytics, crashlytics, app distribution, cloud storage and many more. I exclusively used Firebase to power the backend of the side project I was working on as the free tier allows for a fairly generous number of interactions with the database.
There are alternatives out there like Amazon Web Services, however I’ve not used this much.
Communicating with the Backend
If your application requires a backend then you’ll need to communicate with it. This would be the Model section of the above architectures. At Brightec we use the repository pattern to achieve this. There’s plenty of frameworks for storing data locally once you’ve retrieved it from your backend. Some examples are Room, Realm or SQLite.
You should now be equipped with tools necessary to develop your own mobile app from scratch. I’ll soon be writing about how to test an app you’ve made by yourself and the benefits of developing a side project so be sure to subscribe.
Originally published at https://www.brightec.co.uk.
