Xcode and Android Studio — Everything I wish I knew before building my first mobile app

Introduction

How do I choose the right developer tools for my app project? Should I start with Android or iOS first? Is it necessary to prototype the app? Do I need to use a database, and if so, which one do I need? When should a database be preferred for storing the data over storing the data in a text file?

I’ve had to work through most of these questions myself, as have most developers who have launched apps so far. The most frustrating answer on the internet seems to be, “it depends.” So I thought it would be helpful to dive into the main questions to help you make an easier decision about how to invest your time. If you’re getting started with mobile app development, here’s a few things I wish I knew about it before I built my first native app.

To be totally honest, there is a lot more that can be added to this topic from experienced developers, but I think this is a good start.

Programming language and environment

The programming language and environment are determined by the platform in this case. It’s going to be Kotlin or Java on Android Studio for Android development, or Swift on Xcode for iOS. Currently Kotlin is growing very fast and it’s highly recommended for Android development. At the same time, it’s impossible to know Kotlin without Java. So basically you should learn Java first, deploy your first app, and then slowly move to Kotlin. Swift, on the other hand, would be the only relevant option, unless you want to learn Objective-C, which is not a very popular language anymore according to the job market.

Prototyping

I didn’t prototype my first apps because I thought I have a pretty good understanding of what I want to put into it. But once I started working with complex structures, for instance ImageViews, Labels, and Buttons inside of TableView, I realized that something doesn’t fit on a screen. Apparently, the native mobile app design is much harder than I expected. Moving Buttons around in order to find a specific place for them might take some time. I wish I knew it before building my first app.

There are a dozen apps on the market you can use for user interface prototyping. Sketch and Adobe XD I have personally tried and was able roughly visualise my app on each screen size within a couple of hours. At that point, I have a better idea of what needs to be placed on a certain screen. In addition, the following items I found useful so far: icon libraries, color manipulation, animations, coediting or sharing work in case you work in a team.

Certainly, in regards to prototyping, use your best judgement and look at things objectively. If you have an application with up to 5 different screens then most likely you don’t need to spend time prototyping.

Databases

Speaking of databases the first thing I wish I knew is that the easiest way to provide local data storage for individual application is a database. SQLite is the most simple database for Android and iOS platforms. This is a common database used for mobile applications because it’s small, portable, and uses common SQL syntax. SQLite supports almost any type of data you can possibly think of. For instance, a “Shopping Cart” can be accomplished based on SQLite pretty quickly.

iOS apps on the other hand can be built with CoreData. But it’s important to understand that CoreData is not a database. Core Data provides a means of persistently storing structured data in a searchable store in the way SQLite database does. Since programmers are generally familiar with databases and since Core Data is actually backed by an SQLite database, it is understandable that Core Data is often treated and used as though it were a wrapper around SQLite. Even though you can use Core Data in this way, it provides lots of services that SQLite doesn’t but also that Core Data can’t provide some of the services that SQLite can. Generally speaking, Core Data can and often does serve as a database, but thinking of it in terms of other relational databases is a good way to mess it up.

Databases have many advantages, but making access easier isn’t one of them. Faster, more standardized, interpretable as an embedded command sublanguage, safer, yes — but not easier. Using a text file for storing data is always an alternative. Think of your text file as a database. As long as there are no problems with what you do, and ease of programming is your priority, never switch to a database just because you think it’s “good practice”.

For external data storage, taking into consideration Google Sheet as an external data resource can save you some time. Google Sheet is free and doesn’t require API or complicated SDK to set up. It can include internal calculations using spreadsheet functions and It can be combined with Google Forms for data collection. Your app can be easily upgraded in a later phase to use a real database, as data is exposed as standard JSON.

A couple of tips

Tip #1: Split up your project

You’ll meet many obstacles before you deploy your first application. For this reason, Don’t try to develop the entire app right away. Divide your project into several sub-projects so you can create a single view application for each one of them. For instance, this is how an average project can be divided:

• Database connection, where you read, write, and edit data
• Display information from database
• File export
• Map view screen
• User login credentials check

Once you’re sure all those are working separately, then you can simply merge them together in one single app.

Tip #2: Simplify as possible.

In a journey of becoming more familiar with native app development you can really save some time by limiting a number of tools you’re using: Button, Label, ImageView, TableView, TextView. An app works fine while they all separate. A combination of either of these tools, “Buttons in a TableView” or “ImageView in a ListView” makes the coding process more complicated.

As an example in Android development, there is a very convenient technique of displaying database records using ListViews. But when you have 100 records and over, the app works very slow and crashes very often.