Zach Waugh

WWDC 2025 Wish List

Mon, 09 Jun 2025 16:00:00 +0000

A list of things in no particular order that would solve problems for me in my current apps. There’s no bearing here on whether I think any of this is actually likely or not. I think most of it is rather unlikely, but we’ll know soon enough.

SwiftUI: Dramatically increase APIs available

There’s still way too much you can’t do with SwiftUI directly. I’d love to see them come out and double the surface area of SwiftUI. They say it’s the best way to make apps, but in Artifacts, I drop-down to UIKit/AppKit a lot. I have to hack in a lot of different pieces to get the features and/or performance I want. Of the APIs not available, the biggest missing piece to me where I drop-down to UIKit/AppKit is for UICollectionView/NSCollectionView. It’s a huge hole in SwiftUI for being able to make performant, complex interfaces. It’s long-overdue.

SwiftUI: Improved cross-platform support

Artifacts is absolutely littered with #if os(macOS) blocks. There’s a ton of apis only available on one platform or the other. There’s many other things that just behave differently. I’d like them to both close the gap in the available apis and also just make it easier to tweak things per platform. Even just using different font sizes or colors on different platforms results in a big mess of code for me.

SwiftUI: Backporting

This is the a long-shot and I don’t think they’ll do it if they haven’t already. But part of the problem with SwiftUI is just moving too slow and then having that stuff locked to the latest version. It means something introduced today you might not be able to use for a year. Android has great support for back-porting and something Apple should have done a long time ago. At least for the last major version, everything should just work. I don’t care if the app bundle gets a little bigger (or preferably it gets dynamically loaded by the OS and shared amongst apps), but it would fantastic to use newer apis today.

AI/LLM

I want an LLM available to use from my app. I was hoping this would come last year, and never did. I don’t care if it’s on-device, or on the cloud, or just an Apple provided and secured proxy to OpenAI or Anthropic. There should be a built-in way to use a multi-modal LLM from Swift. I already have a lot of use cases for it in Artifacts and I’ll use a 3rd-party if necessary, but would love to have the option available.

App Store/App Review

I’ve never cared all that much about the 30%. It’s high and I would love to pay less, but it covers a lot. Dropping down to 15% as in the small-business program is totally reasonable to me. What I hate is the app review process. Specifically, my main gripe as I’ve said for years is arbitrary rejections. I think Apple should not reject any app unless they’re malware/scams/illegal. Everything else should be a green-light. If you’re the 100th app in a crowded category, let the market decide if the want to buy it or not. Maybe you make it for 10 people that you know and they love it. That’s fantastic and should be supported. Especially in the world of AI-assisted development where velocity is only ever increasing, this desperately needs to change. Automate the scans, approve all apps within a day, and deep review things that are reported or have suspicious activity.

Xcode/Ecosystem

You should be able to build an iOS app or macOS app completely with VS Code. Keep building Xcode, but make other IDEs a first-class supported option. If you’re not going to make Xcode fully extensible (I can’t even configure Xcode to format on save…) or integrate AI into at as faster pace, give people the choice. I think it would go a long way to making Swift a more friendly choice to adopting on other platforms or for the back-end if Apple met people where they are.

SwiftUI Tip: Using AnyShapeStyle

Wed, 26 Mar 2025 13:00:00 +0000

A quick tip that took me too long to realize and easy for someone new to SwiftUI to get stuck on. Say you have a piece of UI where you want to change the background depending on the state. In this case, we want to have no background (using .clear) or relying on one of the built-in styles like .tertiary or .background or maybe a material like .thinMaterial . Try this out with a ternary operator and you’ll get any number of errors that aren’t immediately clear about the cause.

Let’s try .tertiary and we’ll get an error that it can’t be used on ShapeStyle even though we know it can be used fine without the ternary operator

Let’s try another, here’s using .thinMaterial and we get yet another confusing error

One more and I swear we’ll get to the point soon. Let’s try .background

Ah, yet another error, but this one is actually helpful! If you’ve spent much time in Swift, it’s probably obvious all along, but this a type problem. The .background() modifier we’re using is expecting a ShapeStyle. We have .clear which a Color, .tertiary which is a HierarchicalShapeStyle, .background which is a BackgroundStyle and .thinMaterial is a Material. They all individually conform to ShapeStyle so they work correctly when used in isolation, or they will work when using the same concrete type (.e.g - two Colors or two Materials, etc), but they can’t be directly combined in a ternary.

