iOS Masterclass: Build An iOS AppStore-Quality App In Swift

We explain the core set of coding principles that are used and taught throughout this course. Each coding principle has been assigned a text document within the final Xcode project. We summarise each document in this video.

We discuss the coding principle: Having a layered architecture.

We discuss the coding principle: KISS - Keep It Simple Stupid.

We discuss the coding principle: DRY - Don't Repeat Yourself.

We discuss the coding principle: WET - Write Everything Twice.

We discuss the coding principle: Single Responsibility.

We discuss the coding principle: Unit Testing.

We showcase the app we will be building in Xcode 13. We demonstrate the features such as the color themes (a feature only possible because we used architecture), saving to disk, principles like KISS, how to enforce Single Responsibility and more.

This is a course demonstrating how to create a professional-quality project that could be used as a coding test for a potential employer. We use industry-standard architecture and separation within our demonstration project to not only build an AppStore-quality product but to create it professionally using usual commercial level techniques.

An over view of the Xcode project. We'll discuss the layout the files are stored and provide an overall summary for how things are pieced together.

Download the attached Xcode project and follow this tutorial where we show how the UI communicates to the calculator engine (the brain of our app).

We refactor the code written in the last video demonstrating how we adopt the DRY coding principles to reduce code duplication.

We demonstrate how the paste feature from the copy & paste menu has been created by following a brief tutorial on how it has been connected to the UI.

We follow a brief tutorial and connect the calculators history log to the LogViewController. Once connected we will be able to view a list of equations performed by the calculator.

Together we add some basic animations to the initial experience of opening the app. If the calculator load a saved result for a previous equation then we present the LCD screen sliding in from the bottom of its container view. Otherwise the LCD screen simply fades into view.

We explain how the color theme feature has been implemented within the finished project. Once we've watched this video we will have a better understanding of how this solution has been written with the Xcode project.

We explain how the layered architecture has been implemented and how it is useful for future growth within the finished project. Once we've watched this video we will have a better understanding of how this solution has been written with the Xcode project.

We explain how the actual calculator (i.e. all the math stuff) has been implemented within the finished project. Once we've watched this video we will have a better understanding of how this solution has been written with the Xcode project.

We explain how the log screen (equation history) has been implemented within the finished project. Once we've watched this video we will have a better understanding of how this solution has been written with the Xcode project.

We create a new Xcode project to start our Calculator iOS app and setup the project ready to start editing the UI.

In this video we will start to create the layout of the calculator. Each button will be placed and organised using a stack view inside the main storyboard. The stack views are a very special component because they can save a lot of coding time simply by embedding views and editing stack attributes rather than writing code to layout each button individually.

We spend some more time within the main storyboard file to add two views (UILabel and UIView) representing the LCD screen where we display the calculator input and result. We use UIConstraints as a layout system to manage the layout and position each view in the desired location.

We amend the layout of the zero button on the pin pad as it is almost twice the width of the other buttons. We use the UIConstraint system and change the aspect ratio of the button to accomplish this.

We add a .pdf document containing vector based graphics for our round calculator buttons. A vector based system uses points within a grid system rather than individual colored pixels and so it can be used at any size on any device. We absolutely recommend using .pdf vector based images where possible - it is the future!

In this video we alter the colors of the UI (User Interface) by writing some code and we setup the infrastructure to apply a set color palette from a saved set of colors.

In this video we continue to grow the newly added color palette code, which has allowed us to divide the UI (User Interface) and how it is colored into separate areas. Due to this architectural decision we now have the ability to color the calculator display dependant upon a color palette file that can be set by a designer.

We tidy the UI (User Interface) logic that we have just created. It is always good practice to iterate over our code looking for areas to improve or enhance in someway. Usually we focus on readability to ensure the easy maintenance of the codebase and help out other colleagues who may have to edit the code also.

We create a new struct named MathEquation, which will serve to store the data for each math equation entered into our calculator app.

