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 with what we need. Configure it. Then return the variable.
But the button variable and return statement in the code above is largely boilerplate and specifying button on each individual line is really just visual noise in that it tends to hide the actual configuration options the code is actually…
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 application interfaces in Kotlin. A beta version of Jetpack Compose was announced at Google I/O in 2019; the same year that Apple announced SwiftUI.
You also may not know that Google just took Jetpack Compose out of beta and officially released version 1.0. To quote from the press release:
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 are days.
Resolver
The impetus for this story resolves around an article written by Antoine van der Lee, titled Dependency Injection in Swift using latest Swift features.
Now, as the author and lead architect of the open-source Swift dependency injection framework Resolver, I’m always interested in how people attempt to solve…
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 again and again in regard to SwiftUI, another one of the great new paradigms that Apple’s made available to developers. Or, at least, made available to some developers.
Let me explain.
The UIStackView problem
It was WWDC 2015, and I remember watching the introduction of UIStackView and starting to get excited. …
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 was discontinued months ago. But one could still buy them from Apple “while supplies last”. And apparently, that day had come.
All of which lead me to consider the HomePod, its place in Apple’s lineup, and, above all, what I consider to be one of Apple’s few major marketing screwups.
…
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.
As you’re no doubt aware, last April Apple announced that they were taking the same M1 Apple Silicon chip that powered the new MacBook Pro, the MacBook Air, the Mac mini, and the iMac… and that they were putting it into their brand new iPad Pro.
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 going to borrow from Steven so that we’re on the same page…
If we think about the clean code architecture we may come to understand that, for simple applications domain models may closely resemble network and storage models. However, they have differences
Domain Model: Structure is chosen for suitability for…
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 separation outweigh the disadvantages of writing more code? Code that could, in fact introduce its own set of bugs into the project.
As I tend to hate writing boilerplate code, my initial response to that question is no, it does not.
Second, another stated reason for introducing said objects…
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 when they tried implementing the proposed solution in their own app.
What behavior? Glad you asked.
Understanding NavigationLink
It dealt with using NavigationLink. Check out the following code:
This is an extremely simplified version of the main menu screen from the iDine app I’ve used to illustrate various SwiftUI features in…
Fixing another common environment issue in SwiftUI.
When SwiftUI works it’s a wonderful, magical thing. And then there are the times when I feel like the man hidden behind the curtain, frantically spinning knobs and throwing levers in a desperate attempt to keep the illusion going.
Take today, for example. SwiftUI provides a set of delightfully simple mechanisms for manage editing, deleting, and rearranging items in a SwiftUI List. Just add a couple of action handlers and trigger the whole thing with the built-in EditButton.
What could go wrong?
Well, as we saw with SwiftUI and the Missing Environment Object… plenty.
Let’s start with the problem
It seemed so easy. I wanted…
Michael Long
I write about Apple, Swift, and technology. I’m a Lead iOS engineer at CRi Solutions, a leader in cutting edge mobile corporate and financial applications.