You may have reached for a conditional like this or a modifier to do the same, but that’s not ideal as it complicates the view hierarchy and won’t work as expected for animations since those are two distinct views.

if isSelected {
    Rectangle()
        .background(.thinMaterial)
} else {
    Rectangle()
        .background(.clear)
}

The trivial fix here is to use AnyShapeStyle to type-erase the underlying concrete types so they can be combined. All of these work as expected.

Rectangle()
    .background(isSelected ? AnyShapeStyle(.thinMaterial) : AnyShapeStyle(.clear))

Rectangle()
    .background(isSelected ? AnyShapeStyle(.tertiary) : AnyShapeStyle(.clear))

Rectangle()
    .background(isSelected ? AnyShapeStyle(.background) : AnyShapeStyle(.clear))

That was a long-winded explanation for a one-line fix, but hopefully helpful if you’re new to SwiftUI when you see a similar problem in the future (and you will), you’ll know what tool to reach for. There are a number of other type-erasing wrappers you might need in other cases like AnyShape or AnyGesture when confronted with the same problem.

Detecting image transparency with Swift

Wed, 13 Nov 2024 13:00:00 +0000

This is the first of hopefully many posts about some behind the scenes things in developing Artifacts, which is a new native image + link organizer for iOS and macOS, currently in beta.

When you view an image in Artifacts, we round the corners, give it a border, and add a drop shadow which looks really nice (I can say that since Jordan designed it), especially on iOS.

