Re:Electron apps cannot be submitted to the Apple store
by scarface74 on Monday November 04, 2019 @06:52AM
(#21440790)
The Mac was intended to be a much more tightly controlled developer environment. And it came out at a time when there was still a lot of debate over the right way to develop a computing platform.
This is very much not true. The entire extension mechanism on Macs was about using undocumented hacks to add functionality. Apple has no control over what a third party app could do through the Classic MacOS era from 1984-1999.
In fact, it wasn’t until around 2011-2012 when Apple started having sandboxing and that was only for Mac App Store apps. It was even later that they had system integrity protection. Even today, you can basically do what you want to on the Mac except for having unsigned kernel extensions.
Re:Electron apps cannot be submitted to the Apple store
by DonHopkins on Monday November 04, 2019 @03:57AM
(#21439940)
But Applesoft had perfectly fine extension mechanisms: "&" and "USR()" and "PEEK" and "POKE" and "CALL"! What more do you need?
https://link.springer.com/content/pdf/10.3758/BF03203836.pdf
https://en.wikipedia.org/wiki/Applesoft_BASIC#Extensions
http://nparker.llx.com/a2/as.addons.html
"C is just PEEK and POKE with syntactic sugar." -- Bill Joy
The prehistory is that developers for the Apple ][ had access to third party documentation, and made extensive use of unofficial system variables and entry points. The result was that it became impossible for Apple to update their own system without breaking popular apps and getting blamed for doing so. It turned Apple ][ technology into a dead end.
The Mac was intended to be a much more tightly controlled developer environment. And it came out at a time when there was still a lot of debate over the right way to develop a computing platform.
IBM had a different approach, which was to make things more open like the Apple ][, and they paid the price for it. For instance, a lot of the weird limitations of the IBM PC were caused by developers bit-banging hardware registers and video memory rather than going through "official" BIOS calls that were less efficient.
I don't personally know the right answer, but this is just the history as I recall it. At the time I preferred the IBM approach, because I could do some friendly bit banging and get stuff done, but my programs were mostly for a severely limited audience and lifespan. Today I try to do things in a way that insulates me from knowing anything about the platform that I'm using.