Model-Defined Interfaces
A Pattern for Better, Safer, and More Explicit API
Most iOS architectural patterns rely on protocols to define what data and behaviors (i.e. interfaces) will be available to client code. This is a perfectly workable approach, but it adds quite a bit of overhead in terms of creating the protocol and multiple conforming types.
For example:
protocol AuthenticationProvider . . .A Single Writer Pattern in Swift
A Fun Experiment With Shared Mutable State and Lock-Free "Locking"
I was talking to a co-worker today about different ways to minimize the risks around having a single shared instance in any app that holds global values which can be read and written to from anywhere in the code.
The potential risks around global mutable state are discussed in lots of places, but some of the key problems are:
. . .Swift's "Final" Countdown
And the inevitable deprecation of inheritance-based polymorphism
There’s an interesting discussion happening currently regarding a proposal on the swift-evolution mailing list to make Class types final by default in Swift. The initial proposal references the occasional need for a reference type that is not intended to be subclassed as the primary motivation.
There are some developers who are . . .
The Problems with MVVM on iOS
And some ideas for making it better
I love all the discussions I’ve been hearing about MVVM on iOS lately (that’s the “Model, View, View Model” design pattern for those who are unfamiliar). And I’ve now seen four different implementations of the pattern in working apps, one of which I have been involved with myself. But, despite the positive direction MVVM encourages, I’ve . . .