8 ms·

How short are memories. I remember how Microsoft was vilified for supposedly having secret Windows APIs that allowed Microsoft apps to get better performance.

by kjksf 7y ago

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 ever was. At some point the goodwill they built as underdog making great products will run out and some government somewhere will take an anti-trust action. I'm just hoping it'll happen sooner rather than later.

saagarjha 7y ago
I believe CAContext is private API but performs better than documented alternatives.
BillinghamJ 7y ago
Undocumented APIs get broken. That's a big problem for user experience, particularly if it happens to be being done by a framework relied upon by a very high percentage of app use. Seems pretty fair imo
- DarkmSparks 7y ago
  Is this why so many of the apps on my ipad "need to be updated to work with this version of ios"? and there is no update.
  - saagarjha 7y ago
    No, that's because they're 32-bit apps, which iOS no longer supports.
    - dingo_bat 7y ago
      Which is the same thing.
      - ichicoro 7y ago
        It isn't? There's a difference between dropping 32bit libraries from your OS (after a lot of time in which Apple clearly said "we will drop support!") and banning for using unauthorized APIs inside the MAS.
        dingo_bat 7y ago
        32 bit support is also an API. MacOS agreed to run apps compiled to target a particular instruction set. Arbitrarily refusing to honor that (undocumented) agreement is the same as breaking an undocumented API. Here they broke all the 32 bit interfaces for their OS.
chii 7y ago
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 web app. Don't use hardware api not available to the browser and you cannot be removed!
- zamadatix 7y ago
  > 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.
  - lawnchair_larry 7y ago
    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!
    - zamadatix 7y ago
      I never said code signing DID do that. Of course it didn't, there were no secret high performance Microsoft only APIs in the first place. I said it COULD have easily been used to do that. E.g. make special API/syscall to unlock restricted APIs, Windows checks the signing status of the executable making the call and only grants permissions if it is signed by MS. It's actually also not true that Microsoft only ever blocked things based on signing cert from the Windows Store/UWP platform. Windows Defender Smart Screen blocked/blocks apps from running without user intervention unless it was either extremely well known or was signed (and even then if it was new you might still get caught by it).
deleted 7y ago
[deleted]
scarface74 7y ago
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.
- JohnFen 7y ago
  > 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.
  - scarface74 7y ago
    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.
matheusmoreira 7y ago
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.
- ptlu 7y ago
  As a user of macOS, I want developers who makes apps to use public APIs that will be supported so I don't get breakages on system upgrades or migrations.
  - BoorishBears 7y ago
    As a user of macOS, why don't you put the onus on Apple to not artificially limit what developers can offer you without it breaking on upgrades and migrations? Some of the private APIs being used have been stable for generations and are clear improvements in one way or another over the publicly available APIs (like CAContext stuff). I mean a modern OS is not like a library you stick up on NPM and hope no one tries to use internal methods that you'll end up having to support. There are so many desperate teams working on OSX and the applications from Apple that use these APIs, it's not like backwards compatibility, documentation, and most of the issues public APIs face aren't already an issue that has to be tackled. Apple uses these APIs to make features no one can fairly compete with, which is detrimental to you, as a user, and to external developers. Imagine if any app could use APIs like the ones that Apple Music uses to have tight integration with Siri, or that Apple Maps uses to show on your lockscreen.
    - saagarjha 7y ago
      > There are so many desperate teams working on OSX and the applications from Apple that use these APIs, it's not like backwards compatibility, documentation, and most of the issues public APIs face aren't already an issue that has to be tackled. When push comes to shove, Apple can tell those teams to rewrite their code. It can't do that to the authors of, say, Firefox.
