The honest answer splits in two, because 'free' means two different things here. Free software: yes, and it is good. Free infrastructure: no, and it cannot exist.
Every iMessage sent from code originates on real Apple hardware signed into a real Apple ID. Someone pays for that hardware, that Apple ID, and the operational work of keeping it alive. Either it is you, or it is a vendor charging you for it. There is no third option where it is free.
The free routes, honestly rated
| Option | What it is | Real cost | Good for |
|---|---|---|---|
| BlueBubbles | Open-source server that runs on your Mac and exposes a local REST API plus webhooks. The most complete of the free options. | A Mac that never sleeps, plus your own uptime | Personal projects, internal tools, low volume with a real developer behind it |
| AppleScript | Scripting Messages.app directly. A dozen lines, no dependencies, works today. | Fragile across macOS updates; no inbound; no delivery signal | Scripts, one-off sends, prototypes |
| Shortcuts | Apple's own automation app, driving Messages on a schedule or trigger. | No real API surface, hard to test, hard to observe | Non-developers automating something small |
-- Sends as whatever Apple ID Messages.app is signed into.-- No API key, no vendor, no cost. Also no delivery receipt and no inbound.tell application "Messages" set targetService to 1st account whose service type = iMessage set targetBuddy to participant "+15551234567" of targetService send "Your appointment is confirmed for Tuesday at 2pm." to targetBuddyend tellFree at low volume, expensive at scale
The free routes are genuinely fine for tens of messages a day from a machine you already own. They stop being fine at the point where an unnoticed failure costs you a customer — because none of them tell you a message failed. That threshold arrives earlier than people expect.
What you are actually paying a provider for
It is worth being precise, because if none of these matter to you then you genuinely should not pay for one.
- Account risk absorbed. When a number gets flagged, that is the vendor's problem and their replacement number. On a self-hosted bridge it is your Apple ID and your Saturday.
- Uptime that is not your Mac. No 'the office lost power' outage, no macOS update that broke the bridge at 2am.
- Inbound webhooks with retries. Reliable receiving is the genuinely hard part, and it is where free options are weakest.
- Delivery signal. Knowing a message actually arrived. AppleScript will never tell you this.
- SMS fallback. Automatically routing to SMS for Android recipients, which self-hosted options generally do not do.
If you want none of that, the free path is not a compromise — it is the correct answer. If you want most of it, see what an iMessage API costs; the cheapest published hosted tier is currently well under a hundred dollars a month.
A note on 'open source' in vendor marketing
Several hosted providers publish open-source SDKs, adapters and n8n nodes. That is real and useful — Photon's iMessage kit and Chat SDK adapter are genuine open source. But an open-source client for a paid hosted service is a different thing from an open-source server you can run yourself. Read which one is on offer before you assume you can self-host it.
The full architectural comparison is in hosted API vs self-hosted bridge, and BlueBubbles has its own review.
Related questions
- Is there a free iMessage API?
- No hosted provider offers a free production tier. Free options are self-hosted: BlueBubbles, AppleScript, or the Shortcuts app, all of which require a Mac you own and keep running.
- Is there an open-source iMessage API on GitHub?
- Yes — BlueBubbles is the most established, and several smaller projects wrap AppleScript or the local chat.db. They are bridges to a Mac you own, not hosted services.
Still deciding?
Compare the services that can actually send this on the providers page, see what each one costs, or read the step-by-step guides.