Artifacts item detail on iOS.
(And don't worry, if you start zooming or tap the screen to hide the chrome, it will disable all effects so you can see the original image)

Almost immediately though we ran into a problem. That treatment doesn’t work well on all images, especially macOS screenshots that have a transparent background and their own drop shadow, of which I take a lot. Here’s a screenshot I had saved of some UI in the ChatGPT app for macOS. We add border over empty space and end up with double shadows.

Artifacts item detail on macOS (before)

So we need to detect which images have a built-in drop shadow and which don’t. I considered a few approaches here such as looking at the pixels in the corners and seeing if they are fully transparent, but I realized we don’t need to try to determine if the image has a drop shadow, we can make a simpler rule: does the image contain any transparency? If opaque, we apply our effects, if it contains any transparency, we disable it.

Detecting Transparency

There’s a few ways you can go about this. You can check if the image format has an alpha channel, but that’s not reliable. If it has no alpha channel, you can know it’s opaque, but the presence of an alpha channel doesn’t indicate the image has transparency. Many images will contain an alpha channel in which the alpha component for every pixel is 1. The simplest method I came up with (and if there is be a better way let me know!), was to determine the average color of an image, and if that single color has an alpha < 1, consider it non-opaque and skip our effects.

Luckily, I had come across and saved (in Artifacts, naturally) a post Christian Selig had written about getting the average color - https://christianselig.com/2021/04/efficient-average-color/. Christian’s code didn’t care about the alpha value, so I had to make just a few simple changes. Here’s the final version which is a bit simplified and condensed, but all credit goes to Christian for this. See his original blog post that has more details and his code for the comments I stripped out:

// PlatformImage and PlatformColor here are just conditional
// typealiases depending on the platform with some convenience
// methods to provide a unified api
public extension PlatformImage {
    // Via https://christianselig.com/2021/04/efficient-average-color/
    var averageColor: PlatformColor? {
        #if os(macOS)
        guard let cgImage = self.cgImage(forProposedRect: nil, context: nil, hints: nil) else { return nil }
        #else
        guard let cgImage else { return nil }
        #endif

        let size = CGSize(width: 40, height: 40)
        let width = Int(size.width)
        let height = Int(size.height)
        let totalPixels = width * height
        let colorSpace = CGColorSpaceCreateDeviceRGB()
        let bitmapInfo: UInt32 = CGBitmapInfo.byteOrder32Little.rawValue | CGImageAlphaInfo.premultipliedFirst.rawValue

        guard let context = CGContext(data: nil, width: width, height: height, bitsPerComponent: 8, bytesPerRow: width * 4, space: colorSpace, bitmapInfo: bitmapInfo) else { return nil }

        context.draw(cgImage, in: CGRect(origin: .zero, size: size))

        guard let pixelBuffer = context.data else { return nil }

        let pointer = pixelBuffer.bindMemory(to: UInt32.self, capacity: width * height)

        var totalRed = 0
        var totalBlue = 0
        var totalGreen = 0
        var totalAlpha = 0

        for x in 0..<width {
            for y in 0..<height {
                let pixel = pointer[(y * width) + x]

                let r = UInt8((pixel >> 16) & 255)
                let g = UInt8((pixel >> 8) & 255)
                let b = UInt8((pixel >> 0) & 255)
                let a = UInt8((pixel >> 24) & 255)

                totalRed += Int(r)
                totalBlue += Int(b)
                totalGreen += Int(g)
                totalAlpha += Int(a)
            }
        }

        let averageRed = CGFloat(totalRed) / CGFloat(totalPixels)
        let averageGreen = CGFloat(totalGreen) / CGFloat(totalPixels)
        let averageBlue = CGFloat(totalBlue) / CGFloat(totalPixels)
        let averageAlpha = CGFloat(totalAlpha) / CGFloat(totalPixels)

        return PlatformColor(
            red: averageRed / 255.0,
            green: averageGreen / 255.0,
            blue: averageBlue / 255.0,
            alpha: averageAlpha / 255.0
        )
    }
}

let image = //…some image
if image.averageColor.alpha < 1 {
    // Image is non-opaque
}

And the result is a nice clean presentation of all images:

Artifacts item detail on macOS (after)

You’re probably saying, but wait, what happens if the odd image here and there has a just a few pixels that are semi-transparent and really should be treated as opaque. If that happens, it’s easy enough to make a threshold for considering an image non-opaque instead of 1. In the screenshot above of the ChatGPT app, the average color alpha value is 0.7 so we could change the logic to something like alpha < 0.9 or something and would probably be a safe cut-off.

Getting more from SwiftUI Previews

Wed, 10 Apr 2024 16:00:00 +0000

SwiftUI previews are one of the biggest advantages of SwiftUI to me, enabling you to build new UI almost as fast as you can type (when they work…). It really can’t be overstated how much creating UI without needing to do a build-run loop improves the developer experience. Besides building the UI though, one thing I rely on previews for is testing how a component looks during a variety of states, especially when those states are difficult or tedious to test manually.

Here’s a real-world example. At Rewatch, I build our screen recorder for macOS. The screen recorder has multiple different modes (Full-screen, region, window, GIF, etc), and for each mode it can be in a variety of states. With all the possible permutations, it can be difficult to ensure the toolbar looks good in every state and be sure that changing something in one state doesn’t break another. SwiftUI previews give us a few built-in tools for viewing some of these states, like the color scheme variants, but don’t nearly cover all the cases.

Luckily, we can do whatever we want. There’s nothing to prevent you from arranging your views in whatever way suits you best. What I like to do for a component like this which is fairly small (in pixels) is to customize the preview to view all the states at once. Here’s what this looks like in practice:

The code for this isn’t really important as the concept, but here’s what it looks like for anyone curious.

#Preview("Screen Recording (Full)") {
    controlsPreview(mode: .screenFull)
}

#Preview("Screen Recording (Region)") {
    controlsPreview(mode: .screenRegion)
}

#Preview("GIF") {
    controlsPreview(mode: .gif)
}

@ViewBuilder
private func controlsPreview(mode: ScreenRecorderConfiguration.Mode) -> some View {
    let states: [RecorderState] = [
        .idle,
        .preRecording,
        .preparingToRecord,
        .recording,
        .paused,
        .finishing,
        .finished,
        .canceled,
        .failed
    ]

    VStack(spacing: 16) {
        ForEach(states, id: \.self) { state in
            VStack(spacing: 4) {
                Text("\(state)")
                    .font(.system(size: 12, weight: .semibold))
                ScreenRecorderControlsView(
                    store: Store(initialState: ScreenRecorder.State(
                        recordingState: state,
                        mode: mode
                    )) {
                        ScreenRecorder.failing
                    }
                )
            }
        }
        Spacer()
    }
    .padding(32)
    .background {
        LinearGradient(colors: [.green, .blue], startPoint: .topLeading, endPoint: .bottomTrailing)
    }
    .frame(height: 800)
}

