Wade Tregaskis:

NSPasteboard mutates itself simultaneously from the main thread and the global concurrent Dispatch pool, w.r.t. to its internal type cache. This is surprisingly trivial to reproduce (sample code below) by just dropping, e.g. a file promise (such as by opening a PNG in Preview, revealing the thumbnails sidebar, and then dragging the thumbnail onto the sample project’s window).

[…]

Since this bug causes semi-random memory corruption, it manifests in a large number of ways – not all of which are all that helpful.

[…]

SwiftUI’s onDrop(of:isTargeted:perform:) method makes no claims or promises as to what thread / queue it executes the closure on, and in fact according to the anonymous Apple engineer it never executes the closure on the main thread.

Now, while that may be the intent, the reality of that is wrong – in my experience it always executes the closure on the main thread (which makes a lot of sense to me as drag-and-drop event handling in AppKit has always been on the main thread in practice).

Apple also told him that NSPasteboard is not safe to use outside the main thread, even though that’s not documented, it’s not @MainActor, and Apple’s own code does do that.

"GitHub and the Python Package Index (PyPI) have introduced new policies meant to boost supply chain security," reports SecurityWeek, "by preventing the fast propagation of poisoned package versions and the poisoning of old and long-stable releases." To prevent the fast delivery of malicious code through the immediate fetching of brand-new releases, GitHub has introduced a Dependabot cooldown, where the automation tool waits for at least three days after a release has been published before opening a pull request. "Waiting a few days before adopting a new release gives maintainers, security researchers, and automated scanners time to spot a malicious version and get it pulled before it ever reaches your pull requests," GitHub explains. The three-day cooldown only applies to non-security version bumps, and the behavior can be modified through the configuration option in the dependabot.yml. "Three days as the default balances two goals: it pushes you past the window where most of these attacks live, and it doesn't hold your dependencies back longer than necessary," GitHub notes. And the Python Package Index (PyPI) "now rejects new files being uploaded to releases that are older than 14 days," according to a recernt blog post from the Python Software Foundation's security developer-in-residence Seth Larson: This restriction was put in place to prevent old and long-stable releases from being poisoned in case publishing tokens or workflows of PyPI projects were compromised... The discussion of this behavior began during PEP 740 (Digital Attestations) back in January 2024. The discussion was restarted in March 2026 after the popular packages LiteLLM and Telnyx were compromised. These packages were compromised due to a "mutable reference" in these projects' usage of the Trivy GitHub Action... To quantify how disruptive this change would be to existing workflows, the PyPI database was queried for projects that have published new files to old releases... [O]nly 56 projects of 15,000 had published a [Python] 3.14-compatible wheel more than 14 days after a release was available. This topic was brought to the Packaging Summit at PyCon US 2026 by PyPI Safety & Security Engineer, Mike Fiedler. The rough consensus of the discussion was that the summit attendees thought it was "acceptable to require users to bump to the next version" to support new Python versions. With the data and consensus in hand, Seth moved forward with a patch to reject new files on old releases which was merged July 8th, 2026.

Read more of this story at Slashdot.

Today, Anthropic rolled out Opus 5, the newest update for the model that has recently become a popular choice for coding and other software development tasks, among other things.

While this is a noteworthy bump for Opus, it doesn't seem to be an Opus 4.5-level breakthrough in agentic coding performance.

Read full article

Comments

© Anthropic

I wanted a clock that, annoyingly, didn't seem to exist.

Since childhood, my bedside clocks have been a series of red, seven-segment LED clock-radio specials from Walmart or Target. They are invariably cheap, simple, and long-lived—but they require manual intervention at the start and end of Daylight Saving Time and whenever the power flickers. After a recent power flicker, as I found myself standing by the sideboard holding down "TIME" and mashing the "HOUR" button, frustration boiled over, and I thought to myself, "We're a quarter of the way through the 21st century. There has to be a better way!"

My perfect clock would be self-setting. It would offer auto-DST adjustment (or not, depending on how this bill fares!). It would manage drift and always show the exact sub-second time. It would show that time on a red seven-segment display—not blue, not green, not yellow, and absolutely not white. And I shouldn't have to install any privacy-destroying garbage apps to make it work.

Read full article

Comments

© Lee Hutchinson

Om Malik (2023):

One of the key advantages of MacWhisper, as it utilizes the Whisper technology, is its superior accuracy in transcriptions compared to other services I have used. I was an early adopter of Rev.com and eventually switched to Otter.ai, for which I paid approximately $100/year. However, I have since canceled my subscription.

[…]

After comparing the audio transcripts from MacWhisper and Otter, I found that while Otter’s formatting is superior, there is hardly any difference in the transcriptions. I started with the free model, which was sufficient for my needs, and eventually upgraded to the large models. Nowadays, I primarily use MacWhisper to transcribe my voice memos, which I then import into Lex.Page.

Bon Adamson:

Whisper, which is made by OpenAI, has the distinct advantage of allowing you to transcribe audio in almost any language you may ever need to. For the time being, Otter can only transcribe English. The benefits of better accuracy and accurate punctuation that the service already holds over Siri hold up across other languages as well. If you’re looking to transcribe non-English audio accurately, Whisper is definitely the best option available on Mac.

Dan Moren:

By taking advantage of OpenAI’s Whisper framework, Audio Hijack can now take any audio it’s recording and generate a text transcript. While this process was possible before—see Jason’s lengthy post about his workflow—it required a lot of fiddling and several different tools to accomplish; it’s certainly a lot easier to simply drop Audio Hijack’s block into your existing session. If you record multiple sources, it can even appropriately label each one—though if you record multiple people via one input, say the other end of a Zoom call, it can’t distinguish between the various participants.

Inscribe (2026, Hacker News):

