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.
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 recently presented it at MobileFest in Kiev, and this is the first time I show it publicly in a detailed article.
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.
The Model-View-VievModel pattern has recently become of fashion in the iOS development community.
But it’s not without its controversies.
I, for one, I have my reservations about some of the implementations of MVVM. But I also think that some of its ideas are sound.
Networking nowadays is a requirement for most modern iOS apps.
This often takes the form of interfacing with a remote web service that provides data for an app.
And this web service is often a REST API that returns data in the JSON format.
But writing network code in Swift is not a simple task.
Making asynchronous network calls to get data from a remote API requires the interaction of many complex parts in an iOS app.
Table views are a fundamental piece of almost all iOS apps.
Still, most developers get them wrong, especially using Swift.
This happens in two different ways:
One of the places where most iOS developers make architecture mistakes is passing data between view controllers.
There are many ways to actually do this, but how do you know which ones are the best ones?
Many developers use the wrong solutions because they are quick and easy.