Swift and iOS Development Best Practices
I often recommend avoiding singletons in iOS apps, especially to pass data between view controllers.
I thought that most developers knew why the singleton pattern should be avoided and what is the correct approach.
So I was surprised when I discovered that many iOS developers don’t know this.
In this article, I’ll show you what a singleton is, why you should not use singletons in your apps and what you should use instead.
Auto Layout is a complex beast to tame.
Creating adaptive apps that fit the sizes and proportions of all iOS devices is a complex problem. We can only solve it with a complex solution.
But you don’t need the full power of Auto Layout all the time.
Most apps have fairly straightforward interfaces. Most of the time, you can go a long way by only using Auto Layout’s basic features in an app’s storyboard.
That’s the Pareto Principle at play: learn the 20% of Auto Layout’s functionality that covers 80% of the cases.
From there, you can expand and include the what you miss to solve the problems you have at hand.
Many design patterns guide iOS architecture. People have varying opinions on what constitutes good app architecture in iOS.
I, for one, have issues with all the modern iOS architecture “best practices.”
Their main problem is that they only focus on massive view controllers. While this is a problem that we need to address, it’s far from being the only one.
After years of working in many teams with diverse backgrounds, I created the Lotus MVC Pattern to address these issues.
I have taught this new pattern to my students and email subscribers for some time now. I presented it publicly for the first time at MobileFest in Kiev, and this is the first time I show it publicly in a detailed article.
This article revolves around UIKit apps, but most of the ideas still apply to SwiftUI, since the Model-View-Controller pattern remains essential.
Finding your way in the navigation of a complex iOS app can be quite complicated.
I know this from experience.
During many years of freelancing, I joined many projects at an advanced stage of development.
When you browse the classes in a project, there is a disconnect from what you see in code and what you see in the app.
And when you find a bug in some screen, how do you know in which class to look?
To solve the problem of visualizing the navigation flow of an app, Apple introduced the concept of storyboards in iOS development.
When I started freelancing a few years ago, things did not go well at the beginning.
I started freelancing at a moment in which I was not happy with my employer and I was looking for another job. Back then a friend told me that there was a lot of work freelancing as an iOS developer.
That was what convinced me to make the sudden jump. But it turned out to be quite different.
Many iOS developers seem to go for very complex storage solutions when iOS offers very quick and easy ones that are much better for many tasks.
I myself made such mistake in the past. When the iOS SDK first came out I decided to make a little game for the iPhone. It was a little card game and as such it had to store the values for each card as well as information about the deck and cards the player collected. And I used the worst solution possible.
Sometimes it is hard to know which technology to use in iOS for a specific task.
Storing data is indeed one of these cases. When I wrote my first app, a diet app for the Mac when the iPhone did not exist yet, I used Core Data to store its data (macOS and iOS share the same technologies and frameworks). Looking back, I think that was probably the right choice at the time, given the kind of data the app handled. But back then I had no idea and no way to tell. I picked Core Data just because I heard other developers talking about it and I didn’t know any other way. When it came to store static data in the app, though, I definitely made the wrong choice.
100% privacy. No games, no spam. Unsubscribe at any time.
100% privacy. No games, no spam. Unsubscribe at any time.