This makes a VStack of toolbar views, one for each state I care about, and now I can clearly see all views at once, and easily add/remove states as the design evolves.

A few things worth mentioning:

Viewing all states of every mode in one preview would be too much, so I break them out into their own top-level #Preview to make things a bit more manageable and can focus on a single mode at once.
For each preview, I have a helper function that loops through all the states that the screen recorder can be in and adds a view with that state and the label.
This toolbar is typically rendered as the content view of a window on top of the macOS desktop, so I just add a colorful gradient as the background to approximate a wallpaper and get a better idea of how it will look in production.
The finishing/finished/canceled/failed states are all temporary states. Once we hit any of those states, we’re going to immediately close the toolbar window and transition to a different view, so we just show an indeterminate progress indicator. We could skip rendering these entirely, but I like show them to ensure we don’t break them, even if they are only displayed briefly.
I use The Composable Architecture for this and all my features, which I can’t recommend enough. The ScreenRecorder reducer controls the state that drives this view and is well-tested, so this is more about ensuring the UI looks good.

This setup has been hugely beneficial for building and iterating on this type of UI. When we need to introduce or change a button, I can hop on a call with a designer or share a screenshot and instantly see all the states and where we might need to make a tweak and would be easy for a designer to jump in directly and make any changes, feeling confident they didn’t break anything.

Forcing an AppIntent to run in the main app process

Fri, 13 Oct 2023 16:00:00 +0000

In my new app Breaks, I’m in the process of adding interactive widgets and hit a subtle issue right off the bat. To add an interactive widget, you can add a Button to trigger an AppIntent. But in what process does that AppIntent run? Well, it depends.

The best answer I found is from Michael Gorbach (on AppIntents team) who explains it on Mastodon, but I’ll give you the gist here:

If your AppIntent is only in your widget target, it will run in the widget
If your AppIntent is in both your app and widget target, it will run in the app process if the app is running and not suspended. Otherwise, it will run in the widget process.
Same rules above apply whether it’s run from the widget or via Shortcuts
You can force your AppIntent to run in your app process by conforming it to one of a few different protocols

Why does this matter? Well, it might not depending on your setup. For Breaks, this posed a problem since I have a database in my app and to keep things simple, this database isn’t shared with the widget ¹. When the user creates a session, the app writes it to the database, as well as to shared UserDefaults, and triggers a reload to widget’s timeline. The widget can then read the current session from UserDefaults and then create the appropriate timeline from there.

Since the database isn’t shared, that means when the AppIntent is run in the widget, it can’t update the database. One option is to have the widget write to the shared UserDefaults and have the app read from there, but that is a bit more complex when we really just want the AppIntent to always run in the main app process, which luckily there are a few simple ways to do. The docs explicitly mention a few options:

If you adopt the LiveActivityIntent or AudioPlaybackIntent protocol, the system runs the app intent in the app’s process.

From the Mastodon thread linked above, it is also mentioned that conforming to ForegroundContinuableIntent works, which did the trick for me. The one caveat is that is not available in widgets, so you’ll have to conform it like so:

@available(iOSApplicationExtension, unavailable)
extension StartSessionIntent: ForegroundContinuableIntent { }

With that, you don’t have to change any other code, and the AppIntent will always run in your main app process. If you’re adopting interactive widgets, make sure to think about the context of that will execute and whether you have specific requirements that might require it to run in a particular process.

