.package(url: "https://github.com/pointfreeco/swift-composable-architecture", from: "1.15.0") // SCM
.package(id: "pointfreeco.swift-composable-architecture", from: "1.15.0")                   // registry

Tuist has two switches for the registry, and they do different things.

registryEnabled: true only tells SwiftPM where the registry is:

let tuist = Tuist(
    project: .tuist(
        generationOptions: .options(registryEnabled: true)
    )
)

During tuist generate it writes the registry config into App.xcworkspace/xcshareddata/swiftpm/configuration/, so you no longer have to run tuist registry setup yourself. That’s all it does. Only packages you declared with .package(id:) go to the registry, and every .package(url:) is still cloned from git.

--replace-scm-with-registry rewrites the SCM dependencies themselves:

let tuist = Tuist(
    project: .tuist(
        installOptions: .options(
            passthroughSwiftPackageManagerArguments: ["--replace-scm-with-registry"]
        )
    )
)

On tuist install (or plain swift package --replace-scm-with-registry resolve), SwiftPM asks the registry about every git URL in the graph, transitive dependencies included:

GET /identifiers?url=https://github.com/pointfreeco/swift-composable-architecture
→ 200 { "identifiers": ["pointfreeco.swift-composable-architecture"] }

If the registry knows the URL, SwiftPM downloads the package from the registry. If the registry doesn’t know it (404), that one package falls back to git. Your manifests can keep their URLs. For Xcode’s own package integration, the same switch is a per-machine default, IDEPackageDependencySCMToRegistryTransformation = useRegistryIdentityAndSources, which tuist registry setup writes for you.

Why mixing the two styles breaks without the flag. SwiftPM tells packages apart by identity, not by what’s inside them. For a URL dependency the identity is the last path component, so the TCA URL becomes swift-composable-architecture. For a registry dependency the identity is the scope.name string, so the same package becomes pointfreeco.swift-composable-architecture. Those are two different strings, so SwiftPM treats them as two unrelated packages.

Now say your app adds TCA by registry ID, and some library you depend on declares TCA by GitHub URL in its Package.swift. You can’t edit that file. SwiftPM ends up with two copies of the same package in the graph, each with a target named ComposableArchitecture:

multiple packages ('pointfreeco.swift-composable-architecture', 'swift-composable-architecture')
declare targets with a conflicting name: 'ComposableArchitecture'

Even when the names don’t collide, you can get two independently resolved versions of the “same” library linked into one app. With --replace-scm-with-registry, the library’s URL goes through /identifiers?url=, gets mapped to pointfreeco.swift-composable-architecture, and becomes the same node in the graph as your registry dependency. SwiftPM then has one package with both sets of version requirements to satisfy, resolves one version, and builds one module. (There’s also a narrower flag, --use-registry-identity-for-scm, which only does this identity mapping and still fetches over git.)

Takeaway: registryEnabled makes the registry available, and --replace-scm-with-registry makes the whole graph use it. Turning on only the first and switching a few dependencies to .package(id:) is the easiest way to end up with the duplicate-package error above, because the transitive URL dependencies stay on git under a different identity. Turn on both.

Package.swift            // fallback
Package@swift-5.9.swift  // used by Swift 5.9.x
Package@swift-6.swift    // used by any Swift 6.x

With git-based dependencies that just works, because SwiftPM checks out the whole repo and looks at the files itself. With a package registry it never sees the file list. It has to ask the server, which means the registry has to implement that part of the spec (SE-0292):

GET /{scope}/{name}/{version}/Package.swift
→ 200, body = Package.swift
  Link: <…/Package.swift?swift-version=6>; rel="alternate";
        filename="Package@swift-6.swift"; swift-tools-version="6.0"

