I instantly felt an affinity to Apple.

My mom would end up bringing home or buying an LC “pizza box,” a Macintosh TV (I still have it!), a Performa 6300CD, a PowerBook G3 Lombard, a G3 Blue & White, a TiBook, and on and on.

The most anticipated event of each month was a new issue of MacAddict arriving in my mailbox and I was particularly impacted by issue #54 with the cover story “Build Your Own Apps.”

I fired up the included demo of RealBASIC. I was reading about cryptography at the time and made a simple letter frequency analysis app. On my computer! I made it! It worked exactly the way I wanted it to work.

I was hooked. I was also interested in exploring the other option in the magazine: Cocoa. This turned out to be a pretty important article for my future career. Thank you to the writer, Ian Sammis!

I wanted to build an app for everything. I made a chat app, I made a music guessing game, I made a screensaver that would simulate a kernel panic for April Fools’ Day. I took classes in high school, but had to do programming on Windows with C++. It was an awful experience, but I knew I wanted to do this for a living. And I knew what platform I wanted to do it on.

I went into college knowing exactly what major I wanted: Computer Science. And that meant Java at that time. So I did Java at school and then kept learning Objective-C to fuel my need to build native, beautiful apps for the computer I loved.

Then came the iPhone, running iPhone OS 1.0, and it was incredible.

I wanted to build apps for it! But the “sweet solution” wasn’t so enticing. I eventually found a group of hackers out there who found a way to get their Objective-C code running on-device. All I had to do was perform this thing called a "jailbreak," install Cydia, install OpenSSH, get an ARM cross-compilation setup, run some Makefiles, and BOOM! I built an app I called MobileBeat, a rudimentary step sequencer.

I was running the same code that Apple was running. And I could poke around at how they built things using the same tools I had used on the Mac to dump all the classes of Apple’s built-in apps. I was learning to build for this new Apple platform.

Then came the SDK with iPhone OS 2.0. I wanted to ship something to the App Store, but I was more interested in shipping something that wasn't possible with the official APIs. I wanted copy and paste, which surprisingly didn't come in 2.0, so I built a library to do it. I also wanted a system-wide search of Contacts, calendar events, Safari history, etc. That didn't come in 2.0... or 3.0, or 4.0, or 5.0, or 6.0. So I built an app called "Searcher" to do that. I also wanted drag and drop between apps, so I built a library to do that. Everything I could dream of with this new platform, I could build.

I lived in Xcode. I loved building out my UI in Interface Builder. These free tools were incredible and unlocked a whole career for me.

I received a WWDC scholarship in 2006, 2007, and 2008. In 2008, I spoke with a mobile agency doing J2ME/Brew work that wanted to take a flyer on this new platform and a young kid (almost) out of college to build their first iPhone app. I moved to SF and started making a living doing what I always wanted to do: building apps for the platforms from a company whose products I had loved since I was a kid.

And I've stuck with it. I left that agency with a few others about 15 years ago and started my own agency. We focused on mobile apps, but my focus was fully on the Apple platforms. As Apple made new platforms, I built for them: tvOS, watchOS, iPadOS, visionOS, heck, we even built an iMessage app! Apple created the ecosystem and community, and I built my business around it.

Apple's impact on me continues today. The tools are changing, and the way I'm writing software is changing rapidly, but I’m still building, and I’m excited for the next platform (glasses? HomePod with a screen? pendant?). I am a user, developer, and just plain fan of Apple, and here's to another 50 years for them, and another 30 years of their impact on me 🎉

I started with something like this:

struct EntryField: View {
    let titleKey: LocalizedStringKey
    @Binding var text: String

    let onSend: (String) -> Void

    var body: some View {
        TextField(titleKey, text: _text, axis: .vertical)
            .onSubmit {
                onSend(text)
            }
    }
}

If using an AppKit macOS application, you get the desired return key behavior for free. You also get it with iOS / iPadOS and a connected hardware keyboard. However, when using a Catalyst macOS app target (at least on Sonoma), the return key always inserts a return character and never triggers the onSubmit closure. 🤔

So as a workaround, you can add an invisible Button that responds to the return and performs the passed in closure.

TextField(titleKey, text: _text, axis: .vertical)
    .onSubmit {
        onSend(text)
    }
    .background {
        Button {
            onSend(text)
        } label: {
            EmptyView()
        }
        .keyboardShortcut(.defaultAction)
        .opacity(0)
    }

Now the field behaves as expected on all platforms. The return key sends the message, and option return inserts a newline. This is a simple solution (hack?) that works well for my little app, but if you have a better solution I'd love to hear it!

To start, declare an EnvironmentValues extension which includes a read-only isPreview value. This peeks into the current process environment and looks for XCODE_RUNNING_FOR_PREVIEWS, which is set to "1" if Xcode is running your preview. As an optimization, you can optionally compile this code out if the project isn't in the DEBUG configuration. This saves checking the process info for a value that definitely isn't there.

public extension EnvironmentValues {
    var isPreview: Bool {
        #if DEBUG
        return ProcessInfo.processInfo.environment["XCODE_RUNNING_FOR_PREVIEWS"] == "1"
        #else
        return false
        #endif
    }
}