Apple’s new SpeechAnalyzer is the most accurate on-device speech engine we tested. It beat every Whisper model we ship, including Whisper Small, on both the clean and the noisy half of LibriSpeech, while running roughly three times faster than Small. And the API it replaces, SFSpeechRecognizer, came last on clean speech: behind even Whisper Tiny, a 40MB model.

[…]

The new API cuts word error rate by 3.5 to 4x on the same audio: from 9.02% to 2.12% on clean speech, and from 16.25% to 4.56% on noisy speech. There is no accuracy trade-off to weigh; the new API wins everywhere we measured, and it produces punctuated, cased text where the legacy engine’s output is rougher.

[…]

All five engines ran comfortably faster than real time: between roughly 12x and 40x on the M2 Pro, meaning an hour of audio transcribes in about 1.5 to 5 minutes on-device. SpeechAnalyzer was about 3x faster than Whisper Small per second of audio while beating it on accuracy.

Yuki:

SpeechAnalyzer’s ReportingOption.fastResults reads like a knob you’d reach for when you want to trade power for latency. That framing is what cost me the afternoon.

[…]

If a recording matters — and in a notes app, a lost meeting is the worst thing that can happen to a user — then the container you write while recording has to be PCM in CAF. Not m4a, and not AAC-in-CAF either.

[…]

AVAudioEngine’s inputNode silently ignores your device selection

[…]

I wanted summarization to run on-device. Everything else in Nib’s transcription path does, the audio never leaves the machine, and it would have been a much cleaner story to tell.

But 4,096 tokens for the Foundation Models isn’t enough.

Previously:

• Apple Foundation Models in appleOS 27
• WhisperPad Rejected From the Mac App Store
• Overcast Transcripts
• Generated Transcripts in Pocket Casts
• Apple Podcasts Transcripts
• Dictation and Predictive Text in macOS Sonoma and iOS 17
• macOS vs. Dragon Dictation

Bruno Brito (release notes):

In Tower 15, we introduced the “Fully Merged” badge and Automatic Branch Management to help you keep your repository tidy. With Tower 17, we’re taking the detection behind that badge to a whole new level. […] Tower now matches your local branches against merged pull requests from your hosting service, such as GitHub or GitLab.

[…]

Trust is everything when deleting branches — so we redesigned the “Fully Merged” hint view to show you exactly which checks matched.

[…]

One that is particularly noteworthy is that updating submodules is now significantly faster! Tower gathers each submodule's Git data concurrently instead of one at a time—something you will especially notice in repositories with many submodules.

I’m sad that they got rid of the yellow icon.

Previously:

• Git Tower 16

Wade Tregaskis:

In short: if you have any file in your app (or whatever it is you’re trying to get Apple to sign) that is over 4 GiB, you must use a disk image (DMG) to package it for notarytool, not a zip file.

This is because support for files larger than 4 GiB requires using the “Zip64” zip file format, which would be fine except Apple’s notary servers can’t handle them.

Previously:

• altool Update and notarytool

Update (2026-07-22): Rosyna Keller:

It’s recommended to notarized exactly what you’re going to ship to users and shipping zips is extremely risky because you never know what tool the user will use to decompress the file.

Multiple unzipping tools will strip necessary extended attributes that could cause the code signature to fail to validate. This is especially true if you put non-code files in “code places” and they have to be signed with an extended attribute.

SpamSieve 3.3.1 is an update of my Mac e-mail spam filter that improves the filtering accuracy and includes various optimizations, fixes, and updates for macOS 27. Some interesting engineering issues were:

• I’m still supporting macOS 10.13, but the app can now build with the macOS 12 deployment target in preparation for Xcode 27. The way Swift handles calling deprecated APIs remains annoying. You need workarounds like protocols to suppress a warning in a particular region of code. Often, I am updating to a newer API, but I want to continue using the old one on earlier versions of macOS. Right now I am heavily testing on macOS 26, so I would like to only deploy the new code there. Sometimes the initial versions of APIs are buggy, and I don’t want to have to retest every feature on every version. But Swift doesn’t like me to gate the calls to macOS 26 and later if the new API was actually introduced in, say, macOS 11.

• The most risky update was probably switching to the Swift API for Scanner. This is tricky because the current scan position changes from being based on UTF-16 indexes to String.Index. And in some cases my code was intentionally scanning into the middle of a combining character. I was really glad to have extensive tests here.

• Recent versions of Tahoe introduced a Core Data bug that broke save recovery (when invalid Unicode can’t be written to the database and we have to fix it up first). When the error comes in, SpamSieve looks under the NSDetailedErrorsKey key, but the value of this key is "NSDetailedErrorsKey" while the actual error info is under the key "NSDetailedErrors".

• Database corruption combined with a Core Data bug and two Swift behaviors were causing crashes. The root problem, I think, is that in this situation Core Data neglects to set the error pointer for -[NSManagedObjectContext countForFetchRequest:error:]. Normally, Swift would detect this and throw a generic nilError. However, this method signals errors by returning NSNotFound instead of nil. It’s annotated as swift_error(nonnull_error), which I think means that Swift doesn’t even look at the return value, only the (unset) error. So my code was receiving NSNotFound on the non-error path, treating it as a real count, and doing some math with it, which (by default in Swift) leads to a crash if there’s overflow. Now my code checks for NSNotFound and uses Int.addingReportingOverflow().

• I reimplemented Core Data batch fetching because of two problems with the fetchBatchSize option. First, it logs spurious errors when fetching from multiple stores at once. Second, it leads to high memory use. It will load objects in batches, but it never releases the earlier batches. You can manually refault objects that you no longer need, but it will still hold onto the full object shells, which can add up. My implementation only holds onto IDs, and it can fetch the IDs using a different context than the objects to push more work to background threads.

• I’m now using String.makeContiguousUTF8() in various places to avoid slow iteration of bridged strings.

