Ok, so a comment on the actual content of the article rather than iMessage in general: I do the kinds of things that the author describes in the article (digging into private implementations of things) and I while I believe all of iMessage is a bit obfuscatory it's not nearly as bad as the author has described it. Really, it's one of the places where Hanlon's razor actually applies: the AppleScript bridge sucks because AppleScript in general sucks, as Apple has let it decay until it stops working entirely. The iMessage team for macOS is already kinda eh, and it shows in the app's architecture and lack of new features for years, as well as its fairly strange usage of a web view (actually the long-deprecated one…) for the main content. The rest of the stuff about private frameworks…I mean, I don't really know what to say. They're not meant to be linked against, they're undocumented, they change and disappear between releases…you really cannot complain about them. They're not Apple making it harder for you, they are just a side effect of how Apple writes its applications and the fact that the entire OS is proprietary. Some do venture into that realm (such as the author and I) and find meaning, but I disagree with the characterization that Apple is fighting against reverse engineers by making you dig through class-dump output and figure out how to marshal your arguments through the right function to make it do what you want.
Two of my main gripes with iMessage is the fact that if you scroll back up to read the past it becomes progressively slower and slower to scroll and each time the lag to get a new “page” of history takes longer. The other gripe is search being almost completely useless. Search for say “apples” and it just lists the entire conversation instead of relevant messages containing apples. And then you are left scrolling up endlessly to find said message with the aforementioned slowdown bug being front and center.
They've actually fixed that second part: search now shows individual messages mentioning the search term (even if there are multiple in the same thread).
yeah they fixed that on ios but imessage on mac os is not a great experience. just about as bare bones and janky as a messaging app can be. don't get me wrong... i like imessage as a utility but the app is rough.
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.
Given Apple’s frenetic propensity to be extremely resource conscious, I doubt that team even exists any longer.
There’s likely some larger messages team that is itching to replace that app with the iOS version via Mac Catalyst... which despite the poor experience of most Catalyst apps on the Mac, would still make for a marked improvement. Goes to show you how poorly maintained the app is.
> as well as its fairly strange usage of a web view (actually the long-deprecated one…) for the main content
iMessage (at least on iOS) allows for arbitrary plugins to generate content for it, right? I presume it does that by having the plugin emit a web-component-like bit of HTML+CSS+JS, that is then embedded into the conversation for all participants, and which can be further rehydrated after initial rendering by just-in-time zero-installing the relevant iMessage plugin on recipient hosts.
(For anyone who is wondering why this would be necessary just to display some stickers: there are other kinds of iMessage plugins, e.g. games you can play inside the iMessage window, and not just the "you say something, IRC bot says something" kind of games, but full Canvas kind of games.)
You would presume incorrectly. iMessage extensions use native code + rendering. It is probably the main reason why these things aren’t available on macOS.
The extensions do that on iOS, yes. But the extension has to show up as something when a macOS client sees it, similarly to how Slack add-on messages have to be delivered as something to non-Slack UAs, e.g. bots.
I got the same feeling reading the post. Seems like it was difficult because iMessage is a private API and a little crufty as all long-lived APIs are. This was more of a lesson in what the code usually looks like inside any software org - messy, full of historical cruft etc etc. but it works and powers a very important feature, so there's little to gain / lot to lose by trying to refactor.