Then usage is pretty straightforward. Declare your @Environment var and use your new-found Bool to alter your view based on it being in preview mode.

struct MyView: View {
    @Environment(\.isPreview) var isPreview

    var body: some View {
        Group {
            if isPreview {
                Text("This is a preview!")
            } else {
                Text("This is not a preview!")
            }
        }
    }
}

Bonus tip: In figuring out what environment is available in a preview, I stumbled upon this super useful trick that I somehow missed when it was shared. It's not often you should need to debug something happening in a preview, but now you can!

Edit 8/16/23: Unfortunately the above referenced ability to debug SwiftUI previews was taken out in Xcode 13. Oh well! You can at least see logs for previews, so attaching the debugger isn't as necessary as it used to be.

1. Offset change callback (via UIScrollViewDelegate.scrollViewDidScroll(_ scrollView: UIScrollView) in UIKit)
2. Scroll end point control for pagination (via UIScrollViewDelegate.scrollViewWillEndDragging(_ scrollView: UIScrollView, withVelocity velocity: CGPoint, targetContentOffset: UnsafeMutablePointer<CGPoint>) in UIKit)
3. Animation / setting of offset (via UIScrollView.setContentOffset(_ contentOffset: CGPoint, animated: Bool) in UIKit)

Luckily, for #1 we can use GeometryReader and our own container view to achieve the same view containment behavior as ScrollView, but add a Binder<CGPoint> which can give us the offset.

To begin, we start with all the same API available to ScrollView:

public struct OffsetScrollView<Content>: View where Content : View {

    /// The content of the scroll view.
    public var content: Content

    /// The scrollable axes.
    ///
    /// The default is `.vertical`.
    public var axes: Axis.Set

    /// If true, the scroll view may indicate the scrollable component of
    /// the content offset, in a way suitable for the platform.
    ///
    /// The default is `true`.
    public var showsIndicators: Bool

    ...
}

But we want to add a Binder<CGPoint> to the mix and an initializer that initializes all our properties and a private @State to hold the initial offset:

/// The initial offset of the view as measured in the global frame
@State private var initialOffset: CGPoint?

/// The offset of the scroll view updated as the scroll view scrolls
@Binding public var offset: CGPoint

public init(_ axes: Axis.Set = .vertical, showsIndicators: Bool = true, offset: Binding<CGPoint> = .constant(.zero), @ViewBuilder content: () -> Content) {
    self.axes = axes
    self.showsIndicators = showsIndicators
    self._offset = offset
    self.content = content()
}

Now in the body property, we'll want to return a normal ScrollView, but add our own view above the provided content that can utilize GeometryReader to get a callback for position. By passing the frame origin of this empty, 0x0 view into our Binder<CGPoint> we can get a callback for geometry changes that will allow us to update the binding and subsequently any listeners to the binding:

public var body: some View {
    ScrollView(axes, showsIndicators: showsIndicators) {
        VStack(alignment: .leading, spacing: 0) {
            GeometryReader { geometry in
                Run {
                    let globalOrigin = geometry.frame(in: .global).origin
                    self.initialOffset = self.initialOffset ?? globalOrigin
                    let initialOffset = (self.initialOffset ?? .zero)
                    let offset = CGPoint(x: globalOrigin.x - initialOffset.x, y: globalOrigin.y - initialOffset.y)
                    self.offset.wrappedValue = offset
                }
            }.frame(width: 0, height: 0)

            content
        }
    }
}

You'll notice a Run 'view' which is pretty simple and lets us just execute a bit of code without affecting the layout:

struct Run: View {
    let block: () -> Void

    var body: some View {
        DispatchQueue.main.async(execute: block)
        return AnyView(EmptyView())
    }
}

Putting it all together, we now have a way to access the offset of the ScrollView and update a @State wrapped property. This can be used within other Views in our hierarchy to achieve some interesting effects.

In this watchOS example, we can use it to achieve an effect similar to the built-in News app where as you scroll the content, a header recedes by changing opacity and position based on the scroll offset.

This kind of behavior wasn't possible on previous versions of watchOS, so this serves as a perfect example of why watchOS + SwiftUI is an awesome combo! 🎉

If you'd like to mess around with the watchOS project demonstrating this, here's the zip

Update 10/28/19

Thanks to @dmcgloin on Twitter for pointing out that Xcode 11.2 beta 2 was throwing a helpful warning that the original code was "Modifying state during view update, this will cause undefined behavior." One workaround was to kick the closure inside the Run view to run asynchronously. The above inline code and the sample zip have been updated with this workaround.

Template *template = [[Template alloc] initWithTemplateString:@"/users/:username:/:id:"];

NSString *fullString = [template fill:@{
    @"usernane" : @"zac",
    @"id" : @(42)
}];

// now fullString should be: "/users/zac/42"

What's wrong with that? Well, first of all the identifiers in the template string have to match the strings in the dictionary. If one is wrong, then the other won't be inserted and you'll get a runtime issue. In fact, I snuck in "usernane" above instead of "username" and I bet you didn't notice!

