28

Follow up to yesterday’s “hybrid/cross-platform is shit” rant about Electron apps being blocked from the Apple App Store.

See the below image of the github issues template on the Electron repo, to file an issue for this problem.

Yes, this is such a common issue with their product, they’ve made it easier to file a github issue. Let’s not address the fact that there is a fundamental flaw in the approach they are using, let’s just make it easier to open a ticket while everyone waits to see if we are allowed to ship our app.

I’ve also heard talk that under some circumstances it’s possible for them to patch out the libraries causing issues. Apple provides tools to identify these libraries ... therefore Electron is doing fuck all to adresss this issue, and adopting a “wait until someone complains” style of approach.

A+

Comments
  • 10
    oh wow, not being able to be on the App Store for using non-Apple libraries?

    Who saw this coming?
  • 8
    @Parzi has nothing to do with using “non-Apple” libraries.

    Has to do with third party libraries that use private Mac OS and iOS API’s. This is banned by Apple as they are subject to change at any time, can be used to violate privacy, can lead to malicious software etc.

    Apple is preventing shitty or dangerous apps getting into the store. I think that’s ok.
  • 3
    @practiseSafeHex > private Apple APIs
    so they're banning you FOR USING THEIR APIs. Got it.

    lemme just go get my shit rejected from the microsoft store for using directx and kernel apis real quick as it's totally malware if i use the things i literally have to use to make shit work
  • 7
    @Parzi so again, that’s not the case. A bit ridiculous to think that Apple would build something like directX and then block you from using it.

    Apple creates certain API’s that are private, because they manipulate system configs, or touch sensitive user data that otherwise you’d have to ask permission for etc. They are only intended to be used by system processes.

    These are undocumented API’s, that can only be found through getting class dumps and similar techniques and can only invoked through reflection using strings.

    This is nothing like using directX that’s there for developers to use. These API’s can pose security issues, will change at the drop of a hat (breaking anything depending on it) and were never intended to be used by non system processes.

    Stopping people from using these is actually a good thing
  • 3
    you know sometimes I hate apple, but this comment section makes me feel like Apple was right all along

    And this time that‘s not apple‘s fault
  • 1
    @practiseSafeHex since apple's all about code signing now they could refuse access to the APIs unless the program is Apple signed for Apple use only.

    or just, y'know

    do basic security shit implemented in Linux (the thing they run their shit on) since like Linux 0.7
  • 0
    @Parzi I’m pretty sure a lot of that would get identical backlash to what you’ve posted, from people saying Apple is too closed box even if you arent going through the App Store.

    Is the current way of doing it the best technical solution? I have no clue.

    Regardless if is or isn’t the rant still stands. Apple imposes restrictions on getting into the App Store that are, based on past examples, appropriate in at least some cases. Chromium doesn’t follow those rules. Electron is aware of this and doesn’t emphasis this risk anywhere. Electron is also not doing enough as it should be possible to automate this to, at a minimum, identify the issue so it can be addressed before a new release goes out to its developers
Add Comment