I've been developing for Mac and iOS before the App Store was released, and have experience the author names - in broad strokes, your argument is valid, but it's not correct - errors slip in when describing the Applescript interface as just a reflection of Applescript sucking, describing his issue with Apple having _fragile_ private APIs when his conclusion is the problem is _private_ APIs, and reducing the problems inherent in the walled garden as "making you dig through class-dump output"
Ok, to distill my point: I think the author is going beyond a complaint that the system is proprietary and claiming that Apple has purposefully made the code difficult to reverse engineer, which I something I dispute based on the level that the author was working with, which were fairly standard (might I say comparatively well-packaged) private APIs. I say this because I know there is actual Apple-proprietary code that the company has actually put effort into obfuscating; things like FairPlay (and closer to iMessage, IDS, though I have only heard rumors of the latter not having looked at it personally). Thus, at the moment I think Apple is preventing third-party clients of the type described just by virtue of the literal barrier of “this is a compiled blob that I need to interact with and I don’t have source to” rather than “Apple added obfuscation/prevents you from attaching a debugger/encrypts the code at rest with a Blowfish key that is undone when the kernel maps the process into memory” (all of which are things that Apple does actually do in cases where they half-care). Basically, I’m removing the attribution of malice I felt from the article. Does that make some sort of sense?
There's a very significant difference between releasing an API publicly, and having a few internal users.
Public APIs have a high communication burden, but "fixed cost" if done right -- it shouldn't go up much as the number of users increases. They also have strict compatibility requirements that greatly slow, prevent, or complicate changes. They require more stringent security review and comprehensive tests, etc.
Private APIs can have a low, informal communication burden, but it tends to increase exponentially with the number of clients. They can be changed quickly, but clients have to be changed or and/or tested as well, so again the number of clients is limited. Tests only need to cover use cases the limited set of known clients actually need. It works best when clients are part of the same release cadence, since the price of managing branches is high.
Also, you can't separate the idea of fragile private APIs from private APIs in general. Private APIs are fragile. That they can change quickly, including breaking changes, is the whole point.
Why do people act like having “private APIs” is something evil? The entire purpose of having published public APIs is that they should be something that doesn’t change without a deprecation schedule or warning while the underlying implementation can change without notice. This is software engineering 101.
I don't know about evil, but it's hostile because Apple is intentionally preventing a non-AppleOS version from existing. The details of how they do it are of merely scientific interest.
It’s not hostile that you build a system with a public API that doesn’t change and private methods that you make no guarantees about. This is how software engineering has always worked.
