❌

Normal view

Whisper and SpeechAnalyzer

22 July 2026 at 21:34

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:

Git Tower 17

20 July 2026 at 16:27

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:

notarytool Can’t Handle Zip64 Files

20 July 2026 at 16:27

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:

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

15 July 2026 at 19:53

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:

Dissecting Apple’s Sparse Image Format (ASIF)

30 June 2026 at 20:48

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:

Xcode 26.6

26 June 2026 at 18:23

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’s Device Hub

25 June 2026 at 18:25

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:

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.

Swift Package Index Joins Apple

24 June 2026 at 21:55

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

24 June 2026 at 21:54

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:

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.

Swift 6.3

24 June 2026 at 21:54

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:

SwiftData in appleOS 27

23 June 2026 at 20:14

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:

CrashReportExtension

22 June 2026 at 21:51

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:

SwiftUI in appleOS 27

19 June 2026 at 20:43

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:

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.

AppKit in macOS 27

18 June 2026 at 19:56

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:

UIKit in iOS 27

18 June 2026 at 19:56

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:

Core AI Announced

18 June 2026 at 19:55

Meet Core AI:

Discover Core AI, Apple’s new framework for on-device AI model deployment. Tour the ecosystem, from Python libraries for converting, authoring, and optimizing models, to a Swift API for simple plug-and-play inference and advanced use cases with strict latency and memory requirements. Explore the new Core AI models repository with ready-to-run examples for popular architectures. See how deep Xcode integration, including ahead-of-time model compilation, streamlines the workflow so you can deliver smarter, more responsive app experiences.

Dive into Core AI model authoring and optimization:

Dive into the complete custom model deployment workflow for Apple silicon with the new Core AI framework. Discover powerful techniques for authoring models using custom Metal kernels, alongside platform-aware compression strategies. The new Core AI Debugger offers deep intrinsic analysis, and AI-assisted workflows guide you from initial concept to optimized on-device execution.

Integrate on-device AI models into your app using Core AI:

Discover a curated collection of popular open-source models — including Qwen, Mistral, SAM3, and more — optimized for Apple silicon using the new Core AI Framework. Learn how to download, run, and benchmark models on your Mac, and integrate them into your app with just a few lines of code. Explore a new workflow for model compilation and on-device specialization to speed up first-time model load. Find out how to profile and optimize runtime performance with Core AI tools in Xcode.

Core AI Documentation (Hacker News):

Core AI helps you build, run, and deploy AI models in your app. Designed with Apple silicon in mind, Core AI allows your app to use the latest model architectures and inference techniques across the CPU, GPU, and Neural Engine. The Swift API makes common tasks simple, while giving you more control over model specialization, caching, and inference performance when needed.

Previously:

WWDC 2026 Links

17 June 2026 at 20:16

General:

Documentation:

Sessions:

Podcasts:

Previously:

Rewriting Apple’s TrueType Hinting Interpreter in Swift

12 June 2026 at 20:34

Scott Perry:

My team rewrote Apple’s TrueType hinting interpreter in Swift, ask me anything.

[…]

I feel like naming just one would be a disservices to all of the features that made this effort possible (C interop, generics, noncopyable/nonescapable types) but at the end of the day I think the star of the show was the optimizer; despite being faster than the code it replaced, the new code is super readable and that was only possible because the optimizer was able to completely eliminate all of our abstractions.

The new version is faster, but the main motivation was security concerns.

Dmitrii Kalianov:

Is hinting useful/being used in the days of hi-dpi displays? I was under impression that Apple switched to grayscale anti-aliasing and ditched hinting.

Scott Perry:

For the most part hinting isn’t really necessary anymore, but thanks to being Turing-complete it has been Hyrum’s law-ed by at least one CJK font that uses hinting to lay out strokes in its characters.

Alex Rosenberg:

There were three major TrueType implementations at Apple IIRC:

  • The original 68K one
  • A rewrite for Copland that lived with ATS/ATSUI after Copland was cancelled
  • iPhone shipped one derived from heavily-modified FreeType that was current until today

