Swift at Apple: Migrating the TrueType hinting interpreter

Posted by DASD 4 days ago

Counter240Comment134OpenOriginal

Comments

Comment by jacquesgt 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.

Comment by rfc3092 3 days ago

How do I apply? Historically jobs.apple.com is a black hole unless you know people.

Comment by musicale 3 days ago

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.

Comment by rfc3092 3 days ago

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.

Comment by musicale 3 days ago

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.

Comment by byproxy 4 days ago

Any resources you'd recommend for learning about reasoning about the security of code?

Comment by rinon 4 days ago

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.

Comment by Degorath 3 days ago

Do you folks also hire outside the US?

Comment by ComputerGuru 3 days ago

On-site only?

Comment by KolmogorovComp 4 days ago

> 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.

Comment by leecommamichael 1 day ago

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.

Comment by Altern4tiveAcc 4 days ago

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.

Comment by comex 4 days 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!

Comment by stephencanon 4 days ago

The work discussed in this post shipped in the OS last year (fall 2025), so nothing here is dependent on very recent changes.

Comment by monster_truck 4 days ago

Average swift experience

Comment by pjmlp 4 days 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.

Comment by MBCook 4 days 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.

Comment by commandersaki 4 days 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/

Comment by pjmlp 4 days ago

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

Comment by DASD 4 days 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...).

Comment by pjmlp 4 days 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.

Comment by JimDabell 4 days ago

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...

Comment by pjmlp 3 days ago

Thanks!

Comment by hirvi74 4 days ago

What does RIS stand for?

Comment by gyomu 4 days ago

Rewrite in Swift

Comment by willXare 4 days ago

[flagged]

Comment by cwillu 4 days ago

s/better/blurrier/

Comment by steve1977 4 days ago

Life without retina displays is possible, but pointless.

Comment by ahartmetz 4 days ago

Lower DPI is quite okay with good font rendering (FreeType, slight hinting, subpixel rendering). I have both kinds of devices.

Comment by geon 3 days ago

I get kind of nostalgic when I see Verdana on 1024x768 in winxp/2k.

Comment by steve1977 2 days ago

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.

Comment by tonyedgecombe 4 days ago

I sometimes wish I’d never seen a Retina display. There’s no going back for me now.

Comment by thewebguyd 4 days ago

Careful, you’ll bring out all the “but it’s true to print media” people.

Comment by saagarjha 4 days ago

Interesting that this is published under the MIT, rather than Apple’s more favorite Apache 2, license

Comment by JumpCrisscross 4 days ago

Why is it interesting?

Comment by drob518 4 days ago

Presumably because MIT is even more permissive and it’s a change in Apple’s behavior.

Comment by favorited 4 days 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.

Comment by zdw 4 days 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?

Comment by mrpippy 4 days ago

The author discussed this a bit on Mastodon as well:

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

Comment by numist 4 days ago

I'm also here :)

Comment by atdt 4 days ago

Excellent write-up!

Comment by numist 4 days ago

Thanks!

Comment by dpark 3 days ago

> 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.

Comment by weinzierl 4 days 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.

Comment by DASD 4 days ago

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...

Comment by ks2048 4 days ago

So, hinting only takes place at low resolutions, I believe. How often is it used, eg viewing “typical” PDFs on “typical” screens?

Comment by dcrazy 3 days ago

There are fonts that rely on hinting for correct shaping at all sizes: https://xoxo.zone/@numist/116716601962175503

Comment by yyyk 4 days ago

"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?

Comment by thechao 4 days ago

Its a set cover problem, and is NP-hard. 4100 of something probably runs nicely in your laptop in a reasonable amount of time.

Comment by troupo 4 days 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

Comment by saagarjha 4 days ago

I mean they’re doing both

Comment by airstrike 4 days 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.

Comment by AceJohnny2 4 days 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

Comment by afavour 4 days 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.

Comment by inkyoto 4 days 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/

Comment by pjmlp 4 days ago

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.

Comment by jadengeller 4 days 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

Comment by airstrike 4 days 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

Comment by MBCook 4 days 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.

Comment by geodel 3 days ago

Apple is not going bet all on language whose roadmap they do not control 100%.

Comment by inkyoto 4 days 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.

Comment by stasomatic 3 days ago

It has an unfortunate name though, maybe a short shelf life. Rust++ doesn’t seem inviting either.

Comment by steveklabnik 3 days ago

Rust does not have a ++ operator, so that name would make no sense.

Comment by stasomatic 3 days ago

Not yet.

Comment by kibwen 3 days ago

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.

Comment by stasomatic 2 days ago

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.

Comment by steveklabnik 2 days ago

Yes, it is pretty universally agreed upon that a ++ operator in Rust doesn’t make any sense. += 1 is barely longer, not special cased, and does not make users memorize odd precedence rules.

Comment by stasomatic 20 hours ago

It doesn’t matter, I was speaking in terms of branding. There is ++ in C, but C is not C++.

Comment by steveklabnik 19 hours ago

Right, but the whole reason C++ is named C++ is because ++ is a valid operator in C. Without the operator in Rust, making the brand of a successor based on a feature from an entirely different language doesn't make any sense.

Comment by airstrike 2 days ago

Rust isn't named after what you think it is, but after fungi.

Comment by DenisChetwynd 4 days ago

maybe so on the surface, but it remains quite massive underneath; these languages are fundamentally different and target entirely different use cases

Comment by airstrike 4 days 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.

Comment by ecshafer 4 days ago

Swift and Rust were developed at similar times. I think of them more as having similar influences than borrowing from each other.

Comment by pohl 4 days 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)

Comment by zarzavat 4 days ago

Obviously Rust was first but over time both languages have been taking inspiration from each other. For example let-else was motivated directly because of its success in Swift: https://rust-lang.github.io/rfcs/3137-let-else.html#prior-ar...

Comment by pjmlp 4 days ago

Additionally both have influences from CLU, C++, Object Pascal, Modula-2, Mesa/Cedar, Standard ML, Cyclone.

Many features that get discussed as being Swift/Rust, trace back to one of those languages.

Comment by est31 4 days ago

Similar times and the Rust originator went on to work on Swift after it.

Comment by DenisChetwynd 4 days ago

Graydon Hoare's impact on the language is marginal than that of Chris Lattner, the originator (also, Hoare joined the team much later)

Comment by vardump 4 days ago

Does it borrow borrow checker?

Comment by tialaramex 4 days 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.

Comment by airspeedswift 4 days 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.

Comment by pjmlp 4 days ago

You can pick and chose, and memory ownership is getting better in latest versions.

Being more ergonomic is relevant enough for increasing language adoption, that possible improvements are now on Rust roadmap.

Comment by MBCook 4 days 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.

Comment by 4 days ago

Comment by anextio 4 days ago

Yes, it has a borrow checker.

Comment by pjmlp 4 days ago

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#.

Comment by jounker 4 days ago

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.

Comment by LoganDark 4 days 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).

Comment by airspeedswift 4 days 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.

Comment by ahartmetz 4 days ago

All 150 kloc in six months by two people? Actually, it sounds like way too much code for the task unless 70+% of it is tests.

Comment by dcrazy 3 days ago

> 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.

Comment by dgellow 4 days ago

From what I got Apple is using claude code A LOT internally

Comment by wahnfrieden 4 days ago

Yes they are using Claude Code - not the Xcode agents.

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

Comment by andrekandre 4 days 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

Comment by dcrazy 3 days ago

The UI got a massive overhaul in the new Xcode beta. It’s no longer confined to the sidebar.

Comment by wahnfrieden 3 days ago

Devs continue to be tricked by incremental updates to it. It's still deficient

Comment by wahnfrieden 4 days ago

A lot of devs are tricked into using it because it’s official

Comment by LoganDark 4 days ago

I love how it doesn't even support reasoning output or edit tool diffs. (Yes it can show diffs sometimes when using the 100% official flow but not when using ACP)

Comment by wahnfrieden 3 days ago

It also doesn't support Computer Use or Browser Use among other deficiencies

Comment by LoganDark 3 days ago

Sure but the basics should be down before tackling those, and they're not.

Comment by wahnfrieden 3 days ago

You call it solid foundations, I call it deficiency and being over a year behind state of art available elsewhere (from the same service you're already paying for)

Comment by Caracas288 4 days 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.

Comment by raphlinus 4 days ago

Welcome to the club of doing high performance text in a memory safe language!

Comment by masiulis 4 days ago

There are dozens of us! Dozens!

Vello has been a big inspiration and source of knowledge for my own webgpu text renderer, thank you for that!

Comment by WalterGR 4 days ago

> high performance text

Just strings or rendering strings?

If the latter, who are the other members of the club?

Comment by raphlinus 3 days ago

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.

Comment by AndriyKunitsyn 4 days 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.

Comment by jacquesgt 4 days 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.

Comment by nomel 4 days ago

My last 1080p monitor was around 20 years ago. I have trouble comprehending people still use them regularly.

Comment by afavour 4 days 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.

Comment by kbolino 4 days 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.

Comment by import 4 days ago

It’s very common for the people who got their last monitor 8 years ago.

Comment by bigyabai 4 days ago

It's still the most common resolution for people using desktop monitors today, according to: https://gs.statcounter.com/screen-resolution-stats/desktop/w...

Comment by SSLy 4 days ago

Also for gaming too: https://store.steampowered.com/hwsurvey/

1920 x 1080 51.89%

2560 x 1440 21.20%

3840 x 2160 5.00%

Comment by carlosjobim 4 days ago

OS font rendering doesn't matter for gaming.

Comment by AndriyKunitsyn 4 days 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?

Comment by nomel 3 days ago

I'm a PC user with a work MacBook. I was talking about my PC.

Comment by yjftsjthsd-h 4 days ago

Then let me blow your mind:) One of my daily drivers is an ex-Chromebook at 1366x768. Granted, it's also physically smallish so the DPI isn't quite as low as a macbook would be with those pixels, but still. And that's a touch cramped but it's fine.

Comment by incanus77 4 days ago

I'm reading on that resolution right now! MacBook Air 11" running Linux that I use as a quick hacking/reading machine in bed.

Comment by 4 days ago

Comment by mschuster91 4 days 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.

Comment by AndriyKunitsyn 4 days 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.

Comment by mschuster91 4 days ago

Ham radio software, both open-source and commercial, is a big thing, and so is many an in-house development in many businesses.

Comment by AndriyKunitsyn 2 days ago

Any particular program? GNU Radio seems perfectly fine.

Comment by dcrazy 3 days ago

Oh my sweet summer child. Even software being written TODAY isn’t being tested in HiDPI. Win32 still makes it difficult.

Comment by AndriyKunitsyn 3 days ago

I’m not your child, and that’s false, it’s literally one key to change in the settings. That allows you to select the exact scaling factor, not macos’s “more text”/“less text”.

Comment by dcrazy 3 days ago

Have you ever tried to write HiDPI-aware Win32 code? I suggest enabling HiDPI in Control Panel sometimes and marveling at how many Win32 apps just don’t notice and draw as postage stamps.

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.

Comment by AndriyKunitsyn 2 days ago

Well, you were talking about testing, development of DPI-aware apps is another thing. It requires the developers to be, well, DPI-aware, but I don't think there are particular obstacles to that in winapi itself.

>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.

Comment by wmedrano 3 days ago

I've been fine with Linux/KDE. Even the fractional scaling support is decent.

Edit: Guess it depends on the app

Comment by TazeTSchnitzel 4 days 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.

Comment by bschwindHN 4 days 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?

Comment by kccqzy 4 days 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.

Comment by carlosjobim 4 days ago

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.

Comment by kbolino 4 days ago

I had this problem on the first Apple Silicon Mac Mini in 2020 so it's at least a little older than 2023.

Comment by wg0 4 days ago

No mention of AI? Hand written code?

Comment by numist 4 days 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.