I'm curious as to how Slack was/is still able to get updates out despite clearly relying on electron. Setting aside whether one agrees with Apple on this move or not, I would be outraged if they are playing favorites with a select few high-impact electron apps that they don't want off their store due to the associated bad press it would garner them.
Electron apps cannot be submitted to the Apple store
161–170 of 441 posts
Re: Electron apps cannot be submitted to the Apple store
#162Well, why the hell is electron/chromium using private APIs? That seems like the real problem here...
I started searching for the private identifiers listed in the blog post and ran across this document describing Chromium's Mac compositor: https://www.chromium.org/developers/design-documents/chromiu... Technical details aside, it describes two methods of performing delegated rendering on Mac. One uses public APIs and causes a "reduction in performance and increase in GPU power consumption." The other uses the revers…
IANAL, so I would need someone to explain to me how this differs from Netscape's claims against Microsoft in the 90s.
Because it seems pretty similar.
Also, I wonder if this was code inherited from WebKit, possibly even from Apple engineers.
Re: Electron apps cannot be submitted to the Apple store
#163Electron apps can be submitted to the Apple store...
Slack has recently been updated for example.
This seems to only affect some developers, especially electron <= 5
Re: Electron apps cannot be submitted to the Apple store
#164Earlier quoted context omitted.
Microsoft didn't ban anyone for using undocumented private APIs because they couldn't, not because they chose not to. Apple, or Microsoft for that matter, would do the same thing here, because the locked down platform is more valuable/profitable then an open platform. Developed for Android - at least you can have your app sideloaded if the platform owner decided to remote you. Or better, make your app a progressive w…
> Microsoft didn't ban anyone for using undocumented private APIs because they couldn't, not because they chose not to. Sure they could have, they had a code signing platform since the mid 90s and could have locked API access only to apps signed by them. They didn't because it would have been pointless not because they couldn't figure out how.
Code signing does not do what you apparently think it does. They can’t block it unless it’s a windows store app/universal app, which is sandboxed. And that’s exactly what they do for those apps. Tim Sweeney ranted about this quite vocally!
Re: Electron apps cannot be submitted to the Apple store
#165Re: Electron apps cannot be submitted to the Apple store
#166Re: Electron apps cannot be submitted to the Apple store
#167> I did write back to Apple trying to explain that I am using Electron and I can't really change any of these public-framework usage Yeah. So? By linking a framework that's using private APIs, this becomes your problem now. And Electron's problem, by extension. Go bug them, not Apple.
How short are memories. I remember how Microsoft was vilified for supposedly having secret Windows APIs that allowed Microsoft apps to get better performance. That was mostly made up and even if such APIs existed, any program could have used it. Even at the height of corporate arrogance Microsoft didn't dream of banning developers for using undocumented APIs. Apple seems intent on becoming more evil than Microsoft ev…
Apple wants to own the user's machine. They want to make it so their computers run only the software they approve. This is already true for iOS and it's only a matter of time before it also becomes true for macOS. It's the opposite of a free system.
Giving up software freedom for "ease of use" seemed like a fine deal at first but then Apple started making decisions that don't quite align with what neither users not developers want. Apple has already started taking advantage of their position as the gatekeeper of the platform.
Re: Electron apps cannot be submitted to the Apple store
#168Earlier quoted context omitted.
> because the developer community Which is not a homogenous group, both in ideals and for why they'd upvote a submission like this. > this rejection, and it's backing policy to be nonsensical They're different things. I personally think the rejection is perfectly sensical in the context of the backing policy, with which I don't fully agree.
You must be chugging the koolaid to believe developers LOVE Apple's policies, or enjoy getting their hard-work rejected by a bot, or getting shamed by an overzealous Apple employee on HN. Developers are homogeneously unappreciative of Apple's treatment of them. They just don't have any leverage, or opportunity to negotiate
Who are you going to blame when applications start breaking because Apple removes or changes the functionality of a private function? [1] without warning?
When you are writing any software that has a public API you should feel no obligation to change the functionality or completely remove a private method without warning.
[1] I refuse to call it a private API. An API is public documentation of the inputs and expected behavior of a dependency. It should be a completely black box how that functionality is implemented.
Re: Electron apps cannot be submitted to the Apple store
#169Is this an attempt by Apple to increase robustness by reducing dependencies on unsigned binaries?
I feel Apple is moving into somewhat dangerous territory. If the intent, as documented by internal messages and emails, is purely to protect the consumer by forcing people to use only public APIs, that's one thing. But, if Apple is trying to apply anticompetitive behavior against certain technologies, if this rule is selectively enforced, if there is any bad smell or anything dirty about this process, then Apple is i…
This is nothing new, developing iOS and MacOS apps you use public APIs and never use private ones. I have never had any desire or need to use something not documented/public in anything I have built. You'd have to be pretty dumb to depend on something that Apple can and will change whenever they want. When I worked at Apple 25 years ago I remember the source code to the old MacOS was riddled with "if Word version 4.05 do this, if 4.15 do that" to try and avoid breaking Microsoft's apps". It was a nightmarish attempt to ensure buggy software didn't suddenly stop working. I don't blame Apple for wanting to avoid this kind of pain today.
Re: Electron apps cannot be submitted to the Apple store
#170Earlier quoted context omitted.
I started searching for the private identifiers listed in the blog post and ran across this document describing Chromium's Mac compositor: https://www.chromium.org/developers/design-documents/chromiu... Technical details aside, it describes two methods of performing delegated rendering on Mac. One uses public APIs and causes a "reduction in performance and increase in GPU power consumption." The other uses the revers…
IANAL, so I would need someone to explain to me how this differs from Netscape's claims against Microsoft in the 90s. Because it seems pretty similar. Also, I wonder if this was code inherited from WebKit, possibly even from Apple engineers.
Netscape’s claims had nothing to do with MS not allowing private APIs. MS forbid OEMs from shipping Netscape of they wanted to license Windows.
The definition of anti trust is not “a company does something I don’t like”.