My WWDC 2026 Wishlist | Kyle Browning

WWDC starts Monday, and apparently fewer developers are writing wishlists this year. The main mood seems to be, Snow Leopard us please. I think wishlists are a chance to talk about what we would like to see tho, so here's mine. With some examples.

A real recycling view in SwiftUI

SwiftUI gives us three ways to render large collections, and none of them is the one we actually need.

List recycles its rows, which sounds great until you put @State in a row view and discover that state gets reused along with the view. Scroll far enough and row 200 inherits the expanded/collapsed state of row 3. The standard advice is "don't put state in List rows," which is another way of saying the recycling is something you work around rather than something you control.

LazyVStack and LazyVGrid are lazy - they create views on demand as you scroll - but they don't recycle anything. Once a view is created it sticks around, so memory grows with scroll distance, and there's no reuse pool, no prefetching API, and no way to influence any of it. Scroll a grid of a few thousand photos at high speed and you'll see the frame drops. UIKit solved this problem fifteen years ago with UICollectionView, and the moment your collection gets serious, the honest answer is still "wrap UIKit."

I want a container that treats recycling as a first-class, controllable concept instead of an invisible implementation detail. To be clear this doesn't have to be the API, but it makes my point.

ScrollView {
    RecyclingForEach(landmarks) { landmark in
        LandmarkRow(landmark: landmark)
    }
    .reusePool(maxSize: 50)
    .prefetch(distance: 20) { upcoming in
        await imageLoader.prefetch(upcoming.map(\.imageURL))
    }
}

And alongside it, explicit state semantics for recycled views. The List state bug exists because the framework has no way to know whether your @State belongs to the position or the item. So let us say so.

struct LandmarkRow: View {
    let landmark: Landmark

    // Reset whenever this view is recycled for a new item
    @RecycledState private var isExpanded = false

    var body: some View {
        // ...
    }
}

The pieces clearly exist internally. List recycles today, and the lazy containers already track visibility. This wish is about making the machinery public so we can stop treating scroll performance as a dark art.

iOS apps managed entirely by SPM

I spent a whole series on modularizing apps with SPM, and the pattern that emerged is one a lot of teams have landed on. Every line of real code lives in a local Swift package, and the Xcode project shrinks down to a thin app shell that imports the package.

It's a workaround tho. The .xcodeproj is still there, still required, still doing the only three jobs SPM won't do - signing, entitlements, and producing an actual .app bundle. It's a file format nobody can read, nobody can review, and everybody merge-conflicts on (unless you binary the project). Entire tools (Tuist, XcodeGen) exist purely to generate it from something sane.

What makes this wish less of a fantasy is that Apple already shipped it. Swift Playgrounds supports building real, installable iOS apps from a plain Package.swift using an iOSApplication product type. The capability exists in a first-party tool today. It's just not allowed in Xcode or xcodebuild.

So the sketch here is barely even imaginary.

// swift-tools-version: 7.0
import PackageDescription

let package = Package(
    name: "Landmarks",
    platforms: [.iOS(.v26)],
    products: [
        .iOSApplication(
            name: "Landmarks",
            targets: ["LandmarksApp"],
            bundleIdentifier: "com.kylebrowning.Landmarks",
            appIcon: .asset("AppIcon"),
            capabilities: [
                .pushNotifications(),
                .healthKit()
            ]
        )
    ],
    targets: [
        .executableTarget(
            name: "LandmarksApp",
            dependencies: ["LandmarksFeature"],
            resources: [.process("Assets.xcassets")]
        )
    ]
)

Then:

swift build --platform ios
swift run --simulator "iPhone 17 Pro"

A reviewable, diffable, mergeable project definition. CI that doesn't need a project file. App targets that compose the same way every other target in your dependency graph already does. The three-layer architecture from my modularization series wouldn't need an app shell at all - the package would just be the app.

A blessed package registry

The history here makes the argument better than I can.

