Joe Rossignol:
Apple’s annual developers conference WWDC returns for 2026 next week, and the company has teased the event with a new “All systems glow” tagline.
Clarko:
“We’re keeping Liquid Glass, you weiners”
Joe Rossignol:
Apple has shared a wallpaper, playlist, and a “Get Ready” video ahead of the event.
Basic Apple Guy:
I’ve been Sherlocked.
Jason Snell:
I’ve been attending Apple’s WWDC since sometime in the 90s, which is… a long time. But this year’s event promises to be one of the most interesting ones yet, mostly because Apple really stepped in it in 2024, promising a bunch of features it didn’t deliver. Last year was a bit of an apology tour, but it didn’t directly address what had been promised the previous year.
Which means that Apple has really piled two years of promises on the agenda of WWDC 2026. The stakes couldn’t be higher. Here’s what I’ll be watching for at this year’s event, especially when it comes to its AI do-over.
Dave Mark:
For me, 2 big questions for WWDC:
Will there be enough actual, proper working Siri/AI features to keep people from migrating to other platforms?
And will there be enough AI privacy gains to pull people from other platforms?
John Gruber:
The annual live audience episode of The Talk Show during the week of WWDC.
Jordan Morgan:
The 12th annual Swiftjective-C pregame quiz is here!
Brendan Shanks:
Has Apple eliminated one-on-one labs with engineers this year at WWDC?
Adrian Schönig:
That was the best part. What a bummer.
Juli Clover:
Apple has announced the winners of its annual Apple Design Awards.
Apple’s page doesn’t have a permalink.
Jason Snell:
These days, I’m getting emails pitching me for an endless stream of new Mac apps. It’s quite remarkable because there was a period five or ten years ago when it seemed like all app development on Apple’s platforms was focused on iOS. Even more interesting, these are all indie Mac apps that seem to be built using native Mac frameworks, not the product of big corporations that are just rolling their cross-platform development system out everywhere. These apps seem to have a point of view and are focused on the Mac.
Of course, it’s happening because of AI.
[…]
And, yes, a couple of weeks ago, I made a Mac app of my own [Double Ender], using Claude Code. I can’t say that I wrote it, because I didn’t write a line of Swift code. It would be more accurate to say that I envisioned it, or produced it, or product-managed it. I knew what I wanted, described it in detail to an AI assistant, iterated a whole lot, and ultimately got something that basically does everything I imagined it would do.
[…]
The Xcode learning curve is just too high. Either there needs to be a novice mode for Xcode, or Swift Playground needs to be given a boost, or a new tool needs to be built for the task.
D. Griffin Jones:
It is time for us on the Cult of Mac podcast to lay out our predictions for Apple’s WWDC26 Keynote.
Simon B. Støvring:
In just a few days, Apple will kick off WWDC with their keynote and introduce Vaporized Glass, a design language centered around hiding UI. You can’t complain about illegible controls if users can’t find them in the first place.
Previously:
Apple Intelligence Artificial Intelligence Double Ender iOS iOS 27 Liquid Glass Mac macOS 27 Programming Siri visionOS Wallpaper watchOS watchOS 27 WWDC
Miguel de Icaza and Joseph Hill (tweet):
Xogot was born as a native user interface shell on top of the Godot game engine for iPad devices, and later iPhone devices.
[…]
Because Xogot’s user interface was written in SwiftUI, and because we had already committed to Apple’s design system, bringing Xogot to macOS felt like a natural next step. That does not mean it was automatic. We still had to adapt many parts of the interface, study modern Mac applications, and rethink details so Xogot would feel true to the platform and the modern idioms on the Mac.
[…]
Our goal is for Xogot to feel like a professional creative environment for game developers: a tool for building games with Godot that can sit comfortably alongside the apps in Apple’s Creative Studio, like Final Cut Pro, Logic Pro, Motion, and MainStage, as well as the other first-class creative and development tools Mac users rely on.
[…]
Our goal is to make running your game on an Apple target feel as simple as choosing the target you care about and pressing play. Want to share your game with friends on a Mac? You should be able to package it up without needing a PhD in certificates, signing identities, and provisioning profiles. Want to test on an iPhone? Xogot will handle the packaging, signing, deployment, and device connection details so you can get your project running and start debugging without fighting the toolchain.
Via Jamie Birch:
This is the most complex (yet well crafted) native Mac app I’ve seen in years. They say it’s SwiftUI, but didn’t clarify whether it’s targeting UIKit for Mac or AppKit – but either way, it’s amazing to see a team build an app on the scale of Xcode from scratch these days.
Previously:
Developer Tool Game Mac Mac App macOS Tahoe 26 Programming SwiftUI Xogot
Keren R. Bell:
This is a call to join the topic-of-the-month for the Swift Blog Carnival!
[…]
What do you LOVE about SwiftUI? What boggles your mind about it?
David Bureš:
.sheet is STILL not animatable (a feature since the first OSX release)
[…]
Toolbar item placement is completely broken.
[…]
.searchable is a complete mess that shouldn’t be a thing at all
[…]
Due to a conflict between List’s aggressive view destruction on scroll, and the way .task works, the millisecond a view that calls an API to load and parse a short string disappears, that already parsed string gets de-assigned. Once that particular list item appears again, it has to perform the extremely expensive API call and parsing again. Instead of just saving a 10-character string to memory. […] This leads to funny bugs, such as scrolling too fast through a list that’s made up of only text making the whole Mac freeze up and crash
Patrick McConnell:
SwiftUI is just too incomplete, inflexible and inextensible. It’s also great and that’s what makes this so frustrating.
[…]
Developers used to get Sherlocked when Apple would copy a third party apps features into the OS or packed apps. Now we get road blocked where only Apple can make use of a feature leaving us on the outside left trying to explain to users why Apples app has feature X,Y and Z and we don’t.
[…]
In a framework built on containers and modifiers just don’t go too deep into those containers or things may just break. Often this means your UI simply stops rendering on the screen. You may think you’re not doing anything wrong and then boom your code just doesn’t work.
[…]
Over the years we’ve all seen frameworks offering to create apps with no code or allowing you to write in your favorite language and run on all platforms. There were demos showing it working. None of those ever seem to pan out. They always come up short or perhaps they allow you to shoehorn in some native code to do something the framework authors don’t provide. If this sounds familiar this is what Apple is offering with SwiftUI. Looks impressive in canned demos, often falls short but you can just drop back to your old coding ways to fill in the blanks. I’ve always viewed this as a bunch of incomplete hacks. Now this is Apple standard practice.
[…]
I want SwiftUI to be so much more than it is currently. I want to make real Mac apps with it. I don’t want an iPad app in a Mac wrapper.
Mark Szymczyk:
I encountered the following limitations with SwiftUI:
- Limited rich text editing experience.
- The file exporter returns a folder URL when exporting to PDF.
- SwiftUI lets you save documents in unwanted export file formats in Mac apps.
Nathan Manceaux-Panot:
Despite this simplicity, the first implementation of that list was shockingly badly-behaved. It was:
- Extremely slow (scrolling would cause multi-second freezes!)
- Visually broken in multiple ways (you’ll see)
[…]
This was honestly very entertaining code to write! I think it’s especially fascinating how it’s essentially imperative code, expressed through declarative modifiers. It’s an absolute mess to read, because on top of that mismatch between behavior and expression, respecting view tree constraints forced an unnatural order for everything. Glorious, and dismal.
[…]
And at the same time, it’s a maddening amount of work for such a basic user interface.
Sarah Reichelt:
Recently, I have seen multiple posts on Mastodon suggesting that SwiftUI is a failure, that nobody is using it, and that Apple should have focused on improving or replacing AppKit and UIKit instead of wasting everyone's time with SwiftUI. While I have great respect for some of the people saying these things, I disagree. I love using SwiftUI, I think a large number of developers are using it, and I want to explain what I find so great about it.
[…]
The reactive aspect of SwiftUI feels like magic! It allows me to have something like a stored setting with a default value, connected to a menu item with a checkmark, a toggle in a settings window, a button in the toolbar, and a switch on the main interface. SwiftUI keeps these all in sync without any effort on my part.
[…]
The AI proponents argue that if AI is writing all this verbose code, then there is no need for the more concise SwiftUI. While I have started using AI to write some code, I still review every line and the more the AI writes, the harder this becomes and the more likely it is that there will be un-detected bugs.
[…]
I don't want to imply that I think SwiftUI is perfect. I have struggled with various aspects of it, and I have had to find workarounds for some things that I want to do. Partly, this is due to the buggy nature of Apple software at the moment, but as someone who primarily works with Mac apps, I am feeling the pain of the lack of attention to the Mac. Again, this is not a SwiftUI problem, but a general Apple problem.
Ziga Dolar:
After shipping three small apps with SwiftUI (and actively working on the fourth), I’ve come to a simple conclusion: SwiftUI is great for narrowly scoped small apps.
[…]
Getting from zero to a working app that doesn’t look like a mess was incredibly fast - which helped with staying motivated. For me at least, being able to see interactive progress is part of what drove me to build apps, and SwiftUI makes that feedback loop a lot quicker (and since I struggle with staying motivated, that’s a big win).
[…]
Handling routing in SwiftUI is easier with a router and an enum of all main navigation destinations, that can easily be navigated to from anywhere.
And if you add a new screen or flow without handling it, the code won’t compile, so the compiler makes sure that nothing gets missed.
[…]
SwiftUI didn’t make me a better developer or remove complexity from app development. But it removed enough friction that I started shipping ideas again.
Keren R. Bell:
I still maintain my personal opinion which is, it’s ok that there’s some expectation to dip back to UIKit / AppKit, but yeah, Apple needs to stop shouting “SwiftUI all the way!” at us when it can really only do anywhere from 40%-70% of the way.
[…]
We love SwiftUI. It’s awesome, fast and simple. The allure of highly legible, nearly-natural-language interface writing is strong. But we don’t have to let our love and hopes for SwiftUI limit us: It’s one tool in a big box. It’s ok to use the ol’ WKWebView here and there.
Max Seelemann (Mastodon):
SwiftUI shipped in 2019, seven years ago. At WWDC 2022, Apple put up this infamous claim during the State of the Union[…] Here we are in 2026, right before another WWDC, four years and four major release cycles after that claim. How well does it hold today? In my opinion, we’re not even close. Modern SwiftUI can do a lot. But it’s still riddled with inexplicable bugs and weird limitations that prevent developers from building truly great experiences. Or at least, experiences that match system behavior.
[…]
Example 1: On iOS, SwiftUI can’t autofocus a text field in an appearing sheet to bring up the keyboard in the same animation.
[…]
Example 2: On macOS, drag & drop is essentially impossible to get right. Seven years in, we’re on the third major iteration of drag & drop in SwiftUI. […] Yet you still can’t have it all at once: reorder inside and drag out of the same view, plus drop validation when items may not be accepted, plus defining which drop operation (copy / move / link) a destination would cause. Let’s not dare to think of allowing Option to toggle between “move” and “copy”.
[…]
I believe Apple should tap into this invaluable resource of skilled developers with affection for its platforms and open-source SwiftUI. Sounds crazy. But is it? Swift has been open-source for years now, to great success. Let’s explore the thought, shall we?
Colin Cornaby:
This is not the only call for open source SwiftUI I’ve seen so I’m not trying to pick on it.
But my understanding is that SwiftUI cannot become open source. It touches too many private APIs. Even on platforms like macOS it’s no longer really a wrapper for AppKit, and it’s reaching deeper and deeper into private frameworks.
Previously:
iOS iOS 26 Mac macOS Tahoe 26 Open Source Programming SwiftUI
