The Ultimate Course to Making Professional iOS Apps – Lesson 1

The Ultimate Course to Making Professional iOS Apps

Lesson 1: how the MVC pattern guides the structure of professionally developed iOS apps

Welcome to this first lesson of my “Creating professional iOS apps” mini course. Today we will first have a look at the requirements and the design of our app. We will explore the MVC pattern, which will guide us in implementing the complete app in the coming lessons.

The importance of front-loading the work

The first thing that we will do is gather the requirements of the app we are going to build.

It is very important to know what kind of app you are going to create and how it will look. This helps you think about how the app will work before you start writing the actual code.

Remember that writing code is always a long and expensive process. If you start without a plan and design your app while you are writing its code, you will waste a lot of time. This will happen because you will have to move or delete a lot of code, to adapt to the changing assumptions in your mind.

If I am not working with a designer, I always start by making some designs of the app myself. Even if you don’t have any design skills, drawing a mockup of the screens of the apps you build is going to help you have a clearer image. You will be forced to think about the user interaction and define what screens the app will contain. In doing so you will probably discover things you did not consider. When you have an app in your mind you are making a lot of assumptions that will not survive even the roughest of mockups. For example, you might discover that all the things you want to put in a screen actually do not fit in it or that some interaction does not make sense.

I use Sketch for my designs, which is a very popular and easy to use app for designers. It is a commercial product, but it has a 30 days free trial. You can also find other alternatives. You could even use Apple’s Keynote or Microsoft’s Powerpoint for your mockups. The tool is not that important, anything you already have is better than nothing at all. The important part is doing the work of understanding before writing code.

All the icons I used in these designs come from Icons8. There you can find tons of free icons under a creative commons license. There is also a paid license, if you need it.

The design and development processes

Before we start, I want you to notice in which order I follow this process. I am not going to show you some screens and then tell you what these need. This is not how you gather the requirements of an app.

At first you need to stop and think about what you want your app to do at a high level. Then you start thinking how you could organize this in separate screens and user interfaces. Only then you create mockups or designs for the screens.

This again forces you to think about features before you start creating anything. When you write a book, the most important thing is the table of contents and how the chapters are arranged. Only when you have that you start writing. Here the process is the same.

This does not mean of course that it is a perfect process and you won’t need to go back and change things. As you proceed you will probably find things you didn’t consider and you will have to rethink your approach. But this does not mean that you just have to start throwing out ideas immediately without planning. When you go hiking, you plan your trip in advance and gather all the stuff you need beforehand. If you forget food and water, your hiking trip will stop much sooner than you think, because you will need to go back home and take some supplies.

This starts with design, but its true also for development, although I might not follow it literally in the coming lessons. I made this course to show you all the parts of a professional app, not its development process from start to finish. So I might sometimes follow an unusual path.

When in doubt, always come back to the ideas of this lesson. Planning first, then execution.

The app requirements

Let’s start looking at some high level requirements for our app. First of all, what kind of app are we going to build?

We are going to build a small banking app with a few screens. This is the functionality we want in our app:

  • showing a list of bank accounts
  • addings new bank accounts to the list
  • showing the list of transactions for every account
  • adding new transactions to an account
  • persisting data, so that it is still available the next time the app launches

We can imagine from these requirements that our app will have around four screens. That is indeed what I ended having in my designs, but at the beginning I was not sure. A lot depends on how you design the interactions in your app. For this app I wanted to keep it’s structure simple while making it work like a real app you might find in the App Store.

The accounts screen

Let’s start from the first screen of the app. This will be the screen where the user sees the list of all his bank accounts. This is the list of requirements we have for this screen:

  • show a list of accounts
  • a button to add new accounts
  • tapping on an account will show the details of the account

Moreover each account in the list needs to show:

  • the account name
  • the bank
  • the account number
  • how much money is in the account

This is the screen I designed:

By looking at it, there are actually some more requirements we can add to our list:

  • the amounts of money show the dollar sign and the decimals
  • we make account numbers more readable by dividing them in groups of 4 digits. This will happen also in other screens
  • each account in the list has a different color
  • we use different fonts for labels in our accounts

The new account screen

To add a new account to the app, we need a separated screen. Remember than in iOS usually screens have very specific and limited functionality because the space is limited. So adding new information to an app usually happens inside dedicated screens.

Here we will allow the user to enter the account information. This is what an account needs:

  • the account name
  • the bank name
  • the account number

We will use simple text fields to allow the user to enter such information. This screen also needs buttons in the navigation bar to either save a new account or cancel and go back to the previous screen.

Finally, since this is a screen that requires user input, we will show it with an animation coming from the bottom of the screen. This is the standard interaction in iOS for any screen that requires the user input or action.

This is how this screen will look like:

Notice that the amount of money in the account is not a value we allow the user to enter. This is because it we will calculate it from the transactions in the account.

