In working with SwiftUI you may have noticed that NSManagedObject is not a particularly correct implementation of ObservableObject. Your NSManagedObject does not publish changes when any of its @NSManaged properties are mutated.

There’s an easy fix for this:

open class ManagedObject: NSManagedObject {
    override public func willChangeValue(forKey key: String) {
        super.willChangeValue(forKey: key)

        objectWillChange.send()
    }
}

Simply tweak your model classes to inherit from ManagedObject, instead of NSManagedObject, et voilà  - your managed objects will behave as expected.

Explanation

This essentially hooks into a core NSManagedObject method - willChangeValue(forKey:) and overrides it to also publish changes to the objectWillChange publisher when invoked.

I recently encountered a small but annoying bug with property wrappers in Swift 5.1. When building the following code for archiving/profiling:

@propertyWrapper
public struct Foo<T> {
    public let wrappedValue: T?

    public init(wrappedValue: T? = nil) {
        self.wrappedValue = wrappedValue
    }
}

The compiler throws a Segmentation fault: 11:

While running pass 0 SILModuleTransform "SerializeSILPass".

The fix is rather simple. Simply break init(wrappedValue:) (which contains a default nil value) into two separate initializers, like so:

@propertyWrapper
public struct Foo<T> {
    public let wrappedValue: T?

    public init(wrappedValue: T?) {
        self.wrappedValue = wrappedValue
    }

    public init() {
        self.init(wrappedValue: nil)
    }
}

Currently, as of Xcode 11.1, Apple provides no way for developers to specify a cell separator style for SwiftUI’s List.

Having run into this issue myself, I finally stumbled upon a workaround:

UITableView.appearance().separatorStyle = .none

List seems to respect the UITableView appearance proxy. While this may change in future iOS releases, it’s a good enough solution for the time being.

There is one major caveat - UITableView.appearance() affects the appearance of all Lists in the application. How can we restrict our desired appearance to a single screen?

We utilize a view’s lifecycle events, View.onAppear and View.onDisappear, to set and then unset our custom appearance for a given view.

List {
    Text("a")
    Text("b")
    Text("c")
    Text("d")
}.onAppear {
    UITableView.appearance().separatorStyle = .none
}.onDisappear {
    UITableView.appearance().separatorStyle =

This article may be considered a condensed version of the (highly-recommended) WWDC19 talk, “Data Flow Through SwiftUI”, along with a few thoughts and insights of my own. It represents my own, current understanding of data flow in SwiftUI, derived from experimentation over the past two months.

Let’s start with an important quote from the aforementioned talk:

Data is a first class citizen in SwiftUI.

This is the crux of what makes SwiftUI not only so beautifully elegant, but also extremely ergonomic.

The Two Key Principles

SwiftUI is designed to be declarative and functional. As such, data flow in SwiftUI revolves around two key principles:

• Reading data creates dependencies.
• Every piece of data has a source of truth.

This all seems quite abstract, and so we shall revisit a popular definition for declarative programming:

“You know, imperative programming is like* how you do...

The mellow embrace of blue,
With a silent whisper of white,
Dipped gently in lavender,
Flowing fill into sight.

The quiet stretch of infinity,
Peering deep into the soul,
An ocean of serenity,
Washing away the toll.

An impossible canvas beheld,
Each stroke brushed past,
Dark painted darker,
A memory etched last.

Persuasive, pristine, perfect,
A shapeless void in flight;
That, my dear,
Is the beauty of night.

With Xcode 11 beta 4, Apple deprecated SwiftUI’s View.relativeSize function (as well as View.relativeWidth and View.relativeHeight).

The relativeWidth(_:), relativeHeight(_:), and relativeSize(width:height:) modifiers are deprecated. Use other modifiers like frame(minWidth:idealWidth:maxWidth:minHeight:idealHeight:maxHeight:alignment:) instead. (51494692)

For those dismayed by these changes, there’s an easy reimplementation available using GeometryReader:

extension View {
    public func relativeHeight(
        _ ratio: CGFloat,
        alignment: Alignment = .center
    ) -> some View {
        GeometryReader { geometry in
            self.frame(
                height: geometry.size.height * ratio,
                alignment: alignment
            )
        }
    }

    public func relativeWidth(
        _ ratio: CGFloat,
        alignment: Alignment = .center
    ) -> some View {

PresentationLink (in SwiftUI) seems to be broken in Xcode 11 beta 3.

It succeeds in presenting a modal view controller the first time, but stops working thereafter.

As noted in this StackOverflow post, this seems to occur when embedding a PresentationLink within a NavigationView, with the following warning printed to console:

[WindowServer] display_timer_callback: unexpected state (now:1abc3d3ccc7 < expected:1abc3d91a0f)

This bug has existed since Xcode 11 beta 1 (back when PresentationLink was called PresentationButton), which is quite alarming given the fact that we’re on beta 3 now.

I’ve written a quick and dirty workaround for this:

private enum SetPresentedViewKey: EnvironmentKey {
    static var defaultValue: (AnyView?) -> () {
        fatalError()
    }
}

private extension EnvironmentValues {
    var setPresentedView: (AnyView?) -> () {
        get {

I’m stuck in a plane,
Soaring dreamless through the night.

I’m stuck in a plane,
Flying aimless out of sight.

I’m stuck in a plane,
My thoughts are stuck too.

I’m stuck in a plane,
This poem sucks,
Boo.

3D Touch is a woefully underrated feature in today’s modern iPhones. There are now (what I consider to be) credible reports suggesting that Apple intends to drop this feature in their 2019 iPhone models.

This is highly unfortunate if true.

What is 3D Touch?

Ultimately, this is our focus. 3D Touch is something we’ve worked on for a long time—multi, multi, multi years

3D Touch was introduced circa 2015 with the iPhone 6S. It’s the extra informational input of pressure with every touch on the screen. Apparently it was something they’d been working on for a while.

Why is going away?

Simply put - it failed to become an idiomatic element of the iPhone’s UX language.

Many have speculated on why this is so. Here are the top 5 reasons that I have surmised:

1. A lack of marketing.
2. Inconsistent availability across iOS.
3. Lack of any visual cues to enable discovery.
4. Lack of developer...