• There was a regression where some menu code could crash on macOS 10.13. -[NSMenu setItemArray:] is only available on macOS 10.14 and later, whereas the getter is always available. With old Objective-C, the two methods could be annotated with separate availabilities. The Objective-C property syntax doesn’t allow this, so there’s no way for the compiler to flag calls where the setter is missing.

• The AppleScript support works much better with large data sets. The key, I think, is to never return an array to Cocoa for a scripting property/element. First, if you give it a lazy array it will sometimes try to access all the elements even if it only needs a few. And, second, AppleScript will run out of memory if the array is too large. By using indexed accessors, you can maintain laziness and only convert one object to a descriptor at a time. By caching a batch-fetching collection, you can limit the number of fetches and respond quickly when AppleScript requests individual objects.

Previously:

• Xcode 27 Announced
• SpamSieve 3.3
• Swift Proposal: Precise Control Flags Over Compiler Warnings
• Swift at 10

Erik Schamper:

ASIF takes a lot of inspiration from existing virtual disk formats. Practically, that means it’s another sparse virtual disk format, and functions very similar to sparse VMDK, VHDX or QCOW2 files (for the uninitiated, it allow you to store a large disk, or file, in a smaller, “sparse” manner).

Shortly before the release of macOS Tahoe (late 2025), I thought it’d be a fun exercise to try and write a parser for ASIF files.

Previously:

• DropDMG 3.7
• ASIF Disk Images in macOS Tahoe

Apple (xip, downloads):

Xcode 26.6 includes Swift 6.3 and SDKs for iOS 26.5, iPadOS 26.5, tvOS 26.5, macOS 26.5, and visionOS 26.5. Xcode 26.6 supports on-device debugging in iOS 15 and later, tvOS 15 and later, watchOS 8 and later, and visionOS. Xcode 26.6 requires a Mac running macOS Tahoe 26.2 or later.

[…]

Google Gemini is now available in the coding assistant.

Xcode adds support for the Agent Client protocol.

[…]

Launch Time similar-app goals have been refined for improved accuracy, establishing new baselines.

Previously:

• Xcode 27 Announced
• Xcode 26.5

Apple:

You manage all the devices that appear in Xcode as run destinations using Device Hub.

Run your app on simulated devices in Device Hub to quickly evaluate new features and fix bugs, and to see how your interface works on devices that you don’t have physical access to. Run your app on physical devices to test features or services that have hardware dependencies or investigating performance issues. For more information, see Running your app on simulated or physical devices.

Fatbobman:

Device Hub is undoubtedly a major surprise. It integrates simulators, physical device management, system state testing, and dynamic size adjustment into a new workflow. Its impact on day-to-day development experience may be more direct than that of many individual APIs. That said, iPhone apps now also support dynamic size adjustment, which will bring new challenges for developers, especially in terms of data and state organization. Adapting to different sizes is not something that can be solved merely by relying on dynamic layout containers. In many scenarios, large and small sizes correspond to very different navigation logic.

Collin Allen (Mastodon):

Xcode 27 introduced, among other new features, a new Device Hub app for developers that takes the place of the Simulator app. Where Simulator relied on separate windows for each device, Device Hub brings them all together into a single window where each simulated device is the detail view from a source list of devices on the left. It’s a more organized approach, made necessary by the wide variety of platforms Apple and Apple platform app developers have to build and test against.

[…]

In releases prior to Xcode 27, you could resolve this by importing the root public certificate into the simulated OS. On iOS, this could be done by dragging and dropping the .cer file onto the Simulator device window. Nothing would appear to happen, but you could then navigate to Settings, General, About, Certificate Trust Settings and mark the certificate as trusted.

[…]

In Xcode 27 with Device Hub, this process is much more uniform. […] While this new process does require you to wrap certificates in an Apple Configurator profile, this is much more consistent with how Apple’s device management system works, as it relies on signed profiles with policies, not loose .cer files. And now, just by adding the .mobileconfig to the Profiles section of the device inspector, the embedded certificate is automatically marked as trusted, greatly speeding up installation on new virtual devices.

Steve Troughton-Smith:

I get what Apple is trying to do with the Device Hub, but it’s nowhere near as usable and as useful as the iOS Simulator (in this seed)

Adam Overholtzer:

Device Hub is missing the “pixel accurate” and “point accurate” zoom options and that’s not acceptable.

Steve Troughton-Smith:

Maybe someday the Simulator/Device Hub might even be able to output screenshots in the same orientation as the emulated device 😛

Steve Troughton-Smith:

Thanks to the remote control / screen sharing features of Device Hub, I can remotely navigate to Settings and start a software update on all my iOS27 devices without having to go collect them around the house 👌

Steve Troughton-Smith:

For all of Apple’s nonsense about adding iPhone Mirroring to the EU, the new Device Hub (iOS Simulator) lets you remote-control your physical iOS devices just fine. I don’t think the DMA has an opt-out for developer tools 😛

Steve Troughton-Smith:

It’s such a shame for now that Xcode 27’s Device Hub doesn’t support remote screen sharing with iOSes earlier than 27. I wish the screen sharing functionality was part of the developer disk image, and backported to iOS 26 and even iOS 18. Having a physical device plugged in somewhere is so much faster than booting a Simulator.

Previously:

• WWDC 2026 Links
• Xcode 27 Announced
• No Apple Intelligence or iPhone Mirroring in EU at Launch

Update (2026-06-26): Léo Natan:

Xcode 27’s “Device Hub” is a broken shitshow, but most importantly, it lacks the Debug menu, where you could toggle slow animations and simulate memory warnings. Apple works tirelessly to destroy any good tool they used to have.

He has a thread of issues. Hopefully these will be addressed before it’s out of beta.

Update (2026-07-01): Craig Hockenberry:

The Device Hub sometimes doesn’t kill CoreSimulator processes when you quit the app (not sure if this is a bug or intentional). Given that each device uses several hundred processes, the memory/processing impact is significant.

