The @Environment modifier in SwiftUI is a core data-flow primitive, that allows one to access environment values set by the parent.

Example usage:

struct Foo: View {
    @Environment(\.colorScheme) var colorScheme

    var body: some View {
        Group {
            if colorScheme == .light {
                Text("Light")
            } else {
                Text("Dark")
            }
        }
    }
}

This is all well and good - but note that @Environment is implemented as a property wrapper and cannot be used without a housing View structure.

In prototyping code heavily reliant on @Environment, this can feel cumbersome and boilerplate-y. Hence, I wrote a simple generic wrapper to solve this problem:

public struct EnvironmentValueAccessView<EnvironmentValue, Content: View>: View {
    private let keyPath: KeyPath<EnvironmentValues, EnvironmentValue>
    private let content:

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 {

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...

Take the following code:

func foo() {
    let bar = NSObject()

    let f: (@convention(c) () -> ()) = {
        print(bar)
    }
}

This will not compile. You will instead be presented with the following error:

error: a C function pointer cannot be formed from a closure that captures context

While you are unlikely to ever encounter this error in typical iOS development, it may arise as the result of, say, an attempt to interface with a low-level C library/framework. In my case, I was trying to construct a parameter for a low-level POSIX function (pthread_create), which only accepted a C function pointer.

There is a (dirty) workaround:

import ObjectiveC
import Swift

func cFunction(_ block: (@escaping @convention(block) () -> ()))
    -> (@convention(c) () -> ()) {
    return unsafeBitCast(
        imp_implementationWithBlock(block),
        to: (@convention(c) () -> ()).self