Fundamentals First: Learning iOS
The Start of My Journey
Since I joined Def Method in July 2019, I’ve had the opportunity to work on two iOS related projects. My iOS experience dates back to December of 2019, where I began learning iOS for a project I would then be joining soon. Before then, my only software experiences had been in building practice web apps using React and Rails, and a customer project building a middleware as a Rails API. This article focuses on my journey of learning iOS development, unique iOS concepts I’ve picked up, and lessons learned in terms of efficiently adding a new tech stack to my knowledge base.
When I first started learning iOS development, I began with iOS Programming: The Big Nerd Ranch Guide, 6th Edition. I immediately learned about two tools that would be needed for development, XCode and Swift. XCode is the IDE used for building iOS apps, and Swift is now the default programming language (formerly Objective-C).
My first hurdle came in learning XCode. There are a lot of controls and tools to learn before you can start building an app and getting it to run on a simulator. The main issue for me at this point was the book teaching from an older version of XCode than what I had downloaded. The arrangement of a few controls were different, which prevented me from getting into a good flow of following along with the book. I had to stop reading and google the location of a few tools. The good thing is I only needed to learn it once, as I’d be using the tools often enough that I’d remember after a couple times. In this situation however, my frustration got the best of me. I put the book down and looked for a more updated tutorial for learning iOS. I started a beginner iOS developer course on Udemy. I also looked to YouTube for guides on Swift. I ended up starting on my first iOS project soon after, but didn’t feel too comfortable with where my understanding was. Fortunately, I had great teammates who guided me on where I needed to work within the code base, and helped with filling in any knowledge gaps.
Fast forward to the time of writing this, I’ve been on two iOS projects and revisited Big Nerd Ranch (7th edition) to the point I’ve gotten through most of the big concepts. In retrospect, I echo Big Nerd Ranch in that the ‘big ideas’ take time to sink in. This also reminds me of Steve McConnell’s concept of learning “Technology Knowledge” vs “Principles Knowledge” in his online course Code Complete Essentials.
McConnell explains technology knowledge is readily available to be learned while working on a project, e.g using a particular programming language to solve a problem. Principles knowledge on the other hand consists of approaches towards code construction and software development, which takes longer to learn and often requires dedicated time outside of working on an active project. In all, when picking up a new technology stack, it makes sense to me to initially focus on the core fundamentals, rather than becoming an expert in all the tools available, as you can learn those things while you work. With that, below is a list of iOS concepts I’ve come to learn.
Unique iOS Concepts
Note: These concepts are explained in regard to pre-SwiftUI. I’ve also already mentioned XCode.
MVC - The Model View Controller pattern is ingrained in iOS development, as each object you write in code will belong to one of these three layers. The model layer is responsible for storing and manipulating data, and can talk to the controller layer.
The view layer is responsible for displaying different views to a user. It can also talk to the controller layer.
The controller layer is responsible for managing the flow of the app, as well as synchronizing the model layer with the view layer.
ViewControllers - ViewControllers are typically responsible for managing a screen within an app. They have a view property that can be customized for styling. It also serves as the root view to subviews that can have their own subviews, creating a view hierarchy. This allows you to build screens that are displayed to the user, as everything shown on the screen is an instance of what’s called a UIView. ViewControllers are the main glue of the app, as mentioned above, as most of the functionality and processes are processed in this layer. This emphasis can sometimes lead to large monolithic view controllers. This issue has been addressed through use of variations from MVC, for example, the MVVM pattern.
Storyboards - Storyboards are files that store object data for UIs created using XCode’s interface builder. Interface builder is a visual alternative for UI design where you drag different UIViews from a library, onto a virtual iOS device screen. In order to have UIViews such as buttons respond to user interactions, such as a click, you need to connect that button to a target (usually a ViewController) that has a defined way of handling the event.
As mentioned though, interface builder is a visual alternative to building a UI. UI can also be built programmatically, though you’ll need to override a default method that looks for a storyboard file to provide the root view object to be displayed.
Autolayout - Autolayout is a system that automatically adjusts the layout of your views to display properly on different device types. It determines the layouts based on constraints, which are instructions given to views on how they should be positioned in regard to other views.
Delegation - Is a design pattern where an object passes off certain responsibilities to another object. There are two parts to delegation: the delegator, and the delegate. I like the boss/intern analogy used by Sean Allen. The delegator is like a boss, and the delegate is like an intern. The boss delegates a certain task to the intern, and the intern is responsible for completing that task for the boss. One way that this relationship is fulfilled is through use of protocols.
Protocols - A protocol is a list of rules to be inherited by a class. These rules are simply methods and variables. A class that adheres to a protocol must make sure it implements the variables and methods that are defined in the protocol. This is called conforming. So a common phrase you will hear is class A needs to conform to the B protocol. In regards to delegation, the protocol is the list of responsibilities the delegator wants the delegate to adhere to.
TableViews - TableViews are the preferred way for displaying lists within an app. They display a single column of information and rely on delegate sources to provide the number of rows to be rendered, as well as the information to be displayed within each row.
On the horizon
My next steps regarding learning iOS is to finish the rest of Big Nerd Ranch and complete all of the practice projects. The next chapter is on stack views, but I’m really looking forward to learning about persisting data. Then I want to look into more design patterns or start learning SwiftUI, and eventually write an article on that experience. It’s a great opportunity to apply what I’ve learned thus far about picking up iOS development.
Subscribe to our monthly newsletter to get notified about future articles.