Scott Perry:

One of the axioms for this project was that I wanted my team to write the most boring code possible—nearly identical structurally to the code it was replacing, because to do otherwise would introduce binary compatibility risk. The other axiom was 100% test coverage for all new code as it landed, with the same units testing both interpreters.

Rosyna Keller:

Is the font parsing code itself still C++?

Scott Perry:

There is also a “Safe Font Parser” for WebKit in Lockdown Mode, but it supports a subset of all the myriad features provided by font formats.

Previously:

Update (2026-06-16): Scott Perry (Hacker News):

Font parsers process data from untrusted sources, making the TrueType hinting interpreter a security-critical attack surface. To make the format more resilient on Apple platforms, we rewrote its hinting interpreter from C to memory-safe Swift for the Fall 2025 releases. In addition to memory safety, we also improved performance: on average, our Swift interpreter runs 13% faster than the C interpreter it replaced.

[…]

Binary compatibility was crucial for this project to succeed: existing programs had to continue to function the same as they did before, effectively unaware that a new implementation was in place. This means not just interface compatibility but pixel-identical glyph rendering as well, relative to the C implementation.

[…]

To ensure correctness, we developed two test suites. The first was a unit test suite that can target both implementations, providing exhaustive (99.7%) code coverage for both. This suite is included with the open source release of the Swift interpreter.

Then, to represent real-world workloads, we used a fuzzer to minimize a corpus of 10 million PDF files down to 4,200 without any loss of code coverage.

[…]

Following WebKit’s Safer Swift Guidelines, the example below demonstrates how to wrap a bridged structure from C in a projection type that uses Ref for lifetime safety, brokers bounds-safe access to the underlying data, and returns idiomatic Swift types to its callers.

The interpreter source is on GitHub.

Marcin Krzyzanowski:

@_lifetime(copy code, copy twilightZone, copy glyphZone)

See also: Phillip Tennen’s Writing a TrueType font renderer (Hacker News).

Previously:

Golden Gate Menu Icons

9 June 2026 at 19:15

Wesley Hilliard:

macOS Tahoe threw an icon on every menu item, making them impossible to distinguish at a glance. macOS Golden Gate has rectified that design taboo with blessedly iconless menus.

Apple:

In macOS 27.0, menu bar and context menus present a reduced set of menu item images, similar to the behavior prior to macOS 26.0. By default, NSMenu hides all menu item symbol images — non-symbol images remain visible. For menu items created from a xib file, NSMenu also observes the value of the “macOS 26.0 only” checkbox in the menu item inspector. If this checkbox is unchecked, the menu item image remains visible; if checked, it is hidden. These changes in menu item image visibility apply to applications linked on macOS 26.0 and later. Review the updated Human Interface Guidelines to determine which menu items in your app should still display images. 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.

Joachim Kurtz:

„Icons in menus are now hidden by default“ and you can specifically enable them to draw attention to the most important actions.

Don’t get me wrong, this is a great change! But to take a full year and your lead designer leaving to figure out that this was a mistake… woof…

Dominik Wagner:

I like that Menu Icons now are hidden by default again on macOS - Quite a lot of concessions towards liquid glass being the wrong move last year. Takes courage to take so many steps back, literally. I’m appreciating that. Even if they present it as improvements rather than “undo” - that’s just what one has to do for marketing.

Previously:

Update (2026-06-11): John Gruber (Mastodon, Hacker News, MacRumors):

Wonderful news in MacOS 27 Golden Gate: the icons are gone. It’s like Tahoe’s menu item icons never happened. Prokopov noted it on Mastodon with before and after screenshots, and mentions that Apple has updated the Human Interface Guidelines accordingly[…]

[…]

This is my favorite news from all of WWDC this week.

Marcin Wichary:

Kudos to Nielsen and Prokopov for pushing on this and explaining the problem so well. This wasn’t about ugly icons. This was about improper use and misunderstanding of iconography.

❌