Hacker News

Also a liquid glass hater, but for what it's worth, 27 is supposed to make it a little bit better. I would prefer to go back to what I had before I had to upgrade into this horrible UI, but this is better than nothing.

https://www.cultofmac.com/news/liquid-glass-changes-ios-27-m...

I found if you turn off transparency effects and turn on high contrast in the accessibility settings, it's actually a pretty nice looking UI. Still has some dumb quirks like inconsistent corner radiuses and text appearing under UI elements (because they're assumed to be transparent, but aren't). But all software is trash in 2026 so be thankful it isn't even worse, I guess.

27 is a lot better. You can make the UI opaque again (they provide a transparency slider)

I bought a MBP mainly for the hardware, otherwise I'd have stuck with Linux. OS-wise, the jump from Monterey (which I'd last used) to Sequoia was smooth and still feels that way. I prefer not to notice the OS at all, something that I feel would be hard to do on Tahoe due to all that liquid glass and dumb transparency and animations.

Seriously, who the heck even asked for those?

macOS 27 does polish Liquid Glass and makes it look passable on macOS IMHO. It was very bad on 26. Comically bad.

I hate the round corners. It's already too much on 15, but way worse on 26. It looks like "Baby's first OS", designed by Fisher-Price.

Same. It's not the worst thing in the world, at least with Reduce Transparency enabled in the Accessibility settings, but I still don't feel any inclination to upgrade. My personal Mac Studio is macOS 15 and my work MacBook is on macOS 26, and I don't think there's a single thing that I find to be better on the work laptop than on my personal machine.

I might update to macOS 26 in September to be ready to update to macOS 27. Being two versions behind doesn't seem reasonable and I'd rather be on the "Tahoe but less shitty" version than Tahoe itself.

You can disable it in the accessibility preferences.

As we used to say in the Windows world, wait for service pack 3.

A better strategy would probably be to stick with the previous *major* release, but, do install its ("minor") security updates...

The bug that led to network connection issues after 49 days of uninterrupted uptime was a bit of a showstopper for me.

They changed the numbering scheme, so... no, there aren't. Version numbers are now year-based, but previously they were not.

Last year they unified all their OS version numbers to just match upcoming year.

macOS went from 15 to 26

iOS went from 18 to 26

watchOS went from 11 to 26

and so on

No, 26 is the successor of 15. They changed the numbering to year-based.

They reduced the radius back to older, smaller size and now all apps use a single radius, vs the weird 3 different radii in Tahoe. Looks better.

It was my vague understanding that by the time you implemented all the apis needed to run normal software on top of that, you either have enough apis that different tasks can still compromise each other, or you have shoved everything into a single task with very little isolation between normal user processes. In either case, it doesn't seem like you actually gained so much. What am I missing?

Indeed, however without some regulatory help it Will take its time for such kind of improvements across the industry.

> You need also factor development time and ease of finding developers willing to work in a specific language

This even more strongly favors Rust or Swift. Nobody is writing C or even Objective-C in 2026 as a growth language.

> very verbose languages are likely to be worse

Citation needed. I don't think there's a correlation there. Over-architected Java spaghetti is verbose and unmaintainable. Under-architected Perl code golf that metastisized is terse and unmaintainable.

> languages forcing a lot of abstractions are likely much worse

Citation needed. C++ has had some very high-level abstractions on top of a low-level runtime for awhile, and plenty of people have decided to use it and hire for it regardless. What counts as an "abstraction" or "forced abstraction" is a very very subjective topic.

What happened?

Considering that in Feb 2026 (https://support.apple.com/en-us/126348) Claude wasn't mentioned even once, 4 sure sounds like "lots" compared to nothing :) But you're right, it's subjective ultimately.

Do they? As in Claude but on premises? Wonder if this is gonna be the solution that e.g. banks will require, exactly like they do now for cloud services (e.g. Azure on premises).

source?

edit: it seems asking for a source it frowned uppon in this site. And it seems there's no source.

What I mean is that for “honest” software, built-in to the OS or otherwise, the programmer finds a situation where they take some user-supplied input and concatenate that into a path, and call something like OS.read(). If they want to prevent the user from causing havoc, they now find themselves dealing with path validation in their software instead of calling OS.safeOpen(), which would be a reduced subset of allowed chars?

So using newish phones that don't get updated anymore could be a lot more dangerous now than it was just a year ago.

The vagueness could be intentional. There’s been a big issue with linux where proof of concept exploit code gets posted before the bug is announced because people reverse engineer it from the fix commits.

Apple has the advantage that they can keep everything secret for long enough for the patches to roll out. And realistically there is no reason the user needs to know the details of an exploit that was patched before it was ever used.

I missed that, thanks for pointing out

Is this speculation? Where does it say Mythos was responsible for any of this?

> One CVE even lists the same person twice!

Not necessarily. Could be two persons sharing that name. See https://revstat.ine.pt/index.php/REVSTAT/article/view/382

One of them lists an anonymous person!

CVE-2026-43744: Mathis Mansière, an anonymous researcher