babesh 7y ago
Microsoft was vilified for many anticompetitive practices. I worked on an app that competed with a Microsoft app. Our app was actually winning in the marketplace. One year they release a new version of their app with some really cool features at the same time as the latest Windows release. Those features were based on some new APIs released with that version of Windows. Just gave their app a year leap. Another evil practice was forcing PC makers to pay for a Windows license for each computer sold irrespective of whether the computer shipped with Windows. Microsoft was pretty evil.
- stickfigure 7y ago
  As opposed to "here are some APIs that you can't use but we can, neener neener"?
  - babesh 7y ago
    You are assuming that these Apple APIs are used to give Apple a competitive advantage somehow. From what I can tell, these specific APIs don't. What they do give Apple an advantage in ironically is in forcing more developers to develop using (Apple) native APIs. The CA prefixed ones are core animation related. Some of the others appear to be drawing frame related. I am not sure what the remote one does. None of these are giving Apple a direct advantage. I bet Electron tried to access to them to draw web pages smoothly. The Windows API availability window gave Windows apps market advantages. There are other private Apple APIs that do give Apple an advantage against app developers. Those advantages are in accessing physical hardware and possibly associated software, background processing, and integration (iCloud, etc...) But these aren't the bone of contention.
    - Mirioron 7y ago
      >None of these are giving Apple a direct advantage. >I bet Electron tried to access to them to draw web pages smoothly. How is this not a direct advantage? If these uncommented API calls provide a better performing solution than anything a third party can make then that is a direct advantage. Apps with that call could have a longer battery life or just run smoother.
analog31 7y ago
From what I recall, this practice goes back to the original 68k Apple Mac. 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.
- DonHopkins 7y ago
  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://link.springer.com/content/pdf/10.3758/BF03203836.pdf https://en.wikipedia.org/wiki/Applesoft_BASIC#Extensions https://en.wikipedia.org/wiki/Applesoft_BASIC#Extensions http://nparker.llx.com/a2/as.addons.html http://nparker.llx.com/a2/as.addons.html "C is just PEEK and POKE with syntactic sugar." -- Bill Joy
- scarface74 7y ago
  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.
michaelmrose 7y ago
I think perhaps your memory is short if you think that this is worse than anything Microsoft ever did. Did we forget them funding, to the tune of millions of dollars, a felonious pump and dump scheme designed to defraud investors and destroy competitors with fraudulent lawsuits. In a completely fair world a substantial number of executives would probably be in jail.
shafiqissani 7y ago
I trust the EU with these matters, more so than any other government.
- scarface74 7y ago
  So you expect the EU to not allow Apple to ban the use of private methods? Are they going to also ban Apple from not changing them? What happens when Apple updates the operating system and starts throwing up a big dialog box every time an app accessed a private API that says “the publisher of this app needs to update their poorly written app.”? What next? Is the EU going to also ban language makers from having public and private functions?

by kjksf 7y ago

saagarjha 7y ago

I believe CAContext is private API but performs better than documented alternatives.

BillinghamJ 7y ago

Undocumented APIs get broken. That's a big problem for user experience, particularly if it happens to be being done by a framework relied upon by a very high percentage of app use. Seems pretty fair imo

DarkmSparks 7y ago
Is this why so many of the apps on my ipad "need to be updated to work with this version of ios"? and there is no update.
- saagarjha 7y ago
  No, that's because they're 32-bit apps, which iOS no longer supports.
  - dingo_bat 7y ago
    Which is the same thing.
    - ichicoro 7y ago
      It isn't? There's a difference between dropping 32bit libraries from your OS (after a lot of time in which Apple clearly said "we will drop support!") and banning for using unauthorized APIs inside the MAS.
      - dingo_bat 7y ago
        32 bit support is also an API. MacOS agreed to run apps compiled to target a particular instruction set. Arbitrarily refusing to honor that (undocumented) agreement is the same as breaking an undocumented API. Here they broke all the 32 bit interfaces for their OS.

chii 7y ago

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 web app. Don't use hardware api not available to the browser and you cannot be removed!

zamadatix 7y ago
> 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.
- lawnchair_larry 7y ago
  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!
  - zamadatix 7y ago
    I never said code signing DID do that. Of course it didn't, there were no secret high performance Microsoft only APIs in the first place. I said it COULD have easily been used to do that. E.g. make special API/syscall to unlock restricted APIs, Windows checks the signing status of the executable making the call and only grants permissions if it is signed by MS. It's actually also not true that Microsoft only ever blocked things based on signing cert from the Windows Store/UWP platform. Windows Defender Smart Screen blocked/blocks apps from running without user intervention unless it was either extremely well known or was signed (and even then if it was new you might still get caught by it).

deleted 7y ago

[deleted]

scarface74 7y ago

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.

JohnFen 7y ago
> 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.
- scarface74 7y ago
  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.