You’ll probably want to keep an eye on how many you have running: use right-click on the simulator in the list to “Shut Down” as necessary.

Ted Kremenek, Dave Verwer, and Sven A. Schmidt (Hacker News):

Bringing Swift Package Index to Apple allows us to build on its strong foundations while preserving its vision and expertise. Together, we’re building a comprehensive package registry to serve the Swift community’s evolving needs.

[…]

Swift Package Index will continue to operate as it does today. You can continue to rely on it to discover packages, check compatibility, and explore documentation. As we embark on this new phase, our goal is to accelerate development and introduce new features that make discovering and evaluating packages even better.

[…]

Swift Package Index will remain open source.

Helge Heß:

A little sad that this era ends. SPI was a stronghold of Apple independence, a package index run by independent and trusted individuals.

Swift 6.4 is now available in beta form with Xcode 27. The Swift Evolution proposals are listed here.

What’s new in Swift:

Discover the latest language advancements, including updates for everyday ergonomics, improved concurrency, and safer high-performance code. Explore workflow and language interoperability improvements and updates in embedded Swift.

Build real-time apps and services with gRPC and Swift:

Build engaging live experiences with gRPC in your Swift app and backend. gRPC is an open-source RPC framework designed for high-performance, bidirectional streaming APIs. Explore how the gRPC Swift package provides a modern, safe runtime built with Swift concurrency.

Explore numerical computing in Swift with MLX:

Bring NumPy-style computing natively to Swift with MLX Swift. Discover how to eliminate cross-language friction in your machine learning workflows by handling image processing, tensor operations, and neural network training in a single, type-safe environment. Explore the APIs that let you leverage GPU acceleration while enjoying the compiler, tooling, and debugging experience you already know.

Swift Group Lab:

Join us online for a deep dive into WWDC26 with Apple engineers and designers to ask questions, get advice, and follow the discussion about the week’s biggest Swift announcements.

Matt Massicotte:

There’s a voting system. And that means a number of questions weren’t selected. This time I copied those down and I thought it could be fun to take a shot at answering the ones that are more in my area.

Xcode 27 Beta 2 Release Notes:

The Swift dependency scanner has been optimized to avoid redundant setup work and header searches when looking up Clang modules during a single dependency-scan action, substantially improving scanning performance.

As a consequence of this change, every Clang module reachable from a single Swift dependency-scan action must have a unique module name. If two module maps visible to the same scan declare a Clang module with the same name, the scan may report an error.

[…]

System now provides Swift APIs for the C stat, lstat, fstat, and fstatat system calls. This includes a new Stat type with initializers from FilePath, FileDescriptor, or a C string; FilePath.stat() and FileDescriptor.stat() instance methods; and supporting types (FileType, FileMode, FileFlags, UserID, GroupID, DeviceID, and Inode).

Wade Tregaskis:

The final piece of the Prospective Vision for Accessors, this allows for more efficient accessors on structs, in a nutshell.

[…]

Now there’s a safer version of the existing withUnsafeTemporaryAllocation (first introduced in Swift 5.6). It works just like you’d expect. It comes in both “raw bytes” and typed elements versions, just like its unsafe predecessor.

[…]

The new isTriviallyIdentical(to:) method offers a guaranteed-fast way to check two objects for equality. It is essentially an optimised version of the existing equality condition provided by Equatable and the == operator. It’s useful because it guarantees O(1) time complexity, whereas == makes no formal guarantees at all (and for many types is O(N) or worse). But unlike the existing identity comparison operator === – also O(1) – it promises to do more than just tell if two objects are the exact same pointer, and it works on value types (not just reference types).

[…]

These new types generalise the existing patterns of borrowed and mutable references, that have previously existed in Swift in much more restricted forms (e.g. inout parameters are essentially MutableRef parameters, and Span & MutableSpan are array equivalents).

There’s now a built-in function for demangling Swift symbol names, in the Runtime module (that’s bundled with the Swift toolchain, alongside the stdlib etc).

Khoa Pham:

As Apple has aligned OS version numbers across platforms, Swift 6.4 takes the next step by letting you collapse repetitive availability attributes into a single anyAppleOS token.

[…]

There are situations where you need to call a deprecated API while you plan a migration, or audit a critical function for unsafe usage, without letting those concerns bleed into the rest of the project. The new @diagnose attribute handles both cases.

[…]

Some work should complete even after a task is cancelled, like flushing a file to avoid corruption. withTaskCancellationShield wraps a region where Task.isCancelled always returns false.

Antoine van der Lee:

Swift 6.4 implements SE-0493: Support async calls in defer bodies. This is one of those changes that feels obvious once you need it.

[…]

Swift 6.4 improves error handling for unstructured tasks through SE-0520: Discardable result use in Task initializers. The change helps you catch a subtle bug: creating a throwing task and then ignoring its returned task handle.

[…]

Swift 6.4 also implements SE-0530: Async Result Support.

[…]

Swift 6.4 implements SE-0518: ~Sendable for explicitly marking non-Sendable types. It allows you to communicate that a type has been audited and should not conform to Sendable.

Slava Pestov:

I thought it would be a good time to detail some of the type checker performance improvements we worked on since I shared the type checker performance roadmap last year. I’m also going to outline a couple of things we plan on looking at next.

Previously:

• Swift 6.3
• WWDC 2026 Links
• Xcode 27 Announced
• Swift Pitch: Borrowing Sequence
• Roadmap for Improving the Swift Type Checker
• Swift 6.2: Subprocess
• Swift Prospective Vision: Accessors
• Swift Proposal: Precise Control Flags Over Compiler Warnings

Update (2026-07-09): I was optimistic about improvements to the type checker making compilation faster, but I found that compiling my predominantly Swift project with Xcode 27 Beta 3 was only 0.3% faster than with Xcode 26.6. I wonder if there’s some extra setting I’m supposed to enable.