We connect the buttons of our calculator to functions in code. When ever a button is pressed by the user its associated function will also be called. This will allow use to move slowly away from the UI (User Interface) and direct our efforts more into the actual code for the calculator brain itself.

We create a new struct named CalculatorEngine. This struct will serve as the API (Application Programming Interface) between the UI and the calculator logic. In other words, the CalculatorEngine will become the type that is called by the UIViewController in order to trigger and control each feature of the calculator.

We implement the code for the clear button. When pressed the calculator logic will reset creating a brand new math equation and allow the user to start again with their input.

In this video we implement the logic for the negate button. When pressed the value entered by the user will be negated, which means that it will be multiplied by negative one (-1).

In this video we implement the logic for the percentage button. When pressed we divide the entered value by one hundred. This feature allows the user to enter a whole number between 1 - 100 and view the decimal representation of that percentage. i.e. 50 would be represented by 0.5.

We add a printout to the development console each time an equation is executed. This serves as a development tool to view the values of the equation in an area other than the calculators LCD display screen.

As the user enters and executes each equation we add them to an array. This array will then serve as a log of history for each equation that has been entered and can be displayed in the future inside a UITableViewController.

In this video we add some more layers of architecture to the calculator system. This extra layer of abstraction serves to separate our concerns and ensure that each type exists for solely one purpose or main task.

The Input Controller will exist to read and interpret each input from the user. This input will then be used to update the LCD display and set the values for the math equation.

In this video we implement the code to handle the numeric input from the user when they press each number on the pin pad.

In this video we refactor the method used to format the values displayed within the LCD display. All areas that apply formatting are centralised into one function allowing only one area of code to be in charge of generating values ready to be displayed to the user.

In this video we implement the code for the decimal button. When pressed, the newly added Input Controller will change state for entering decimal values and will also reveal the positive decision we made in introducing it to our calculator architecture.

Now that we have evolved the behaviour and feature-set of our calculator the negate button logic has become a little out of sync. We have now introduced our first bug and must refactor the negate button in order to resolve it and bring the code into alignment with our new functionality.

In this video we add some validation to our calculator system securing both the behaviour and also its use by developers when interacting with our exposed API (Application Programming Interface).

As code grows and evolves into something different there will always be areas that would benefit from a little more attention. In this video we tidy up some of our logic to improve ongoing maintenance and keep to our coding principles.

We add a second color theme to the CalcViewController proving that our architecture can easily support a variety of different themes.

In this video we write the code to support separating each color theme into a different file that can be shared with designers or other members of the team who could set the color values independently of the development team.

The resources folder attached to this video contains 10 different color theme files which will be added to the project. Please download them to follow alongside the video add them to your own project also.

We add a status bar style to our color theme system so that each theme can display either a light or dark styled status bar.

In this video we update the main storyboard tweaking a few values to polish the look of our UI (User Interface). We increase the padding between stack views, change the font size and amend the button title insets to bring the app a little closer to look like the finished product - an amazingly well designed calculator app!

We introduce a new class to take the responsibility of managing the color theme feature. This ThemeManager class will load in each theme and manage the currently selected theme.

As this feature evolves all of the color theme related code will be implemented only within this file - supporting the 'Separation Of Concerns' coding principle.

We add a double tap gesture recogniser to the LCD display screen allowing the user to interact with our newly added color theme system. Our goal is to display a different color theme each time the user double-taps the display.

We add some code to set the index of the current color theme to disk within Apples UserDefaults system. The UserDefaults exist and have been made available for this very purpose i.e. to store and revive the preferences set by the user.

We create a datastore manager to add an extra layer of abstraction and prevent the Theme Manager from knowing exactly how the data is stored.

Now that we have implemented the infrastructure for storing data to disk and saving the users preferences for their desired color theme we enhance the system by saving the whole color theme to disk itself.

We convert the color theme data into a JSON format and then save it to disk within the DataStoreManager.

