[HN Gopher] Electron-based apps cause system-wide lag on macOS 2...
___________________________________________________________________
Electron-based apps cause system-wide lag on macOS 26 Tahoe
Author : STRML
Score : 223 points
Date : 2025-09-25 18:36 UTC (4 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| kccqzy wrote:
| https://github.com/electron/electron/issues/48311#issuecomme...
|
| If this comment is to be believed, it's not Apple's fault. It's
| the apps mucking around with the internals of AppKit.
|
| This example just happens to illustrate two of my least favorite
| software engineering practices: (1) despite one piece of code
| making a method private, another piece of code still overrides
| it/modifies it/calls it, an affront to the idea of encapsulation;
| (2) a piece of code has different behavior depending on the
| identity of a function, contrary to the principle of
| extensionality.
| wk_end wrote:
| "Not Apple's fault" is up for debate; even if Electron
| shouldn't be doing this, Apple arguably shouldn't be pushing
| out updates that cause issues with wide-swaths of software that
| users use regardless.
| tom1337 wrote:
| So you're blaming because they've changed a private API which
| electron not only used, but also seemed to have patched?
| asqueella wrote:
| No, for "pushing out updates that cause issues [with very
| common software]".
| smashedtoatoms wrote:
| As a dev, if you use a private method, you've just taken
| ownership of the problem. I suggested to you in our
| contract not to do it, and that it would likely not be
| supported, and you did it anyway. Fix your shit, common
| software or not.
| pavlov wrote:
| That's the principle that prevented Windows from making any
| meaningful progress for the past three decades.
| wk_end wrote:
| What? Windows made tons of progress while maintaining this
| principle and became the most popular operating system in
| the world. Are you trying to tell me that you believe the
| evolution of Windows from 1.0 all the way to 7 - the entire
| time trying to operate according to this principle -
| doesn't constitute meaningful progress?
|
| The recent stagnation of the OS has nothing to do with
| attempting to maintain backwards compatibility.
| acdha wrote:
| It's true that they've made some progress but my work
| laptop running Windows 11 still has UI elements from
| Windows 95/NT 4. The file system hasn't improved since
| then and the keyboard responsiveness is actually worse.
| BeOS on 90s hardware absolutely torches Windows 11 on
| things like UI responsiveness, ability to multitask
| without degrading UI performance, and the file system
| (not networking, of course, it wasn't perfect).
|
| I think it's fair to question whether the decisions
| around backwards compatibility have been worth the cost
| but I'd imagine they're already doing that. Enterprise IT
| departments love Windows but nobody else does, and the
| generation of people who grew up using iOS/Android and
| macOS/ChromeOS for school aren't going to jump at the
| chance to bring that enterprise IT experience into their
| personal lives.
| cyberax wrote:
| You can actually tell the old controls from the Win NT by
| how fast and responsive they are. They also properly
| follow the best practices by showing keyboard
| accelerators when you press "alt".
|
| It's the new stuff that is slow and unusable.
| 1718627440 wrote:
| And they also explain themself to the user. The new UI
| often doesn't tell you at all, what exactly you are
| modifying here, while the old often has paragraphs of
| explanation.
| wk_end wrote:
| > The file system hasn't improved since then
|
| The file system is a great example of how Windows has
| evolved, actually. Windows 95 was (initially) still using
| FAT16! NT4 was using NTFS 1.2, we're now on NTFS 3.1. To
| the file system itself MS added (per Wikipedia): disk
| quotas, file-level encryption, sparse files, "reparse
| points" (dunno), journaling, "distributed link tracking"
| (also dunno), "the $Extend folder and its files" (ditto),
| and better MFT recovery. Also, apparently not part of the
| file system itself: symbolic links, transactions,
| partition shrinking, and self-healing. And that's just
| what I gleaned from the History section on Wikipedia's
| NTFS article; I'm sure there's more.
|
| Apple specifically was much slower catching its file
| system up with Microsoft, despite their disinterest in
| backwards compatibility. And if Apple jumped ahead a
| little with APFS, well, NTFS holds its own just fine
| against APFS for 99% of users. And for when it doesn't,
| there's also ReFS, an entirely new next gen file system
| used on Windows Server, and is now slowly making its way
| onto the desktop.
| acdha wrote:
| Okay, I'll grant that links and mountpoints were good but
| NTFS is still missing integrity checks, fast queries,
| etc. For most users nothing had changed since the Clinton
| administration.
| sgjohnson wrote:
| You can still find applications written for Windows 3.1
| in the latest builds of Windows 11. Something regarding
| database drivers if I recall correctly.
|
| Now imagine if you could get rid of all that legacy crap
| to make it work in the first place. Microsoft CAN'T do
| that, because the entire premise of Windows is backwards
| compatability.
|
| Apple? They don't care. Killing 32bit apps? Just make an
| announcement saying that in 2 major macOS releases, macOS
| won't be able to run 32 bit apps. It cuts down bloat, and
| it cuts down on the potential attack surfaces for
| malicious actors.
|
| Obviously just about everyone would agree that Windows 1
| -> 7 was progress. I don't think you'll find too many
| people who'll say the same about Windows 7 -> 11.
| wk_end wrote:
| > Now imagine if you could get rid of all that legacy
| crap to make it work in the first place.
|
| What would be the consequence of this? What harm does
| this do? Would it be worth Spotify and Slack breaking
| when I upgrade my OS?
| jojobas wrote:
| > Now imagine if you could get rid of all that legacy
| crap to make it work in the first place.
|
| Yeah, and someone will wake from the dead and rewrite all
| the programs that run the world, written 20-40 years ago,
| that are to a large degree perfectly working under these
| compatibility layers.
|
| You should be eternally grateful to MS for dedicating
| tons of money and some of its best people to maintaining
| backwards compatibility.
|
| Apple can only afford it because pretty much nothing
| critical ever ran on macos.
| badsectoracula wrote:
| > Now imagine if you could get rid of all that legacy
| crap to make it work in the first place.
|
| That's easy to imagine: people would have zero reason to
| use Windows.
| cosmic_cheese wrote:
| Apple's attitude here is that it's an inherent risk of using
| private APIs, because it's not something they want devs
| doing. They don't facilitate it like MS tends to. Don't touch
| the stove if you don't want to get burnt.
| wk_end wrote:
| The person who's getting burnt is Random Officer Worker
| Joe, who just wants to run Slack and Spotify and who
| doesn't know a thing about Electron or private APIs, but
| knows that ever since upgrading their version of macOS
| things are running terribly. Apple's position is
| technically noble, but that doesn't help their users.
| cosmic_cheese wrote:
| The Electron maintainers should've considered that
| possibility before reaching for a private API. It's on
| the Electron's team's shoulders and nobody else's.
|
| If I were building a FOSS platform, I wouldn't give a
| second thought to third parties making use of my
| platform's private APIs. They're private for a reason,
| whether that be because they're not yet fully baked or
| because using them can have unintended consequences,
| they're not intended for public consumption. I especially
| wouldn't want somebody else's platform to depend on my
| private APIs, because I am then effectively locked into
| keeping that API frozen in time by the numerous others
| building on this other person's platform.
|
| It's generally poor practice to build upon such brittle
| things as under-the-hood tinkering anyway.
| Aaargh20318 wrote:
| > Apple's position is technically noble, but that doesn't
| help their users.
|
| The alternative doesn't help either. That's the approach
| Microsoft has taken and look what a mess Windows is
| because of it.
| viraptor wrote:
| > what a mess Windows is because of it.
|
| Can you point at any part of windows being a mess
| specifically because of backwards compatibility?
| dpoloncsak wrote:
| Sounds like Joe will direct his anger towards Slack and
| Spotify, and as a paying customer he has every right to
| be upset when his software doesn't work.
| wk_end wrote:
| I doubt he will - they didn't change, his OS did, they
| worked before, post hoc ergo propter hoc. Anyway, they're
| from different companies, how could they _both_ be at
| fault? If he even identifies them as related - he
| probably had them both running at startup and never quits
| them.
| Aurornis wrote:
| We've had developer betas of macOS Tahoe since June.
|
| Standard practice for any mobile or desktop software is to
| start testing on the betas as soon as they're available.
| Unless this was a last-minute change before the final
| release, it's on the software developers to use the betas to
| prepare their software for upcoming releases.
| Tteriffic wrote:
| Exactly. Who you blame depends on if it was introduced in
| beta 1 or RC.
| cosmic_cheese wrote:
| A good argument for allowing and working with minor platform
| differences instead of trying to micromanage every little
| aspect to force inter-platform consistency and/or perfect
| compliance with the mockup.
| x0x0 wrote:
| Nah, it's Apple's fault. Not regression testing against major
| apps is pure incompetence.
|
| Also, this in the comment:
|
| > _[a user] Please try any way of getting in touch with Apple
| engineers you can. As a project, we don 't have a better
| connection to Apple than you do._
|
| >
|
| > _One approach might be the engineer who replied to the
| Bluesky post that someone linked to above about the input
| issue._
|
| Pure incompetence. Major projects have no way to do anything
| but ping randoms on socials.
| bombcar wrote:
| This is downvoted, but it's true.
|
| It doesn't matter _who 's fault_ it is in some Aristotelean
| sense, what matters is the user upgraded to YOUR new OS, and
| now shit don't work.
|
| Raymond Chen and Microsoft got this, years ago. Joel talked
| about it. _You make shit work_ , even if it's the software
| being a fuck.
| kridsdale3 wrote:
| No time to do that when you need to re-do the entire UI of
| 100 apps for no good reason other than to make an iMac
| indistinguishable from an iPad.
| marcosdumay wrote:
| > despite one piece of code making a method private, another
| piece of code still overrides it/modifies it/calls it, an
| affront to the idea of encapsulation
|
| That's inherent on the way current computers manage the memory.
| And I don't know if the gains are enough to pay for the loses
| of guaranteeing encapsulation.
|
| One could reach for static analysis, but that would imply some
| restrictions on the machine's assembly. Those are probably
| worth it.
|
| > a piece of code has different behavior depending on the
| identity of a function
|
| I have written my quota of "find the latest caller on the stack
| with property X, verify if it has access", on different
| languages. Some times a function can't in any way be just a
| function.
| btown wrote:
| There's also the good old use case of "am I dealing with a
| subclass that overrode the superclass's implementation of the
| method."
|
| How do you distinguish between a superclass that always
| returns null/noop, vs. a subclass that _happened_ to return
| null _in this specific case?_
|
| Sometimes this is useful/vital for setting expectations to
| the user what functionality the instance is likely to have.
|
| Now, you could refactor everything to have the superclass's
| implementation either throw a NotImplementedError, or return
| a sentinel value... but changing every call site might be a
| gargantuan task. Similarly, adding static metadata to every
| subclass might not be feasible. But checking whether the
| function's (pre-bound) identity is different is a very easy
| hack!
|
| Ironically, this might indeed be exactly what Apple is doing
| here, and they're doing it in a tight loop.
| 1718627440 wrote:
| Couldn't you use isinstance(), which would not be a hack?
| ryandrake wrote:
| I don't understand what goes through the developer's mind. A
| method is marked as private. It's documented as not to be
| used by developers. Further documentation says that using it
| may break your application in strange ways now or in the
| future. Despite all this, the developer concludes: "yea, I
| think it's a good idea to use this API!" Then, later when
| something breaks, it's Shocked Pikachu all around.
| stalfosknight wrote:
| And there are people who's default setting is to hate/blame
| Apple because it's fashionable to do so and they are
| defending not just the use of but also overriding an API
| explicitly marked as private.
|
| I don't get it.
| Wowfunhappy wrote:
| Apple does also break public APIs, so it goes both ways.
| I will blame Apple when they are blameworthy and not when
| they are not.
| cyberax wrote:
| Yeah, but you HATE how the system behaves because some
| great spark at Apple thought that corners must always be
| _this_ rounded.
| thfuran wrote:
| The alternative to using private methods or reflectively
| mucking about with library/platform internals isn't always
| "do the same thing but with only public API"; it's
| sometimes "you can't possibly fix the bug or implement the
| feature that you want to". It sure does increase
| maintenance burden though.
| bigstrat2003 wrote:
| > it's sometimes "you can't possibly fix the bug or
| implement the feature that you want to"
|
| Yes. It is, and that is what any responsible person
| should choose.
| thfuran wrote:
| So you'd tell customers "No, I'm not fixing that bug
| because doing so would offend my aesthetic sensibilities.
| Yes, I know you have a support contract, but I simply
| refuse to address your problem even though I could"? Or
| maybe you'd phrase it a little differently in public.
| toast0 wrote:
| Ok, but
|
| > // By overriding this built-in method the corners of the
| vibrant view (if set) will be smooth.
|
| If you don't override the built-in method, the corners
| won't be smooth. Jagged corners cause thousands of eye
| injuries every day.
|
| Using (or overriding) private APIs comes with risks, but
| sometimes it's the only way to get things done. Of course,
| it comes with consequences too. Sometimes vendors test
| their new releases with commonly use applications and reach
| out when they've changed things and breakage results, but
| testing releases isn't webscale.
| runjake wrote:
| _> I don't understand what goes through the developer's
| mind. _
|
| I'm not defending anyone here, but sometimes it's to work
| around bugs in public APIs that never get fixed. And
| sometimes it's because some perceived needed functionality
| isn't exposed in public APIs.
|
| They figure "It'd be a lot easier to use this private API.
| We can just fix it if it breaks.", not really realizing the
| ramifications, for example a lot of apps use older versions
| of Electron -- some even EOL.
|
| Is the Electron team now going to backport this fix to
| several versions back? Sounds... involved.
| porridgeraisin wrote:
| > I don't understand
|
| Well. This is hardly the funniest example then. Check
| _this_ one out:
| https://github.com/reactjs/react.dev/issues/3896
| tclancy wrote:
| I get it but a lot of the war stories from Raymond Chen's
| blog https://devblogs.microsoft.com/oldnewthing/ were about
| helping major corporations unscrew something that had
| relied on a private Windows API because there hadn't been a
| good way to do it. I would guess most cases of people
| choosing to rely on a private method are laziness or lack
| of knowledge about "the right way" (or call it bad
| documentation), but not 100%.
| whywhywhywhy wrote:
| Apple has to take some of the blame from this, MacOS
| without Electron apps is a much less useful proposition. If
| they knew they were going to change this API in this
| release it would have made sense to reach out and offer a
| public way to Electron.
|
| End of the day the needs of users running Electron apps
| outweighs whatever opinions the internal Apple team has
| about their APIs
| urbandw311er wrote:
| Absolutely not. Apple has zero responsibility to anybody
| for changing a private API. That's the whole point of it
| being marked private.
| mvdtnz wrote:
| > Then, later when something breaks, it's Shocked Pikachu
| all around
|
| This isn't really true. When something breaks it's
| generally "darn, we knew it would happen eventually".
| kccqzy wrote:
| I have written my share of "inspect caller and do things"
| too. I still don't like that.
| marcosdumay wrote:
| Personally, at this point I blame that universal assumption
| that every piece of code inside a program has the same
| reliability, trustworthiness and disclosure properties. At
| some point we'll have to burn down every bit of software
| infrastructure and build it new with some care about
| security.
| 1718627440 wrote:
| > That's inherent on the way current computers manage the
| memory.
|
| You can trivially do that today by telling the linker to
| discard this symbol. Sure it's still not hardware isolation,
| but now the caller needs to disassemble the binary and
| hardcode locations. When its inlined before, then you aren't
| even able to do this.
| snarfy wrote:
| It's all pretty terrible. For problem (1) why does the language
| allow it? And why are they doing it this way? Did Apple not
| provide an official way?
| cosmic_cheese wrote:
| With Objective-C's nature as a dynamic language, there's no
| way to make APIs fully private and unusable to third parties.
| Despite heavily embracing Swift in recent years, much of
| AppKit and UIKit are still written in Objective-C.
| SkiFire13 wrote:
| > (2) a piece of code has different behavior depending on the
| identity of a function, contrary to the principle of
| extensionality.
|
| Note that most definitions of extensionality don't consider the
| number of steps to achieve the result as an observable
| property, although in practice it is.
| cyberax wrote:
| Abuse of private APIs means that your public API is incomplete.
| And that people dislike how your system behaves so much, that
| they're willing to muck with its internals.
| stalfosknight wrote:
| No, it means some people are doing it wrong either because:
|
| 1. They don't know how to do it the right way
|
| or
|
| 2. They can't be bothered to do it the right way
|
| #1 I can understand. We all make mistakes as we learn and
| grow as developers. #2 is just arrogance / laziness on the
| part of the developer. Compounding it by blaming the platform
| owner that clearly and explicitly told you not to go that
| route is gross.
| bigstrat2003 wrote:
| No, it means that people think they know better than to
| listen to the warning.
| 1718627440 wrote:
| > (1) despite one piece of code making a method private,
| another piece of code still overrides it/modifies it/calls it,
| an affront to the idea of encapsulation;
|
| That's why its a good idea to strip a symbol or provide a
| linker script. This way you can also properly version the code.
| huijzer wrote:
| Don't Electron-based apps cause lag on basically any system?
| GuinansEyebrows wrote:
| Perhaps, but this specific case appears to be related to
| (ab)use of a private API on Electron's part.
|
| https://github.com/electron/electron/issues/48311#issuecomme...
| nkozyra wrote:
| I know it's a defacto complaint to leverage against Electron
| apps, but memory usage notwithstanding, I've never run into
| much lag issue on any major Electron app.
| ToucanLoucan wrote:
| It depends. Numerous times when internet is spotty Slack and
| Discord both on different occasions have brought my systems
| to a _halt_ until they can complete whatever task is stuck
| waiting (or I force close them).
|
| It's really fucking obnoxious that somehow a goddamn web app
| in a wrapper is managing to cause system wide hangs.
| Vilian wrote:
| True, i'm gonna start limiting electron apps CPU and IO
| percentage to not halt everything
| nsriv wrote:
| I think that's probably a recipe to hit the limits more
| often and end up being more frustrating, depending on
| your hardware.
| 1718627440 wrote:
| Can't you interrupt them (aka SIGSTOP) instead? Then you
| could resume them, instead of reopening them and
| potentially using state.
| arcfour wrote:
| Surely there is a more effective way to write an app than to
| bundle an entire end-of-life browser and Node.js runtime into
| a 600MB monstrosity.
| hluska wrote:
| Of course there is, but not every decision in computing is
| (or should be) about raw efficiency.
| paxys wrote:
| Electron apps don't have to be 600 MB. VS Code is an entire
| fully-featured IDE and is a 90 MB download.
| shawn-butler wrote:
| VS Code package in my applications folder is 600+ MB.
|
| The Electron Framework.framework it contains is 400+ MB
| alone. I don't understand where you come up with your 90
| MB figure?
| ethmarks wrote:
| The VSCodeUserSetup file from
| https://code.visualstudio.com/download is in the 90MB
| range.
|
| Perhaps this file is just the installer and the actual
| system files are much larger? Or maybe your 400MB figure
| comes from a bloated install? Just speculating here.
| mcintyre1994 wrote:
| I've never noticed anything before, though I'm sure their
| performance is worse than native apps. I think the M series has
| so much headroom at this point that you can get away with a
| lot.
| nottorp wrote:
| It's in the runtime specifications, I think.
|
| "Application should use all cores and all available memory."
|
| In the past few years, the only applications i've seen run amok
| with memory usage at least were of course Electron based.
|
| However, note that this problem is on Mac OS "users had too
| much contrast so we ruined it" 26 Tahoe. It's part of the early
| adopter experience.
| altairprime wrote:
| No, they typically do not interfere with performance at the OS
| level. They may be wasteful with resources that are limited --
| CPU/GPU/RAM/IO -- but for them to interfere with system
| function at this level is not the usual bloatware problem.
| schmidtleonard wrote:
| Discord and VSCode work smoothly for me on an M4 MBP -- not sure
| if it's a compatibility difference or just performance hiding the
| problem, though.
|
| But Spotlight file search is completely broken, rebuilding the
| index doesn't help, and web results are the only thing it
| returns. After 20 years of intense research, Apple finally caught
| up to Microsoft in race to make search broken and useless.
| jama211 wrote:
| Search works great for me, I'm sorry it broke on your machine
| but it needs to be broken for everyone to be on Microsoft's
| level
| schmidtleonard wrote:
| Haha fair enough, and now it's fixed on my machine but
| Windows Search is still asking if you'd like Bing with that.
| jama211 wrote:
| Hahaha always with the bing
| navigate8310 wrote:
| It's funny, bing literally means disease in Mandarin.
| duskwuff wrote:
| > But Spotlight file search is completely broken, rebuilding
| the index doesn't help, and web results are the only thing it
| returns.
|
| I had the same issue; killing Spotlight processes fixed it. (A
| reboot would probably do the job too.)
| schmidtleonard wrote:
| Hey it worked. Thanks!
|
| (Killing the process, ofc)
| tw04 wrote:
| M4 works great for me. M1 Max with 64gb of memory consistently
| has issues.
| JumpCrisscross wrote:
| For what it's worth, my 2020 M1 normal is chugging along like
| the champ that it is :).
| jeffbee wrote:
| The instructions for fixing a Mac's corrupted spotlight index
| are amazing. I was planning to do it earlier this year, but the
| number of manual actions was just too ridiculous. Then, after
| it was broken for months, it spontaneously started working
| again.
| rpgbr wrote:
| It's a little heterodox, but not hard at all[1] and it takes
| literally less than a minute to trigger the rebuilding.
|
| [1] https://support.apple.com/en-us/102321
| jeffbee wrote:
| The ones I was reading involved recovery mode and editing
| inodes.
| brailsafe wrote:
| It's very possible that the hardware performance is hiding the
| issue. I upgraded from my 2020 intel 13" mbp (16gb of ram,
| 4-core i5) to 16" M4 Pro for a variety of reasons, but the
| basic processes of MacOS were making it nearly inoperable
| periodically throughout the day. I gifted the old one to my gf,
| and I can hear the fans spin up from across the apartment when
| nothing else is happening but indexing. I recall regularly
| being irritated that I'd just have to wait a while for the
| indexing process to finish before getting anything done. Idk
| wth is going on, but it puts far more strain on the system than
| anything else I could throw at it except games and Docker. Even
| ProTools doesn't seem to produce audible noise unless a bad
| plugin or a rendering is taking place.
|
| Aside from that, the Settings menu memory leak (or whatever it
| the problem is) is very much more apparent on the older mac
| than it is on the new one, but it's still reproducible. Neither
| computer is running Tahoe yet, these issues were already
| present, but based on on your comment, they might now be
| functionally worse in addition to being a performance and user
| experience joke.
|
| My new Mac is still amazing hardware-wise, and since those
| issues seem to just be compensated for, perhaps by having
| efficiency cores that they're able to delegate background
| processes to, but the sluggishness and in-adequacy of frontline
| processes and apps must be embarrassing for what I presume to
| be smarter engineers than myself who probably just don't get to
| allocate time or energy toward any of the problems, especially
| with things like Xcode and SwiftUI also having major issues,
| and the mac being a relatively small market.
| josephg wrote:
| I make a habit of turning off spotlight almost entirely.
| Search never returns what I want anyway, and the juice isn't
| worth the squeeze.
|
| Go into preferences, spotlight and you can add folders to
| exclude from indexing. I add my home directory and most of
| the system directories and that more or less fixes the issue.
| rpgbr wrote:
| That's the way to go. Who the hell searches for reminders
| or podcasts or anything besides files and apps on
| Spotlight?
| efitz wrote:
| I was just noticing the stuttering and lag but I hadn't tracked
| it down to electron yet.
| OGEnthusiast wrote:
| FWIW haven't experienced this at all on an M4 Max (with Slack and
| VSCode open).
| Etheryte wrote:
| To be fair, the M4 Max is such a beefy machine that you could
| do a lot of things wrong and still not notice it.
| OGEnthusiast wrote:
| True, but looking at Activity Monitor I don't see any CPU or
| GPU spike when having an Electron app open and scrolling in
| Chrome (vs scrolling without any Electron apps open)
| STRML wrote:
| Watch your power usage. With large windowed VSCode or
| Cursor, you will see far higher CPU and GPU usage by
| WindowServer and more system power consumption. It's easier
| if you track it with stats.app.
| masklinn wrote:
| Apparently the issue has to do with transparencies (shadows
| and straight up transparency), so could be a question of
| capabilities not capacity e.g. older gens have less range
| and some non-default require falling back to software
| whereas newer gens can keep to hardware.
| bdash wrote:
| Strangely the WindowServer issue is a constant issue on my
| personal MacBook Pro, but I've never seen it on my identical
| work MacBook Pro. It seems like there's some other factor that
| is necessary to trigger the problem.
| kace91 wrote:
| I'm surprised to see so little pushback in press to iOS/macOS 26.
|
| I've been part of the public beta and it's been so weird going
| from "this sucks but it's a first beta" through "it really isn't
| improving much as time goes by" to "we're a week from launch,
| there's no way they release this after the Apple Intelligence
| fiasco".
|
| And yet here we are. Performance issues, ui inconsistencies and
| garish design everywhere.
| coolspot wrote:
| Yeah, screen time for kids is absolutely broken in iOS 26.
| Fwirt wrote:
| I'm glad I'm not the only one experiencing this. They
| absolutely destroyed Guided Access in iOS 26 to the point of
| borderline non-functionality. I've had the system idle-sleep
| while in Guided Access and wake to a lock screen that I was
| unable to interact with in any way, including turning off
| guided access. Softlocked my device for about 5 minutes until
| panicked swiping and button mashing managed to snap it out of
| it. There appears to be a race condition with the lock screen
| and home screen, if the device idle sleeps in guided access
| mode then about 50% of the time it wakes to the home screen
| instead of the app. Sometimes waking it on iOS shows the lock
| screen for a brief second before the app starts. Also,
| exiting guided access sometimes doesn't recolor the apps on
| the home screen so it still appears as if all apps are
| disabled. Not to mention that they reclassified the pen
| settings dialog as a "software keyboard" meaning that in
| order for my kids to draw with the Apple Pencil I also have
| to allow them to enter text now. None of these were issues on
| iOS 18.
| MBCook wrote:
| I think you mean "since release".
|
| Hasn't it always had horrible problems? I've never heard a
| good thing about it in use.
| Fwirt wrote:
| I used it from iOS 15-18 and it always worked great. We try
| to limit our kids' iPad use to drawing in Freeform and the
| occasional edutainment app, and I never had issues with
| them escaping Guided Access or it causing lockups. The fact
| that I can barely trust it to work properly on iPadOS 26 is
| a huge disappointment for me.
| MBCook wrote:
| I've never used it myself (no kids) but I've long heard
| tales of kids being able to get around it, it miscounting
| time used allowing too much use, etc.
|
| It sounds really nice for the intended purpose, just not
| reliable for many.
| coolspot wrote:
| It's just getting worse with each new iOS release. For
| example before iOS 18, screen time requests from kids would
| come as notifications, now they are coming in as iMessages,
| polluting history of your actual conversations, so you
| can't have functional group chat with your kid & parents.
|
| Now in iOS 26 they messed up calculation of how much screen
| time is spent, so an app can have limit of 3hrs/day and
| still lock up after just first 9 minutes of screen time
| spent in that app in a day.
|
| It seems like they have zero QA.
| _0xdd wrote:
| I'd hate to suggest this, but I'm concerned that outlets are
| hesitant to critize Apple for fear of them losing access.
| kace91 wrote:
| That would make sense for the mainstream outlets, but I'd
| expect a large number of influencers jumping on the bandwagon
| of "apple in hot water!!".
| wswope wrote:
| > Performance issues, ui inconsistencies and garish design
| everywhere.
|
| Hasn't that been Apple's norm for a few years now?
|
| Not trying to land a cheap dunk here; I've honestly been
| running into rough edges and bad design with every major
| release for a long time.
| nixpulvis wrote:
| Yep
| kace91 wrote:
| >Hasn't that been Apple's norm for a few years now?
|
| Not to this degree.
|
| I've had 3 memory leaks in native apps, including the
| calculator. There's basic alignment errors pretty much
| everywhere. In many places text can become fully unreadable
| (black on black, white on white, text over a transparent
| background with overlapping text below...).
|
| It's not slightly lowered quality, it's the kind of
| inconsistency you expect mixing custom launchers and icon
| packs.
| Fwirt wrote:
| I was going to wait for a few bugfixes until I upgraded, but I
| was forced to update to iOS 26 because the AirPods Pro 3 that I
| bought required it for some inexplicable reason (which I didn't
| know until I tried to pair them). The AirPods are just
| fantastic in every way and a huge leap forward, I don't regret
| buying them for a second. But sheesh, none of the OS updates
| were ready for release. I found 3 obvious bugs (non-functional
| UI elements, invisible labels due to incorrect handling of dark
| mode, soft locks caused by guided access) not to mention a
| distinct pause when unlocking the device, GPU issues with
| Safari. It seems like the pendulum has swung from Apple making
| mediocre overpriced hardware and reliable software, to making
| best-in-class hardware and garbage software. I'm hoping that
| with the end of Intel support we get a "Snow Leopard" style
| polish and bugfix of the entire stack, but with their recent
| track record it seems unlikely. It's just inexcusable for a
| company with Apple's focus on consumer products and market cap.
| At least Microsoft has the excuse that they have a sprawling
| empire to oversee.
| b_e_n_t_o_n wrote:
| I upgraded on launch and didn't notice anything too wrong. I
| like the UI and performance seems fine?
| pier25 wrote:
| Tahoe is the worst macOS release I've ever experienced in 20
| years. I think not even Yosemite was that bad.
| paxys wrote:
| You are describing every single macOS release. I still remember
| their permissions disaster which broke the majority of critical
| apps in people's workflows at launch. It's always best to wait
| a few months to upgrade.
| kayodelycaon wrote:
| It's possible that the majority of people are fine with it. I
| thought it would hate it but I love iOS 26. It adds much needed
| depth and allowed me to turn off accessibility options.
|
| - Button Shapes: Buttons actually look like buttons.
|
| - Reduce Motion: Animations are a lot more fluid and the
| parallax effects are more subtle. They don't trigger motion
| sickness like the previous ones did.
|
| - Larger Text: The worst areas of the UI have better contrast.
|
| - Reduce Transparency: While there's more transparency effects,
| they're a lot better.
|
| - Increase Contrast: If I do need to turn this back on it is a
| much better integrated effect than previous version.
|
| The changes in macOS 26 are half-finished. Anything with raised
| glass looks like plateaus in the middle of a flat desert. Only
| half the apps have the new rounded corners on window and they
| do not match the rounded corners in the rest of the interface.
| They even cut off parts of the interface like the bottom of
| every scrollbar.
|
| It's disappointing. I loved Windows 7's aero theme.
| rpgbr wrote:
| I'm doing my job: https://manualdousuario.net/en/liquid-
| glass-2/
| altairprime wrote:
| Notes from the Google bug tracker linked by the GitHub issue:
| applying this command to each Chrome/Chromium app impacting your
| system will workaround the underlying macOS resource leak (EDIT:
| which only occurs when Electron mucks with private APIs to fake
| having native UI): defaults write
| com.google.Chrome NSAutoFillHeuristicControllerEnabled -bool
| false
|
| https://issues.chromium.org/issues/446481994#comment17
|
| That command's equivalent is being patched into Chrome and will
| have to ripple downward into Electron apps; directing complaints
| to each electron app impacted with a link to the relevant Google
| issue workaround will give them sufficient data to mitigate it,
| if they bother to.
|
| Apple is already aware --
| https://x.com/ian_mcdowell/status/1967326413830472191 (apologies
| for the Twitter link, but it's an Apple employee). EDIT: Someone
| else has traced the issue to Electron messing with internal OS
| APIs! Courtesy of https://news.ycombinator.com/item?id=45377253
| --
|
| > _It turns out Electron was overriding a private AppKit API
| (_cornerMask) to apply custom corner masks to vibrant views._
|
| ps. This issue was discussed a week ago here:
|
| https://news.ycombinator.com/item?id=45292019
|
| pps. Manually applying this workaround without scheduling its
| future removal has a slight but non-zero risk of someday breaking
| OS-linked autofill in your electron apps in weird or unexpected
| ways.
|
| ppps. I don't work for anyone, school for another three years
| minimum.
| ThePowerOfFuet wrote:
| >hxxps://x.com/ian_mcdowell/status/1967326413830472191
| (apologies for the Twitter link, but it's an Apple employee)
|
| https://xcancel.com/ian_mcdowell/status/1967326413830472191
|
| FTFY :)
| altairprime wrote:
| "And yet", she persisted, "my apology remains necessary."
| mikamika83 wrote:
| GPU load bug and Autofill bug are two separate, completely
| unrelated issues.
| altairprime wrote:
| I'm happy to refer to a better workaround if you have one?
| mikamika83 wrote:
| 1. workaround for high GPU load by Electron apps (what this
| HN thread is about) -- see the command here: https://github
| .com/electron/electron/issues/48311#issuecomme...
|
| 2. unrelated workaround for scroll bug - defaults write
| com.google.Chrome NSAutoFillHeuristicControllerEnabled
| -bool false
| altairprime wrote:
| Too late to edit now, but yep, the launchctl headless
| workaround works around Electron lagging the system, and
| the scroll bug works around macOS lagging the system.
| Thanks!
| nntwozz wrote:
| I'm a simple man, I see Electron I don't install.
| reaperducer wrote:
| Awesome if you're a one-man-band.
|
| Not awesome if you're in a large company where you have to
| communicate with others and don't get to choose the medium.
| modeless wrote:
| I find Slack and Discord to work fine in browser tabs and
| never felt the need to install their desktop apps.
| VSCode/Cursor is the only Electron app I felt actually
| provided value.
| rvz wrote:
| Well, that's...Electron for you.
|
| The most inefficient solution (in both space and time complexity)
| being suggested to build desktop apps is now shown to be causing
| widespread sluggishness.
|
| So much for interviewing developers for algorithms and data
| structures. Also Rust won't save you or make Electron faster
| either.
| IgorPartola wrote:
| 1. This is about a specific bug, not about Electron in general.
|
| 2. What better cross platform GUI alternative do you suggest?
| SBArbeit wrote:
| Avalonia. https://avaloniaui.net/platforms
| ttoinou wrote:
| The most inefficient solution (in both space and time
| complexity)
|
| Those are not the only qualities / metrics to optimize for.
| Developer eXperience, cross platform, open standards, easy
| compatibility with websites, easiness to keep updated etc. can
| be far more important
| IlikeMadison wrote:
| >Developer eXperience
|
| if all you can create are electron apps then you are not a
| developer.
|
| >cross platform
|
| many programs are cross platform, without the need of
| Electron.
|
| >open standards
|
| ???
|
| >easy compatibility with websites
|
| Electron isn't necessary, e.g. Telegram.
|
| >easiness to keep updated
|
| not Electron exclusive
|
| Electron exists for lazy "programmers" to make their products
| as fast as possible, without caring for code quality and
| their customers experience. This is why managers love it, it
| saves money: you don't need to hire proper software engineers
| nor allocate an appropriate amount of time to develop and
| maintain your product.
|
| Electron is part of the enshitification of the web and the IT
| in general.
| bigstrat2003 wrote:
| Developer experience is _never_ more important than the
| quality of the end product. The goal is to make good
| software, not to have the easiest time possible making
| mediocre to bad software.
| boomlinde wrote:
| For most commercial endeavors, the goal is to make money.
| If you're lucky, that goal is somewhat aligned with making
| good software, but in practice there's always a compromise
| between quality and development cost.
| c-hendricks wrote:
| It's not limited to Electron applications:
|
| https://github.com/neovide/neovide/issues/3225
|
| Other Tahoe issues with non-Electron apps:
|
| https://github.com/zed-industries/zed/issues/33182
|
| https://github.com/wezterm/wezterm/issues/7255
| mrtesthah wrote:
| This might be the fix: https://github.com/ghostty-
| org/ghostty/pull/8625/commits/431...
| mikamika83 wrote:
| GPU load bug and Autofill bug are two separate, completely
| unrelated issues.
| c-hendricks wrote:
| Correct! That's why I listed them under "other". One seems to
| be their new SMS 2FA functionality causing high CPU usage,
| the other seems to be private window APIs causing high GPU
| usage.
| bdash wrote:
| This affects some of the most widely used applications on the
| platform, including "productivity" applications such as Slack
| that Apple uses internally. How did no-one at Apple notice this
| and do something about it prior to macOS 26 being released?
| cosmic_cheese wrote:
| I stopped using the Slack Electron wrapper as soon as Safari
| added support for "installing" web apps (File > Add to
| Dock...). Wouldn't be surprised if people within Apple did
| similar.
| bombcar wrote:
| Mind blown, this may actually be freaking useful ...
| bdash wrote:
| I'd sorta hope they are testing widely-used applications in
| the way that typical end users will experience them before
| releasing a new OS version.
| kccqzy wrote:
| I actually did that as soon as Safari added a pinned tab
| feature. I remember doing this as early as 2016.
| electric_muse wrote:
| Anyone ever experience Zoom meeting lag that reproducibly
| connects with receiving a Mac notification?
|
| I've had this issue on my M1 and now my M4 mac for about a year
| now, and I can't figure it out. Uninstalling and reinstalling
| hasn't helped.
|
| Literally, someone can reliably send me a slack notification in a
| meeting (even when DND is on) and cause my Zoom outbound video to
| get gummed up.
|
| Edit: I ask because I wonder if it has to do with this.
| trothamel wrote:
| It seems odd that Apple could release an update that breaks
| common software, and not go to the trouble of at least contacting
| the developers of the software and discussing the issue.
| cjk wrote:
| Before I left Apple ~10y ago, it was pretty common to drop
| linked-on-or-after hacks into AppKit and UIKit to keep popular
| software chugging along. Assuming they're still doing that sort
| of thing, this was either missed or deemed not high-enough
| priority to add such a check (or maybe one was added, and the
| only reason this issue has been noticed is because Electron and
| Electron apps are now being built against the macOS 26 SDK).
| vahid4m wrote:
| Just imagine you are investigating a bug and everyone is trying
| to express their opnion on whose fault is this. What happened to
| not having a blaming culture?
| wg0 wrote:
| If I'm not wrong it affects VS code hence Cursor, Kiro etc.
|
| At least I notice fan going jet speeds with VSCode lately.
| system7rocks wrote:
| How difficult would it be just to switch to Swift for some of
| these apps?
| kridsdale3 wrote:
| You're talking about adding at least $10M to the budget and a 2
| year lead time for each of these companies.
| mobiledev2014 wrote:
| Without question worth it for the big CO's like salesforce
| (market cap $230B) and MS (market cap $4T)
| wiseowise wrote:
| Electron haters are going to have a field day over this
| (obviously it's not an electron issue, but why they care?).
| urbandw311er wrote:
| Joke's on them, turns out that it is an electron issue.
| urbandw311er wrote:
| Another great reason not to have upgraded to macOS 26.
| alberth wrote:
| This was fixed in Chromium yesterday, credited to @mitchellh
|
| https://xcancel.com/mitchellh/status/1970944369336475713#m
___________________________________________________________________
(page generated 2025-09-25 23:01 UTC)