Holly Borla and Joe Heck (Hacker News):

Swift 6.3 introduces the @c attribute, which lets you expose Swift functions and enums to C code in your project. […] @c also works together with @implementation. This lets you provide a Swift implementation for a function declared in a C header[…]

[…]

Swift 6.3 introduces module selectors to specify which imported module Swift should look in for an API used in your code. If you import more than one module that provides API with the same name, module selectors let you disambiguate which API to use[…]

[…]

Provide pre-specialized implementations of a generic API for common concrete types using @specialize.

[…]

Guarantee inlining — a compiler optimization that expands the body of a function at the call-site — for direct calls to a function with @inline(always).

[…]

Expose the implementation of a function in an ABI-stable library to clients with @export(implementation). This allows the function to participate in more compiler optimizations.

The Swift Evolution proposals are listed here.

Florian Pircher:

I love that I can now name my module the same as the primary/only type of the module without making the module namespace unreachable.

Jordan Rose:

Congrats to my Swift colleagues for #finally pushing @c over the finish line! Been a long time coming.

Previously:

• Xcode 26.4
• Swift 6.2
• Swift Proposal: weak let

SwiftData updates:

Section your query results by creating your query with a macro that takes a sectionBy parameter, as listed on the Additional query macros page.

Use types that conform to Codable in a model, including types you don’t control directly, by using the codable option for Schema.Attribute.

Receive real-time updates to models that match specified fetch criteria by using the ResultsObserver type.

Observe remote model changes with the HistoryObserver type.

What’s new in SwiftData:

Discover the latest enhancements to SwiftData. We’ll show you how to persist custom and third-party types using Codable, and group fetched data into sections in your SwiftUI app. We’ll also explore how to observe data store changes anywhere else using ResultsObserver and HistoryObserver, giving you the flexibility to drive powerful state objects and react precisely to model updates.

Again, there seems to be nothing new in Core Data this year, nor any communication about it. There’s still no interoperability for object IDs. The SwiftData changes seem fine but don’t really address the new framework’s deficiencies relative to Core Data. It seems like there are still basic problems with threading. I just don’t understand how Apple is deciding what to prioritize with this framework.

With SwiftUI, the bones seem questionable, but at least we can see that Apple is full steam ahead, with substantial progress to address limitations and pain points. SwiftData seemed to have better bones and is much less ambitious. Getting it right seemed like just a matter of follow through. But, for some inexplicable reason, it seems to lack the resources and/or urgency to reach its potential. And even though SwiftUI is clearly the chosen one, AppKit remains in development. Meanwhile, Core Data seems to be abandoned, even though SwiftData feels more like a side quest than a genuine attempt to supplant it.

The implicit message, for those who have build the core of their app on top of Apple’s old persistence framework, seems to be that Apple is not looking out for their needs. Core Data will surely get maintenance to the extent that Apple’s own apps need it, but there’s no evidence of a future or even a migration plan. The answer, I guess, is third-party frameworks, but that’s not an easy migration, either, since none is even as close a match as SwiftData.

Add persistence with SwiftData:

Experience SwiftData in action as we add persistence to an existing app. We’ll show you how to define your data models and seamlessly integrate persistent data with SwiftUI. You’ll also learn foundational skills for managing your app’s state using this expressive, declarative API.

SwiftData Group Lab:

Join us online for a deep dive into WWDC26 with Apple engineers and designers to ask questions, get advice, and follow the discussion about the week’s biggest SwiftData announcements.

macOS Golden Gate 27 Beta Release Notes:

Fixed: You might experience a deadlock for @Query when saving a ModelContext on a background actor while scheduling new async tasks for a ModelActor.

Paul Hudson:

I am so pleased to say these words: IT IS A BIG YEAR FOR SWIFTDATA! 🎉

Mohammad Azam:

SwiftData predicates can now work directly with enum values, resulting in cleaner models and simpler query code.

[…]

In iOS 27, Apple introduced support for compound predicates through the Predicate(all:) and Predicate(any:) initializers, making it easier to build queries dynamically based on user input.

I’m not sure why that took so long.

The framework is gradually moving beyond simple demos and becoming easier to use in larger, more sophisticated projects.

[…]

iOS 27 is the first release where many of the framework’s early rough edges have started to disappear.

Matt Massicotte:

Results of my now-yearly check to see if SwiftData’s ModelActor continues to sometimes run code on the main thread: yes it does

Fatbobman:

Compared with @Query gaining support for section fetches, and ResultsObserver enabling observation of query result changes outside views, I am more interested in @Attribute(.codable). It provides a clearer storage intent and gives developers a way to avoid falling into the black box of composition.

Of course, @Attribute(.codable) is not a silver bullet. It is more like a clearly defined escape hatch SwiftData provides for opaque Codable types: suitable for storing external types that you cannot model yourself, but still genuinely need to persist. The cost is that this content cannot participate in SwiftData’s predicate, sort, or migration awareness. Precisely for this reason, its value lies not in being “more powerful,” but in being “more explicit.”

However, SwiftData still does not provide cloud syncing for public / shared data, nor have I seen a clearer signal of performance improvements. These issues will continue to limit its adoption. For many developers, SwiftData this year feels more like it is filling key gaps rather than making a leap significant enough to fundamentally change confidence in it.

Helge Heß:

Codable types in SwiftData seem pretty lame given that SQLite absolutely does have JSON support and does support queries on it?

But the funnier thing in the MKMapItem.Identifier example is that MKMapItem.Identifier is a RawRepresentable==String, so it could actually be stored as a String in the store.

Previously:

• WWDC 2026 Links
• Batch Delete in SwiftData
• SwiftData’s ModelActor Is Just Weird
• SwiftData Runtime
• Ways SwiftData’s ModelContainer Can Error on Creation
• SwiftData and Core Data at WWDC25
• Returning to Core Data
• Dynamic Swift Predicates in macOS 14 and iOS 17

