Hacker News Reader

Comment by kokada | Hacker News Reader

> 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.

View on HN

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”.

Reply on news.ycombinator.com