¹ I could share the database between processes, but that involves a lot of extra complexity and possible issues (see https://swiftpackageindex.com/groue/grdb.swift/v6.20.1/documentation/grdb/databasesharing for an in-depth explanation) that I'd like to avoid.

Improving sharing authenticated links on iOS

Tue, 18 Jul 2023 13:00:00 +0000

When you share a link using the system share sheet, iOS will automatically fetch the underlying page to get the metadata to render a rich preview for the link. This a problem though for links that require authentication. When iOS tries to fetch it, it will be redirected to a sign in page, and iOS will instead display the metadata for the sign in screen instead of the original link.

This makes sense for publicly shared links: you don’t want to leak private data, and iOS wouldn’t have access to it anyway. But in many cases, it provides a bad experience for all parties. The sharer might think they made a mistake or the wrong thing will be shared. The recipient will see a link with no context until they click through.

Authenticated links show Sign In page info

The Fix

Typically though, if we’re sharing something, we already have the context for it. What we need is a way to provide it ourselves instead of iOS trying to fetch it. We can do exactly that by providing our own LPLinkMetadata to the share sheet, which is the type that the share sheet populates under the hood with the metadata from the fetched URL.

We do this by creating a type that conforms to UIActivityItemSource and implementing the func activityViewControllerLinkMetadata(_ activityViewController: UIActivityViewController) -> LPLinkMetadata? method (docs). I created a small reusable type for this called URLShareItem to use throughout the app:

final class URLShareItem: NSObject, UIActivityItemSource {
    let url: URL
    let title: String
    let icon: UIImage

    init(url: URL, title: String, icon: UIImage) {
        self.url = url
        self.title = title
        self.icon = icon
        super.init()
    }

    func activityViewControllerPlaceholderItem(_ activityViewController: UIActivityViewController) -> Any {
        url
    }

    func activityViewController(_ activityViewController: UIActivityViewController, itemForActivityType activityType: UIActivity.ActivityType?) -> Any? {
        url
    }

    func activityViewControllerLinkMetadata(_ activityViewController: UIActivityViewController) -> LPLinkMetadata? {
        let metadata = LPLinkMetadata()
        metadata.title = title
        metadata.url = url
        metadata.originalURL = url
        metadata.iconProvider = NSItemProvider(object: icon)

        return metadata
    }
}

You can present a sheet with this item instead of a URL to provide the extra context:

func share() {
    // Provide the url and a relevant title/icon
    let item = URLShareItem(url: url, title: title, icon: appIcon)
    let activitySheet = UIActivityViewController(activityItems: [item], applicationActivities: nil)
    present(activitySheet, animated: true)
}

Now we can provide the actual title of the document instead of a sign in page and even customize the icon to be more accurate.

Customized title and icon

Unfortunately though, it’s not all roses. First, since we’re bypassing the network request, you have to provide your own icon instead of getting the favicon for free. Here we provide a relevant icon for the content we’re sharing, or you might use your own app icon if sharing a link to your app since that is most likely the same or similar as the website favicon image.

Second issue is that not all apps use the provided metadata, some will still just use the underlying URL and fetch it themselves, undoing all our hard work. Messages gets it right, and I’m hoping more apps will improve that, but I think this is still a worthwhile improvement since the user gets a better experience while sharing and confident that the URL they’re sharing has the correct context.

UX Improvement Bonus

Even if your links don’t require authentication and the fetching will work correctly, this can still be a nice UX improvement to implement. When you present a share sheet with a URL, iOS will immediately display the raw url address and placeholder icon for the URL while it fetches the metadata in the background. Once the URL has been fetched, it updates UI with the correct information, which doesn’t look great. If you provide the LPLinkMetadata as above, this request is skipped and the share sheet is presented immediately with the final data and no UI updates occur.

Share sheet with network fetch

Share sheet with provided metadata

Streaming messages from ChatGPT using Swift AsyncSequence

Wed, 26 Apr 2023 12:00:00 +0000

I was recently playing with the ChatGPT API (like everyone else in the world) and hit the point of needing to consume their streaming API in Swift. The API uses server-sent events to stream partial responses so you can update the UI in real-time as the response streams in. This gave me a chance to use a new protocol introduced in Swift 5.5 called AsyncSequence for the first time with URLSession. John Sundell has a great article that explains it more in depth, but the gist you can consume a sequence asynchronously as easy as you would iterating through an array:

for try await value in asyncSequence {
  // do something with `value`
}

To use that for HTTP requests to process data as it’s received, you can use a new URLSession method (as of iOS 15.0) that returns a tuple of (URLSession.AsyncBytes, URLResponse). The AsyncBytes type has methods to get an AsyncSequence of individual characters or entire lines. Using lines saves us a lot of work where we can let URLSession buffer until a newline is received and give us the whole message at once. I was surprised how easy it was to get this working in Swift for ChatGPT.

let (bytes, response) = try await URLSession.shared.bytes(for: request)

for try await line in bytes.lines {
  print(line)
}

Each line we get there will be partial response, and all we need to do is parse the message. That is less interesting, but here’s a demo of how it looks and a full code sample that you can run from the command-line to query ChatGPT and stream the messages in a simple Swift script is below.

Demo of streaming from ChatGPT in Swift from the command-line

import Foundation

/// Execute a streaming request to ChatGPT and prints the response as it comes in
/// Set OPENAI_API_KEY environment variable to a valid API key
/// This is simplified version to demonstrate using async sequences from an API in Swift
/// and is not production ready as it has almost zero error handling
///
/// Usage:
/// swift chat.swift <query>
///
guard let apiKey = ProcessInfo.processInfo.environment["OPENAI_API_KEY"] else {
  print("*** Error: No OpenAI API key provided! Set an $OPENAI_API_KEY environment variable and try again ")
  exit(1)
}

guard CommandLine.arguments.count == 2 else { 
  print("Usage: swift chat.swift \"<query>\"")
  exit(1)
}

let content = CommandLine.arguments[1]
let request = try makeRequest(content: content, apiKey: apiKey)
let (stream, _) = try await URLSession.shared.bytes(for: request)

for try await line in stream.lines {
  guard let message = parse(line) else { continue }

  print(message, terminator: "")
  fflush(stdout)
}

/// Make a URL request for the ChatGPT endpoint
/// https://platform.openai.com/docs/api-reference/chat/create
func makeRequest(content: String, apiKey: String) throws -> URLRequest {
  let query = Query(messages: [.init(role: "user", content: content)])
  let url = URL(string: "https://api.openai.com/v1/chat/completions")!

  var request = URLRequest(url: url)
  request.httpMethod = "POST"
  request.httpBody = try JSONEncoder().encode(query)
  request.allHTTPHeaderFields = [
    "Content-Type": "application/json",
    "Authorization": "Bearer \(apiKey)"
  ]

  return request
}

/// Parse a line from the stream and extract the message
func parse(_ line: String) -> String? {
  let components = line.split(separator: ":", maxSplits: 1, omittingEmptySubsequences: true)
  guard components.count == 2, components[0] == "data" else { return nil }

  let message = components[1].trimmingCharacters(in: .whitespacesAndNewlines)

  if message == "[DONE]" {
    return "\n"
  } else {
    let chunk = try? JSONDecoder().decode(Chunk.self, from: message.data(using: .utf8)!)
    return chunk?.choices.first?.delta.content
  }
}

/// Encodes the query
struct Query: Encodable {
  struct Message: Encodable {
    let role: String
    let content: String
  }

  let model = "gpt-3.5-turbo"
  let messages: [Message]
  let stream = true
}

/// Decodes a chunk of the streaming response
struct Chunk: Decodable {
  struct Choice: Decodable {
    struct Delta: Decodable {
      let role: String?
      let content: String?
    }

    let delta: Delta
  }

  let choices: [Choice]
}

Note: you need to set an environment variable for OPENAI_API_KEY to use it, then you can run swift chat.swift <query>

Creating a blurred window background with SwiftUI on macOS

Wed, 29 Jun 2022 21:30:00 +0000

I’ve been experimenting with using SwiftUI for some native macOS apps, and had trouble figuring this out initially. If you want a modern blurred window background for your macOS app from SwiftUI, there’s not a built-in way to do it (or at least that I could find, if there is, let me know!). Luckily, the code to do it is short and simple.

First, we need to set the background of the view to a NSVisualEffectView. That class or an equivalent is not yet available in SwiftUI, so we have to create a NSViewRepresentable to expose it to SwiftUI:

struct VisualEffectView: NSViewRepresentable {
    func makeNSView(context: Context) -> NSVisualEffectView {
        let effectView = NSVisualEffectView()
        effectView.state = .active
        return effectView
    }

    func updateNSView(_ nsView: NSVisualEffectView, context: Context) {
    }
}

Once you have that, you can add it as a background to your window’s main content view. The ignoresSafeArea() isn’t required, but looks better if you want to use the full-size content view and let the content go under the window titlebar.

struct BlurredWindowContentView: View {
    var body: some View {
        content
            .background(VisualEffectView().ignoresSafeArea())
    }
}

And that’s all you need to do. Here’s a screenshot of what that looks like as of macOS 12.3:

Example of a blurred window on macOS in SwiftUI

If you want more configuration for the VisualEffectView, you can add additional properties to the representable struct to configure the underlying NSVisualEffectView.

The full code and demo app is available here - https://github.com/zachwaugh/swiftui-examples.

Using Swift Playgrounds in an Xcode project

Mon, 14 Mar 2022 14:00:00 +0000

Swift playgrounds have been around for years, but I haven’t found them all that useful so far. I’ll spin up a playground now and then when I want to quickly see how a particular api works or iterate on a small function, but they’ve never been a crucial part of my workflow.

I was watching a Point-Free episode the other day and I noticed they had a playground in their Xcode project that also had full access to all the types in their app target, which I didn’t know you could do! A little searching shows that I missed this was added over a year ago in Xcode 12.5.

Xcode 12.5 release notes

Setup

The setup is really simple, just open your project, then go to Xcode > File > New > Playground, and be sure to select the option to add it to your existing project. I found I needed to close and reopen the project afterwards to get the playground to actually work. But after reopening, the playground can access all of your app types. You can even access packages that your app target depends on as well if you import them.

Playground accessing types from the app target as well as from packages shown in a demo app

This ends up taking playgrounds from a seldom used tool to being something I’ll integrate in every project from now on. As I write more SwiftUI, I find myself seeking the speed of that feedback loop in every part of development. Often I want to either explore how an existing thing works (like what kind of output do we get from this method) or figure out some new functionality (like spike out a new protocol), and doing it within the full app flow is too slow and tedious.

Now I have a built-in, live executing environment for exploring existing code, adding new code, and iterating on my app without needing to run the whole thing. You can even test views as well. Playgrounds still aren’t perfect — and I hope we see more improvements this year — but this gets a lot closer to the SwiftUI flow and so far is a big overall improvement to my workflow.

Using Swift Package Manager to distribute a 3rd-party binary framework

Fri, 18 Feb 2022 14:00:00 +0000

Recently, I had to integrate a dependency that wasn’t available via Swift Package Manager (SPM), which is my preferred dependency manager these days. The options available were CocoaPods and manual installation. I didn’t want to add CocoaPods for a for a single dependency, so that leaves manually integrating it. That typically involves manually downloading the framework and vendoring it into your repo, which I hate doing for a bunch of reasons:

Adds bloat to your repo, depending on how big the framework is
Makes it harder to track and manage which version of the dependency you’re using
Every time you have to update it, you have to track down the new link, download it again, delete the old one, and make a noisy diff when you really just want to bump versions.

It’s not the end of the world, but it’s a pain and this time I thought there has to be a better way, and luckily, there is! As of Swift 5.3, SPM supports binary targets. So that means all we need to do is make our own Package.swift with a target that points the 3rd-party’s binary framework. I had to do this recently with Amazon’s IVS SDK, and this was how I solved it:

// swift-tools-version:5.5
import PackageDescription

let package = Package(
    name: "AmazonIVSPlayer",
    products: [
        .library(name: "AmazonIVSPlayer", targets: ["AmazonIVSPlayer"])
    ],
    dependencies: [],
    targets: [
        .binaryTarget(
            name: "AmazonIVSPlayer",
            url: "https://player.live-video.net/1.7.0/AmazonIVSPlayer.xcframework.zip",
            checksum: "39c8b9f9423b0105d3e10b20a4cf3ebb72e7f5fd77ce4bdac68a6c6aa8b4a42a"
        )
    ]
)

You still have to do a little bit of work to update this package and tag the version when the vendor updates the framework, but I still prefer that over needing to manually manage it, since it means you get to treat it like all of your other dependencies. You can easily switch between versions in different branches, revert to older versions if there is a bug, etc. I’m unsure of the legality around creating a package to distribute someone else’s library, so I didn’t make this package public for others to consume.

One gotcha I encountered is SPM wants the binary target’s name to match the name of .xcframework provided, so make sure they are the same. If the vendor doesn’t provide the checksum on their site, you can easily compute the sha256 checksum on macOS with shasum -a 256 path/to/archive.zip

Hopefully, this is becoming a problem of the past now that SPM has support for resources and binary targets. I think it’s capable of covering the majority of use cases these days and it slowly seems to becoming the de facto means of distributing iOS and macOS libraries, but it’s still a nice tool to have in your toolbox.