Swift at Apple: Migrating the TrueType hinting interpreter
swift.org240 points by DASD 4 days ago
240 points by DASD 4 days ago
If you want to help improve the security of OS software through the magic of memory safe languages, the team that did this work is hiring: https://jobs.apple.com/en-us/search?search=Spear&sort=releva...
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.
How do I apply? Historically jobs.apple.com is a black hole unless you know people.
Apple (like most large tech companies) is indeed a resumé black hole, and knowing people helps, so definitely network if possible. However, applying to the right position, with a good resumé that highlights experience/skills/projects/open source contributions/education/etc. that are directly related to the position, also matters. I am aware of several people who simply applied online and got interviews.
I may be wrong about this, but I don't think Apple bans you from applying to multiple positions within the same year the way some companies do.
There also seems to be a decent pipeline for new graduates (though I think highlighting relevant academic, research, and open source projects can still help.) Internships can also be a path if you are currently in school.
I don't know if Apple recruits on linkedin, but that might also be an option.
Of course connecting right here on HN seems like a great idea as well.
I was hoping to get some sort of a more direct contact from GP since he advertised the position. Not sure why would you mention it on HN otherwise.
> However, applying to the right position, with a good resumé that highlights experience/skills/projects/open source contributions/education/etc. that are directly related to the position, also matters.
I assume that Apple is even more competitive, than my current place. But even here it is not realistic: I heard we’re getting 500+ applications/position/day and _nobody_ looks at them unless there’s a lead/recommendation.
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.
Any resources you'd recommend for learning about reasoning about the security of code?
For low-level system security, I'm a fan of https://llsoftsec.github.io/llsoftsecbook/LLSoftSecBook.pdf as an overview for any systems developer, not just compiler devs. It might not be the most approachable, but it's got great info on everything memory corruption.
> 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.
I've always wondered if JS engines could rewrite those array functions at compile time, like this: https://github.com/SomeRanDev/Haxe-MagicArrayTools
Though, it probably wouldn't work if user code modified the Array prototype.
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!
The work discussed in this post shipped in the OS last year (fall 2025), so nothing here is dependent on very recent changes.
During the State of Platform keynote, on the subject of Swift adoption across macOS, several examples were given, not only TrueType engine.
RIS is happening across all OS levels, if the keynote is to be believed.
They’ve been doing it for years. I don’t remember how we first knew, but I know they’ve been using Swift in kernels for at least some of the other chips like the Secure Enclave or whatever.
I’m not sure exactly which. I assume it’s some of the code and not all. But it’s not new in the abstract.
That said I don’t think I’ve heard of it in the kernel of MacOS on the main processor. That may be new.
Either way this is certainly the most concrete announcement I remember them ever giving on this stuff.
I know internally they use an IPsec implementation written by Rust (I think in the iCloud infra). Heard this from an ex-Apple engineer Ben (forgot his last name) that did a wonderful presentation of Rust from first principles. He said that it was hard to get people in on Rust when most would argue for Swift.
Edit: This is the guy: https://rustcurious.com/course/
Some stuff was discussed at Meet with Apple security event a few months ago, and the talks on FoundationDB rewrite, or why Swift Embedded subset came to be.
However I miss them actually having had one of those 15 - 30m WWDC sessions, where they could have gone a bit deeper into the keynote examples
Curious the direction of Webkit as there was a nebulous mention of select portions being rewritten from C++ to Swift. And yet, the new ECMAScript module (ESM) loader for Safari 27 is implemented in C++ (https://webkit.org/blog/17967/news-from-wwdc26-webkit-in-saf...).
No idea, maybe the private parts of the code, Safari isn't open source, or is coming later.
In any case I would have liked to have more info during the deep dive sessions.
As it is, Meet with Apple on security (a 5h long event) had much more information.
Alexandre Colucci has published a series of articles analysing the use of Swift in iOS and macOS by Apple here:
https://blog.timac.org/categories/reverse-engineering/
And frequently discussed on Hacker News:
https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...
What does RIS stand for?
Rewrite in Swift
[flagged]
s/better/blurrier/
Life without retina displays is possible, but pointless.
Lower DPI is quite okay with good font rendering (FreeType, slight hinting, subpixel rendering). I have both kinds of devices.
I get kind of nostalgic when I see Verdana on 1024x768 in winxp/2k.
ClearType was/is a nifty technology. I remember I had a HP Jornada PocketPC that came preloaded with The Time Machine to show off ClearType.
I sometimes wish I’d never seen a Retina display. There’s no going back for me now.
Interesting that this is published under the MIT, rather than Apple’s more favorite Apache 2, license
Why is it interesting?
Presumably because MIT is even more permissive and it’s a change in Apple’s behavior.
Some corporations prefer Apache 2.0 for projects where they'll be accepting contributions, because it includes patent protection and retaliation clauses. In case like this, where source code is just being published for reference and contributions aren't accepted, those risks don't exist.
Given the age of TrueType, wouldn't nearly all patents be expired already?
Apache2's license I've heard described as mutually-assured-patent-destruction - if you use the code and make a patent claim, your rights to use the code go away.
So Apache2 offers little benefit here, and MIT may get it into more hands?
The author discussed this a bit on Mastodon as well:
> 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.
Back in 2023 there was talks about Microsoft rewriting the font stuff in Rust for similar reasons Apple is now doing the Swift move.
I'm not sure what became of it and if it ever shipped. If anyone knows I'd be curious.
Russinovitch (Azure's CTO/CISO) gave a speech at RustConf 2025 and mentions it(DirectWriteCore) took 2 engineers 6 months resulting in 154K LOC and 5-15 percent performance increase for font shaping. https://www.youtube.com/watch?v=uDtMuS7BExE&list=PL2b0df3jKK...
So, hinting only takes place at low resolutions, I believe. How often is it used, eg viewing “typical” PDFs on “typical” screens?
There are fonts that rely on hinting for correct shaping at all sizes: https://xoxo.zone/@numist/116716601962175503
"we used a fuzzer to minimize a corpus of 10 million PDF files down to 4,200 without any loss of code coverage"
Did they need a fuzzer for that? They could've render them all and see what's exercised?
Its a set cover problem, and is NP-hard. 4100 of something probably runs nicely in your laptop in a reasonable amount of time.
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
As much as I enjoyed Swift, one can only wonder what the world would look like if they had gone with Rust as their default language instead.
Rust doesn't have an ABI [1]. Swift needed one to be a useable application language:
https://faultlore.com/blah/swift-abi/ (written by a core Rust developer)
[1] apart from the basic/universal C one, which prevents exposing any useful Rust semantics over the interface
One of the genius things about Swift is its interop with Objective C. Made the switch over considerably easier for developers. I’m not sure what that looks like in a Rust world.
Rust is also just a more complex language. I’m not convinced the benefits would have been worth it.
Not just interoperability with Objective C but with C (full) and C++ (increasingly better but not full) as well.
Swift is also interoperable with different versions of itself courtesy of the Swift stable ABI (Application Binary Interface)[0], which they invested a significant amount of time into at the expense of adding other new features to the language, which have come along later.
Rust offers a different approach: recompile everything and static linking.
C compatibility comes via Objective-C, because contrary to C++, Objective-C extends C, instead of being based on a C subset.
You missed Java as well.
Modern Swift borrows a lot from Rust! And it also has its own benefits, both ergonomic and also supporting eg generic in dynamic libraries
These days I mainly write Rust but I did write a semi complex iOS app and enjoyed Swift. I just didn't love how slow the type checker was and how it got lost. I recall having to break things into smaller bits to help the compiler, and there were some oddities about the language.
The gap between the two languages is quite small, it just makes me wish Apple was also all-in on Rust
In the last year they’ve added improvements to the type checker to speed it up, those would have been released now.
They have further and much more significant changes that I think might have recently landed in the development version. That should make an even bigger difference. But it’s not in a released version yet.
And yes, none of us like that one part of Swift. Especially the DRASTIC difference compared to objective-C which really only checked syntax and little else.
It’s still probably my favorite language right now though I don’t get to write in it much.
I see Swift as a more approachable version of Rust.
If somebody is mulling over Rust but finds it too difficult to grasp, they could start off with Swift first and then move over to Rust.
One of the main advantages of Rust is a more developed and thriving ecosystem.
It has an unfortunate name though, maybe a short shelf life. Rust++ doesn’t seem inviting either.
Rust does not have a ++ operator, so that name would make no sense.
Not yet.
I can assure you that Rust will never have a ++ operator. Not only is it semantically bizarre, it's entirely unnecessary in a language where iteration is overwhelmingly performed via iterators rather than via manually incrementing array indices.
Is that a bullet point in the Rust manifesto? :) In any case, ++ has taken another meaning outside of operator loading and such some.
The “Rust” branding, to this rando, implies corrosion, oxidation, decay, regardless of the true origin of the name. Swift is “quick”, Java is “caffeine”, Rust is something I need kerosene for.