GET /{scope}/{name}/{version}/Package.swift?swift-version=6
→ 200, body = Package@swift-6.swift
  (or 303 See Other → plain Package.swift if there isn't one)

The Link header lists the alternates that exist, and the swift-version query parameter fetches one of them. If a home-grown registry ignores the query param and always serves the plain Package.swift, resolution still “works”, just against the wrong manifest. You get the fallback’s tools version, platforms and dependencies, and you end up with build errors that never show up when the same package comes from git.

Takeaway: if you run your own registry (or proxy one), serving Package.swift isn’t enough. Advertise Package@swift-*.swift files in the Link header and honor ?swift-version=, or any package with versioned manifests will resolve differently than it does from git.

Text(line.text)
    .overlay(alignment: .bottomLeading) {
        Text(line.formattedTimestamp)
            .alignmentGuide(.bottom) { $0[.top] }
    }

The overlay is anchored .bottomLeading, so normally its .bottom guide lines up with the base text’s bottom edge — stacking the timestamp inside, over the last line. Overriding .bottom to resolve to $0[.top] (the overlay’s own top edge) tricks the alignment math: the position SwiftUI computes for “bottom” is now wherever the timestamp’s top is, which pushes the whole timestamp view upward until its top edge sits where its bottom used to — landing it flush above the text instead of overlapping it.

Takeaway: alignmentGuide’s closure can return any Dimension off the view’s ViewDimensions, not just an offset from the guide you named. Swap in a different edge when you need to flip which side of an overlay touches the anchor, instead of reaching for manual offsets or a separate VStack.

import Playgrounds

#Playground {
    let items = fetchItems()
    let total = items.reduce(0) { $0 + $1.price }
}

Open the file in Xcode and the canvas (⌥⌘Return) shows each statement’s result inline, same as classic Playgrounds, but scoped to that block and living right beside the production code it’s exercising — so it can call your app’s real types and functions directly, no copy-pasting into a standalone playground.

Takeaway: for quick “let me just try this” experiments against existing app code, reach for #Playground { } instead of spinning up a separate .playground file — it stays version-controlled with the code it tests and gets deleted in the same PR when you’re done.

Swift Language Version → SWIFT_VERSION
Enable Bitcode          → ENABLE_BITCODE
Other Linker Flags      → OTHER_LDFLAGS

// Debug.xcconfig
SWIFT_VERSION = 5.0

Takeaway: don’t guess or grep the internet for a setting’s underlying name — option-click it in the Build Settings editor and Quick Help gives you the exact key to drop into an .xcconfig.

-disableAnimations YES
-apiEnvironment staging

UserDefaults.standard.bool(forKey: "disableAnimations") // true, no code change needed
UserDefaults.standard.string(forKey: "apiEnvironment")   // "staging"

Even if the app has previously called UserDefaults.standard.set(false, forKey: "disableAnimations") and that’s sitting on disk, the scheme argument wins on every launch — it doesn’t persist, it just shadows whatever’s stored for the life of that process.

Non-string values need plist syntax, quoted so the shell doesn’t eat the parens:

-featureFlags '(chat, offlineSync)'

Takeaway: for temporary overrides — feature flags, locale testing, pointing at a different API environment — duplicate the scheme and set the argument there instead of adding #if DEBUG branches or hand-editing defaults in the simulator. Switching schemes becomes the toggle.

Question: how do you present a full-screen overlay above everything, including whatever sheet or full-screen-cover is already up — say, a forced login screen after a network disconnect? Short answer from the panel: SwiftUI doesn’t have an API for that, and that’s arguably on purpose.

Presentations in SwiftUI form a hierarchy. From the root, one fullScreenCover on top is easy:

struct RootView: View {
    @State private var showLogin = false

    var body: some View {
        ContentView()
            .fullScreenCover(isPresented: $showLogin) {
                LoginView()
            }
    }
}

But if something else already presented a sheet or cover deeper in the hierarchy, you can’t just reach in from outside and stack another presentation above it — you’d need to track every active presentation yourself and coordinate through that, since SwiftUI has no built-in registry of “what’s currently on top.”

When that coordination isn’t worth building, the panel’s fallback is to drop to UIKit: with the UIKit scene lifecycle you get direct access to UIWindowScene, so you can spin up a new UIWindow, give it a UIHostingController root, and position it above everything — SwiftUI content included.

final class OverlayWindowController {
    private var overlayWindow: UIWindow?

    func showOverlay(in scene: UIWindowScene) {
        let window = UIWindow(windowScene: scene)
        window.rootViewController = UIHostingController(rootView: LoginView())
        window.windowLevel = .alert + 1
        window.makeKeyAndVisible()
        overlayWindow = window
    }
}