The other issue that can come up is what kinds of values are supported? If you are a particularly lazy developer, you might define the parameters of the fill method as being: NSDictionary<NSString *, id>. And if someone passes in an unsupported type, just ignore it I guess?

We can do better with Swift.

What if we utilize ExpressibleByStringInterpolation and key paths to create something that doesn't have the above issues?

struct Values {
  let username: String
  let id: Int
}

let template: Template<Values> = "/users/\(keyPath: \.username)/\(keyPath: \.id)"
let fullString = template.fill(with: Values(username: "zac", id: 42))

So now we have something that shows exactly what value should go where in the string. And more importantly, those values are strongly typed to be something that can definitely be inserted into the template. If I mistype "usernane" again, I'll get a compiler error.

There are a couple down-sides though:

1. It requires a definition of a type to 'contain' the inserted values so the key paths have something to reference.
2. Because the interpolation syntax in Swift uses \() and the key paths use \. there are a lot of backslashes. Couple that with our current use-case of a path which has several forward slashes and visually parsing the string can be difficult.

(1) doesn't bother me too much, but (2) makes the string a little tough to read. I'm not sure what would be better, but another approach is to use overloading to use "+" as a concatenation operator. So you'd end up with something like this: "/users/" + \.username + "/" + \.id. Is this better? 🤷‍♂️

How to build it?

We first need to control the type being passed to us to fill values in the template, but in a way that allows developers to extend support for custom types in the future. We can accomplish this with a protocol:

public protocol TemplateInsertable {
    var stringValue: String { get }
}

extension String: TemplateInsertable {
    public var stringValue: String { return self }
}

extension Int: TemplateInsertable {
    public var stringValue: String { return "\(self)" }
}

Next we'll need the Template type which can handle 'appending' TemplateInsertables or can append key paths to TemplateInsertables. We have to store these components in a way that allows us to go through and construct the final template string with different passed in values. Below is one way to accomplish that where we keep a string internally of all the strings that have been appended to the template. And when a key path is appended, the future index in that string where the value will be inserted is stored along with the key path itself.

This lets us enumerate through those key paths and insert the string values into the positions which were defined in the interpolation.

public struct Template<T> {

    private var template: String = ""
    private var keyPaths: [(offset: String.IndexDistance, keyPath: PartialKeyPath<T>)] = []

    mutating func append<U: TemplateInsertable>(keyPath: KeyPath<T, U>) {
        keyPaths.append((offset: template.count, keyPath: keyPath))
    }

    mutating func append(string: TemplateInsertable) {
        template.append(string.stringValue)
    }

    public func fill(with value: T) -> String {
        var fullString = template
        var indexOffset: String.IndexDistance = 0
        for item in keyPaths {
            let stringValue = (value[keyPath: item.keyPath] as! TemplateInsertable).stringValue
            let insertionIndex = fullString.index(fullString.startIndex, offsetBy: item.offset + indexOffset)
            fullString.insert(contentsOf: stringValue, at: insertionIndex)
            indexOffset += stringValue.count
        }

        return fullString
    }
}

Now comes the ExpressibleByStringInterpolation piece. The protocol requires declaring a type conforming to StringInterpolationProtocol which will be called by the standard library based on the components in the order required to 'build up' the full instance of your type. An example from the docs explains that if you have ("The time is \(time)." as MyString) in your source, the compiled code will be similar to:

var interpolation = MyString.StringInterpolation(literalCapacity: 13, 
                                                 interpolationCount: 1)

interpolation.appendLiteral("The time is ")
interpolation.appendInterpolation(time)
interpolation.appendLiteral(".")

MyString(stringInterpolation: interpolation)

If we implement StringInterpolationProtocol, we can call our internal append() functions. Note the type of the appendInterpolation function. We get to define the number of parameters, the parameter name and importantly for us, the type constraints on the parameters. Now we can be sure that all elements in our string interpolation will definitely be from our generic type T and be pointing to a value of type U which conforms to TemplateInsertable.

extension Template: ExpressibleByStringInterpolation {

    public init(stringInterpolation: StringInterpolation) {
        self = stringInterpolation.template
    }

    public struct StringInterpolation: StringInterpolationProtocol {

        fileprivate var template: Template<T>

        public init(literalCapacity: Int, interpolationCount: Int) {
            template = Template<T>()
        }

        mutating public func appendLiteral(_ literal: String) {
            template.append(string: literal)
        }

        mutating public func appendInterpolation<U: TemplateInsertable>(keyPath: KeyPath<T, U>) {
            template.append(keyPath: keyPath)
        }
    }
}

Conclusion

ExpressibleByStringInterpolation is a powerful way to build some interesting functionality out of syntax that appears like it's part of the language itself. Apple is going to be allowing more hooks like this in the future. Along similar lines, Property Delegates is another possible upcoming feature of Swift which could allow developers to define how properties store their values.

Type-safety can be tricky and require jumping through some hoops. Fortunately, they are hoops you jump through once when creating interfaces for your future self or other developers to use. Then, no more hoops. Just auto-completable, typo-proof code.

If you'd like to mess around with the Playground, here's the zip