Now that we have successfully implemented the data storage to store and revive each color theme to disk we complete the system by removing the theme index and replacing it with the actual identifier for each theme.

We add a nice little feature by highlighting each operation button that was selected by the user.

E.g when the user presses the multiply button it will remain highlighted providing feedback to the user of the operation that is about to occur in their equation.

We add a new file to our project which will replace the class type for a UIView within the main storyboard. We subclass UIView to gain access to the exposed methods required to present a copy & paste menu (known as the UIMenuController) such as becoming a first responder.

But for this video we solely focus on creating a new subclass and implementing the basic infrastructure.

In order to trigger the display of the UIMenuController we first add a long press gesture recogniser as our type of interaction with the user. After touching down upon the main display and pausing for a moment the menu will preset itself. In this video we will create and setup the UILongPressGestureRecogniser.

In this video we try to understand the qwerks of subclassing a UIView, how to register different types of actions (such as copy & paste) and how to become whats known as the first responder. Toward the end of the video we will have successfully presented the menu (UIViewController) with both options to copy & paste.

We write the code to perform the copy & paste operations within the LCDDisplay view and successfully copy the value displayed by the calculator as well as pasting in a new value into a new equation.

We post a notification from the LCDDisplay view which will be recieved by the CalcViewController and from that point we filter our communication down through each level of layered architecture until we reach our MathInputController which will handle the insertion of the new pasted value.

To enhance the UX (User Experience) we make a call to hide the menu (UIMenuController) in a certain scenario. When the user is presented with the UIMenuController and selects to view the next color theme we write some code to hide the menu so that the app feels more polished.

To start animating each button we make a call to a method held within a new UIButton extension. This method will allow us to easily experiment with new animations ideas.

We write a UIView animation block explaining the easiest form of animation for UIViews and all related subviews. This is the fastest form of animation and allows us to create basic but amazing animations in a very short amount of time.

When referencing objects within a closure (which is what happens inside an animation block) we must think about the memory management system. We have 3 options to reference objects, however, we only focus on weak references within this video which won't prevent objects from being released from memory just because we wanted to apply various animations.

In this video, we write the code to implement the animated behaviour that will be submitted to the AppStore for this calculator app.

To enhance the UX (user experience) of the copy & paste feature we will highlight the LCD display by animating a color change from the clear color to the operation button color. This will add further feedback that the user has entered a different 'state' or 'mode' when they perform a long-press gesture.

We tackle the complexities that arise from adding some extra animations. As with any project, several code paths will exist when adding extra features and they must all be addressed when working in a professional setting. Even though it may be difficult and (dare we say) annoying to add complexity, the user experience must be preserved in every scenario.

The UIMenuController that is presented when the user performs a long press gesture on the LCD display can also include custom menu options. We utilise this feature to add our own menu item ready to present the history log screen.

We create the infrastructure and new classes required to present a new screen - the LogViewController. This new screen will then become our blank canvas to display a list of each equation that was executed by the calculator.

We connect the data source within our newly created LogViewController to the calculator engine.

We add 3 UILabels to our new UITableViewCell subclass so that we can display the three main properties of each equation - the left-hand side, the operator combined with the right-hand side and the result.

Instead of presenting the LogViewController directly, we present a UINavigationController which encapsulates a LogViewController. This is widely accepted as a best practice due to a new set of navigation being created and also we want to take advantage of having a navigation bar with a system done button displayed.

It is always better to use an existing system than to reinvent the wheel simply because we have added a new feature. We hijack and use the existing paste system in order to restore the result displayed within the selected UITableViewCell pressed by the user. A clever example of code reuse and reducing unnecessary complexity. i.e. the KISS coding principle.

We decorate the history log screen with the selected color theme which brings our new feature to life and certainly makes it more fun to use.

The UX (user experience) feels confusing when restoring the result of a previous equation. This is mainly due to the rapid speed at which the selection is made. We add a beautiful tick animation combined with a delay to slow things down.