CrashReportExtension:

The Crash Report Extension framework allows you to perform analysis and produce a report when your app crashes. Your crash-handling code executes out-of-process, rather than from a signal handler or other in-process techniques.

You implement your handler by writing an app extension that conforms to the CrashReporterExtension protocol. The system calls your processCrashReport(process:) method when the app crashes. Use the CrashedProcess parameter to inspect the state of the crashed app by retrieving a crash reason, symbolicating relevant addresses, and communicating with the process over a read-only Mach port. After collecting the crash data, you can send a report back to your own server.

[…]

Crash Report Extension is available on iOS 27 and later. It isn’t available to Catalyst-based macOS apps, or on iOS apps running on Mac computers with Apple silicon.

The top of the page says “macOS 27.0+,” so I guess this means it does work for regular AppKit and SwiftUI Mac apps. It’s great to finally have a supported way to do this.

I don’t know why they can’t just give you the crash report text or .ips JSON directly, though. It looks like you have to use Mach IPC with the corpsePort to get the backtrace for each thread and then use the extension API to symbolicate the addresses. Even then, I’m not sure you can get all the information that’s in a standard crash report, such as the Application Specific Backtrace. Maybe you can find the address for gCRAnnotations/__crashreporter_info__ and load it with mach_vm_read?

Previously:

• WWDC 2026 Links
• Visual Studio App Center Retirement
• What Happened to __crashreporter_info__?
• Restarting macOS Apps Automatically on Crash
• Crash Reporting for Sandboxed Mac Apps
• Reliable Crash Reporting

macOS Golden Gate 27 Beta Release Notes:

AsyncImage now automatically caches downloaded images using HTTP caching protocols, allowing servers to control caching behavior via standard headers.

[…]

Xcode 27 introduces a new @State implementation that avoids this repeated evaluation. This new behavior back-deploys to iOS 17 aligned OSes. The new @State is implemented with a Swift macro. It is largely source compatible with the property wrapper version, with a few exceptions.

[…]

Text views now support TextRenderer.

[…]

In apps built with the 27.0 SDKs, the new ReadableDocument and WritableDocument protocols support asynchronous reading and writing, progress reporting, and direct access to document URLs. New DocumentGroup initializers that adopt these protocols let you disable document creation for editing-only apps and present custom UI before any document is opened.

[…]

TextField respects custom font and color styling applied to its prompt.

[…]

List accepts drops in two cases that previously didn’t work: drags with compatible transfer representations are accepted into reorderable content even when the .reorderableItem transfer type isn’t present, and a .dropDestination(…) modifier declared on a list item now performs the drop.

SwiftUI updates:

Build your project in Xcode 27 or later to construct type-agnostic content from closures that you mark with ContentBuilder, which serves as the unified replacement for type-specific builders like ToolbarContentBuilder and CommandsBuilder.

Add reordering by drag-and-drop in containers such as lists, stacks, grids, or custom layouts with reorderable() and reorderContainer(for:isEnabled:move:).

Add custom swipe actions to views in containers such as scroll views, stacks, grids, or custom layouts using swipeActions(edge:allowsFullSwipe:content:onPresentationChanged:) and swipeActionsContainer().

[…]

Use the visibilityPriority(_:) modifier to prioritize important toolbar actions so SwiftUI keeps them visible as space shrinks, moving lower-priority items to the overflow menu first.

[…]

Present an alert or confirmation dialog from an optional data item or error object, and use that data to produce the content and title[…]

What’s new in SwiftUI:

Explore the latest additions to SwiftUI and discover how they can improve your apps. We’ll introduce a new Document protocol with direct disk access and snapshot-based diffing for building high-performance apps; new APIs for reordering content in lists, grids, and sections; and toolbar enhancements including visibility priority and auto-minimizing behavior. We’ll also cover expanded presentation APIs — including swipe actions on any view — plus AsyncImage caching improvements and lazy state initialization for Observable types.

Use SwiftUI with AppKit and UIKit:

Discover how to incrementally adopt SwiftUI in your existing AppKit or UIKit app. We’ll show you how to use the Observation framework to automatically update your views, integrate SwiftUI components into an existing view hierarchy, and bring gesture recognizers into SwiftUI. We’ll also explore how to add complete SwiftUI scenes to your app without changing your overall architecture.

Dive into lazy stacks and scrolling with SwiftUI:

Discover the inner workings of lazy stacks in SwiftUI. We’ll explore how LazyVStack and LazyHStack estimate sizes, lazily load subviews, and prefetch content to deliver smooth scrolling experiences. We’ll also cover advanced performance optimizations, state management best practices, and tips for precise programmatic scrolling. To get the most out of this session, we recommend basic familiarity with SwiftUI layout using stacks.

Compose advanced graphics effects with SwiftUI:

Discover how to craft rich, custom experiences by creatively composing SwiftUI layout and graphics APIs. We’ll show you how to break down complex designs and use a creative pipeline to chain simple building blocks together. Learn how to draw with layer shaders, animate with timelines, and anchor views with alignment guides.

Build powerful drag and drop in SwiftUI:

Follow along as we build a game of Solitaire to explore the latest drag-and-drop capabilities in SwiftUI. We’ll show you how to use the new reordering API to let people arrange content, implement drag containers to move multiple items at once, and customize the drag-and-drop lifecycle to fit your app’s rules.

There are also a bunch of labs.

Natalia Panferova:

Up until now it was a property wrapper conforming to the DynamicProperty protocol, but in Xcode 27 it becomes a Swift macro. In this post we will look at what the change means for @Observable models stored in @State.

Malcolm Hall:

Only took 3 years lol!

Majid Jabrayilov:

SwiftUI also introduces a new prominent tab role. You can use the prominent role for trailing-separated tabs, similar to search.

