Because of the way iMessage encryption works, iMessages do not sync, even if they appear to. Plus, you shouldn’t treat an iMessage archive as permanent.
Say you want to send me an iMessage, and I have three devices. You type in a message, hit send, and then the message shows up on my Mac, my iPad, and my iPhone. Those messages aren’t syncing. You are simply sending three separate messages from your device, each addressed to one of my devices–not one message that gets sent to three devices or syncs between them.
This is a result of the way that iMessage works: it has true “end-to-end” encryption. When you register a new device for iMessage, your device generates a public and a private key. The public key is put on Apple’s servers. The private key never leaves the device. When you try to send a person an iMessage, you check Apple’s servers to make sure you’ve got the public key for each device. You encrypt the message with the public key that corresponds to each device, for each device, and after that, it can be read only on the particular device the message was encrypted for. The message never travels in the clear, and it is never transmitted encrypted by anything other than the public key that corresponds to the private key that never leaves your device.
In other words: If you send a message to me, and I have three devices, you’re sending out three separate strings of random numbers, each going to a different place. No computer in the world, except the one you’re sending the message to, can have any way of knowing what’s inside each message. (I mean, an observer would probably be able to figure out that each message says the same thing. But that doesn’t help actually decoding what any of the messages say.)
The result of this is that if you add a new device to your lineup, there is no way for your message history to appear on that device. Each message that each of your existing devices has was sent specifically to that device. If messages synced between devices, or if there was a central store of messages that any device, including a new device, could read, then the entire security benefit of end-to-end encryption would be lost.
This is also why there is not, and never can be, a web client for iMessage. A web client would imply that a private key is stored on Apple’s servers, instead of on a customer-owned device.
Messaging apps that do not have end-to-end encryption can have all sorts of conveniences–new devices can sync, and you can have a web client accessible from any logged-in browser. But it also means that the company providing the service can read the messages, and turn them over if required to. Even if their systems are not easily structured to allow this, if a service has both the messages and the key required to read them, they are less secure than they are with a system where private keys are never transmitted anywhere or stored anywhere besides on the device that generated the,.
There is one important way, however, where messages are stored off your device, but encrypted in a different way: backups. Once a message has been decoded on your device it is simply considered to be part of your device’s data, no different that a Word document or an image. So if your device backs up–if it’s an iOS device, to iCloud, if it’s a Mac, to Time Machine, or to an online service like Backblaze–the messages leave your device, encrypted only with whatever encryption system the backup system uses. (On iOS, the private key is not backed up. They have specific hardware that hides the private key from anything else on the device. On a Mac, the private key might also be included in a backup, because it’s just saved somewhere on your hard drive.) This weakness would apply to various other encrypted communications apps as well–at some point, the message is decrypted on your device, and what happens to the message after that is another matter. Along with someone gaining physical access to one of your devices, this is probably one of the biggest vulnerabilities in end-to-end encrypted messaging apps. (Even password-protecting and encrypting the app’s message archive would mean that the messages are only as secure as your password.) A more secure solution would probably involve securely deleting your messages after you’ve read them.
Despite how the architecture of iMessage fights against this, people often want to use third-party tools to save message archives and somehow finagle them into new devices or at least be able to access them in another way. Maybe this works, and maybe if there’s important information in your archive you might have to do it, but I would suggest that with chat and messaging apps generally, you should probably embrace ephemerality. Not every digital communication should necessarily be stored for all time. Pick one form of digital communication to keep forever: say, email. If you want a permanent archive of a conversation, conduct it over email, not a messaging app, and if someone sends you an iMessage that you want to keep, screenshot it or save it some other way. If you go into iMessage expecting a permanent, always-accessible archive of all of your messages ever, you’re going to be disappointed, and it’s not the result of Apple just failing to support some feature you think it ought to, but the inevitable result of mathematics and the secure architecture Apple has decided to use for iMessage. And if you really do want a messaging system that, though less secure than iMessage, has all the conveniences that end-to-end encryption disallows, you should probably just use one of those instead.
You cannot send an iMessage to a phone number or email address, even if it appears you can.
iMessage is a private messaging system that has nothing to do with email or the telephone system, where user IDs are strings that happen to correspond with email addresses and phone numbers. iMessage could have used anything for its user ID system, and this is what it chose. Lots of services do the same thing. It’s as if, when you tried to order a hoagie at Wawa, and instead of giving you a number from a ticket or asking you your name, they asked you for your phone number. When they call out your phone number and hand you an Italian Shorti®, you wouldn’t say they were transmitting your Italian Shorti® over the Public-Switched Telephone Network (PSTN) or somehow sending it to your cell phone. Instead, they are clearly using your phone number as an arbitrary unique string; they could have used anything.
iMessage works under the same principle as Wawa in my example: when you sign up for it, it checks to see if you really do control the phone number or email address you give it, both to make sure they are unique to its system and to prevent you from impersonating someone. But after that, when someone sends you an iMessage, they’re not really sending it “to” your phone number or “to” your email address–they are sending the message to an iMessage ID that, looked at merely as a sting of characters, is identical to your phone number or email address.
This is all obvious, so why do I belabor it? Well, as I’ve written about before, there are issues like “Can I text to 911” where these details can have pretty big consequences. But with most systems where you use a phone number or an email address as a user ID, there’s basically no possibility for confusion. I have to log in with a phone number as a user ID to manage my mobile phone service. On most sites on the Internet, I log in with an email address. I don’t see how there’s any possibility for confusion there.
But iMessage silently intercepts text messages! On iPhones, the SMS client is the same as iMessage. If you try to send an SMS to someone, the client checks Apple’s servers to see if that person uses iMessage, and if so, sends an iMessage through Apple’s servers instead of a text message through the phone system. Using phone numbers as user IDs makes this pretty seamless–but it does lead to some problems, and those problems are caused by that same seamlessness. Say, for example, you change your actual phone number. iMessage problems can result from both iMessage not knowing you have the new number, and from the system not knowing that the old number is no longer active. So people might send you messages, and they’re not rejected, but there’s no device they’re delivered to. Or they might try to send an iMessage to your new number, and it fails, since iMessage doesn’t know about the new number yet. Because it’s using your phone number but is not part of the phone system, the two can get out of step. This also leads to the recurring issue where someone switches away from an iPhone and when iPhone users try to send SMS messages to that person, they get send via iMessage instead, and lost.
iMessage would not be as successful as it is unless Apple built it as it did–and it could probably solve most problems if there were some manual way that people can remove their email addresses and phone numbers from iMessage in the instances. One difficulty with this is that it’s not required to have an Apple ID to use iMessage–you can set up an iPhone where the only Apple online service you use is iMessage associated with a phone number. So in that circumstance, if you get a new phone, Apple has no real way of knowing who that phone number belongs to, making a self-serve tool likely a bad idea. But that’s another consequences of the low-friction way Apple chose to design its service, and not my problem to solve.