The singleton pattern is a widely used design pattern in software development. Despite its popularity, it's often considered an anti-pattern. Why is that? In this tutorial, I explain what the singleton pattern entails and how to create singletons in Swift.
The Cocoa frameworks and the Model-View-Controller pattern go hand in hand. A typical iOS application, for example, is composed of models, views, and view controllers.
When I first started dabbling with Cocoa development, I almost immediately came into contact with the singleton pattern. Many Cocoa frameworks, including UIKit and Foundation, use the singleton pattern.
A typical Swift application is composed of dozens and dozens of objects, working together to make your application tick. To get the job done, these objects need the ability to talk to each other. In this tutorial, we take a look at three common patterns that enable objects to communicate with one another. We also discuss when to use which pattern and, more importantly, when to avoid a particular pattern.
Type safety is a fundamental concept of the Swift programming language and optionals neatly tie into Swift's strict type safety rules. The concept underlying optionals is simple, an optional has a value or it does not.
In yesterday's tutorial, I showed you how to use closures as an alternative to delegate protocols. Closures—or blocks in Objective-C—are incredibly useful and I frequently use them as an alternative to existing design patterns. One such pattern is the target-action pattern.
Pixelsync was the first iOS application I published on the App Store. For a first project, it was quite complex and far more challenging than I had anticipated. The project grew quickly as I added more features and maintainability quickly became an issue I could not ignore.
View controllers are notoriously hard to test. Ironically, the Model-View-Controller pattern forces developers to put a lot of the heart and brains of their applications in view controllers.