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.
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.
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.
It does feel like a compiler/optimiser failure to have to rewrite those cases.
Though, it probably wouldn't work if user code modified the Array prototype.
That said, I’m looking forward to using Swift lifetimes once they actually work!
RIS is happening across all OS levels, if the keynote is to be believed.
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.
I'm not sure what became of it and if it ever shipped. If anyone knows I'd be curious.
Did they need a fuzzer for that? They could've render them all and see what's exercised?
It worries me. I hope Codex adoption picks up there.
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.
It looks like this hinter will be used only in rendering PDFs, because that's where they test the performance.
But I personally reviewed every line that shipped and was absolutely insufferable about testing.
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.
Edit: This is the guy: https://rustcurious.com/course/
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
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.
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://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
Rust is also just a more complex language. I’m not convinced the benefits would have been worth it.
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.
The gap between the two languages is quite small, it just makes me wish Apple was also all-in on Rust
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#.
https://www.dell.com/en-us/shop/dell-laptops/dell-15-laptop/...
It is very, very common. Just not in the Mac 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?
Other way around, most Mac software is not tested how it behaves on inferior external monitors.
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.
> 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.
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?
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/...
You missed Java as well.
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.
Many features that get discussed as being Swift/Rust, trace back to one of those languages.
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.
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.
I use it for making user-facing desktop applications, to name one example.
Being more ergonomic is relevant enough for increasing language adoption, that possible improvements are now on Rust roadmap.
1920 x 1080 51.89%
2560 x 1440 21.20%
3840 x 2160 5.00%
Edit: Guess it depends on the app
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.
Mac OS X 10.4 tried the same thing (Quartz2D scaling) and it was so damn difficult that they threw it out and went for simple 1x/2x/3x auto-scaling. Even 3x was a challenge because of pixel alignment.
>Have you ever tried to write HiDPI-aware Win32 code?
I haven't. I don't think there's any reason to, I'm more of a wxwidgets fan. I don't think even Microsoft makes applications in raw WinAPI.
>I suggest enabling HiDPI in Control Panel sometimes and marveling at how many Win32 apps just don’t notice and draw as postage stamps.
The default behaviour of a DPI-unaware app in Windows is to scale everything by the scale factor. Which - yes, looks completely awful and blurry, but that's not what you describe.