Swift is still very, very young and many developers are still figuring out how to best use the language. There are countless tutorials about patterns and best practices, which makes it hard to see the forest for the trees.
In this free book, you learn the four patterns I use in every Swift project I work on. You learn how easy it is to integrate these patterns in any Swift project.
For the next four days, I send you a new pattern every day. I promise that they are easy to understand and implement.
The first Swift pattern I use in every project that has any complexity to it is namespacing with enums and structs. Swift modules make the need for type prefixes obsolete. In Objective-C, it's a best practice to use a type prefix to avoid naming collisions with other libraries and frameworks, including Apple's.
Even though modules are an important step forward, they're not as flexible as many of us would want them to be. Swift currently doesn't offer a solution to namespace types and constants within modules.
Dependency injection is a bit more daunting. Or that's what you're made to believe. Does dependency injection sound too complex or too fancy for your needs. The truth is that dependency injection is a fundamental pattern that's very easy to adopt.
My favorite quote about dependency injection is a quote by James Shore. It summarizes much of the confusion that surrounds dependency injection.
Dependency Injection is a 25-dollar term for a 5-cent concept.
When I first heard about dependency injection, I also figured it was a technique too advanced for my needs at that time. I could do without dependency injection, whatever it was.
When talking about object-oriented programming, most of us intuitively think about classes. In Swift, however, things are a bit different. While you can continue to use classes, Swift has a few other tricks up its sleeve that can change the way you think about software development.
This is probably the most important mindset shift when working with Swift, especially if you're coming from a more traditional object-oriented programming language such as Ruby, Java, or Objective-C.
Model-View-Controller, or MVC for short, is a widely used design pattern for architecting software applications. Cocoa applications are centered around MVC and many of Apple's frameworks are impregnated by the pattern.
But there's an alternative that resolves many of the issues MVC suffers from, Model-View-ViewModel. You've probably heard of MVVM. But why is it becoming increasingly popular in the Swift community? And why have other languages and frameworks embraced Model-View-ViewModel for years?