[…]

Document-based apps get a refreshed look and feel, along with a performance boost. It looks like Xcode has started using these improvements, which might explain why we see so much work around document-based apps this year. And finally, Xcode introduces SwiftUI Specialist and What’s New in SwiftUI skills for agentic coding in Xcode.

Fatbobman:

For me, the biggest change in SwiftUI comes from its comprehensive support for document-based apps. It not only adds a large number of new APIs, but also shifts the mental model toward “observable document objects + asynchronous snapshots + dedicated readers / writers.” This is clearly better suited to complex document apps, and it also aligns more closely with the overall evolution of modern Swift around Observation and Concurrency.

The sessions also mentioned that SwiftUI continues to optimize layout- and container-related implementations, bringing noticeable performance improvements in some scenarios. This is an improvement developers have urgently needed. However, SwiftUI still does not provide the ability to create custom Lazy containers, which remains a clear disappointment.

Natalia Panferova:

iOS 27 introduces new reordering APIs that work with any container. We can mark dynamic content with reorderable() and define the scope of the interaction with reorderContainer(for:). SwiftUI handles the drag preview, insertion placeholder, and drop animation, while our code applies the resulting change to the model.

SwiftUI’s drag container APIs are also now available on iPhone and iPad, after previously being limited to macOS. They let us make items in a collection draggable without making the collection reorderable, and include multiple selected items in the same drag. The APIs also support lazy generation of transferable values and drag-session observation.

robb:

I love the new #SwiftUI Text selection but without a way to make selection span multiple Texts in a group, it doesn’t really address our needs at Linear – here’s hoping we see an update in a later seed 🤞

Natalia Panferova:

The NavigationTransition protocol has been available in SwiftUI since iOS 18, letting us control how views animate when pushed onto a NavigationStack and when presenting sheets and full-screen covers. We specify the transition using the navigationTransition(_:) modifier on the destination or presented view, and SwiftUI uses it instead of the default animation for that context. Before iOS 27, SwiftUI provided two built-in conforming types: AutomaticNavigationTransition, used via the automatic static value, which defers to the system default for the current context, and ZoomNavigationTransition, used via zoom(sourceID:in:), which animates the presented view expanding from a source view marked with matchedTransitionSource(). iOS 27 introduces CrossFadeNavigationTransition, a new built-in transition that cross-fades between views without requiring a source, and adds AnyNavigationTransition, a type eraser that lets us select a transition at runtime.

Kyle Howells:

The last few years watching WWDC has been a mixed experience for me, because I honestly believe Swift and SwiftUI are actively either bad or being made worst.

Yet every year, the problems I have with them are doubled down on, not improved.

Kyle-Ye:

The FB21333309 cache bug I submitted is now confirmed to be fixed on iOS 27.

Instead of introducing a new CacheKey like I suggested, SwiftUI team choose to move the intensity payload out of the FeedbackType enum to a new Payload enum and add a new payload var to SensoryFeedback storage.

dasdom:

A few weeks ago I realised that most iOS jobs require knowledge of SwiftUI. So I started to rebuild my Mastodon client in SwiftUI. Then I got an offer for a new job and accepted it. This means I can get back to working on the ObjC version. Feels good. :)

Previously:

• UIKit in iOS 27
• AppKit in macOS 27
• WWDC 2026 Links
• Rewriting Notion in SwiftUI
• Xcode 27 Announced
• Xogot for Mac Beta
• WWDC 2026 Preview
• Where Did SwiftUI Leave You Hanging?
• WWDC 2026 Wish Lists
• SwiftUI at WWDC 2025

Update (2026-06-23): Natalia Panferova:

iOS 27 adds new AsyncImage initializers that accept a URLRequest instead of a URL. We can now configure request headers, cache policy, and timeout interval while continuing to use the built-in loading and phase handling provided by AsyncImage. A new asyncImageURLSession(_:) modifier also lets us provide the URL session used by asynchronous images in a view hierarchy.

Update (2026-07-10): Luc Vandal:

SwiftUI .reorderable() crashes when the reordered view body contains if #available: “Unexpected identifier type. Expected [Type], got [Type]”

[…]

Even attaching a .popover to an item causes it to crash when reordering.

Update (2026-07-23): Yakov Manshin (video, via Mohammad Azam):

Seven years after its blockbuster 2019 announcement, SwiftUI was supposed to be the mature, production-grade future of cross-platform UI development on all Apple platforms. Instead, SwiftUI feels like a perpetual beta, even in 2026. In this deep dive, I break down why the initial excitement has given way to deep professional frustration for senior engineers. I analyze the systemic issues with performance and layout predictability, the chaotic state of SwiftUI’s ever-changing data flow, and the frustrating lack of backward compatibility that forces developers into a nightmare of shims and workarounds.

Through real-world examples—including Apple’s own SwiftUI tutorial (which is broken) and a head-to-head performance comparison with UIKit (guess who wins)—I demonstrate how SwiftUI trades precise engineering for an illusion of convenience.

Beyond the code, this video explores a broader, more concerning shift in Cupertino: a transition away from the uncompromising craftsmanship of the original era of Cocoa, Aqua, and Auto Layout toward a modern corporate culture of “good enough” products.

macOS Golden Gate 27 Beta Release Notes:

AppKit adds NSRefreshController, providing pull-to-refresh functionality for NSScrollView.

[…]

NSToolbarItemGroup adds the role property and the NSToolbarItemGroupRole enum, allowing toolbar item groups to be tagged with a semantic role. NSSegmentedControl similarly adds a role property and the NSSegmentedControlRole enum, including a tabs role for controls that represent tab-based navigation and content selection.

[…]

