The M5 MacBook Pro still gets the Broadcom WiFi chip but the M5 iPad Pros get the N1 and C1X (Sweet).
All in all, apple is doing some incredible things with hardware.
Software teams at apple really need to get their act together. The M1 itself is so powerful that nobody really needs to upgrade that for most things most people do on their computers. Tahoe however makes my M1 Air feel sluggish doing the exact same tasks ive been last couple of years. I really hope this is not intentional from Apple to make me upgrade. That would be a big let down.
The fix is to disable Glass. In a terminal: defaults write -g com.apple.SwiftUI.DisableSolarium -bool YES
This gets rid of the slow animations, inconsistent window cornering, and other annoyances.
Then (so menus aren't transparent and unreadable): System Settings > Accessibility > Display > Reduce Transparency
If you do those two things your machine should look and feel normal again. I've been running an M1 Max since 2021 and Tahoe was simply a disaster. Removing the glass layer made everything feel good again.
If for some reason you ever want the bad performance and glass back, you change the YES to NO in the Terminal command. Maybe someday it won't suck.
I think DisableSolarium has no effect anymore. At least I can't see any. I'm in macOS 26.0 (25A354)
Works for me. 26.0.1 (25A362)
> Tahoe however makes my M1 Air feel sluggish doing the exact same tasks ive been last couple of years.
I have a work provided M2 Pro with 32GB of RAM. After the Tahoe upgrade it feels like one of the sluggish PCs at the house. It is the only one that I can see the mouse teleporting sometimes when I move it fast. This is after disabling transparency in Accessibility settings mind you, it was even worse before.
It's probably due to the Electron bug[1]. A lot of common apps haven't patched up yet.
I also have an M2 Pro with 32GB of memory. When I A/B test with Electron apps running vs without, the lag disappears when all the unpatched Electron apps are closed out.
1. https://avarayr.github.io/shamelectron/
Here's a script I got from somewhere that shows unpatched Electron apps on your system:
Edit: HN nerfed the script. Found a direct link: https://gist.github.com/tkafka/e3eb63a5ec448e9be6701bfd1f1b1...
> It's probably due to the Electron bug[1]. > When I A/B test with Electron apps running vs without, the lag disappears when all the unpatched Electron apps are closed out.
Look, if userspace apps can break system functionality, to the level that simple mouse cursor is not responsive, it suggests that there is something fundamental broken in the OS.
Yes, everyone should blame and shame Electron, but here the bug is firmly in the OS.
Apparently Electron was using a private API to tweak how window border shadows were rendered.[0] I leave it to you to decide how to assign blame.
What's private API?
If it is accessible from userspace it is by no means private.
Does it mean the API is private in the sense of "unstable" interface? It could very well break the userspace app relying on undocumented behavior, however, crucially here, anything that is exposed to userland WILL at some point be used by some application, be it legitimate or malicious, and it should not break the OS in any way. That's basic hygiene, not even security.
inb4: yes, userspace app could trigger e.g. millions of io operations and millions of number crunching threads and thus cripple the rest of userspace (or at least the rest of userspace at given priority level), yet the system part should still run within performance envelope. Insert "Task Manager (Not Responding)" meme.
It’s not in a public header. You can easily snoop “private” properties and methods quite easily in Objective-C, because the concept doesn’t exist. It doesn’t exist in C either, but if you roll up your sleeves and figure out the memory layout and offsets, you can do whatever.
> if you roll up your sleeves and figure out the memory layout and offsets, you can do whatever.
So we are talking about public/private access specifiers in source code, which only matter in cooperative setting. But that's IMO highly naive view as compute, especially OS, is objectively an adversarial environment. Some actors, at some point WILL figure out the memory layout and use that in an attack. There have been literally decades of whack-a-mole against bad actors.
I maintain my stance that any fields/members/methods loaded into a userspace program should not be capable of breaking the system.
Yeah, of course they shouldn’t, but they do. Kick off a bunch of processes doing too much of the wrong thing on any platform and it will bring the whole system down. DDoS for example. It’s not a solved problem.
Wax idealistic all you want, but just imagine the discussion we’d be having if Apple had sigabort-ed all these misbehaving electron apps on day one. “No userland APIs, private or otherwise, should be able to crash your app!!!” Is the argument I would be responding to right now.
People using private APIs know that they might cause instability (in their apps usually). That's why those APIs are private, they can change since there are no guarantees.
I'd point fingers towards the electron core devs for this one, and not devs building apps on top of electron (since they likely didn't know that's how electron was doing it).
There are cases where OS companies noticed the use of private APIs and made cleaner public ones (the most obvious was the file system syncing stuff used by Dropbox and others, which used to use private APIs until Apple provided a public one).
Can we blame the Apple employees who apparently never tested their new OS release with any Electron-based application?
How else do you get the message across? Do not use the private APIs.
Electron is most likely using a whole ton more. Apple is sending a message. "Fix your crap or expect more."
I can think of multiple ways to pass the message to Electron developers:
- Open a GitHub issue explaining those private APIs shouldn't be used.
- Even better, open a PR fixing their use.
- Make those API calls a no-op if they come from an Electron app.
- Fix those API calls not to grind the OS to a halt for a seemingly simple visual effect.
- Create a public API allowing the same visual effect on a tested and documented API.
Choosing to (apparently violently) downgrade the user experience of all Electron app users, without a possibility to update at the launch day, if a deliberate decision and not an overlooked bug, is a rather shitty and user-hostile move, don't you think?
The beta has been accessible to the public including the electron devs for 2+ months.
To be clear, Electron themselves fixed the bug quite quickly; but many Electron apps haven't pushed a version that vendors in the fixed version of the Electron runtime.
(And shit like this is exactly why runtimes like the JVM or the .NET CLR are designed to install separately from any particular software that uses them. Each of their minor [client-facing-ABI compatible] versions can then be independently updated to their latest OS-facing-bugfix version without waiting for the software itself to ship that update.)
How nice of Apple to take a huge UX/PR/User Satisfaction hit just to send a message.
Apple is consistent in their warnings to not use private APIs, and especially don't override them for custom implementations which is what Electron does here.
The _cornerMask override was a hack that shouldn't ever have existed in the first place, and it's not the only use of private APIs in the electron code base.
Apple is very clear about how they want you to make software for their OSes. It's 100% on electron that they choose to do it this way regardless.
I'd go as far as to say Electron itself is a hack that shouldn't exist, but sadly everyone has decided it's the only way they are going to make desktop software now.
This mindset is not conducive to loving your customers.
But I also blame users for using crappy electron apps ;-)
> How else do you get the message across? Do not use the private APIs.
The most effective way would be for Apple to actually seek feedback on requirements and then actually implement public APIs for functionality that people need.
That's confusing "consensus building" with "effective". Killing a private api is pretty effective. And consensus building doesn't always build the best software.
... and in the process we will deteriorate the performance of millions of users and hurt our brand as a top class experience company?
Don't really care who is to blame, but they should have identified this, and either warn developers, or warn users. Or provide a tool for identifying guilty apps in your machine, and let users decide how to proceed.
And they did both, so…?
the reason for having a large public beta process would be to get broader testing that definitely should have found this
I’m glad they broke it. People that use private APIs in their apps must suffer.
If any apple app uses a private api then that api should be made public and documented. Having private apis is unfair competition and bad practice
There's no meaningful difference between "private" and "documented, but changing every patch release" from userspace POV, yet not committing to documentation saves development effort for the same result, hence "private" APIs. If anything, private apis let "system" apps run at userspace, reducing attack surface dramatically.
Helpful script, except it prints the same line regardless of the version found.
If I’m remembering correctly, the original script he found had different emoji in the two lines (red X vs. green checkmark), but since HN comments strip emoji, pasting it here made them equivalent.
HN nerfed the script. Here you go: https://gist.github.com/tkafka/e3eb63a5ec448e9be6701bfd1f1b1...
Should we not be shaming apple for their recent software releases? Every bit of the os is N times slower than on the previous macOS version. Safari has been unusable. Constant lags and crashes in the shipped browser alone. We are back in Windows Vista times
Windows Vista broke UX for apps that tried to request admin permissions too often but didn't break the applications thenselves, and for video drivers wasn't that largely due to Intel shipping crap?
My MacOS experience has been first party software is getting worse.
This is weird. I have an M3 MBAir and it does not feel slower than under Sequoia at all.
hmm there are apps produced by your script that claim to be fixed according to https://avarayr.github.io/shamelectron/ (Signal, Discord, Notion, etc). And I checked that those apps are updated. Which one’s correct?
the website is correct, you need to update the apps on your mac
HN broke the script. Here's a link: https://gist.github.com/tkafka/e3eb63a5ec448e9be6701bfd1f1b1...
unpatched include Asana, Bitwarden, Dropbox… some pretty high-profile apps
Yes, and 1Password up until today!
Do you have a few electron powered apps that didn’t get updated yet?
Electron used to override a private function that makes the Mac OS sluggish on Tahoe, and apparently no one uses Electron apps while doing testing at Apple.
I keep my applications pretty much up-to-date but I didn't check the release notes for each Electron application that I have to make sure they're updated. I still think this is a failure of macOS, since one misbehaving application shouldn't bring the whole environment to slow to a crawl.
What I can say is that while the situation is much better than at Day 1, the whole Tahoe experience is not as fluid as Sequoia.
Also, it doesn't really matter to me if this was a private function or not, if this was Windows or Gnome/KDE people would blame the developers of the desktop instead.
It shouldn't be the user's responsibility to know what architecture the software uses to then need to go look at upgrading them. Upstream comments blaming Apple for this for "not testing Electron apps internally", but I don't expect Apple to test every single app ever released for regression testing. Apple releases betas, and the software devs are expected to test their app against it. The problem comes from the app devs using a bit of private code where it is suggested to not do that for this very reason. Even if Apple did test and find the result, it would still be the app dev that would need to fix it. Maybe the thought is that an email from Apple to the dev saying fix your code would more compelling???
> Upstream comments blaming Apple for this for "not testing Electron apps internally", but I don't expect Apple to test every single app ever released for regression testing.
This happens in pretty much every Electron app as far I know, and lots of Electron apps are like Spotify, VSCode or Slack are very likely to be in the Top 10 or at least Top 100 most used apps. And yes, I would expect Apple to test at least the most popular apps before releasing a new version of their OS.
> Maybe the thought is that an email from Apple to the dev saying fix your code would more compelling???
Of course not. Apple controls the SDK, they could workaround this in many different ways, for example instead of changing how this function was implemented they could introduce a new method (they're both private so it doesn't matter) and effectively ignore the old method (maybe also they could add a message for developers building their application that this method was removed). It would draw ugly borders in the affected apps but it wouldn't cause this issue at least.
"When developing Windows 95, one manager bought every program available at a local software store..."
https://www.pcworld.com/article/2816273/how-microsofts-windo...
That was the 90’s, the QA was harder to do but actually done sometimes.
QA then was taken pretty seriously because, unlike today, they could not just issue a patch over the internet and expect their users to find, download, and install it. Much of the '90s was pre-internet era for many people, and it was certainly before today's world of having auto-updating apps, good search engines, etc.
In the 90's we also got to enjoy native apps.
> (maybe also they could add a message for developers building their application that this method was removed)
why do we think this would be a solve as the devs clearly ignored the previous message about not using a private method?
> why do we think this would be a solve as the devs clearly ignored the previous message about not using a private method?
If anything the fact that devs can actually access private symbols is an issue with how Apple designed their APIs, because they could make this so annoying to do that nobody would try (for example, stripping symbols).
Also, the fact that devs need to access private symbols to do what they need to do also shows that the public API is lacking at least some features.
Another thing, if this only affected the app itself that would be fine, but this makes the whole system slow to a crawl.
So while devs share some of the blame here (and I am not saying they don't), I still think this whole situation is mostly Apple's fault.
If you actually read the specific bug and use of a private method it really was a stupid decision by one developer awhile ago that just fell through the cracks. There really wasn't a benefit to doing what they did, which is why their fix was to just go back to using public APIs.
I think the failures here are that Apple should have tested this themselves and the Electron devs should have tested and resolved this during the beta period.
> If you actually read the specific bug and use of a private method it really was a stupid decision by one developer awhile ago that just fell through the cracks. There really wasn't a benefit to doing what they did, which is why their fix was to just go back to using public APIs.
I don't think it's that clear cut. It looks like it was a workaround for a MacOS rendering bug going back to at least 2017, landed in 2019 and had no apparent downsides for six years[1].
The PR removing the private API code also included someone verifying that Apple had fixed the original bug some time in the intervening years[2].
I probably wouldn't have taken this approach personally (at the very least file the original rendering issue with Apple and note it with the code, though everyone knows the likelihood of getting a even a response on an issue like that), but it wasn't some cargo culted fix.
[1] https://github.com/electron/electron/pull/20360
[2] https://github.com/electron/electron/pull/48376#issuecomment...
Who’s to say Apple didn’t test it and pushed it out anyway to force the Electron devs hands. It’s their garden and they can move the walls
This only made Apple look bad, again this is not a bug that make the app slow, it makes the whole system slow.
Imagine now that you're a non tech savvy user, that probably doesn't update apps as often, they are probably wondering why "my laptop is so slow after updating". But like I said in other thread, maybe this is on purpose to make people upgrade.
I don't think they care, they'll pass the blame to 3rd party app devs. They care more about forcing users and devs to interact with their products how Apple wants them too. They have a long track record of this behavior
> because they could make this so annoying to do that nobody would try (for example, stripping symbols).
Many of Apple's OS frameworks are managed code (ObjC/Swift); and in ObjC, calling across a library boundary is always done with a message-send — i.e. a dynamic-dispatch, necessarily symbol-table-based call into an entrypoint of the target library. So anything Apple did to "strip symbols" would make it impossible for them to have one of their libraries call into another of their libraries.
> because they could make this so annoying to do that nobody would try (for example, stripping symbols).
If they stripped symbols, they’d get flak for not having good stack traces. I think it boils down to “if you’re huge, you’re never doing it right”.
- [deleted]
- [deleted]
Spotify doesn't use Electron, though. Also, I do not expect Apple to care about Electron because delivering shitty electron experience only benefit their native apps.
If anything the ones that got a worse reputation here is Apple itself. The bug basically slow the whole system, not just the application that has the bad behavior.
Sure, people in Hacker News now know that the issue is "that Electron bug", but I am sure lots of other people that are less tech savvy just kept questioning what the hell is happening and maybe even considered an upgrade. But maybe that is the whole point.
Seems like the right patch is to just crash any app attempting to use the private API so blame would go where it is deserved. And if it caused a lot of more awareness of the need to get rid of Electron, bonus.
It seems as though a lot of arguments about this boil down to a few inane implications:
1. Apple should test every (common?) app and any change to the OS that they make that makes an app worse shouldn't be done regardless of why they wanted to make that change. 2. Even though Apple tells people not to use private APIs, if a program uses a private API anyway Apple should build a workaround into their OS instead of letting apps suffer their own repercussions. 3. Apple should test everything ahead of time and then go around telling all the app developers that there's a problem, as if those app developers are going to do anything about it.
No matter what Apple did here, their actual choices boiled down to:
1. Add workarounds for misbehaving broken apps, giving those apps no incentive to fix their issues, and forcing Apple to support those workarounds indefinitely; this also undermines their "don't use private APIs, they could break later" position. This is the kind of thing that made Windows into an unmaintainable sack of cruft.
2. Do what they did, which is change the API and let broken apps be broken to the user's detriment. Everyone blames Apple even though it's objectively not their fault.
2. Add some kind of non-workaround that caused problems for the app and not the user; e.g. have this private API rate limited or something so that the app ends up blocking in the call. Could cause problems for actual consumers of this API, and people would still blame Apple but in this case it would be more of their fault than option 2.
In the end, Apple can't spend their time fretting over what bad developers do wrong; they spend their time on their OS and software and if a developer writes bad software and causes problems then so be it.
I think testing the top 10 projects in a few verticals is a pretty reasonable thing. For my open source projects I do this kind of basic QA against their top users.
Then the bugs could be reported to the various app developers, and they would have been able to get some notice. Many would have acted on it. Many of the top apps have dedicated Apple contacts already. Seems like a completely reasonable expectation?
4. push Gatekeeper-blacklist entries for the broken (bundle ID, version) pairs of these apps (even if those are the current versions!) — such that when the user goes to open them, they just get a dialog reporting the app as being "not compatible with this Mac, and should be moved to the Trash."
Apple really should investigate why so many popular apps are implemented using Electron. Is it that hard to use the native APIs now? If so, Apple needs to improve the native application development experience. The UX on these apps is terrible and should be embarrassing for all involved.
Electron isn't popular because SwiftUI sucks (although both statements can be true at the same time) it's because big shops have decided that it's not worth the cost to develop native UIs on each platform anymore, so the only way they've decided we will get "native" apps is via Electron.
If electron didn't exist, it would be QT, or we'd only see native apps on Windows like the old days, and nothing at all on macOS and Linux (or just web apps).
It's not a tech issue but a cultural/management problem.
Personally I try to avoid Electron apps as much as possible, but it's pretty much unavoidable now. Docker Desktop, Bitwarden, 1password, slack, VSCode, dropbox, GitHub Desktop, Obsidian, Notion, Signal, Discord, etc. All the major apps are electron. Even in the Windows world Microsoft stopped making native and makes heavy use of their own version of Electron (EdgeWebView2) for their own apps. The freaking start menu is react native ffs.
The industry has lost its collective mind in favor of being able to hire cheap javascript talent
The other reason is that many of the companies that ship Electron apps are web-first companies. Slack, Discord, VSCode, Github, and Notion were all solely web apps at first — some for years — before any native app was released.
To these companies, a "native app" is just "a web app with its own start-menu icon, no browser chrome, and access to OS APIs."
(In other words: if PWAs had access to all the same OS APIs that Electron does, then these companies wouldn't ship native apps at all!)
I have written applications for macOS in Objective-C and remain a Swift skeptic. Maybe the language has more serious design behind it now. I don’t know. As much as I hate JavaScript, maybe it is time for Apple to provide a JavaScript API or their own official Electron layer. I really hate how Electron apps don’t use the same text input field as the rest of macOS.
That's sort of the route Microsoft went with EdgeWebView2.
Swift itself is great and stable enoug now. I really like the language. SwiftUI though still needs work and is still missing functionality that you have to fall back on AppKit for so there's tons of bridges to embed AppKit views in your SwiftUI hierarchy (like NSTextView still relies on AppKit, as does some drag and drop functionality) so at a certain point you might as well just continue using AppKit.
Apple introduced an entirely new language and UI framework to make it easier, Swift and SwiftUI respectively. They have tutorials, classes, thousands of example projects, playgrounds, videos, and documentation. No, it’s not hard at all.
But very few users seem to care about performance or polish, so why not save a few bucks and build your desktop software with some cheap JavaScript devs?
I seem to recall from past reading of the AppKit source code that one solution to (1) was to have version specific workarounds that worked for e.g. RecklessApp 39, but would no longer work for RecklessApp 40. I assume that the developers in question were informed of the fact, and now had every incentive to fix the problem.
> blaming Apple for this for "not testing Electron apps internally", but I don't expect Apple to test every single app ever released for regression testing.
Given how high profile the impacted app are, yes it's their responsibility to test it. Even Microsoft does better there (or at least used to). Contacting electron and finding a solution would have been an easy step to take
Here's the thing: they undoubtedly did test these and shipped Tahoe anyway.
Electron was using an undocumented API. There is no guarantee at all that undocumented APIs will continue to work or to be supported. Why should Apple encourage this behaviour?
Yes I think Apple is to blame there. Electron is so prominent that they should have detected the problem and found a solution well before the general release.
Apple releases betas of their OS specifically so that developers can try their apps on them. macOS is so prominent that Electron-using developers should have detected the problem and found a solution well before the general release.
Well, I personally know of cases Apple did explicit patching for specific apps to keep them working / avoid breaking.
My simple guess is that slipped QA or wasn’t escalated from Apple’s feedback.
Considering the amount of electron apps, expecting all developers and all users to update all their app (and guessing which one is Electron based) isn’t good user-experience.
Let’s say the change is needed in the OS, you’d expect transition time. Also, a good UX on OS would be to notify user this app is using some API in a way that could reduce experience. but guessing and expecting only the developer and user parties without the OS side is making less sense imho.
I don't do desktop applications professionally (firmware is my thing) but I would balk at the suggestion that I should run a beta OS on the machine that pays my rent.
What portion of, say, Slack devs actually run a MacOS beta at work? Are they regular devs, or are they in QA/test? It seems to me like the latter is the far more appropriate team for this.
I write macOS software (among other things). I always run the earlier betas on another machine for testing. The primary dev box gets the beta a few weeks before release. It’s never been a problem.
This is 100% on electron, they didn’t do their due diligence that every Mac & iOS dev goes through every summer before the next release. It’s been two decades of the same song and dance every year. There’s just no excuse.
If the result of this policy is that users think Apple products are crap, then it's probably counter-productive for Apple, no?
Apple just doesn’t work that way, and hasn’t since I worked there in the 90s. Private APIs are out of bounds. It’s like a “the FBI doesn’t negotiate with kidnappers” situation.
> "the FBI doesn’t negotiate with kidnappers”
Welp
https://leb.fbi.gov/articles/featured-articles/fifty-years-o...
Apple's private API situation was also much more nuanced, back in the days if Adobe was using an API, private or not, it probably wouldn't be degraded in any way until the core applications moved forward. Current Apple might not give a damn though.
Yeah true, there was a period when they couldn’t really afford to annoy the big developers. But it doesn’t seem like the underlying attitude changed much!
So now you can disregard the notion of "private function" if you pass 100k stars on GitHub ?
There's definitely a line of thinking that would say "yes": https://www.hyrumslaw.com/
Sure, someone will depend on it, we all ignored "private" vs "public" at least once. Okay to do and okay to be mad when your thing breaks because you decided to depend on it? Nope.
Okay to be mad the OS vendor didn't do anything to help when the users are the ones that face the fallout? Yes.
Even if you disqualify the devs from being mad, everyone else gets to be mad.
Vendor did help...marked function as private. I view this specific incident as another argument against electron, so I'm biased.
That's a good initial step. But once it got put on a zillion computers, there should have been additional mitigation steps.
In an ideal situation, they would have noticed the widespread use of this private function a long time ago, put a note on the bug report that it works around, and after they fixed the bug they would have reached out to electron to have them remove that access.
Exactly. As they say: if you owe the bank $100, that's your problem; if you owe the bank $100 million, that's the bank's problem.
No? Developers had access to _developer_ preview builds on macOS to test their apps. Those builds are meant for this.
That's not what that quote is about.
If you owe the bank $100 and don't pay, that's your problem: you'll get in trouble for it, and the bank isn't going to be unduly harmed.
If you owe the bank $100 million and don't pay, that's the bank's problem: the loss of that $100 million is going to hit the bank hard, whether or not they're the ones who are in the right and regardless of how much trouble you get in over it.
Likewise, if you're a small time app developer and you use a private method that gets yanked and your app breaks, that's your problem: your users are going to be pissed at you, you'll take the reputational damage, and even if your users are also pissed at the OS vendor they represent such a small group of individuals that the OS vendor isn't going to be unduly harmed by that.
If, on the other hand, you develop one of the most widely used frameworks and you use a private method that gets yanked and your app breaks, that's the OS vendor's problem: the number of people who are pissed off at them (rightly or wrongly) is now much larger and they're going to take some reputational damage over it, whether or not they're the ones who have the moral high ground and regardless of how much reputational damage you also take.
And that's exactly what we're seeing here: it doesn't matter that Electron used an API they weren't supposed to, people are pissed at Apple about this and Apple, rightly or wrongly, has to contend with that reputational damage if they don't take steps to prevent this sort of thing before it happens (like letting the developers know that private-on-paper API is going to be yanked in advance, or making it mechanically impossible for anyone outside of Apple's own code to invoke that API long before someone depends on it).
Yes, sorry, it wasn't clear. I meant this quote has nothing in common with this situation we're talking about.
> has to contend with that reputational damage if they don't take steps to prevent this sort of thing before it happens (like letting the developers know that private-on-paper API is going to be yanked in advance, or making it mechanically impossible for anyone outside of Apple's own code to invoke that API long before someone depends on it).
Again, that is what dev builds are for. Developers had months to verify their software still works on an OS that has confirmed release date and has very high ration of users that install the latest and greatest.
That's true, and yet they didn't. We can (rightfully) blame them for that, but people are still pissed off at Apple, and whether or not they deserve it they still suffer the reputational damage.
That's why this quote is relevant to this situation: it's totally Electron's fault for not adequately testing their framework against Apple's latest developer builds, but Apple could have absolutely done more to minimize the chance that Electron would make a mistake like this and cause lots of folks to be mad at Apple over it.
Should Apple be required to? No. Will they still suffer reputational damage if they don't and something like this happens? Yes.
all APIs are public APIs
Only if you don’t care about your users or your apps reputation. Of course, if you are using Electron those ships have already sailed.
The check script I've been recommending is here:
https://github.com/tkafka/detect-electron-apps-on-mac
About half of the apps I use regularly have been fixed. Some might never be fixed, though...
wasn't there a workaround for those apps that might not ever get updated? I thought I saw something on reddit. Some config change
> Run launchctl setenv CHROME_HEADLESS 1 on every system start. The CHROME_HEADLESS flag has a side effect of disabling Electron app window shadows, which makes them ugly, but also stops triggering the issue.
From: https://www.reddit.com/r/MacOS/comments/1nvoirl/i_made_a_scr...
This is why I stay on previous release until at least 0.2 or 0.3 to let them work out the bugs so I dont' have to deal with them, there was nothing in 26 that felt pressing to me that I would need to update
Tbh I'm purposely not updating because I'm not in love with the new ~Aero~ glass UI.
> apparently no one uses Electron apps while doing testing at Apple.
You have it the other way around. It should be, apparently no one making Electron bothered to test on the numerous developer and public betas to make sure their hacky override of undocumented APIs (which Apple explicitly says not to use) didn't break.
> apparently no one uses Electron apps while doing testing at Apple
Or also the other way around, nobody who develops electron apps cares to test their app on macos in the beta releases (beta testing for developers was long out afaik).
Except if it was like that JIT JVM bug that caused apps to crash and was not in the beta release.
The OS and stock apps are much slower in Tahoe even. And the UI updates/interactions are also slower. I’m lucky I only upgraded my least used machine, and that’s a well stocked M2.
It should not be slower. File a report in Feedback Assistant.
WWDC keynote on the state of the nation was quite clear on what Apple thinks about Electron and related stuff like React Native.
Hence I am not surprised that they ignore their existence.
Or more likely nobody gives a damn about performance while doing testing.
my tinfoil-hat theory is that on each OS iteration Apple adds a new feature that leverages the latest chips hardware acceleration features and for older chips they do software-only implementations.
they ship-of-thesseus the crap out of their OS but replacing with parts that need these new hardware features that run slow on older chips due to software-only implementations.
I got the first generation iPad Pro, which is e-waste now, but I use it as a screen for my CCTV, it cannot even display the virtual keyboard without stuttering like crazy, it lags switching apps, there's a delay for everything, this thing was smooth as butter on release.
I have the 4th gen (2020) iPad Pro with the A12X Bionic, the same chip they put in the Apple Silicon transition dev kits. With iPadOS 26 it's become barely usable, despite still being performant as ever on iPadOS 18. I'm talking huge drop in performance, stutters and slow downs everywhere.
I was considering just replacing the battery and keeping it for several more years but now I feel forced to upgrade which has me considering whether I still want/need an iPad since I'd also have to buy a new magic keyboard since they redesigned it, and they bumped the price ($1299 now vs. $999 when I got the 4th gen) so I'd be looking at $1700. Trying to hold out for an iPad Air with ProMotion.
I may be in the minority here, but I think 5 years is too short of a lifespan for these devices at this point. Early days when things were advancing like crazy, sure. But now? I have 8 year old computers that are still just fine, and with the M-series chips I'd expect at least 10 years of usable life at minimum (battery not withstanding)
That's weird. I have an 8th Gen iPad, the slowest device that can run iPadOS 26, and everything is fine on that old thing. (except the OS takes up the majority of the storage)
Interesting. Might try a factory reset then and see. There's noticable lag for me, it's especially slow when switching apps or bringing up the keyboard, as well as on first unlock. Interacting within a single app is still fine, it's interacting with the OS that's really sluggish.
How long have you been running on 26? Every iOS/iPadOS update takes a few days to stabilize.
> Every iOS/iPadOS update takes a few days to stabilize.
What in the actual world of software engineering?
Total guess but is there a tiny fan inside that got filled with dust? Maybe it's thermal throttling.
Apple has never made an iPad with a fan
8th Gen iPad is about the same on iPadOS 26 as 18 for me, which is slow. The 32GB really handicapped it for even being usable as to even upgrade it, I have to factory reset it first. I'm replacing it with a Mini.
The iPad Air 13 with a M3 is a really nice experience. Very fast device.
weird, my iPaid Air 3 which should have the same specs has been really for at least a year. Plenty of free storage, not so many apps, all visual enhancements turned off.
I think you accidentally a word?
I have perfectly fine Mini 2 Retina, but because they blocked Safari updates and faked AppStore connectivity issues - I have just perfect display with still good battery than can be used as bread cutting board :(
I have a 3rd Gen iPad Pro from 2018 and iPadOS 26 runs fine.
Plus they don't let you downgrade to previous iOS versions on iPhones and iPads (unless you've been smart to save SHSH blobs and all that) so the only option to revert to a smooth version now is to download a sketchy jailbreak.
> A12 devices and newer
> You cannot restore to any iOS versions other than signed ones. All SHSH blobs are currently useless.
So, anything newer than iPhone X can’t be downgraded
Yep, this is pretty much how they operate. Apple has always done that to some extent. Sometimes they are even quite clear about it and use it as a marketing point to push upgrading.
At some point you have to use the new features available to you. That's not really tinfoil, just progress, and how all tech works no.
They could choose to not offer the new feature to users on old hardware, but still provide those platforms with e.g. security updates and key features like Safari upgrades.
this couldn't be farther from the truth. people still use vim and it's better than most new tech that was made post 2000s.
I'm on an M2 with 24GB ram and it feels like it flies as fast as ever.
26.0.1 fixed the sluggishness. 26.0 was pretty unstable - felt like a game dropping frames.
26.0.1 is better, but I can still get sluggishness in a few specific cases.
I just got one example while passing the mouse quickly through my dock (I still use the magnify animation) and I can clearly see it dropping a few frames. This never happened in macOS 15.
With Tahoe my M2 Pro feels snappier than before.
I don't get this - I have an M1 iMac - haven't noticed much difference.
> work provided
I too have a work-provided laptop and a personal one bought the same month, with identical specs (the only difference is the US vs UK keyboard layout). The work-provided one is at least an order of magnitude slower to do anything thanks to enterprise crapware.
same here
Transparency disabling ads anothe draw layer that is opaque on top making it even worse than when it’s on
If they developed it in the most naive and stupid way imaginable, sure. If we're assuming Apple isn't filled with 3rd year comp sci students, then no.
HAHA this is where HN has become delusional. It quite literally is the implementation, they've checked the render pipeline on reddit. Jesus the arrogance here is so shit.
There are so many software related things that drive me absolutely loony with Apple right now.
* My iPhone as a remote for my Apple TV has randomly stopped deciding it can control the volume - despite the "Now Playing" UI offering an audio control that works.
There auth screens drive me crazy:
* Why cannot I not punch in a password while Face ID is working? If I'm skiing, I know Face ID isn't gong to work, stop making me wait.
* Likewise, on Apple TV the parental control input requires me to explicitly choose to enter a Pin Code. Why? Just show me the Pin Code screen. If I can approve from my device, I will.
* Similarly, if I use my phone as a remote, why do I need to manually click out of the remote to get to the parental control approval screen. I'm literally using my phone. Just auto-approve.> * Why cannot I not punch in a password while Face ID is working? If I'm skiing, I know Face ID isn't gong to work, stop making me wait.
Funny, a similar thing has been driving me crazy on my Ubuntu 20.04 laptop with fingerprint login. When unlocking, I can either enter a password or use fingerprint. On boot, I am not allowed to enter a password until I fail with fingerprint. If I use fingerprint to log in on boot, I have to enter my password anyways once logged in to unlock my keychain.
I should probably just figure out a way to disable fingerprint on boot and only use it for the lock screen.
I think this is a GNOME thing...the keychain by default has the same password as the login password, so logging in with the password unlocks it too. fingerprint login doesn't unlock it: https://news.ycombinator.com/item?id=38527876, https://wiki.archlinux.org/title/GNOME/Keyring
Yeah, I've resigned myself to that. The part that irks me is that it doesn't present a password prompt (on initial login) until fingerprint attempts are exhausted.
I see the same bug with the remote on my phone, how did they manage to break volume control in the app while keeping it working from the lock screen “now playing”?
I’ve also been unable to get the remote app on my watch to work at all. It’s hard to imagine people working at Apple don’t also run into these issues all the time.
Why can I not use my password manager for my Apple ID but can use it for any other password field? Instead I have to switch to my password manager, copy the password, reopen the App Store, select get app, and paste the password in the Apple ID login pop up in the 10 seconds before my password clears from my clipboard.
Been ages but I think you can mitigate that annoyance by approving fingerprint purchases.
It requires a password to enable Touch ID whenever you restart your phone. For security reasons, the iPhone automatically restarts every few days. So I run into this issue regularly.
As someone who jumped in the apple bandwagon at peak apple and hasn’t been through all their ups and downs the way some die hards have been, it’s been super aggravating dealing with apples shit lately - not what I signed up for all those years ago
It seems to have been degrading for a long time, but for me it’s been in this past year where it’s crossed into that threshold android used to live in where using the phone causes a physiological response from how aggravating it can be sometimes
I let my guard down and got too deep into the apple ecosystem- I know better and always avoided getting myself into these situations in the last, but here I am
The phone sucks right now - super buggy and they continue to remove/impose features that should be left as an option to the user By Yes, this has always been the knock on apple, but I typically havent had an issue with their decisions - it’s just so bad now
Lesson (re)learned and I will stay away from ecosystems - luckily the damage here is only for media
The minute I can get blue bubbles reliably on an android, I’ll give the pixel a shot again - if that sucks too then maybe I’ll go back to my teenage years and start rooting devices again
So, I still think the experience is generally better and more integrated than when I was on an Android device. I just find they're generally not really paying attention to user details the way they have in the past.
How would you ever get blue bubbles reliably on Android? Are you talking about iMessage or something else?
I am fully bought into the Apple ecosystem. Not sure yet if I regret it. It is annoying to be so tied down to one company that isn’t going the way I want it to.
Yeah iMessage - over the years there have been “breakthroughs” - people find nifty workarounds or have even reverse engineered the iMessage protocol, but for whatever reason nothing ever sticks
There are current workarounds, like isn’t your home Mac as a relay, but nothing super elegant that I know of
Having used Whatsapp for the majority of my messaging the last decade or so, every time I'm forced to use iMessage for communicating with family I can't help but think it's absolutely a garbage interface. Buggy, slow, difficult to really get anything done effectively. Threaded messages is a nightmare. I really can't wrap my head around how anyone prefers using this over literally anything else.
no one actually prefers it, its just the default for ios users and what everyone uses in the US
this means that i either use ios or i have to be "that guy" always asking everyone to send something in a different format or to please move the conversation to some other app - no one wants to be that guy - apple's got us right where they want us
and to be honest, when texting other people, it makes a huge difference, believe it or not, if your chat bubbles on their screen are blue vs green. it shouldn't matter - people who would care about this aren't people you would want to talk to anyway blah blah - that's all fun and great but it does matter, unfortunately
I highly recommend the Apple remote .. then you also don't need to take your phone with you when you are watching TV, which is an added benefit for some.
Of course the thin Apple remote has a way of getting lost, but it has a Find Me feature which locates it pretty well.
It also feels ice cold, with sharp edges
Remote is fine, but it's always stuck in a couch cushion.
There was a company or two that made cases for the older Apple remotes with the express purpose of making them larger, which I always thought was kind of funny. I would buy one for the current remote if one existed.
Same here.. so we use that Find Remote functionality about once a month! Without it we'd be lost. Business idea: Make a cover for the Apple remote that makes it bigger and harder to lose.
I think they are readily available:
The volume on iPhone when being used as remote seems to work of you use the hardware buttons. It’s not intuitive at all but it works
Yes, I'm aware. That feature breaks - despite volume control still working on the "Now Playing" screen.
> Software teams at apple really need to get their act together.
WatchOS 26 has rendered my Apple Watch almost useless. It's gone from lasting a whole day including 2 cycling 'workouts' for my commute and the occasional lunch time run (or gym session before work) to now being at 40% battery by the time I make my mid-morning coffee and dead before I get home.
I don't use most of the 'smart' features anyway - I'm mostly using the fitness features - so I'll probably switch to a Garmin at some point.
> I don't use most of the 'smart' features anyway - I'm mostly using the fitness features - so I'll probably switch to a Garmin at some point.
If that's your use case, I can absolutely recommend getting one. I have a Forerunner 745 and it works great for workouts alongside some smart functions like NFC payments, quick-replies to texts, etc. The battery lasts for days as well, which you can't really beat.
> The battery lasts for days as well, which you can't really beat.
The Garmin Instinct 2X's (and 3) battery lasts for 40 days in smartwatch mode, not counting the solar charging.
The Instinct is an "outdoor watch" with a monochrome display, but it has most features the Forerunners have.
For the sake of completeness, I would also mention:
- Suunto (20 to 30 days in smartwatch mode for the Verticals, optional solar charging, flashlight on the Vertical 2)
- Coros (2 to 3 weeks depending on the model), no flashlight
- Withings (30 days, looks like a regular watch)
Coros is good for how long they support their watches, and the fact that they don't restrict features in lesser models. Suunto is great for route planning. Polar is renowned for its training metrics (sleep, recovery etc.) but only fetches a week in smartwatch mode.
Also it has a proper builtin flashlight which is surprisingly useful. Amazing watch, especially if you get a comfortable aftermarket strap e.g. from Hemsut.
Dropping in to add that the Venu 4 is an amazing watch as well. Battery says it'll last 14 days. With Pulse Ox enabled at Sleep, it drops to 11, but I'm happy with the tradeoff. Workouts like running for half an hour drop it even more, but comparing it to an Apple Watch, it's no match. It has a flashlight as well and looks like a normal smartwatch instead of rugged. All in all, if you care more about health features rather than watch<->phone connectivity, a Garmin is worth it.
If you want to try something cheap, try the Amazfit BIP 6 watch. It costs around 1/4 of Apple watch, has most but not all of the same sensors (can't do ECG). It has far too many configuration options for my taste, but it does mean you can make it look like Apple like with Apple watch like battery life or configure it to last well over 3 weeks on a single charge. TL;DR: software is kinda clunky, but the hardware works well, and it's focus is on fitness.
It's incredible what the hardware teams at Apple have been doing. I imagine they also feel let down by the software that's driving these beasts. It's as if they're 2 completely different companies.
The latest iPhone OS (iOS 26) is embarrassing. The number of glitches and amount of UI sloppiness is crazy for a company that historically prided itself on the details. It's the first major iOS update I've taken that just seems almost strictly worse than its predecessor.
I remember using my first Apple product years ago, it was an iPod touch 4th gen. The quality of the software on that thing was in a completely different league compared to anything I had used before.
I also installed the iOS 26 update recently. The competitive advantage of software polish that Apple had seems totally gone.
Add to that bugs in iCloud, AirDrop... I don't think I will be buying any more Apple devices for myself.
What line of laptops is in the same league as the MacBook Pro?
A small silver lining is if the worlds largest company can ship complete garbage like this don't feel bad about your own small mistakes. I mean i've hotfixed and done my fair share of production reverts - but never, never anything as bad as this.
Disclaimer, i actually like a bit of "bling", but both Tahoe and IOS so filled with glitches and errors, while the UX is bizarrely inconsistent it really is catastrophically bad.
This feels more like a repeat of iOS7 to me.
iOS 7 was the first version of iOS that looked good. Its release was far better and stable be than this liquid glass thing.
i've never had such a major downgrade as this one
In the case of Microsoft and Intel, they were. Vertical integration is Apples claim to fame, but apparently, it has its limits.
Before the whole "batterygate" thing[1], there were forums and discussions on macrumors and similar inquiring about the feasibility of inserting no-op codes deep below the kernel that would kick in under certain conditions. Post-batterygate, you can't find anything NOT about batterygate when searching.
1] Which I still firmly believe WAS indeed a power-supply design failure that would have forced a massive hardware recall had they not done something (slowing down the os). I believe it encompassed everything from inaccurate CPU power estimates to something actually incorrect with the PCB design, causing brown outs - and not merely a battery-aging red herring as is the reported scandalous reason they were "caught". In fact, I think Apple is GLAD that all it amounted to was some philosophical hullabaloo about protecting your poor aging battery.
To clarify, I suspect the "aging battery" merely exposed the real issue - the incorrect PS design - which Apple successfully covered up.
I've seen every new OS update leading to M1 Air performance degrade, at this point I'm pretty convinced Apple is doing this intentionally.
Edit: Same experience with iPhone X
Edit2: I still remember the feeling when I got them initially - that Apple is on customer's side, but now I feel totally helpless and i'm being forced to upgrade
I haven’t noticed this to be honest: macOS 26 Tahoe is the first update that significantly hindered the performances of my MacBook Air M1. Even with the Electron _cornerMask fix + disabling auto heuristics at the OS level.
I wonder how much is due to just scale vs. a Bertrand Serlet vs Craig Federighi culture/management style
I personally have no idea but I seem to recall the golden age of open source/unix embrace was under Serlet
>The M5 MacBook Pro still gets the Broadcom WiFi chip but the M5 iPad Pros get the N1 and C1X (Sweet).
Is that good? Their cellular modems have been terrible. I'll reserve judgement until trying one out.
>The M1 itself is so powerful
I think this is a bit of a fallacy. Apple Silicon is great for the power consumption to power ratio, but something like a Ryzen 9 7945HX can do 3x more work than an M1 Max. And a non-laptop chip, like an Intel Core Ultra 7 265k can do 3.5x.
Those ratios seem way off if you're referring to the M1 Max and not the base M1. If we use Geekbench CPU performance, the Ryzen 9 7945HX (which is from 2023) is around 12% faster single core and 32% faster multicore than the M1 Max (which is from 2021). If you look at the 2024 M4 Max, it's substantially faster than the Ryzen and Intel you mentioned.
https://browser.geekbench.com/processors/amd-ryzen-9-7945hx
https://browser.geekbench.com/processors/intel-core-ultra-7-...
https://browser.geekbench.com/macs/macbook-pro-16-inch-2021-...
https://browser.geekbench.com/macs/macbook-pro-16-inch-2024-...
Source re:modem claims? Performance seems fine in general, modestly slower on very high end networks but using 25% less power.
Performance claims:
https://www.ookla.com/articles/iphone-c1-modem-performance-q...
Energy claims:
https://appleinsider.com/articles/25/02/27/apples-c1-modem-b...
- [deleted]
Having a cellular modem on a MacBook would be really handy even if it's not perfect.
I really wish apple sold the Mx to others like Lenovo.
I would love to se a ThinkPad with an M5 running Linux.
What is the Linux experience on new Mac hardware? I'd be interested also in running a Macbuntu.
Asahi linux is essentially in a holding pattern with only support up to M2. Likely linux will never be supported above M2 and even M2 has a lot of rough edges. When my monitor sleeps on M2 linux it can never reawaken without a reboot.
So the normal Linux desktop experience then!
I kid, I kid.
maybe the normal desktop Linux experience in 1996
There are very nice Thinkpads running on Snapdragon now. But no Linux is available…
The Broadcom WiFi support 320Mhz while N1 is stuck with 160Mhz. There were report of N1 not supporting 4096 QAM as well but I didn't check.
> The Broadcom WiFi support 320Mhz while N1 is stuck with 160Mhz.
I was at a Wi-Fi vendor presentation a while back and they said that 160 Mhz is pretty improbable unless you're leaving alone and no wireless networks around you. And 320 Mhz even less so.
In real life probably the best you can get is 80 Mhz in a really good wireless environment.
For which band? I run 160/160 on 5/6ghz and it’s nice. They are short range enough to work. For 2.4 yeah 20mhz only
For 5ghz, that's a pretty unusual. You need to be somewhere where DFS isn't an issue to even get 160mhz.
For 6ghz? Yeah, not uncommon.
I would believe that MLO or similar features could make it a bit more likely that large amounts of bandwidth would be useful, as it allows using discontiguous frequencies.
WiFi does currently get anywhere near the bandwidth that these huge channels advertise in realistic environments.
OFDMA also makes it more useful, but I don't know if vendors actually use that in practice.
Given that they had WiFi 6 as trial I expect WiFi 7 to have it ironed out for OFDMA. And MLO to be not working until WiFi 8.
Indeed, in any relatively dense setting no one should even think about using channels that wide. Think about the original problem with 2.4ghz 802.11b/g: there were only three non-overlapping channels, so you had interference no matter where you went. Why would we want to return to that hell?
My limited experience:
2.4Ghz is pretty much only used by IoT, you generally don't care about channel width there. When your client device (laptop, phone) downgrades to 2.4Ghz it might as well disconnect because it's unusable.
5Ghz get stopped by a drywall, so unless your walls are just right to bounce off single, you need AP in every room. Ceiling mounting is pretty much required and you're pretty much free to use channels as wide as your device support and local laws allow.
6Ghz get stopped by a piece of paper, so the same as 5Ghz except you won't get 6Ghz unless you have haev direct line of sight to the AP.
"stuck".
An infinitely small percentage of people can take advantage of 320Mhz. It's fine.
Today. But in 3 years time it'll be widespread and your Mac will be the one with the sluggish WiFi connection that jams up the airwaves for all other devices too.
It really won't, and there will be a ton of devices "jamming up" the airwaves. In most places the backhaul isn't fast enough for anyone to get any use for 320MHz channels beyond maybe very large LAN file transfers which are for some reason happening over WiFi?
Thankfully, there has been nothing new to use computers for since 2022. Definitely no new technology that involves downloading different 10+ Gib large files to test with, and users couldn't possibly conceive of a NAS, nevermind owning one because Netflix has never removed shows while people are watching them, breaking an assumed promise by users. ISP speeds are never ever going to improve either. Everyone knows that!
How does it “jam up the airwaves” if its operating at a different frequency than the devices you say it will be jamming?
From Apple's support docs:
https://support.apple.com/guide/deployment/wi-fi-ethernet-sp...
No devices support 320Mhz bandwidths, and only supports 160Mhz on 6GHz band on MacBooks and iPads. Some iPhones support 160Mhz on 5GHz as well.
Does it? If it’s the same WiFi chip used in other M4 Mac’s then it’s still limited to 160MHz:
https://support.apple.com/en-gb/guide/deployment/dep268652e6...
My word I thought the Broadcom ones were better. Thanks for checking.
Channel width is not the only thing that determines the usability or quality of a chipset though.
Reducing Broadcom's influence over the WiFi ecosystem alone would be a large benefit.
I doubt the number of people in both "has no neighbors" and "owns Apple hardware" camps are significant at all.
Poe's law?
I don’t think 4096 QAM is realistic anyway, except if your router is 10 cm away from your laptop.
I would be soo excited if apple split out the hardware and software orgs and moved to make hardware more standardized with macos/ios/etc being just one consumer.
Not going to happen, but I can dream.
That’s a bit silly though, that implies that the MacBook Pro M5 will not be compatible with Apple’s lossless wireless codec introduced in the iPhone 17 and AirPods Pro 3?
That really is a reason for me to skip this upgrade and wait for the next release.
As a UI/UX nerd, it’s a coin flip on intentionality. I’ve been noticing so many rough edges to Apple’s software when it used to astound. iOS Settings search will flash “No Results” as you begin to type which is comically amateurish. The macOS menu bar control panels can’t be keyboard navigated... It’s just silly.
I’ve been debating making a Tumblr-style blog, something like “dumbapple.com,” to catalogue all the dumb crap I notice.
Liquid Glass feels rushed to me. Tons of UI annoyances especially on iPhone - it's suddenly many clicks to get to prior calls for instance, a core way I call people. I'm imagining it will get ironed out over the next two years.
It really does. It’s a two-year update and hey should have had two teams - one for Liquid Glass working for the next release, and one doing a Snow Leopard-type cleanup for this year. Let the Mac and iPhone be a bit out of sync if needed.
There already is something like it (though not Apple-exclusive): https://grumpy.website/
I’ve been having the same idea for a while. I think it would be a great way to let them prioritize the stability a bit more by publicly displaying how shamefully the UI behaves.
Interested in collaborating on this? Perhaps a simple open-source static blog built with Astro?
"iOS Settings search will flash “No Results” as you begin to type which is comically amateurish."
I'd love to agree that comically amateurish, but apparently there's something about settings dialogs that make them incredibly difficult to search. It takes Android several seconds to search its settings, and the Microsoft start menu is also comically slow if you try to access control panels through it, although it's just comically slow at search in general. Even Brave here visibly chokes for like 200ms if I search in its preferences dialog... which compared to Android or Windows is instant but still strikes me as a bit to the slow side considering the small space of things being searched. Although it looks like it may be more related to layout than actual searching.
Still. I dunno why but a lot of settings searches are mind-bogglingly slow.
(The only thing I can guess at is that the search is done by essentially fully instantiating the widgets for all screens and doing a full layout pass and extracting the text from them and frankly that's still not really accounting for enough time for these things. Maybe the Android search is blocked until the Storage tab is done crawling over the storage to generate the graphs that are not even going to be rendered? That's about what it would take to match the slowdown I see... but then the Storage tab happily renders almost instantly before that crawl is done and updates later... I dunno.)
The parent isn't commenting about the speed of search, just that saying "No Results", when they really mean "we're still checking for results" is bad UI (which I agree with).
The speed is bad too. At least on Android, it does actually take 5-10 seconds sometimes. That's not an exaggeration.
It should be searching, what, a few hundred strings? What is it doing? Is it making a network call? For what?
Anyway, barely related, but it does bring into question the quality of modern software.
It is possibly Null value pattern in action, which is a good thing in my opinion (as in robust), though its display this way is a bit suboptimal.
Funny I'm defending them, but I think this is not even a papercut in my opinion, while they have far bigger issues.
- [deleted]
- [deleted]
I'm sure this is me seeing the past through rose-colored glasses, but the reason bits of visual pollution like that is particularly annoying is Apple shit used to be so exceptionally polished. Not sure what emotion I want to project on them as to why they're like that now (or if it's even actually true), but it's the perception that if they're no longer getting the little stuff like that polished anymore, what else just isn't being done to the same high standard?
Lots of things. iOS has never implemented the iPod USB interface properly and whoever thought listing music alphabetically was a good default should be fired.
Might have to be more specific than Android and Windows. Tried them on my devices (S24, windows 11) and they're practically instantaneous.
The old System Preferences search was lightning fast compared to current SwiftUI System Settings on macOS.
Please do this. Here are some examples to add to your list, leaving out the 26.0 bugs that I've come to expect running a .0 release.
1. I won't focus on a bunch of Siri items, but one example that always bugs me: I cannot ask Siri to give me directions to my next meeting. The latest OS introduces an answer for the first time, though. It tells me to open the calendar app on my Apple watch, and tap on the meeting, and tap the address. (I don't have an Apple watch.)
2. Mail.app on iOS does not have a "share sheet." This makes it impossible to "do" anything with an email message, like send it to a todo app. (The same problem exists with messages in Messages.app)
3. It is impossible to share a contact card from Messages.app (both iOS and MacOS). You have to leave messages, go to contacts and select the contact to share. Contacts should be one of the apps that shows up in the "+" list like photos, camera, cash, and plenty third party apps.
4. You still have to set the default system mail app in MacOS as a setting in the Mail.app, instead of in system settings. Last I checked, I'm pretty sure you couldn't do this, without first setting up an account in the Mail.app. Infuriating.
> Mail.app on iOS does not have a "share sheet." This makes it impossible to "do" anything with an email message, like send it to a todo app.
You can’t directly share the mail message, but you can “share” selected text or you can use the “print” option to generate a PDF of the message and “share” that instead. Not very discoverable but might cover at least some of what you want to do.
Also not sure if it’s new with iOS 26 but for the contacts thing you can at least skip the “leave messages and search for the contact in the contacts app” part. There’s button in the contact info that will take you directly to the contact in the contacts app. It does feel silly that you can’t share direct from the card in messages though.
I had that complaint about Mail too. Then I realized you can begin dragging an email (from the list view), switch apps with your other hand, and drop it into, say, a todo. Of course, this is less discoverable, so I agree a Share button would not go amiss.
Wow. I didn’t even know it was possible to drag and drop between apps on iOS. TIL. Thanks!
iirc, there's a setting to make the menu bar navigatable. you just need to "alt+tab" to it with some weird button combo, like Ctrl + Cmd + 1 or something.
You can turn on "Full Keyboard Access," which paints a hideous rectangle around anything you focus but does allow keyboard access to everything.
But, like, man - why can't I just use the arrow keys to select my WiFi network anymore? I was able to for a decade.
And the answer, of course, is the same for so much of macOS' present rough edges. Apple took some iPadOS interface elements, rammed them into the macOS UI, and still have yet to sand the welds. For how much we complain on HN about Electron, we really need to be pissed about Catalyst/Marzipan.
Why does the iCloud sign in field have me type on the right side of an input? Why does that field have an iPadOS cursor? Why can't I use Esc to close its help sheet? Why aren't that sheet's buttons focusable?
Why does the Stocks app have a Done button appear when I focus its search field? Why does its focus ring lag behind the search field's animated size?
Where in the HIG does it sign off on unfocusable text-only bolded buttons, like Maps uses? https://imgur.com/a/e7PB5jm
...Anyway.
There's also an app, MenuWhere, that enables you to configure different keys to walk the menu bar. It's free (but nagware). https://manytricks.com/menuwhere/
- [deleted]
Yeah I love my M1 iPad Pro. But the "liquid glass" update made it feel slower. Really only the 'unlock' feels slower, once I'm using it it's fine. But it's slightly annoying and does make me want to update this year to the m5.
But it's a glorified Kindle and YouTube box, so I'm hesitating a little bit.
my dad's got a pre AS iPad Pro and it's so bad after updating to 26. My 6th gen iPad on iOS 17 felt faster than this
I have a 5th gen? Can’t even remember now it’s so old. Nothing works anymore except Netflix, YouTube and Disney, and that only after a minute or so.
Which is fine, since it’s exclusively used to watch a kids show for a half an hour a day.
…but it’s also super sad to see a once fantastic piece of kit to degrade so much primarily due to software.
"make me want to update this year to the m5." Then Apple software devs did what they were told
I’m still daily driving my M1 Max and have no reason to upgrade for a long time. There’s really nothing in my workflow that could be markedly improved performance wise. There’s only thing is maybe more ram as the need for that keeps growing - I’m isn’t just under 30 when running a bunch of containers.
I think it's probably a play to get you to upgrade for the new GPU computational power. I _do_ think that what we're seeing (and marketed as AI) will be the future, but I don't think it will look like what we're seeing now. Whatever that future holds will require the upgraded capabilities of these new GPU architectures, and this being a reason for the subtle nudge to upgrade from Apple makes sense to me.
It feels very much like how I imagine someone living in the late 1800's might have felt. The advent of electricity, the advent of cars, but can't predict airplanes, even though they're right around the corner and they'll have likely seen them in their lifetime.
I think Tahoe is great on my m1 studio. It’s the first os update in a long time that I actually like. The new design feels very futuristic. And I think I’ll get an m5 MacBook Air. There no better computer deal . Even my m1 computer 5 year old still never has any issue with video or render. It’s insane.
My M1 Air got very sluggish after upgrading to Tahoe but then it started behaving normally after a couple of days. Hopefully, you'll experience the same soon.
- [deleted]
Probably building a spotlight index or something of that sort.
They are known to slow down devices on purpose. For them its simply to bring the most out of their new models but it ends up deprecating the old ones.
And it kind of defeats the purpose of having such powerful hardware if the OS isn't keeping up (or worse, actively throttling older devices)
Seems like the software teams are there to simply squander the extra processing power that the hardware teams provide, thus ensuring recurring revenue. I see no good reason to upgrade to Tahoe. I’d have to buy a new computer just so I could power transparencies that I don’t want.
Disable transparencies in Settings then. Simple.
This feels like it's always been true.
Devices get slower for no perceivable reason, when in reality software at all levels makes higher assumptions about how much power you have, and squanders it more readily.
That's why I did not upgrade :) I upgraded VM and when I saw how slow it was, it was a no no for my M2...
> Tahoe however makes my M1 Air feel sluggish
Counterpoint: my M1 Pro was a turtle for a few weeks and then stopped doing nonsense in the background and is back to its zippy self. (Still buggy. But that would be true on new hardware, too.)
mediaanalysisd has been consuming ~140% CPU since upgrading a few weeks ago. I just turned off Apple Intelligence and it dropped to 0%.
> I really hope this is not intentional from Apple to make me upgrade. That would be a big let down.
I've got a reference macbook air from 2015, which is almost clean, only zoom, teams and chrome for meets are installed and used for calls. And boy, how do I regret making macOS updates.. I can believe teams and zoom are shitbags of modern software slop, and thus started to fail running simple video calls. But even native macOS apps that are barely updated for years like notes and calendar are freezing now. So I can conclude that these anti-backward compatibility updates are highly intentional, because hardware is absolutely fine for decade, i even used this ultra-tiny air for travel work once back in 2022, it was still capable to do all office things and thin client. But last year it just turned into pumpkin.
My question is - maybe installing linux can help bring it back to life.
Won't that make Linux support even harder :/
I tried many times to install linux on my m4 and it's very limited (only Asahi) and not with a great support of features like sleep. It's painful so at the end of the day, I restart with osx
> The M5 MacBook Pro still gets the Broadcom WiFi chip but the M5 iPad Pros get the N1 and C1X (Sweet).
I think many IT departments will be thankful for that as Wifi behaviour can be challenging and hopefully will lower ticket counts.
Does this mean that the MacBook Pro still has no option for a cellular modem?
“nobody really needs to upgrade that for most things”
Maybe, but for lots of scenarios even M5 could still benefit from being an order of magnitude faster.
AI, dev, some content scenarios, etc…
If Tahoe made M1 slower then I am sure it was intentional. Apple had done this in the past and been fined for hundreds of millions in different courts all over the world. So I am pretty sure they continue slowing software down intentionally on older hardware. You can google "batterygate" and you can see for yourself
The reason for better hardware is so software can lag more.
>> Tahoe however makes my M1 Air feel sluggish doing the exact same tasks ive been last couple of years
Quit the Dropbox app, it’s electron, and it’s brand spanking new
>The M1 itself is so powerful that nobody really needs to upgrade that for most things most people do on their computers
a rant on my part, but a computer from 10 years ago would be fine for what most people do on their computer, only for software bloat..
Don't kidd yourself: Planned obsolescence is real.
Apple has a higher duty to their shareholders than to their customers.
Not hating on Apple, just stating the hard economic truth.
Nope, never been real, never will be real. Just conspiracy theories like all the others.
PS The Earth isn’t flat. We did go to the Moon. Vaccines don’t cause autism.
Planed obsolescence is not a conspiracy. Apple specifically has been proven to sneakily add "silently slow down the hardware" to their updates. But there's examples of planned obsolescence abound.
Yes, it's real and it's plain funny that you discredit simple facts in a case as obvious and with as many data points as Apple.
From the 2005 iPods settlement [0], to the 113 Mio USD Batterygate [1], to Flexgate [2] where Apple only escaped settlement due to plausible deniability.
To quote from Batterygate:
> Apple has agreed to pay millions of dollars to 34 states over its controversial previous practice of deliberately slowing down older iPhones to extend their battery life.
> [...]
> Many believed it was an effort to encourage users to buy new iPhones.
I agree on all your "PS" points, where we seem to differ is that reading is a virtue and not knowing something because you haven't heard of it doesn't constitute a conspiracy theory.
0: https://www.cbsnews.com/news/ipod-class-action-suit-settled/
1: https://edition.cnn.com/2020/11/19/tech/apple-battery-settle...
2: https://www.macrumors.com/2021/07/20/flexgate-class-action-l...
These obviously are’t planned obsolescence though.
Flexgate is a manufacturing error, that they handled in a consumer hostile way
Batterygate, was an arguably misguided way to support outdated models - prioritising one goal (battery life) over another (speed)
The iPod thing I’ll admit I know nothing about.
It sounds like, for you, planned obsolescence is defined as any instance where a product isn’t manufactured perfectly or degardes over time, regardless of whether it was planned. For me, planned obsolescence should contain at least a hint of planning.
This needs benchmarks.
Sad if true. I feel my M1 max sluggish too lately. After bragging that this was the longest lived work machine I had and thinking I'm good to wait for M6. This is not good for business, but IMO you need more than raw power to justify upgrades even for professional use - form factor, screen quality, battery, etc.
I think they bet a lot of hardware money on AI capabilities, but failed to deliver the software, so there was no real reason to upgrade because of AI features in the chip (which is literally what they boast on the first line of the announcement - yet nobody cares about making more cute faces)
It's not 100% their fault. Everyone got onto the LLM bandwagon like it's "the thing" so even if they didn't believe it they sill needed something. Except an OS is not a chat interface, and LLMs do suck at stricter things.
Which is harder these days, software or hardware?
Each challenging in their own ways. The real challenge is that we need codesign and that’s the tricky part.
I really want to know why Apple refuses to put a cellular chip in the macbooks.
They are so scared about cannibalizing mac/ipad sales - they really really want people to own both.
Even the M4 Max MacBook, I tried in the stores were running like shit on Tahoe
[dead]
[flagged]
What I have seen with iPhones is that the ram has gone from 4gb to 12gb very quickly compared to how it went from 1gb to 3gb.
Apps used to use less ram but over the years apps have become big and more complicated. This is probably why iPhones feel sluggish because new iPhones have more memory and apps snap back faster as newer iPhones which also have faster storage and memory bandwidth to reduce latency of reading more data from the flash.
Batteries are also a problem as maintaining voltage is difficult for a 2-3 year old battery. An official battery swap at apple service for a 3 year old iPhone will make it run much better.
I used to believe (and sometimes I still do) that apple intentionally makes everything heavier to make old phones and devices feel slower but I don't think thats the case.
I think that more things are happening on newer phones and devices and that same task feels slower on older device. This happens are lot faster on iPhones and phones in general (a year or two) as opposed to Macs/computers which can show signs of aging in 4-5 years.
My 2018 intel computer feels very slow in 2025 running Gnome. No one slowed it down. It's just that the 2025 world of software is a lot heavier and 2026 will be even more and so on.
Apple has been proven to intentionally slow down older devices, but it's definitely not to inflate their profits. It's just a way to kindly preserve your old battery for you. And they try to keep it a secret from you so you don't get confused.
… Eh? It was neither. It was due to a design defect in a particular model; if voltage fell into a range that was perfectly possible with an aging but still functional battery, the SoC would shut off. The only viable software fix was to clock it down instead (there was an option to decline that and risk the abrupt shutoffs).
Not really sure what else they could have done there.
That's some new version of what happens, never heard of that before, do you have any prooflinks?
https://www.theregister.com/2017/12/20/apple_iphone_slowdown...
My old iPhone 7, before I eventually replaced it, would sometimes just die due to this as the battery aged (I kept the slowdown setting turned off). AFAIK it is _not_ a thing in any version after the 7 (or maybe 8?); certainly my 11 had a significantly degraded battery by the end (I kept it for four years), and didn't suffer this issue.
EDIT: Actually, I think this article is a _little_ inaccurate, or at least confusing:
> thus preventing the handsets from rapidly running out of juice and powering off.
IIRC the issue was, more precisely, that the SoCs had insufficient voltage smoothing to reliably tolerate full power draw at lowered voltages, and would shut off randomly. I assume the fix was, pretty much, more capacitors.
It's not a particular model. It's every model. And it's just interesting that no other manufacturer seems to have the same problem. iPhones are just too advanced, I suppose.
Apps are heavier because a lot of them do not use native code. It's all cross platform BS. And they include a lot of A/B code as well. Really wish Apple would nip that all in the bud.
My iPhone X worked fine for 7 years, even without a battery replacement. It still works just fine. I wanted a larger screen and better zoom lens, so I upgraded earlier this year but I absolutely didn't have to and didn't feel any pressure from Apple to do so.
n=1.
I've been using an iPhone 11 for 4 years now (also, reminder: the 11 was launched 2 years prior to when I bought mine). I replaced the battery earlier this year as it wouldn't last to the end of the day any more but besides that it's showing no slowdowns or any other issues.
Do you have iOS 26 on it? That pigdog is making my 15 Pro Max sweat and cry.
I have an iPhone 13 and haven't upgraded yet. Sounds like I should hold off.
I have an iPhone 13 Mini and upgraded is iOS 26 and it seems fine to me.
I also have a 2018 iPad Pro and put iPadOS 26 on it and I haven't had any issues on it either except sometimes my keyboard is slow to connect. I'm not sure if it's the software or hardware though.
I haven't really found anything that blew my socks off, and the number of "strange bugs" (not even talking about the UI complaints, just things like "touch stops working suddenly" and other weird things) is too damn high.
I'll probably wait for 26.1 then!
My SE has been fine with iOS 26.
I only just upgraded to iOS 18 recently. I'm unlikely to go to 26 unless there's a good reason to do so.
Never, ever, upgrade to any Apple OS until at least .1. .0 is _always_ broken.
i don't see what the big deal is with iOS 26. it looks a little bit different, everything now seems to have some degree of transparency but everything works the same.
They support their phones for years longer than any vendor. This has been widely understood for probably 10+ years at this point.
There's plenty of room for criticism without a blanket conspiracy that doesn't match what most can observe.
Support means that the manufacturer just still releases OS updates. But it says absolutely nothing about the quality of those updates: what if those updates simply degrade the situation? Every iPhone user I know says the same without conspiring with each other: it's better to stop updating to newer major OS releases for older iPhones.
No more than any other company.
> ...The <thing I own right now> is so powerful that nobody really needs to upgrade...
I keep hearing this since the Intel 486DX times, and
> Nobody will ever need more than 640K of RAM!
This is the first time I’ve gone four+ years without even a real desire to upgrade, I have a hard time figuring out even what would be faster.
Amusingly enough, adding more ports could do it.
They always release a slowdown update to destroy their older hardware. I don't know why you're even questioning it
I agree with your feeling that about Apple devices eventually getting updates to the point they becomes sluggish. I have just reached that point with iOS 26 and my iPhone 13 mini.
I am undecided in my thoughts about how malicious this is. Do people think that it is something like wanting to cram more features into the operating systems, and they are careless how it affects the earliest supported models? Or do most people think it is planned obsolescence?
Apple generally offer updates longer than Android, so is it more pronounced on iPhones than Android phones? I remember seeing similar slow-downs on Android phones in the past.
Apple generally offer updates for iOS for less time than Windows. I don't really have a feel for the difference between the two in terms of how much new versions slow down older hardware.
Obviously separating feature updates and security updates would be a way to address, and it's not possible that no one at Apple has considered that idea. They are a business and selling new products is unfortunately a disincentive pushing them away from doing that.
Apple was fined all over the world for intentional malicious software slowdown by different courts in many countries. Just google "batterygate". At this point this a proven fact that apple had been doing this. I am pretty sure they continue to do so. Why would they stop?
The slowdown occurs on systems that can't hold sufficient charge to reliably power the CPU to full anymore. If the battery can't supply the expected voltage, then the system simply shuts off. That is much worse than slowing down. This feature inarguably increased longevity—hardly what I'd expect from a "planned obsolescence" scheme.
They did make a mistake, though: they should have been up-front about it. They should have advertised it rather than hiding it away.
Or, better yet, asked people what they want: whether the phone should crash or slow down when the battery is choking.
I'd prefer a faster horse.
Meanwhile Ubuntu is still snappy on my original 2012 rMBP. It got a new screen, two new batteries, still has the last supported version of macOS installed if I want it. Still sparks joy. If only my fingers could keep the Ubuntu cmd and ctrl key functions properly mapped.
