I think these are the types of things Apple should've focused on instead of half-heartedly barging ahead with SwiftUI and breaking the language in the process
I'm surprised the code has visible LLM smells. Though, I shouldn't be surprised. I hope the important bits are still human-controlled (and the same for Apple's many operating systems that absolutely deserve to remain stable and understood).
Swift takes the right approach in language ergonomics, many of its use cases would be much harder with explicit .clone() all over the place, lack of back references, no standard ABI for binary libraries, interop with Objective-C and C++, no standard concurrency runtime, or error handling types.
Rust 2026 roadmap has language ergonomics on it for a reason.
That said, outside Apple ecosystem you probably better with Rust, or if one has no GC issues, OCaml, Haskell, F#, Scala, C#.
Apple has a runtime system that looks a lot like smalltalk. Everything at that layer is dynamic. They needed a language that could seamlessly interact with that system.
Yeah, probably should have made a more substantive comment. I'm mostly thinking of the trio of Skrifa, Harfrust, and Parley, but there is other open source Rust work that qualifies as well.
There's also, very relevantly, the DWriteCore work from Microsoft. My understanding is that there's been some talk of open sourcing that, but it's still proprietary.
There are other things that count as high performance text in memory safe languages, for example implementations in Go, but in general those are not a good candidate to replace C and C++ in environments like operating systems and browsers.
What's funny is from 2023 (I think), macOS just draws the UI unhinted. You have a 1080p display and you don't want to see the letters in the UI blurred to death? Tough luck, 1080p is incompatible with macOS, everybody needs "retina", and nobody cares that Windows and all Linux DEs look on 1080p just fine.
It looks like this hinter will be used only in rendering PDFs, because that's where they test the performance.
While hinting is disabled for most fonts, there are some fonts that require hinting to render correctly. We have to support hinting for those fonts, and it was easier to make it secure by rewriting hinting in Swift than it would have been to comprehensively identify every font created by those foundries.
Retina displays were introduced more than a decade ago. Why should Apple still support outdated technology after such a long time?
If you work with text and fine UI elements, do yourself a favour and get proper tools for the job. Get an ergonomic mouse and a good keyboard while you're at it. In every other field professionals use high quality tools to do their jobs, IT shouldn't be any different.
A plumber has equipment worth tens of thousands of dollars, while IT professionals think it's outrageous to pay a few hundred for equipment which is undeniably an improvement.
Knowledge of Swift not required. If you know your way around OS software, can reason about the security of the code you write, and are excited about writing exhaustively tested software, we’d love to talk to you.
We’re hiring for roles in kernel/systems and userspace. Like the Platforms SOTU mentioned, we’re using Swift at all layers of the software stack now. https://www.youtube.com/live/yl2jsIoMfDU
I had the pleasure of leading the effort to ship Swift in the Secure Enclave back in 2022. Now I have multiple teams working on accelerating the transition to memory safe languages. We’re showing that with good planning and a relentless focus on testing, we can improve security, performance, and functionality. And we get to have a ton of fun working with some amazing colleagues. It’s the most enjoyable and impactful work I’ve ever done in my career.
Great to see this happening. Personally I want an OS where everything is memory-safe by default.
Of course in an alternate universe where macOS (and iOS etc.) was based on Multics rather than Unix, it would have had essentially zero buffer overflows - which are hard to create in PL/I but hard to avoid in C. Even Apple's Pascal compilers from the 1980s had range checking...
But legacy C code can/should absolutely use things like clang's -fbounds-safety (has been in clang on macOS for years) etc. Fil-C is another option.
Beware: As of a few months ago, when I tried to use the lifetime features shown off in this post, I ran into constant compiler crashes with very simple programs, until I gave up and wrote off the features as unusable. This happened on both stable and nightly compilers. I guess they work well enough for this TrueType interpreter, but I suspect they’re using a narrow subset of what the features are supposed to support. Or maybe things have been fixed very recently.
That said, I’m looking forward to using Swift lifetimes once they actually work!
> Operations like filter and map allocate memory, but that allocation is only necessary if the value escapes. The Swift standard library provides .lazy.map and .lazy.filter, but they don’t work in every case. For logic that only iterates over the filter or map, it’s much more efficient to loop with continue (or use for … in … where) and transform elements into local variables as necessary.
It does feel like a compiler/optimiser failure to have to rewrite those cases.
It isn't. You'd need full lifetime analysis as part of the compiler to even decide whether you _could_ skip the allocation, and even then it's 100% up to the circumstance and actual lifetime of the data to say whether it can be, e.g. stack-allocated to avoid placing it somewhere less localized.
> By the end of the project, we wrote nearly four times as many lines of test code as we wrote for the Swift interpreter itself.
This is the most interesting bit to me. Engineers consistently underestimate the amount of effort that testing demands for projects that need truly high quality, it’s nice to see this shared.
29 comments
[ 3.2 ms ] story [ 43.8 ms ] threadRIS is happening across all OS levels, if the keynote is to be believed.
https://blog.timac.org/categories/reverse-engineering/
And frequently discussed on Hacker News:
https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...
https://xoxo.zone/@numist/116716469017975106
I'm not sure what became of it and if it ever shipped. If anyone knows I'd be curious.
Rust 2026 roadmap has language ergonomics on it for a reason.
That said, outside Apple ecosystem you probably better with Rust, or if one has no GC issues, OCaml, Haskell, F#, Scala, C#.
Vello has been a big inspiration and source of knowledge for my own webgpu text renderer, thank you for that!
Just strings or rendering strings?
If the latter, who are the other members of the club?
There's also, very relevantly, the DWriteCore work from Microsoft. My understanding is that there's been some talk of open sourcing that, but it's still proprietary.
There are other things that count as high performance text in memory safe languages, for example implementations in Go, but in general those are not a good candidate to replace C and C++ in environments like operating systems and browsers.
Skrifa - Skia in Rust. https://github.com/googlefonts/fontations/tree/main/skrifa , https://developer.chrome.com/blog/memory-safety-fonts
Harfrust - HarfBuzz in Rust. https://github.com/harfbuzz/harfrust , https://github.com/googlefonts/oxidize
Parley - text layout in Rust. https://github.com/linebender/parley
DWriteCore - the Windows App SDK implementation of DirectWrite. https://learn.microsoft.com/en-us/windows/win32/directwrite/...
It looks like this hinter will be used only in rendering PDFs, because that's where they test the performance.
If you work with text and fine UI elements, do yourself a favour and get proper tools for the job. Get an ergonomic mouse and a good keyboard while you're at it. In every other field professionals use high quality tools to do their jobs, IT shouldn't be any different.
A plumber has equipment worth tens of thousands of dollars, while IT professionals think it's outrageous to pay a few hundred for equipment which is undeniably an improvement.
Knowledge of Swift not required. If you know your way around OS software, can reason about the security of the code you write, and are excited about writing exhaustively tested software, we’d love to talk to you.
We’re hiring for roles in kernel/systems and userspace. Like the Platforms SOTU mentioned, we’re using Swift at all layers of the software stack now. https://www.youtube.com/live/yl2jsIoMfDU
I had the pleasure of leading the effort to ship Swift in the Secure Enclave back in 2022. Now I have multiple teams working on accelerating the transition to memory safe languages. We’re showing that with good planning and a relentless focus on testing, we can improve security, performance, and functionality. And we get to have a ton of fun working with some amazing colleagues. It’s the most enjoyable and impactful work I’ve ever done in my career.
Of course in an alternate universe where macOS (and iOS etc.) was based on Multics rather than Unix, it would have had essentially zero buffer overflows - which are hard to create in PL/I but hard to avoid in C. Even Apple's Pascal compilers from the 1980s had range checking...
But legacy C code can/should absolutely use things like clang's -fbounds-safety (has been in clang on macOS for years) etc. Fil-C is another option.
That said, I’m looking forward to using Swift lifetimes once they actually work!
It does feel like a compiler/optimiser failure to have to rewrite those cases.
Did they need a fuzzer for that? They could've render them all and see what's exercised?
This is the most interesting bit to me. Engineers consistently underestimate the amount of effort that testing demands for projects that need truly high quality, it’s nice to see this shared.