Hallo eindkandidaten, Leo hier. The topic today is Architecture, iOS Tooling, and how to study them at the beginning of your career as an iOS developer.
If you didn’t read the Introduction, Part 2, Part 3, Part 4 and Part 5 I would strongly suggest doing so.
This is the sixth and last part of my series “How to start iOS Development Career”. This is our last stop and I’m glad that now I put it out. Maybe in the future, I can revisit some of the articles and make them better but for now, I’ll just sit back and enjoy that I could complete this.
In this last part, we will talk a little bit about the most common app architectures and how to study them. This is a very important topic as every company one way or another adopted some kind of architecture and structures to be followed. Ultimately, it is all down to how you decouple responsibilities and communicate with other parts of your system.
The other topic of this article is iOS tooling which is good to learn the basics. Here we will briefly discuss Xcode, Package Managers, and Simulator which are tools that we iOS developers use in our day-to-day life.
Wasn’t my intention for this series but it end up putting all the controversial topics to the end, for example, App Architecture, testing, and the choice between SwiftUI or UIKit.
A special thanks to Marco Eidinger that send coffees to me through Buy me a coffee, you are awesome!
Painting of The day
The painting I chose today is called Finish Line made in 1986 by the Japanese painter Hiro Yamagata. Hiro Yamagata (born 山形 博導 Hiromichi Yamagata, May 30, 1948, in Maihara, in Shiga prefecture, Japan) is a painter/artist, based in Los Angeles, California.
He has been considered one of the most famous silkscreen artists because of his use of vivid colors in his pieces. However, he has been known as a contemporary artist using laser and hologram technology recently. He is recognized as a pioneer of contemporary laser art.
I chose this painting because of the name finish line, it is indeed the finish line of the series. Those articles were important to me but I’m glad I finished them so now I can write about other things.
The Problem – Architecture and iOS Tooling
You want to learn how to better structure your code and use common iOS tools.
The first topic to approach is app common architectures and how to study them.
iOS App Architectures
iOS App Architectures are, in a few words, the way you split each piece of responsibility of your code and how each piece communicates with each other. For example, we have the UIViewController that has a UIView property, there are a lot of devs that advocate splitting the UIView configuration from the UIViewController class. Another example is that some people are ok using UIViewControllers to control the screen flow of the app and there are people that say that this is not a responsibility for UIViewController but you would need a Coordinator or Router to abstract that flow for you.
App architecture is the most controversial topic in iOS development. This is by far what most people have “Strong opinions” on and a lot of endless discussions were already taken in our community.
My 5 cents about any App architecture is: It depends. When you are choosing an architecture for your app you have to put a lot of things into the equation to come up with something that fit your organization. This is the best way to describe what I think and choose what best fits your organization and plans.
One could argue that making a hiper-modularised app with everything decoupled and 100% features covered with Unit and UI tests is the best architecture that one can think of.
But what if your company has a high turnover? That would make the maintenance so complex that the learning curve to start working on the project is steep and slowing down everything. Although you had a beautiful architecture that is not functional for the business.
Remember that the end-user, your customer, does NOT CARE about your app architecture, how much is covered by unit tests, or even if is SwiftUI, UIKit, or Xibs. If you have an app architecture that is so convoluted that this is making more trouble than solving problems, it is time to rethink your architecture.
Questions before choosing an App Architecture
Some questions you might want to ask yourself before choosing one architecture:
- How big is/will be this app?
- How many people/teams will work on this app? They will work simultaneously?
- What are the current technologies and what are the options to solve each problem?
- What Swift frameworks everyone is comfortable working with? They are acceptable for new projects? Or maybe we should find new ones? Is it worth it?
- What architectures do the company’s developers already know?
App architectures can be whatever the iOS devs want. Each company will have its definition of what a piece of code should be and where it should go. The variations are so vast MVC, MVVM, MVP, MVVM-CR, etc that we have a perfect joke about app architectures that you can find here.
Studying App Architectures
At the beginning of my career, I studied MVC. I got interested in making a lot of controllers to handle app states and user responses. Of course, you can pick up any other architectural pattern you want.
My recommendation is: to choose one and be mindful of the pros and cons of your architecture. For example: on MVC you have a separation of responsibilities with view, model, and controllers but the use of delegations in the controllers has a side effect that the view layer has to conform to that. Also, you have to be careful to not end up having a massive view controller.
In the end, for beginners, I would recommend studying MVVM. Today we have built-in tools like Combine and SwiftUI that make everything so much easier to use. You don’t need RxSwift anymore and you would be ready for the future. Of course, you can also use Combine with UIKit.
As a study resource, I used Paul Hudson’s Swift Design Patterns book. It is really interesting how it describes the history of the iOS App architecture and gives examples of each one of them.
Again, if you are a beginner just focus on one architecture and try to learn as best as you can.
iOS Tooling
Writing about iOS tooling is kinda hard. Because two reasons, first it is very project dependent, and second for each external tool you have a lot of options.
For example: if you are working heavily with designers you probably are using an app design tool. But you have a lot of options to choose from Figma, Adobe XD, Sketch, etc. Or if you are working in a heavily network-based app you need to check networking traffic a lot. You could use Charles or other proxy tools to do that.
Instead, I’ll just put the tools I tried to get know when I was starting. And I end up with 3 very important ones: Xcode, Simulator, and Package Managers.
Xcode and Simulator are the bread and butter of iOS development. I can’t stress enough how comfortable you should be using Xcode and a bunch of good shortcuts to speed up your development. I’ve already written an [article about the shortcuts](https://holyswift.app/xcode-tips-1-shortcuts) I use and maybe that would be helpful for you too.
The idea here is to be the most comfortable and proficient in the Xcode and Simulator as you can be. That doesn’t mean that you need to know or even use 100% of it. There are a lot of features in Xcode that we don’t use all the time. For example: if you build your UI programmatically it is very rare to use the command + L to open the component library.
Know your weapons and you will be fine.
Package Managers
Package managers are one important topic for any developer. First, because we don’t reinvent the wheel, if someone somewhere already solved our problem, we can just use their code.
An important disclaimer has to be made. DO NOT ADD an external package to your project without being very mindful of what it does. There are packages that you can’t run from if you are using some technologies but please don’t add packages mindlessly. Try to keep your project as pure as you can without external libs/frameworks. Each new external dependency is an increased time in building and
At the beginning of my iOS career, there were more or less two big options to go when talking about package managers, but nowadays we have three. We have Cocoapods, Cartage, and SPM.
For any beginner, I would recommend studying a little bit about each one of the three but focusing on SPM because is the Apple way of package management. Each one will teach you something interesting about how you can handle external packages to your code and you will probably end up working with one if not three of them in the future.
What I did Not cover in my Early Studies for Architecture and iOS Tooling
As this series is coming to an end, it is important to point out things that I conscientiously put aside when I selected things to study at the beginning of my career. They are indeed important topics but not necessary to start an iOS career. They were the AppStore app release process, design tools, and Objective-C.
Objective-C
Let’s start with the elephant in the room, the Objective-C language. When I started my iOS journey, I started because I fall in love with Swift in the first place, this way at the time didn’t make sense to learn another language used to develop iOS apps. I was already very sure that I wanted to work with Swift. Although I knew that I would probably encounter some Objective-C code on my way and I was fine with that. Objective-C is important to a lot of codebases nowadays but it is something that is “learn in the way”, I mean that you will learn just enough to be able to give maintenance to old code or to just translate to Swift.
AppStore Release Process
The AppStore app release process is important if you are an indie developer. All the provisioning profile processes and certificates are really important subjects later on in your career. That said, in the beginning, if you are focusing on a junior position doesn’t make sense to spend time studying this topic, mostly because I was almost sure that if I get into a junior position it won’t be me that will handle the release process.
Design Tools
And finally design tools. Like a lot of topics discussed here, this is a controversy. Some people would argue that any front-end developer should also have at least some design knowledge, other will argue that you should know only Apple’s human interface guidelines and that is all design you need, and other would say you should not focus on design at all. It is almost sure that the design tool would not affect the Architecture and iOS Tooling, so don’t worry about that.
My five cents on the subject is that you should have some design knowledge. For me, and for a lot of companies out there the Apple’s human interface guidelines are enough.
I would like to have more design knowledge though, also it is a very interesting area to study because of the user interaction discoveries.
One cool story about that is that one design research team discovered that some app actions should have a “fake delay” to be perceived as true by the users. Imagine that you are opening an account in a digital bank, and when you finish inputting all your information in the registration forms the app took 0,01 seconds to show you that your account was created. Kinda weird, right? Opening a bank account, even a digital one should be an “expensive” process. So the developers placed a cool loading animation and delayed it for 3 seconds ( even though the server had answered in 0,01 seconds) and the user perception of the process was better than with the very fast one.
Summary – Architecture and iOS Tooling for Beginners
This is my last article of the series. Today you read about app architectures and how to start studying them. Also, we take a look at what iOS tools are essential for starting iOS development. And finally, things that I left aside while was at the beginning of my career.
I hope you had a good time reading this, I was planning to post this series a long time ago, but only now have enough will to put it on “paper”. Any insights are always welcome.
That’s all my people, today we finished the Architecture and iOS Tooling article closing the series about the beginning of iOS development. I hope you liked reading this article as much as I enjoyed writing it. If you want to support this blog you can Buy Me a Coffee or leave a comment saying hello. You can also sponsor posts and I’m open to freelance writing! You can reach me on LinkedIn or Twitter and send me an e-mail through the contact page.
Thanks for reading and… That’s all folks.
Credits:
