_______ __ _______
| | |.---.-..----.| |--..-----..----. | | |.-----..--.--.--..-----.
| || _ || __|| < | -__|| _| | || -__|| | | ||__ --|
|___|___||___._||____||__|__||_____||__| |__|____||_____||________||_____|
on Gopher (inofficial)
HTML Visit Hacker News on the Web
COMMENT PAGE FOR:
HTML Swift at Apple: Migrating the TrueType hinting interpreter
dpark wrote 6 hours 44 min 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.
yyyk wrote 11 hours 56 min 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?
thechao wrote 10 hours 35 min 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.
KolmogorovComp wrote 13 hours 46 min 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.
Altern4tiveAcc wrote 11 hours 36 min ago:
I've always wondered if JS engines could rewrite those array
functions at compile time, like this: [1] Though, it probably
wouldn't work if user code modified the Array prototype.
HTML [1]: https://github.com/SomeRanDev/Haxe-MagicArrayTools
ks2048 wrote 19 hours 53 min ago:
So, hinting only takes place at low resolutions, I believe. How often
is it used, eg viewing âtypicalâ PDFs on âtypicalâ screens?
dcrazy wrote 6 hours 4 min ago:
There are fonts that rely on hinting for correct shaping at all
sizes:
HTML [1]: https://xoxo.zone/@numist/116716601962175503
comex wrote 19 hours 56 min 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!
monster_truck wrote 11 hours 49 min ago:
Average swift experience
stephencanon wrote 19 hours 54 min ago:
The work discussed in this post shipped in the OS last year (fall
2025), so nothing here is dependent on very recent changes.
jacquesgt wrote 20 hours 14 min 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:
[1] 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. [2] 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.
HTML [1]: https://jobs.apple.com/en-us/search?search=Spear&sort=relevanc...
HTML [2]: https://www.youtube.com/live/yl2jsIoMfDU
musicale wrote 2 hours 5 min 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.
ComputerGuru wrote 5 hours 17 min ago:
On-site only?
rfc3092 wrote 7 hours 57 min ago:
How do I apply? Historically jobs.apple.com is a black hole unless
you know people.
musicale wrote 1 hour 56 min 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.
rfc3092 wrote 19 min 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.
byproxy wrote 16 hours 11 min ago:
Any resources you'd recommend for learning about reasoning about the
security of code?
rinon wrote 15 hours 9 min ago:
For low-level system security, I'm a fan of [1] 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.
HTML [1]: https://llsoftsec.github.io/llsoftsecbook/LLSoftSecBook.pd...
AndriyKunitsyn wrote 23 hours 8 min 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.
carlosjobim wrote 9 hours 35 min 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.
jacquesgt wrote 19 hours 38 min 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.
kbolino wrote 22 hours 27 min ago:
I had this problem on the first Apple Silicon Mac Mini in 2020 so
it's at least a little older than 2023.
TazeTSchnitzel wrote 22 hours 28 min 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.
bschwindHN wrote 20 hours 40 min 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?
kccqzy wrote 20 hours 17 min 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.
nomel wrote 22 hours 58 min ago:
My last 1080p monitor was around 20 years ago. I have trouble
comprehending people still use them regularly.
yjftsjthsd-h wrote 15 hours 48 min 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.
incanus77 wrote 14 hours 54 min 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.
mschuster91 wrote 22 hours 8 min 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.
wmedrano wrote 6 hours 36 min ago:
I've been fine with Linux/KDE. Even the fractional scaling
support is decent.
Edit: Guess it depends on the app
AndriyKunitsyn wrote 19 hours 38 min 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.
dcrazy wrote 5 hours 54 min ago:
Oh my sweet summer child. Even software being written TODAY
isnât being tested in HiDPI. Win32 still makes it difficult.
AndriyKunitsyn wrote 4 hours 52 min 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â.
mschuster91 wrote 14 hours 34 min ago:
Ham radio software, both open-source and commercial, is a big
thing, and so is many an in-house development in many
businesses.
afavour wrote 22 hours 34 min ago:
A very quick search yielded Dell selling 1080p laptops today: [1]
It is very, very common. Just not in the Mac world.
HTML [1]: https://www.dell.com/en-us/shop/dell-laptops/dell-15-lapto...
import wrote 15 hours 54 min ago:
Itâs very common for the people who got their last monitor 8
years ago.
bigyabai wrote 14 hours 52 min ago:
It's still the most common resolution for people using desktop
monitors today, according to:
HTML [1]: https://gs.statcounter.com/screen-resolution-stats/des...
SSLy wrote 10 hours 29 min ago:
Also for gaming too: [1] 1920 x 1080 51.89%
2560 x 1440 21.20%
3840 x 2160 5.00%
HTML [1]: https://store.steampowered.com/hwsurvey/
carlosjobim wrote 9 hours 33 min ago:
OS font rendering doesn't matter for gaming.
kbolino wrote 22 hours 31 min 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.
AndriyKunitsyn wrote 22 hours 46 min 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?
wg0 wrote 23 hours 45 min ago:
No mention of AI? Hand written code?
numist wrote 23 hours 10 min 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.
raphlinus wrote 23 hours 47 min ago:
Welcome to the club of doing high performance text in a memory safe
language!
WalterGR wrote 15 hours 29 min ago:
> high performance text
Just strings or rendering strings?
If the latter, who are the other members of the club?
masiulis wrote 15 hours 30 min 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!
airstrike wrote 1 day 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.
jounker wrote 11 hours 53 min 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.
pjmlp wrote 14 hours 15 min 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#.
afavour wrote 22 hours 45 min 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.
inkyoto wrote 16 hours 31 min 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]
HTML [1]: https://faultlore.com/blah/swift-abi/
pjmlp wrote 14 hours 12 min 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.
AceJohnny2 wrote 23 hours 10 min ago:
Rust doesn't have an ABI [1]. Swift needed one to be a useable
application language: [1] (written by a core Rust developer) [1]
apart from the basic/universal C one, which prevents exposing any
useful Rust semantics over the interface
HTML [1]: https://faultlore.com/blah/swift-abi/
jadengeller wrote 1 day 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
ecshafer wrote 23 hours 57 min ago:
Swift and Rust were developed at similar times. I think of them
more as having similar influences than borrowing from each other.
pjmlp wrote 14 hours 28 min 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.
pohl wrote 20 hours 58 min 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)
zarzavat wrote 18 hours 39 min 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:
HTML [1]: https://rust-lang.github.io/rfcs/3137-let-else.html#pr...
est31 wrote 23 hours 51 min ago:
Similar times and the Rust originator went on to work on Swift
after it.
DenisChetwynd wrote 23 hours 44 min ago:
Graydon Hoare's impact on the language is marginal than that of
Chris Lattner, the originator (also, Hoare joined the team much
later)
vardump wrote 1 day ago:
Does it borrow borrow checker?
tialaramex wrote 22 hours 33 min 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.
pjmlp wrote 14 hours 9 min 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.
airspeedswift wrote 22 hours 15 min 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.
MBCook wrote 22 hours 15 min 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.
anextio wrote 22 hours 47 min ago:
Yes, it has a borrow checker.
airstrike wrote 1 day 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
geodel wrote 6 hours 37 min ago:
Apple is not going bet all on language whose roadmap they do not
control 100%.
inkyoto wrote 16 hours 24 min 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.
stasomatic wrote 2 hours 27 min ago:
It has an unfortunate name though, maybe a short shelf life.
Rust++ doesnât seem inviting either.
steveklabnik wrote 2 hours 15 min ago:
Rust does not have a ++ operator, so that name would make no
sense.
stasomatic wrote 1 hour 56 min ago:
Not yet.
MBCook wrote 22 hours 16 min 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.
DenisChetwynd wrote 23 hours 33 min ago:
maybe so on the surface, but it remains quite massive underneath;
these languages are fundamentally different and target entirely
different use cases
airstrike wrote 21 hours 20 min 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.
LoganDark wrote 1 day 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).
airspeedswift wrote 1 day 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.
ahartmetz wrote 9 hours 59 min 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.
dcrazy wrote 5 hours 55 min 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.
dgellow wrote 1 day ago:
From what I got Apple is using claude code A LOT internally
Cassell wrote 23 hours 59 min 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.
wahnfrieden wrote 1 day ago:
Yes they are using Claude Code - not the Xcode agents.
It worries me. I hope Codex adoption picks up there.
andrekandre wrote 20 hours 43 min 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
dcrazy wrote 5 hours 59 min ago:
The UI got a massive overhaul in the new Xcode beta. Itâs no
longer confined to the sidebar.
wahnfrieden wrote 5 hours 49 min ago:
Devs continue to be tricked by incremental updates to it.
It's still deficient
wahnfrieden wrote 20 hours 26 min ago:
A lot of devs are tricked into using it because itâs official
LoganDark wrote 12 hours 15 min 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)
wahnfrieden wrote 5 hours 48 min ago:
It also doesn't support Computer Use or Browser Use among
other deficiencies
LoganDark wrote 5 hours 26 min ago:
Sure but the basics should be down before tackling those,
and they're not.
wahnfrieden wrote 2 hours 16 min 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)
weinzierl wrote 1 day 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.
DASD wrote 1 day 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.
HTML [1]: https://www.youtube.com/watch?v=uDtMuS7BExE&list=PL2b0df3jKK...
mrpippy wrote 1 day ago:
The author discussed this a bit on Mastodon as well:
HTML [1]: https://xoxo.zone/@numist/116716469017975106
numist wrote 1 day ago:
I'm also here :)
atdt wrote 21 hours 24 min ago:
Excellent write-up!
numist wrote 20 hours 1 min ago:
Thanks!
saagarjha wrote 1 day ago:
Interesting that this is published under the MIT, rather than Appleâs
more favorite Apache 2, license
JumpCrisscross wrote 1 day ago:
Why is it interesting?
drob518 wrote 1 day ago:
Presumably because MIT is even more permissive and itâs a change
in Appleâs behavior.
favorited wrote 23 hours 18 min 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.
zdw wrote 23 hours 35 min 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?
troupo wrote 1 day 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
saagarjha wrote 1 day ago:
I mean theyâre doing both
pjmlp wrote 1 day 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.
JimDabell wrote 10 hours 21 min ago:
Alexandre Colucci has published a series of articles analysing the
use of Swift in iOS and macOS by Apple here: [1] And frequently
discussed on Hacker News:
HTML [1]: https://blog.timac.org/categories/reverse-engineering/
HTML [2]: https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...
pjmlp wrote 8 hours 25 min ago:
Thanks!
MBCook wrote 22 hours 19 min 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.
pjmlp wrote 14 hours 24 min 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
commandersaki wrote 21 hours 3 min 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:
HTML [1]: https://rustcurious.com/course/
hirvi74 wrote 23 hours 37 min ago:
What does RIS stand for?
gyomu wrote 23 hours 36 min ago:
Rewrite in Swift
willXare wrote 23 hours 15 min ago:
So RIS is Appleâs version of RiiR, but with better fonts.
cwillu wrote 20 hours 44 min ago:
s/better/blurrier/
steve1977 wrote 17 hours 26 min ago:
Life without retina displays is possible, but pointless.
tonyedgecombe wrote 9 hours 10 min ago:
I sometimes wish Iâd never seen a Retina display.
Thereâs no going back for me now.
ahartmetz wrote 10 hours 13 min ago:
Lower DPI is quite okay with good font rendering (FreeType,
slight hinting, subpixel rendering). I have both kinds of
devices.
geon wrote 4 hours 25 min ago:
I get kind of nostalgic when I see Verdana on 1024x768 in
winxp/2k.
thewebguyd wrote 20 hours 39 min ago:
Careful, youâll bring out all the âbut itâs true to
print mediaâ people.
DASD wrote 1 day 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++ (
[1] ).
HTML [1]: https://webkit.org/blog/17967/news-from-wwdc26-webkit-in-saf...
pjmlp wrote 1 day 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.
DIR <- back to front page