No, iMessage does that. That's no more "Apple" doing that, than the functioning of a copy of gpg that you installed from Ubuntu's apt repo would be the GNU Foundation or Canonical Inc. "doing that." The client is in ultimate control. Someone wrote that program, but now you have it, and you get to say what it does or doesn't do (if by nothing else than by choosing whether to run it.) The iMessage servers can't make the client do something that's not part of its executable.

You downloaded, and now have, the software—a collection of bits with a fixed function—on your device. You can do what you like to verify those bits, and then either trust them, or not; but either way they're not going to suddenly change out from under you without your consent (which you might supply implicitly by turning on auto-update, but you don't have to do that either.)

When entities like the US Navy use cryptosystems like Tor, they're not blindly installing it from the web, trusting the theoretical guarantees it makes; they're ensuring security in practice by isolating a specific version-under-test, static- and runtime-analyzing the binary to ensure it meets their needs, and then declaring that exact binary good and trustworthy, and giving operatives simple tools to acquire and validate that exact binary.

If you're paranoid, you do nothing less. But nothing about getting iMessage as part of your iPhone's OS stops you from doing any of that. You just take apart the IPSW it ships in, and throw it iMessage.ipa into Ghidra. Once you've verified it, you can say "the version of iMessage that ships in iOS with hash 0xXYZ, is known-good, and can be used for low-security comms."

> Let's trust (again) that they absolutely have no mechanism to intercept your password and do whatever they want with your data.

No, let's trust-but-verify that the binaries are E2E-encrypting the key-sharing process. Then there cannot be a man in the middle.

Also, as I said previously, you never "log into" iMessage, and so you don't have an iMessage "password" per se. iMessage uses your iCloud username to discover the device-group to attempt to join, but it doesn't use your iCloud account to authenticate to that group in any way. Instead, you're basically doing a https://en.wikipedia.org/wiki/Key_signing_party with yourself, manually pairing your devices with each-other through challenge-response. (This turns out to actually be a convenient kind of key-signing party—and so probably the only time key-signing parties are relevant in practice.)

In the design of the iMessage key-sharing process, the iMessage servers could be replaced with an ephemeral channel on a public IRC server, and the semantics—including the security guarantees—would remain the same. The servers only see—and pass along—opaque, encrypted blobs.

> How do you know that when you connect to me over iMessage using state-of-the-art / end-to-end-encryption / made-from-carbon-free-alumeenium (sorry for that one), there is no man in the middle?

You're moving the goalposts; intra-account multi-device key sharing, and inter-account key exchange, are separate concerns.

What you are asking about is the Fundamental Problem of Key Exchange. And the answers are as they have always been: you either do a key-signing party; or you choose a Central Authority to trust to act as a directory mapping identities to public keys (and then maybe use that key to do a challenge-response identification process with out-of-band signaling elements.)

iMessage solves key sharing better than other messaging services. Nothing[1] really "solves" key exchange any better than anything else.

[1] Except maybe Keybase, but Keybase's unique shape—an identity-aggregating service—is a necessary element of that solution. No chat service can do what Keybase does without getting into the business that Keybase is in.