Table views are a fundamental component of almost any iOS app. But most developers don’t use them when they should or get their architecture wrong.
Table views are more versatile than you might think.
For example, many developers make their life harder using a scroll view when a
would be a better choice. UITableView
architecture is crucial for table views. The code of the table view data source often ends inside view controllers when it should go into a separate class.
Even though Apple introduced SwiftUI at WWDC 2019, you won’t be able to use it in your apps until a large portion of users gets on iOS 13.
Until then, you need to know the right approach to using table views with data sources and delegates.
Since the introduction of Swift, the iOS community has been buzzing with the words
That’s because many features of Swift were inspired by the ones you find in functional programming languages.
These features make some tasks easier. One example is easily configurable callbacks for
While Swift is not a functional language, we can draw many lessons from functional programming to write better Swift code in our iOS apps.
Unwind segues in iOS can be quite confusing.
Unlike their forward counterpart, they are based on a more complicated mechanism and different rules. That usually complicates their setup.
Moreover, many wonder why you should use an unwind segue when you can dismiss a view controller with a single line of code.
I will answer all these questions in this article.
Many iOS developers make serious architectural mistakes when passing data between view controllers.
There are many ways to do this, but they are not all good. Only a few of them are the best practices.
Quick and easy solutions like
singletons often lead to severe problems you will discover only later.
If you want to be a skilled iOS developer, you need to know the architecture behind view controller communication.
In this article, I will show you the best practices to pass data both forward backward. We will also discuss some advanced techniques, and the solutions you should not use.
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
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.