This is one design pattern you definitely don’t want to use. Here’s why.
Design patterns come and go, and one of the fads currently ascendant in the iOS/Swift programming world is the concept of Immutable Objects.
To quote Wikipedia:
In object-oriented and functional programming, an immutable object is an object whose state cannot be modified after it is created.
Pretty straightforward. Immutable objects…
Bring a Kotlin like functional pattern to your Swift toolkit
We’ve all written code where we need some function to create and return a configured object.
func makeButton(_ title: String?) -> UIButton {
let button = UIButton()
button.translatesAutoresizingMaskIntoConstraints = false
button.titleLabel?.text = title
button.titleLabel?.font = .headline
button.setTitleColor(.red, for: .normal)
return button
}The pattern is the same. Create a variable…
SwiftUI is a powerful tool, but Android’s version is better. Here’s why.
If you’re an Apple developer then there’s no doubt you’ve seen and heard all about SwiftUI, Apple’s new declarative framework for creating apps that run on iOS, iPadOS, macOS, watchOS, and tvOS.
But what you may not know is that Android also has a brand new declarative framework for creating…
It’s… complicated.
Don’t get me wrong. I’ve used quite a few languages in my career, and I wouldn’t want to go back to any of them. Swift in 2021 is modern, type-safe, highly-functional, and with new features like actors and async/await it keeps getting better and better.
I love Swift.
But… there…
It’s a powerful new feature in Swift 5.5… but you‘ll have to await for it...
With Actors and Async/Await, Apple has finally brought modern, asynchronous concurrency support to the Swift language. The syntax and concepts are powerful, clean, and elegant.
But Async/Await and Actors both suffer from a single, minor, almost insignificant issue… we can’t use them in our code.
I’ve written about this problem…
Some thoughts on how Apple missed a major opportunity in the home.
I was in an Apple store last week looking to buy another HomePod. No, not the new HomePod mini, but the original HomePod. Only to find out that they were no longer in stock in the store — or online, for that matter.
Yes. I know that the original HomePod…
WWDC 21, iPadOS 15, the M1 chip, mismanaged expectations, and cancelled orders.
Apple announced iPadOS 15 during WWDC 21 and — to put it mildly — this wasn’t the iPadOS I was looking for.
Time to move along.
False expectations
To understand exactly what it was I was looking for, and why, we need to go back in time to Apple’s “Spring Loaded” event.
…
A case for and against (mostly against) using classic DTO’s.
In a recent article, Using Data Transfer Objects (DTO) in Swift Code, Steven Curtis makes an argument for using DTO’s in Swift code as a standard practice. I disagree with that premise, and in this article I hope to demonstrate why.
Domain Models and Domain Transfer Objects
First, we need to define our terms. Here I’m…
From what I gather, you're adding objects primarily for Separation of Concerns.
Okay... I get that. But adding another object means that I now have to write code that maps data to and from the model to the domain object. So the question here is that did the benefits of…
The number one problem most people have with NavigationLink, and with SwiftUI itself, for that matter
I’m heavily into SwiftUI. I like writing it. I like learning it. I like reading articles about it. I like puzzling out its internals and behaviors.
Basically, I’m a SwiftUI geek.
So, I was reading an article and one of the readers commented that they were seeing some unexpected behavior…