The catch: this doesn’t scale past one team doing it. If two parts of the app both decide their thing “always needs to be on top,” it degenerates into whichever UIWindow was made last winning — a distributed layering decision with no source of truth, which is exactly the kind of bug SwiftUI’s presentation model is designed to prevent.

Takeaway: the panel’s real advice was to question the design brief before reaching for this. A forced full-screen cover over an arbitrary presentation state is disruptive to the user regardless of how it’s implemented — often the better fix is unwinding the navigation/presentation stack to a base state and restoring it after login, rather than layering on top of whatever’s currently shown. If you do need a global overlay, a single coordinated owner (not ad hoc UIWindows from wherever) is what keeps it from becoming a last-window-wins race.

Body invalidation in SwiftUI is invisible by default — a view can re-evaluate far more often than you’d guess, with nothing on screen to show it. The panel’s trick: give the view a random background color on every body evaluation, so each re-render literally flashes a different color.

struct RowView: View {
    let item: Item

    var body: some View {
        Text(item.title)
            .padding()
            .background(Color(
                red: .random(in: 0...1),
                green: .random(in: 0...1),
                blue: .random(in: 0...1)
            ))
    }
}

Since the color is generated inside body, it changes on every invalidation. A row that should only redraw when its own data changes but instead flickers on every parent update, scroll, or unrelated state change becomes obvious at a glance — no Instruments session required.

Takeaway: wrap a suspect view’s background in a random color during development to turn invisible re-renders into a visible signal, then strip it out before shipping.

Treat a scroll view’s content offset as an implementation detail — with lazy stacks it’s only estimated from the heights of off-screen views and carries no reliable semantic meaning. Trigger UI changes off the views actually on screen instead.

scrollPosition tracks which item is currently visible by ID, not by offset — so it stays relative to your data model rather than a pixel value:

struct FeedView: View {
    @State private var position = ScrollPosition(idType: Item.ID.self)

    var body: some View {
        ScrollView {
            LazyVStack {
                ForEach(items) { item in
                    ItemRow(item: item).id(item.id)
                }
            }
        }
        .scrollPosition($position)
    }
}

For visibility-based triggers — analytics, impression tracking — onScrollVisibilityChange(threshold:) fires when a view crosses a percentage-visible threshold, instead of you computing that from offsets yourself:

ItemRow(item: item)
    .onScrollVisibilityChange(threshold: 0.8) { isVisible in
        if isVisible { analytics.logImpression(item) }
    }

onGeometryChange and scroll transitions round out the toolkit: the former replaces GeometryReader hacks for reading frame changes, the latter offloads scroll-driven visual effects to the system and is often cheaper than computing them by hand from offset.

Infinite scrolling, per the panel, doesn’t need any offset math either — put a sentinel view at the end of the list and let its onAppear trigger the next page fetch:

LazyVStack {
    ForEach(items) { item in
        ItemRow(item: item)
    }
    Color.clear
        .frame(height: 1)
        .onAppear { Task { await loadMore() } }
}

Takeaway: stop reasoning about scroll views in terms of content offset. Whatever you’re after — revealing a view at some scroll depth, tracking impressions, or paging in more data — there’s an API keyed to the views on screen instead.

@Test func featureRequiresDevice() async throws {
    guard await DeviceCapability.isSupported else {
        Test.current?.cancel()
        return
    }
    // test body runs only when supported
}

This is different from #require (which records a failure) or throwing a Skip (which marks the test skipped). Test.cancel() cancels the underlying task — the test shows up as cancelled in the report, signalling “not applicable” rather than “broken.”

Because it goes through Swift concurrency cancellation, any try await after the call will throw CancellationError — so a bare cancel() followed by return is the safest pattern.

Cancellation also propagates to child tests in a suite:

@Test func suite() async {
    if ProcessInfo.processInfo.environment["CI"] == nil {
        Test.current?.cancel()
        return
    }
    // child tests run only in CI
}

Takeaway: use Test.cancel() when a test is conditionally irrelevant — not wrong, just not applicable. Reserve #require for preconditions that should hold, and keep cancel() for environment or capability gates.