Live data from Hacker News

iOS 27, iPadOS 27, and macOS 27

apple.com

881–884 of 884 posts

Re: iOS 27, iPadOS 27, and macOS 27

#881

Earlier quoted context omitted.

From what I understand you're saying that Apple should provide 2 things: (1) Vulkan drivers and (2) backwards compatibility forever. I don't really know enough about graphics to discuss point (1). From what I understand, Apple GPUs don't really fit the Vulkan model too cleanly, and the Asahi Vulkan drivers are significantly less performant than Metal (how much of that is due to beta/community status vs. architectural…

I'm only asking for (1); Apple can keep breaking APIs forever as long as they support the libraries that enable Proton. (2) is precisely the reason why nobody can port games to macOS anymore, and largely why ARM is a second-class citizen in PC gaming too. You cannot depreciate things like AVX or 32-bit library execution modes, and then demand native builds get made to 20-year-old games. Apple Silicon's ISA extensions…

Everything you said about (2) is wrong imo.

Games should simply not be written for a particular architecture. The rendering part of the game engine should already be abstracted away from the particular rendering API (there are other significant platforms which do not support Vulkan: PS5 and Xbox, which your game should be capable of targeting). And the math library should have fallbacks to standard C (or standard C++ etc.) and then specialized implementations for AVX, NEON, SVE, etc.

Nothing else needs to be architecture specific.

Now, sure, NEON is slower than AVX-256/512. But backending to NEON or even standard C is certainly going to be faster than running stuff over an x86-to-ARM translation layer.

Sooner or later the Steam Deck 2 will release, probably on an ARM platform (if the Steam Frame compatibility layers go well), and millions upon millions upon millions of dollars of electricity will simply be wasted running x86-to-ARM, Win32-to-Linux and Direct3D-to-Vulkan dynamic compatibility layers when, if the games were well written in the first place, they could simply be trivially recompiled.

> 32-bit library execution modes

If your application assumes pointers are 32-bits, or any particular size, or even any set of particular sizes, it's completely broken.

As for (1), if Asahi Vulkan drivers are really good, that just goes to show why Apple isn't supporting Vulkan. Metal applications seem to be faster, and Apple wants to push devs to make their apps for the faster API.

Re: iOS 27, iPadOS 27, and macOS 27

#882

Earlier quoted context omitted.

Fair question. I expect the following from such a system : I set a time limit per app/set of apps,and the phone locks said apps once the limit is reached. In theory, this is what it does, in practice it almost never works : it doesn’t lock, gets broken whenever you upgrade the os, gets broken whenever your child upgrades the os, can be trivially bypassed by a kid, cannot be unlocked when you want it to unlock remotel…

So I don't have kids but in the keynote I remember them making a big deal about totally revamping it in 27. I know they definitely added a way to officially lock it (with a passcode) so your kids won't be able to theoretically just deactivate screen time. I think before you technically could do sorta the same thing (you can restrict almost any app to require FaceID or passcode to unlock). There's also the assistive a…

The main problem here is that even if they revamp it, it likely still won’t work since the most basic features don’t work as advertised . It’s like buying a car and it won’t start every other day and will only move backwards.

Re: iOS 27, iPadOS 27, and macOS 27

#883

Earlier quoted context omitted.

Yes, very fast for me now after library migration

That's good to hear. It'll be nice to have an update which isn't just random UI changes. What is "library migration"?

just the loading screen after updating

Re: iOS 27, iPadOS 27, and macOS 27

#884

Earlier quoted context omitted.

100% agree. We had to turn it off because it was too frustrating for everyone involve. Now we’re at “trust, but verify” where “verify” is looking at Screen Time stats at the end of each week. My only plausible explanation is that no one who works at Apple has kids.

That’s a good idea . So you’re telling me that I can trust the on device numbers enough?

> So you’re telling me that I can trust the on device numbers enough?

Not at all :-) But at least this process doesn’t lead to pain and suffering because either the ScreenTime notification doesn’t arrive on a parent device, or the “Allow” action isn’t picked up by the child’s device. The whole messaging part to get permission to do something is really unreliable, at least in our household.

Post reply on HN