180 pointsby DASD10 hours ago13 comments
  • jacquesgt4 hours 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.

    • byproxy3 minutes ago
      Any resources you'd recommend for learning about reasoning about the security of code?
  • comex4 hours ago
    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!

    • stephencanon4 hours ago
      The work discussed in this post shipped in the OS last year (fall 2025), so nothing here is dependent on very recent changes.
  • pjmlp9 hours ago
    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.

    • MBCook6 hours ago
      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.

      • commandersaki5 hours ago
        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/

    • DASD9 hours ago
      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...).
      • pjmlp8 hours ago
        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.

    • hirvi747 hours ago
      What does RIS stand for?
      • gyomu7 hours ago
        Rewrite in Swift
        • willXare7 hours ago
          So RIS is Apple’s version of RiiR, but with better fonts.
          • cwillu5 hours ago
            s/better/blurrier/
            • steve1977an hour ago
              Life without retina displays is possible, but pointless.
            • thewebguyd5 hours ago
              Careful, you’ll bring out all the “but it’s true to print media” people.
  • mrpippy9 hours ago
    The author discussed this a bit on Mastodon as well:

    https://xoxo.zone/@numist/116716469017975106

    • numist8 hours ago
      I'm also here :)
      • atdt5 hours ago
        Excellent write-up!
  • saagarjha9 hours ago
    Interesting that this is published under the MIT, rather than Apple’s more favorite Apache 2, license
    • JumpCrisscross9 hours ago
      Why is it interesting?
      • drob5188 hours ago
        Presumably because MIT is even more permissive and it’s a change in Apple’s behavior.
        • favorited7 hours ago
          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.
        • zdw7 hours ago
          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?

  • weinzierl9 hours ago
    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.

  • ks20484 hours ago
    So, hinting only takes place at low resolutions, I believe. How often is it used, eg viewing “typical” PDFs on “typical” screens?
  • airstrike8 hours ago
    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.
    • AceJohnny27 hours ago
      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

    • afavour7 hours ago
      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.

      • inkyoto23 minutes ago
        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.

        [0] https://faultlore.com/blah/swift-abi/

    • jadengeller8 hours ago
      Modern Swift borrows a lot from Rust! And it also has its own benefits, both ergonomic and also supporting eg generic in dynamic libraries
      • ecshafer8 hours ago
        Swift and Rust were developed at similar times. I think of them more as having similar influences than borrowing from each other.
        • pohl5 hours ago
          There’s no reason to invent your own head canon, the influence was openly acknowledged when Swift was new and it continues now that the language is developed out in the open (see Swift Ownership Manifesto)
        • est318 hours ago
          Similar times and the Rust originator went on to work on Swift after it.
          • DenisChetwynd8 hours ago
            Graydon Hoare's impact on the language is marginal than that of Chris Lattner, the originator (also, Hoare joined the team much later)
      • airstrike8 hours ago
        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

        • inkyoto16 minutes ago
          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.

        • MBCook6 hours ago
          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.

        • DenisChetwynd7 hours ago
          maybe so on the surface, but it remains quite massive underneath; these languages are fundamentally different and target entirely different use cases
          • airstrike5 hours ago
            I'm not sure Rust has one specific use case as its main goal, despite being immediately suitable for systems programming.

            I use it for making user-facing desktop applications, to name one example.

      • vardump8 hours ago
        Does it borrow borrow checker?
        • tialaramex6 hours ago
          I believe Swift tends to use reference counting and copy-on-write strategies. This, like GC, is less for the programmer to think about and doesn't require the semantic checks, but sometimes the performance cost is unacceptable compared to what you'd write in Rust.
          • airspeedswift6 hours ago
            You can choose to use either refcounting or unique ownership for your types. For most use cases, refcounted (+ copy-on-write) is the best choice and is the default, but the truetype interpreter made extensive use of non-refcounted types to achieve this performance.
          • MBCook6 hours ago
            They have either recently added or talked about a borrow style system in the language as a way to avoid more copies and speed things up/lower memory usage/help with asynchronous programming.
        • 8 hours ago
          undefined
        • anextio7 hours ago
          Yes, it has a borrow checker.
  • AndriyKunitsyn7 hours ago
    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.

    • jacquesgt4 hours ago
      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.
    • nomel7 hours ago
      My last 1080p monitor was around 20 years ago. I have trouble comprehending people still use them regularly.
      • afavour6 hours ago
        A very quick search yielded Dell selling 1080p laptops today:

        https://www.dell.com/en-us/shop/dell-laptops/dell-15-laptop/...

        It is very, very common. Just not in the Mac world.

        • kbolino6 hours ago
          It's also the corporate standard for generic cubicle workstation monitors, though it's unusual to find a Mac in such a place anyway.
      • AndriyKunitsyn7 hours ago
        People also use usable mice instead of touchpads, and they put the "ctrl" key where Apple thinks a useless "fn" should be. All kinds of things happen outside Apple world.

        To me, it's more about what I'm used to. I have a perfectly fine several years-old monitor, so why should I throw it away?

      • mschuster916 hours ago
        The problem is, as soon as you are not on a Mac but Linux or Windows, you are in for an awful, truly awful lot of pain. HiDPI support is a mess because even in the rare case applications are made with HiDPI in mind they are not tested on HiDPI machines.

        Other way around, most Mac software is not tested how it behaves on inferior external monitors.

        • AndriyKunitsyn4 hours ago
          What kind of windows programs are these? HiDPI is more than a decade old. A desktop application, no matter what OS it is, should always be tested with different scaling factors.
    • TazeTSchnitzel6 hours ago
      macOS has been drawing unhinted text for an eternity, and for those who can tolerate it on low-DPI screens, it's a great thing: the letter shapes look the same at all sizes, and the spacing between letters is consistent at all sizes.
      • bschwindHN5 hours ago
        I'm a high DPI snob so I haven't used a low res monitor for work in forever, but isn't the entire point of font hinting to make the text more legible at smaller pixel grid sizes? Yes, of course the shapes are more consistent since the hinter isn't touching them, but isn't the end result just less legible text?
        • kccqzy4 hours ago
          Hinting purposefully destroys letter shapes in exchange for crispness. People who like macOS style font rendering prioritize letter shapes faithful to the font designer more than crispness.

          Whether good letter shapes is more legible or crisper text is more legible is basically subjective. In the 2000s before HiDPI became popular different people really thought one was more legible than the other and vice versa. HiDPI made this basically moot.

    • kbolino6 hours ago
      I had this problem on the first Apple Silicon Mac Mini in 2020 so it's at least a little older than 2023.
  • raphlinus8 hours ago
    Welcome to the club of doing high performance text in a memory safe language!
  • LoganDark9 hours ago
    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).
    • airspeedswift8 hours ago
      I assure you, every inch of the interpreter code has been stared at by humans, a lot. TBH even the assembly generated by it has.
    • dgellow8 hours ago
      From what I got Apple is using claude code A LOT internally
      • Cassell8 hours ago
        It would be interesting to see their internal guidance on LLM use. It’s a massive amount of new power that has to be wielded carefully. That kind of guidance might mean the survival or downfall of some big corps in the next few years.
      • wahnfrieden8 hours ago
        Yes they are using Claude Code - not the Xcode agents.

        It worries me. I hope Codex adoption picks up there.

        • andrekandre5 hours ago
          thats a shame if true, they really should be dog-fooding that horrible agent ui in xcode to bring it up to a usable state
          • wahnfrieden4 hours ago
            A lot of devs are tricked into using it because it’s official
  • troupo9 hours ago
    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
    • saagarjha9 hours ago
      I mean they’re doing both
  • wg08 hours ago
    No mention of AI? Hand written code?
    • numist7 hours ago
      There's mention at the end. The models (and Swift itself!) have evolved a lot since this project started, so the early code is largely hand-rolled and the later changes were mostly authored by centaurs (to steal a term from chess).

      But I personally reviewed every line that shipped and was absolutely insufferable about testing.