During WWDC 2015 Apple dropped a small bombshell on the Swift development community during a session titled “Protocol-Oriented Programming in Swift”. In it Apple demonstrated just how Protocol-Oriented Programming (POP) could free us from the constraints of traditional class-based object hierarchies.

Swift hasn’t been the same since.

Then, just over a year ago during WWDC 2019, Apple dropped another nuke and introduced SwiftUI — its proposed user-interface replacement for the ever venerable UIKit and AppKit.

There’s just one problem.

SwiftUI and Protocol-Oriented Programming don’t get along very well.

To see why, let’s start with an example.

SwiftUI and the ObservableObject

Say that we’ve begun a new SwiftUI project and that we’re writing YAARR: Yet-Another-Another-RSS-Reader. …

SwiftUI gives us an amazingly concise declarative approach to programming our user interfaces. Consider the following code:

struct SomeHeaderView: View {
  var text: String
  var body: some View {
    HStack {
      Image(systemName: "star")
        .font(Font.title.smallCaps().bold())
        .foregroundColor(Color(red: 88, green: 86, blue: 214))
      Text(text)
        .font(Font.title.smallCaps().bold())
        .foregroundColor(Color(red: 89, green: 86, blue: 214))
    }
}

Here we use view decomposition to build a customer header view for our application that anyone can include and use in their own views. The image and text in our headers use a title font with some custom modifiers, and they use our application’s brand color.

But we have a few problems here. The first and most obvious is that we’re duplicating our view modifier code. Let’s fix that problem now. …

It’s a new year (finally), and with it, we have a new version of RxSwift.

Version 6.0 brings quite a few new features and changes to the table, but the one I want to discuss today is withUnretained and how it solves — and fails to solve — one of the most common problems in our RxSwift code.

Weak Self and Retain Cycles

Consider the following code:

Subscribing to an observable and handing off the result to a class method is an extremely common occurrence in RxSwift. Unfortunately, it’s prone to retain cycles when used inside of class instances, which is why we’re constantly adding [weak self] to our closures and often adding the guard statement to make sure that our instance hasn’t been released. …

So let’s cut to the chase. Geekbench test scores from a “MacBookAir10,1,” reveals a single-core score of 1687 and a multi-core score of 7433. The 8-core processor was clocked at 3.2 GHz.

Which has Apple’s new ASi M1 chip blowing past all mobile Macs, all current Mac mini configurations and even a healthy portion of the iMac desktop specs.

And that includes the late-2019 MacBook Pro with the Intel Core i9–9980HK processor clocked at 2.4 GHz.

So their lowest-end MacBook Air with ASi beats the eight-core Intel Core i9 used in the high-end 16-inch MacBook Pro.

My current machine.

Think about that for a minute. …

For the past few years now, like clockwork, I’ve sent the following letter to Tim Cook at Apple, Inc.

Dear Mr. Cook,

As you’re no doubt aware, ISPs can legally sell any information they want from our online activity and mobile app usage — financial information, medical information, our children’s information, social security numbers — even the contents of our emails.

They can even sell our geolocation data, tracking where we’ve been and when, and, by implication, who we’ve seen and what we’ve done.

It’s time for this to stop.

Apple has long stood for protecting personal privacy, and I’d now like to ask you to stand up and do it again. …

SwiftUI was introduced just one year ago at WWDC 19 and launched with iOS 13. In that short period of time SwiftUI has generated a ton of interest, a bit of controversy, and a lot of articles. Including my own.

I’ve written rather extensively on SwiftUI, on SwiftUI application architectures, and on issues and hidden gotchas that have developed from creating applications using SwiftUI.

This a handy reference guide to them all.

Note that articles marked with an asterisk (*) are recommended reading.

I also consider Deep Inside Views, State and Performance in SwiftUI to be required reading if you’re serious about SwiftUI application development. …

I’ve noticed quite a few articles recently promoting Flutter as the “next big thing.” Several have even explained in detail how Flutter is going to replace React Native as the leading cross-platform technology of choice.

It’s not.

I’ve stuck my toes into Flutter’s clear but cold waters, and in my opinion, it suffers from several critical issues.

Note that this article has generated a lot of passionate comments from the Flutter community, both pro and con. I strongly suggest you read the article and then read the comments section below for points and counter-points.

It’s Not React Native

You can’t discuss cross-platform technologies without discussing React Native. …

Quite a few people have written articles on SwiftUI, SwiftUI state management, and on SwiftUI application architecture. And quite a few of those articles were written by people eager to take their favorite iOS application architecture and port it over to SwiftUI.

Hence we’ve had articles telling us how to use MVVM with SwiftUI. Or VIPER. Or Clean. Or those that insist that we need to impose a React/Redux architecture on top of it.

But most of them have a problem.

You see, many of the architectures and methodologies that we’re attempting to inflict on SwiftUI were constructed and honed on applications built with UIKit and that relied on UIKit behaviors. …