As SwiftUI starts to make its way into production apps, the architectural debates are brewing again. It’s still early to know what works yet in SwiftUI, but in this post, I’d like to share my attempt in creating a scalable app in SwiftUI.
There are so many diverse use cases for Property Wrappers, but dependency injection in particular seems like a natural fit. In this post, we’ll explore how we can leverage this newly exposed feature of the language to achieve native dependency injection in Swift.
Themes are usually downplayed as an after-thought instead of being an integral part of the development process. How many times have you inherited a codebase where the design team wants to tweak it, or business wants you to clone the app with a whole different theme. In this post, I’m going to show you the native way of theming an iOS app as intended by Apple that is often overlooked.
The topic of iOS app architecture has evolved a long way from MVC. Unfortunately, the conversation becomes a frameworks and patterns war. The reality is: Rx is a framework; MVVM is a presentation pattern; and so on. Frameworks and patterns always come and go, but architectures are timeless. In this post, we will examine the Clean Architecture for building scalable apps in iOS.
The key to dependency injection is protocols. From there sprouts many variations, flavours, and techniques. Although this is yet another dependency injection™ blog post, I would like to share a pure Swift, battle-tested DI implementation with no outside dependencies or magic. It combines protocol extension and type erasure to give you a solid, flexible dependency injection.
Many techniques have been tried to tame the AppDelegate beast, usually ending up in moving code into private functions or extensions. However, the AppDelegate is much more complex than just moving code around. In this post, let’s examine a pluggable service technique with a few bonuses at the end.