The transactions screen

When tapping on an account in the accounts screen, the app will show a screen with the details of all the transactions for the selected account. This screen will show:

  • the total amount for the account
  • the account number
  • a list of transactions
  • a button to add a new transaction to the selected account
  • a back button to go back to the accounts screen

Each transaction in the list needs to show:

  • a description of the transaction
  • the transaction amount
  • the date in which the transaction happened
  • a category to classify the transaction

The presentation of this screen is different than the one for the screen to add accounts. In iOS terms, this is a “drill down” screen where we show more details related to a selection in the previous screen. As such, we will show this screen with the standard iOS right to left animation for drill down lists.

Again, from the design of this screen we can get some extra requirements:

  • the total amount and the account number are displayed prominently at the top of the screen, in big fonts
  • the navigation bar shows the account name
  • we show the category of each transaction through a colored circle and an icon
  • the transaction dates have also a specific formatting, showing the full month name, the day and the year
  • if a transaction indicates money that comes into the account, the money amount is green. Otherwise it is grey like other labels

The new transaction screen

Finally, we need a screen to add new transactions to an account. This screen has to allow the user to enter:

  • the transaction amount
  • a description for the transaction
  • the category of the transaction

We will again use text for all these.

The user won’t be allowed to enter a date, because for bank transactions that depends on the execution day. Notice that this just depends on the nature of our app. If it was a budget app and not a banking app, the user would also need to put a date.

We will allow only 6 categories in our app for our transactions:

  • income
  • groceries
  • utilities
  • home
  • transport
  • fun

Again, this is again a screen that requires user input, so it will come in from the bottom. It will also need buttons to either save the transaction or cancel and go back to the previous screen.

This is how the screen looks like:

Again, some extra requirements come from our design:

  • we show categories in a grid and each one has a distinct color and an icon
  • a light blue circle surrounds the selected category

The Model-View-Controller pattern guides the development of every iOS app

Now that we have the design of our app, we need to start thinking how to translate these in a real app. When we write our code, where should all the parts we mentioned in the requirements go?

As you see, the visual design of our app shows only screens. This is normal, because designs concern what the user sees on the screen and how he interacts with the app.

But when when we build an app there is actually much more that we have to consider. How do we organize all the code, exactly? How do we represent the data? How do we save it? How do we bring the necessary data from one screen to another? This is what makes the true difference between making a real, professional app from just cobbling some code together from a tutorial.

Again, plan first, then execute. But to create an effective plan, you need a map to help you.

In software development we do not need to make to create this map by ourselves all the time. Through the years, software design patterns have been created to guide developers. There are many design patterns, but the most important one in iOS is the Model-View-Controller pattern.

The MVC pattern divides the objects we create in three layers. Each layer has its own responsibility:

  • the model layer represents data and its logic
  • the controller layer acts as a bridge between the model and the views
  • the view layer displays data to the user and allows interaction

The MVC pattern is a pattern used in many fields of software development. There is one very important distinction to keep in mind though. In iOS, this pattern works differently than in other platforms. Specifically:

  • the layers are only allowed to communicate with the one directly above or below them. So the views and the model do not know anything about each other, while in other platforms they do
  • the main type of object around which an iOS app is built is the view controller. As the name implies, this element is part of the controller layer of MVC. In iOS a view controller represents one screen of the app

In our design, our app has 4 screens. So, from the above we can deduce that our app will have 4 view controllers. The reality though is that our app will have at least 4 view controllers. We will see in a later lesson why.

Now, there is a big open “secret” that many iOS developers seem to ignore. Not knowing this concept leads to a common joke between iOS developers, where MVC stands for “Massive View Controller”. This means that view controllers often become bloated by a lot of code and become unmanageable very soon.

This secret to solve this problem lies in plain sight in Apple’s documentation. Quote:

“One can merge the MVC roles played by an object, making an object, for example, fulfil both the controller and view roles—in which case, it would be called a view controller. In the same way, you can also have model-controller objects. For some applications, combining roles like this is an acceptable design.”

So there are actually two types of controllers in iOS, not just one:

  • view controllers are mostly concerned with views (hence their role in representing the screens of an app)
  • model controllers are mostly concerned with the model

Now, I have to admit that I understand why this concept is not well known. If you read the whole Apple documentation it is a bit ambiguous and this concept is not very clearly explained.

Nonetheless this is a powerful concept that will make a big difference in your apps. We will see in the coming lessons how.

In my “The Confident iOS Professional” course I talk more extensively about software design principles, design patterns and the roles of each or the parts of an iOS app. But the important lessons I want you to learn here are:

  • The MVC pattern guides you in structuring professionally written iOS apps
  • Despite what many iOS developers believe, the MVC pattern has four layers and not just three

In tomorrow’s lesson we will start applying these concepts to build our app.