matheusmoreira 7y ago

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.

ptlu 7y ago
As a user of macOS, I want developers who makes apps to use public APIs that will be supported so I don't get breakages on system upgrades or migrations.
- BoorishBears 7y ago
  As a user of macOS, why don't you put the onus on Apple to not artificially limit what developers can offer you without it breaking on upgrades and migrations? Some of the private APIs being used have been stable for generations and are clear improvements in one way or another over the publicly available APIs (like CAContext stuff). I mean a modern OS is not like a library you stick up on NPM and hope no one tries to use internal methods that you'll end up having to support. There are so many desperate teams working on OSX and the applications from Apple that use these APIs, it's not like backwards compatibility, documentation, and most of the issues public APIs face aren't already an issue that has to be tackled. Apple uses these APIs to make features no one can fairly compete with, which is detrimental to you, as a user, and to external developers. Imagine if any app could use APIs like the ones that Apple Music uses to have tight integration with Siri, or that Apple Maps uses to show on your lockscreen.
  - saagarjha 7y ago
    > There are so many desperate teams working on OSX and the applications from Apple that use these APIs, it's not like backwards compatibility, documentation, and most of the issues public APIs face aren't already an issue that has to be tackled. When push comes to shove, Apple can tell those teams to rewrite their code. It can't do that to the authors of, say, Firefox.

babesh 7y ago

Microsoft was vilified for many anticompetitive practices. I worked on an app that competed with a Microsoft app. Our app was actually winning in the marketplace. One year they release a new version of their app with some really cool features at the same time as the latest Windows release. Those features were based on some new APIs released with that version of Windows. Just gave their app a year leap. Another evil practice was forcing PC makers to pay for a Windows license for each computer sold irrespective of whether the computer shipped with Windows. Microsoft was pretty evil.

stickfigure 7y ago
As opposed to "here are some APIs that you can't use but we can, neener neener"?
- babesh 7y ago
  You are assuming that these Apple APIs are used to give Apple a competitive advantage somehow. From what I can tell, these specific APIs don't. What they do give Apple an advantage in ironically is in forcing more developers to develop using (Apple) native APIs. The CA prefixed ones are core animation related. Some of the others appear to be drawing frame related. I am not sure what the remote one does. None of these are giving Apple a direct advantage. I bet Electron tried to access to them to draw web pages smoothly. The Windows API availability window gave Windows apps market advantages. There are other private Apple APIs that do give Apple an advantage against app developers. Those advantages are in accessing physical hardware and possibly associated software, background processing, and integration (iCloud, etc...) But these aren't the bone of contention.
  - Mirioron 7y ago
    >None of these are giving Apple a direct advantage. >I bet Electron tried to access to them to draw web pages smoothly. How is this not a direct advantage? If these uncommented API calls provide a better performing solution than anything a third party can make then that is a direct advantage. Apps with that call could have a longer battery life or just run smoother.

analog31 7y ago

From what I recall, this practice goes back to the original 68k Apple Mac. 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.

DonHopkins 7y ago
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://link.springer.com/content/pdf/10.3758/BF03203836.pdf https://en.wikipedia.org/wiki/Applesoft_BASIC#Extensions https://en.wikipedia.org/wiki/Applesoft_BASIC#Extensions http://nparker.llx.com/a2/as.addons.html http://nparker.llx.com/a2/as.addons.html "C is just PEEK and POKE with syntactic sugar." -- Bill Joy
scarface74 7y ago
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.

michaelmrose 7y ago

I think perhaps your memory is short if you think that this is worse than anything Microsoft ever did. Did we forget them funding, to the tune of millions of dollars, a felonious pump and dump scheme designed to defraud investors and destroy competitors with fraudulent lawsuits. In a completely fair world a substantial number of executives would probably be in jail.

shafiqissani 7y ago

I trust the EU with these matters, more so than any other government.

scarface74 7y ago
So you expect the EU to not allow Apple to ban the use of private methods? Are they going to also ban Apple from not changing them? What happens when Apple updates the operating system and starts throwing up a big dialog box every time an app accessed a private API that says “the publisher of this app needs to update their poorly written app.”? What next? Is the EU going to also ban language makers from having public and private functions?