Electron apps cannot be submitted to the Apple store

Re:Electron apps cannot be submitted to the Apple store by scarface74 on Sunday November 03, 2019 @08:43PM (#21438266)

There are no such things as “secret APIs”. By definition an Application Programmers Interface is the vendors promise to other developers that when you call it, it will have well defined results no matter if the implementation changes. Every modern programming environment has the concept of public and private methods either enforced by the language (with hacks to get around it) or by convention (prepending a function with an underscore)

The fact is that all of MS’s Office competitors early on wrote horrible GUI apps whether it be fir Windows or the Mac.

[ Parent | on HN ]

Re:Electron apps cannot be submitted to the Apple store by JohnFen on Monday November 04, 2019 @01:24PM (#21444644)

> There are no such things as “secret APIs”.

I don't know what Apple means by "secret APIs", but I'm assuming they mean "undocumented APIs". Those are certainly real things that commonly exist.

> By definition an Application Programmers Interface is the vendors promise to other developers that when you call it

Yes, but those "other developers" may be other engineers in the same company. The APIs they use are still APIs, but are not intended for use by anyone outside the company.

[ Parent | on HN ]

Re:Electron apps cannot be submitted to the Apple store by scarface74 on Monday November 04, 2019 @01:43PM (#21444884)

That’s true. Apple doesn’t say “secret APIs” that’s a conspiratorial phrase made up by third party developers.

Say Team A within Apple creates a module that is only to be used by Team B and C. Then Teams D creates a module that depends on Team A and B and they release a public API.

Team A should publish an internal documentation and Teams B and C should also not use methods that were not documented by Team A and Team A shouldn’t follow standard semantic versioning. If Teams B and C need some functionality they should inform Team A.

The same goes for Teams B and C. Also, Apple controls the release schedule for any internal teams. If they want to move to ARM tomorrow they can coordinate it within Apple without breaking any third party apps. The only team that has any responsibility to not break external developers is Team D.

If Apple starts allowing external developers to use private functions now their release schedule is tied to when enough major third party developers update their documentation.

Amazon is even a better example. They have a policy that everything should be a service internally and no team should reach “inside” of the implementation of another team.

[ Parent | on HN ]