NSTextSelectionManager provides common text selection interactions (click, drag, shift-click, double/triple-click word/line/paragraph selection) to a NSView with a set of NSGestureRecognizers rather than overriding NSEvent mouse methods. NSTextView now uses NSTextSelectionManager and provides its own set of NSGestureRecognizers to provide additional features in addition to text selection.

[…]

By default, NSMenu hides all menu item symbol images — non-symbol images remain visible. […] Use the new preferredImageVisibility property on NSMenuItem to customize the image visibility for your menu items. As in macOS 26.0, NSMenu automatically provides default visible menu item images for certain common system-wide menu items, such as Settings, Share, and Print.

AppKit updates:

Create events similar to UIControl events on NSControl with the new NSControl.Events type.

[…]

Initiate a drag operation from a gesture recognizer using the new beginDraggingSession(items:gesture:source:) method on NSView.

[…]

Update views automatically in response to Observable model changes using the guidance in Updating views automatically with observation tracking.

How is this different from what was announced last year?

Modernize your AppKit app:

Bring your AppKit app up to date with modern macOS conventions. Dive into handling input with control events and gesture recognizers, moving beyond traditional tracking loops. Enhance keyboard navigation in your app, implement graceful state restoration after restarts, and take advantage of new corner concentricity APIs that let your interface blend seamlessly with the macOS aesthetic.

Steve Troughton-Smith:

To summarize the singular AppKit session this year: hey remember all these APIs and design patterns from UIKit? Well they’re now in AppKit and you should use them! Also make your glass use interactive bounce effects.

Why? No reason!😉

TN3212:

In macOS 27, AppKit continues to standardize on gesture recognizers as the primary mechanism for input handling. This change directly affects Sidecar because gesture recognizers are the only way to respond to touch input from a Sidecar-connected iPad running iPadOS 27. If your app relies on tracking loops for mouse event handling, migrate to gesture recognizers to support Sidecar touch input.

This article explains how the gesture recognizer model works, how to implement gesture recognizers correctly for Sidecar touch input, how to update your existing event-handling code, and which APIs macOS 27 adds. Codebases that implement nextEvent(matching:) or mouseDown(with:), mouseDragged(with:), and mouseUp(with:) events are most affected by the updates discussed.

Greg Pierce:

After the AppKit session blindsided me a bit after telling me not to override mouseDown, and then telling me I should override hitTest

Mario Guzmán:

A few years ago, Apple introduced:

func tableView(_ tableView: NSTableView, userCanChangeVisibilityOf column: NSTableColumn) -> Bool

for NSTableView, which Is a native way users could control-click on a TableView column to show/hide columns.

This year, in #macOS27, they updated it to have a new “Reset to Defaults” option.

This is awesome bc I have done my own implementation of this feature JUST to have the option to “reset all columns” and now Apple just includes it!

Elevate your app’s text experience with TextKit:

Discover how to combine the convenience of built-in text views with the control of TextKit. We’ll show you how new APIs make it easy to extend UITextView and NSTextView with custom behaviors like line numbers and collapsible sections. We’ll also explore the TextKit architecture and walk through new caching and reuse policies for text attachments.

Previously:

• macOS Touch
• WWDC 2026 Links
• Golden Gate Menu Icons
• Golden Gate Sidebars and Toolbars
• TextKit 2: The Promised Land

iOS & iPadOS 27 Beta Release Notes:

[You] can use UIScene.extendStateRestoration and UIScene.completeStateRestoration to extend state restoration for UIScene.ActivationState.background to UIScene.ActivationState.foreground lifecycle transitions.

[…]

iOS and iPadOS apps built with the 27.0 SDK or later are required to include a launch screen.

[…]

Siri can load resources from drag interactions installed in your app’s interface.

[…]

In apps built with the iOS 27.0 SDK, a presented view controller inherits its trait collection by walking up its view’s superview chain through the intermediate views of the presentation, rather than jumping directly to the presentation controller.

UIKit updates:

Use UICollectionViewCompositionalLayoutSectionProvider closures as part of automatic observation tracking to automatically invalidate and update compositional layouts when observable objects change.

[…]

Use UIRefreshControl and UIStepper in Mac apps built with Mac Catalyst. These controls are now fully supported in the Mac idiom.

[…]

Starting in iOS 27, apps built with the latest SDK must use the scene-based life cycle or they fail to launch.

[…]

Use NSTextTable, NSTextBlock, and NSTextTableBlock to represent table structures in attributed strings.

Modernize your UIKit app:

Discover the latest updates to UIKit. Learn how to update your iPhone app layouts to work great when resized with iPhone Mirroring and on iPad. Explore new APIs for tab and navigation bars, find out how to prepare your app for new Apple Intelligence capabilities, and get introduced to a skill for your coding agent of choice that helps modernize your codebase.

Kyle Howells:

iOS 27’s UIKit is a tiny release in terms of API changes, but does have some changes. There are no new top-level paradigms, but there’s an new addition to TextKit 2, a new scene accessory API, Liquid-Glass-era bar minimization controls, and a small amount of quality-of-life additions to menus, tab bars, and drag interactions.

Hartley Charlton:

Apple appears to be laying the groundwork for a foldable iPhone in iOS 27, with new references discovered in the operating system’s frameworks and a notable emphasis on flexible app layouts at this year’s Platforms State of the Union.

Jordan Morgan:

The nav bar and its friends got quite a bit of attention, and to be honest that’s where we will find most of the changes. They adapt to all sorts of sizes and situations…hmmm, I WONDER WHY!?

[…]

A few years ago, I wondered if UIKit would be deprecated altogether. That would’ve been drastic, sure, but I did wonder. These days, I don’t share the same concern anymore. SwiftUI gets better each year, and yeah — it’ll have top billing. But UIKit is solid, and it appears to be a core part of Apple’s strategy into the future.

Not much changed this year, and not much was added that’s flashy. But, that’s true of iOS 27 in several ways.

Previously:

• UIKit in iOS 26
• WWDC 2026 Links