Search Apple's developer site for Messages and you get frameworks, sample code and WWDC sessions. It looks like everything you need. Then you read closely and discover that every one of them is scoped so that a human being taps send, or so that your code only ever runs inside a conversation the user already opened.
That is not an oversight. It is the same constraint expressed five times.
The Messages framework
This is what powers iMessage apps — the small applications in the drawer above the keyboard. You build an extension with MSMessagesAppViewController, and it renders inside the Messages UI.
| What you get | What it means in practice |
|---|---|
MSConversation.insert(_:) | Puts your message into the input field. The user still taps send. |
MSMessage and MSMessageTemplateLayout | A rich, tappable bubble with your own layout and data payload. |
MSSticker | Sticker packs. Genuinely the whole API for a large category of apps. |
MSSession | A message that updates in place — how the chess and drawing apps work. |
`insert` is not `send`
This is the single most misread method in Apple's messaging documentation. It stages content in the compose field of a conversation the user has already open. There is no variant that sends, no entitlement that unlocks sending, and no way to reach a conversation the user is not currently in.
MFMessageComposeViewController
From MessageUI, this presents the system compose sheet with recipients and body pre-filled. Your app cannot dismiss it, cannot send it, and cannot read what the user changed. It is a courtesy, not a channel — the user is always the one who sends.
Worth knowing: it composes an SMS or an iMessage depending on the recipient, and your code does not choose which.
SiriKit messaging intents
INSendMessageIntent lets Siri send a message through your app — WhatsApp, Signal, your own product. It is a hook into your messaging service, not into Apple's. It cannot send an iMessage; that path is reserved for Apple's own client.
Apple Messages for Business
The only officially sanctioned way for a business to hold an iMessage conversation, and a genuinely good product. It has a REST API, it is documented, and it works — for conversations the customer starts.
You cannot send the first message. That single constraint is what separates it from what most people mean by an iMessage API. The full guide is here.
Shortcuts and AppleScript
On macOS, the Messages app is scriptable, and Shortcuts can send a message on both platforms. These are automation surfaces for a person's own device, running as that person, under their Apple ID. They are the basis of every "free iMessage API" you will find, and their limits are the reason those are not a business channel. Working examples and where they break.
The pattern
| Framework | Who sends | Reaches a new recipient? |
|---|---|---|
| Messages (iMessage apps) | The user | No — only the open conversation |
| MessageUI compose sheet | The user | Pre-fills only; user must tap send |
| SiriKit intents | Your app's own service | Not iMessage at all |
| Messages for Business | Your server | Only after the customer messages first |
| Shortcuts / AppleScript | The device owner | Yes, as that person, on their device |
Every row keeps a human or a prior customer action in the loop. Whatever else it is, it is consistent — and consistency at that level is a policy, not a gap in the roadmap.
Why Apple holds the line
The blue bubble is worth something precisely because it has not been filled with automated commercial messages. Every platform that opened programmatic access ended up with a spam problem and a filtering arms race; SMS is the obvious example. Apple's restriction is what preserves the asset.
There is a competitive argument too — iMessage is a reason to buy an iPhone, and that argument is stronger if it stays a personal channel. The longer version, including the regulatory pressure, is on the API gap page.
The uncomfortable corollary
The third-party providers in this category are commercially valuable because Apple holds this line. If Apple shipped an official API tomorrow, the category would be commoditised within a year — and the channel would be worth less to everyone, because it would start to look like SMS. Anyone selling you an iMessage API is, in a real sense, selling you access to Apple's restraint.
So what do you build against?
- Customer starts the conversation, you need Apple's blessing → Messages for Business.
- You need to send first → a third-party provider. No official path exists.
- You want rich content inside a thread the user is already in → the Messages framework. It is very good at that.
- You want to automate your own device → Shortcuts or AppleScript.
- You want a bot → read this first.