WWDC25 Pre-Game Analysis and Predictions

The Captain’s Take Heading Into The Happiest Week of an Apple Devs Year

We're roughly a month away from the most wonderful time of an Apple Dev's year: World Wide Developer Conference 2025. Every year we are bestowed goodies from Cupertino (and beyond) that often give us insight on where Apple is hoping to take the platforms and app development (ranging from glimpses to full-blown fire hose).

Some of my fellow writers have already shared their thoughts on and wishes for WWDC (shout out to Majid). I'm always trying to read the SwiftUI Sea, myself, and so here are some of my thoughts for this year.

The Mood Going In

This year feels... odd. There's already been strong rumors of things to come, doubts casted on what we'll see, and questions about where Apple actually envisions things are headed towards. That's awkward to say about the company that introduced the world to affordable PC's, revolutionized the music industry, radically changed the world with smart mobile devices, and so on.

But with Vision Pro production being halted (albeit possibly to prepare for a Vision Pro 2) and Apple Intelligence delays, it's caused some concerns about Apple's ability to pivot to "the next big thing".

I don't believe this threatens the ecosystem Apple has built and, therefore, those already a partaker in it will most likely remain faithful (did that sound cult-of-mac like or what?). However, FOMO (fear of missing out) has already begun to creep in. And especially as a developer who uses Xcode daily.

A Word on AI and Xcode

I want to see more Apple Intelligence features across all platforms.

I want to see more Apple Intelligence in Xcode.

I want a more stable and improved Xc…

In all sincerity, I would of course love for many of the AI goodies we see with IDE’s like VS Code and Cursor make it’s way (natively) into Xcode. Having Apple provide the goods could give Xcode users more fine-tuned and relevant features. I’m already a fan of the auto-complete model, a step in the right direction.

Having said that, I’ve grown to use AI in one IDE, and then switch to Xcode to run/debug. If better AI in Xcode didn’t happen this year, I’d be fine with that.

Instead, I rather see Xcode become more stable and more robust, in general. Xcode really does provide some awesome features when you stop and take stock. But there are enough annoyances with Xcode that produce some of the negative/meh feelings I read and see in the community.

If I had to choose an MVP, I’d go with making Xcode as solid as possible.

What We Can Strongly Expect

Without a doubt, SwiftUI will continue to be the primary UI framework in majority of demos and announcements, just like we saw in WWDC 24. I also expect more frameworks to provide better interfacing with SwiftUI (similar to Translation and MapKit in prior years).

But beyond those strong speculations, here are a few strong rumors worth keeping an eye out for...

Overall Design Changes

A strong rumor is that that iOS 19 will bring about some of the biggest design changes in over a decade. The goal is being reasoned that this will bring cross-platform cohesiveness much closer together, which is certainly a win. The inspiration seems to be many of the design decisions already found in VisionOS.

This rumor feels solid because we already saw some VisionOS concepts creep into iPadOS 18 through the tab bar. That particular change was a bit of an upheaval, so a more wide-scale makeover could enhance UX, but it may hurt developer backlogs this summer/fall.

UIApplicationDelegate Deprecation

According to Jeff Johnson's analysis, he presents compelling evidence that UIApplicationDelegate will be deprecated in iOS19. While deprecation does not mean mandatory change, this would still be a tremendous shift in iOS development. The app delegate has been the core for what feels like ages, so this news almost seems baffling.

The alternative Apple would push for is switching to UISceneDelegate (in fact, Apple already suggests this for apps targeting iOS 13 onwards). The full strategy has not been revealed (pending this rumor being true), but it may be worth exploring the (current) differences and possible meanings this will have on development.

UPDATE: CONFIRMED!

Hours after this article was published (coincidence? I think not), Apple released a Tech Note confirming the move from UIApplicationDelegate to UISceneDelegate.

The most intense quote came towards the beginning where they state: “Soon, all UIKit based apps will be required to adopt the scene-based life-cycle, after which your app won’t launch if you don’t.”

This is striking because man believed the rumor would mean more ceremonial deprecation, not something mandatory. But the wording here is strong and clear: migrate or your app won’t launch…

Closing the Combine vs Observation Gap

There is a swift evolution proposal currently wrapping up review (seemingly just in time for WWDC) called SE-0475: Transactional Observation of Values. When Observation was announced two years ago, it was exciting because it really embraced the concurrency/task-based/thread-safe future we all saw coming in Swift 6. Plus, it was shared that SwiftUI was already optimized to use Observation under the hood with more basic property wrappers.

One thing that felt awkward, though, was that programmatic tracking was primarily done using withObservationTracking

func printFlowers() { 
    withObservationTracking { 
        print(flower.name) 
    } onChange: { 
        print("Schedule printing.") 
    }
}

The proposal would essentially create an asynchronous sequence (note: not an AsyncSequence, which we'll come back to) using a new closure-initialized Observed type as well as "just-the-right-amount-of-magic" (their words, not mine).

let flowerNames = Observed { flower.name }

Which would allow us to then write something more familiar like:

for await name in flowerNames {
    print(name)
}

This also helps to better close the gap that Observation attempts to close between a Combine Publisher and AsyncSequence: the former supports broadcasting to multiple subscribers while the latter does not.

So now, when we attempt to do the following, all of the tasks will receive the same values from the same event that bore them:

Task.detached {
  for await name in flowerNames {
    print("Task1: \(name)")
  }
}

Task.detached {
  for await name in flowerNames {
    print("Task2: \(name)")
  }
}

For those looking to move away from Combine and over to something more concurrency-based, this bolsters the argument for Observation.

Want to talk more about this year’s upcoming WWDC? Join me live at Office Hours!

Open to all paid subscribers! Join at the button below and take advantage of a special promo discount!

What I'd Like to See

Just like I the one I write for Santa every December, it's now time for my WWDC wishlist. See, The Captain has been good all year and would love to see a few of these items under the OutlineGroup tree (note: even I rolled my eyes at how corny this paragraph turned out to be).

Default Theming/Styling of Components

Let's say I have a particular vision for how I want Button to look across my app. I could:

• Create a ButtonStyle, but that requires adding .style to each Button or surrounding Container

• Create my own Button that wraps Button with my styling, but I might not be able to anticipate what initializers I need to account for (did you know there are 15 initializers for Button?)

• Write a macro that automatically adds the modifiers I want to a specific component when recognized, but at the risk of blocking additional styling

What would be great is for a way to simply declare style overrides in a centralized manner that could even be swappable.

Recycling

Considering all of Apple's green initiatives, it's surprising that SwiftUI doesn't offer more recycling (badum-tish). I want to echo one of Majid's wishes, as its one that so many SwiftUI devs have wanted (or have yet to realize they wanted): container views that allow for recycling.

This is what I wanna see! C’mon Craig!

There are custom built solutions out there, everything from wrapped UICollectionViews to more calculated, yet pure-SwiftUI solutions like this one by Nil Coalescing.

But, it would be great to see more native offerings. List was changed under the hood by Apple a few years ago to use UICollectionView, and it’s been a game changer. If Apple wants to continue to encourage prioritizing SwiftUI, this would be a great boost.

Let The Hype Begin

As we count down to the lights dimming on June 9th, I find myself riding that familiar mix of excitement and curiosity. Whether Apple delivers long-rumored hardware, surprises us with (actual) AI integrations, or simply refines what’s already great, WWDC always finds a way to mark a turning point—for our tools, our workflows, and our ambitions as developers.

I’m not just watching as an engineer—I’m watching as someone who still gets pumped when Craig takes the stage. And I know many of you feel the same. So what are you hoping for? What’s your boldest prediction? I’d love to hear it.