2019: GitHub announces Swift support for GitHub Package Registry. The registry service spec gets pitched on the Swift forums by a GitHub engineer.
2021: SE-0292 is accepted. SwiftPM gets full registry support in Swift 5.7.
2023: SE-0391 adds package signing and a publish endpoint.
2025: Tuist gets tired of waiting and ships a community registry mirroring the entire Swift Package Index - then opens it to everyone, free, no account required.
2026: GitHub's announcement remains unfulfilled. There is still no default registry, and Xcode still has no UI for the feature SwiftPM has supported for four years.

Today, a fresh swift package init resolves every dependency by deep-cloning git repositories. Tuist's numbers show what that costs. Registry resolution is roughly 40% faster than source control resolution, and teams have cut dependency disk usage from 6.6 GB to 600 MB. The protocol is done. The signing spec is done. A community implementation is live in production.

The missing piece is a default, and that's the one piece nobody but Apple can provide. A registry only becomes infrastructure when it ships preconfigured in the toolchain, and that's a trust position, not a technical problem. Anyone can run a Swift package registry - Tuist proved it. No one can make it matter.

A blessed registry would also open the genuinely interesting door, which is prebuilt binaries. Apple already validated this in the narrowest possible way with the swift-syntax prebuilts in Xcode 16.4, which took macro-using clean builds from about 37 seconds to 15 on a small project. That's one hardcoded special case for one package. A registry that served verified, signed, prebuilt artifacts for the ecosystem's most-used packages would be the single biggest build-time win Apple could ship.

First-class SwiftUI view testing

I wrote recently about testing the Landmarks app, and the architecture there - closure-based services, observable stores - exists partly because views themselves can't be tested. We push logic out of views into testable layers, then cross our fingers that the thin view layer wiring it together is correct.

Seven years into SwiftUI, there is still no native way to assert on what a view produces. ViewInspector works by reverse-engineering SwiftUI's internal type structure, and every major OS release is a coin flip on whether it keeps working. Snapshot tests compare pixels, which tells you something changed but never what.

The frustrating part is that the machinery exists. Previews evaluate view bodies constantly. The framework knows exactly what your view resolved to. We just can't get at it.

import Testing
import SwiftUI

@Test func favoritingUpdatesTheHeart() async throws {
    let host = try await ViewHost {
        LandmarkDetailView(landmark: .mock)
            .environment(\.landmarkService, .mock)
    }

    try await host.button("Favorite").tap()

    #expect(host.contains(image: "heart.fill"))
}

Give us a host that evaluates a view hierarchy, a query API over the resolved output, and a way to drive interactions. The dependency injection patterns from earlier in this series mean the views are already isolated and injectable. The last missing piece is being able to look at them.

The lightning round

A few more, briefly.

List row heights that animate. When a row's content changes height - a subtitle appears, text wraps to a second line - List jumps instead of interpolating. No .animation modifier fixes it. Row height changes should animate like everything else in the framework.

Official hot reloading. The community keeps Inject alive because iterating on a real running app beats iterating in a preview canvas. Previews are great for components. They're not great for flows, deep links, or anything stateful. The compiler team built the injection primitives years ago. Productize them. (OR JUST MAKE PREVIEWS WORK ACROSS SPM)

Stability over features. The community is right about this one. Previews that stop resolving, simulators that won't boot, indexing that pegs a CPU core. If the keynote slide says "we made everything you already use actually work," I'll cheer louder than I would for anything else on this list.

Open-source SwiftUI. The perennial wish, and I'll keep making it. Half the items on this list exist because SwiftUI's behavior is a black box we probe from the outside. Foundation went open source and got better. Let the community see List's source, and someone will have a recycling fix the same week.

What I actually expect

Realistically? Probably none of it. WWDC wishes have a bad conversion rate, and this year's rumors point at AI features and platform polish, not developer-tools moonshots. But if I had to guess (WISH). It's probably true List parity with UICollectionView.

But the two headline items on this list aren't moonshots. The recycling machinery already exists inside List. The SPM application target already exists inside Swift Playgrounds. In both cases the wish isn't "build something new" - it's "let us use the thing you already built."

See you Monday.