There is exactly one way to send an iMessage: from a device signed into an Apple account. No wholesale interconnect exists, no licensing programme, no gateway. So every provider in this category — the polished enterprise ones included — is ultimately operating Apple hardware and Apple identities and putting an HTTP interface in front of them.
The architecture
- Apple hardware, typically Mac minis, in a data centre or a colocation rack.
- An Apple account per line, each with a phone number attached.
- A control layer that drives the Messages client on each machine and reads what comes back.
- An API tier in front of it, which is the only part you see: authentication, routing, queueing, webhooks.
- Monitoring, because devices wedge, accounts get challenged, and macOS updates break things.
When you POST a message, the API picks the machine holding your line, hands it the message, and reports back what it can observe. The blue bubble your customer sees is genuinely a blue bubble, because it genuinely came from a real Apple account.
Why "phone farm" is an insult
The phrase carries baggage from click fraud and account farming, and competitors deploy it precisely for that association. What it literally describes is what everyone in the category does, including whoever is using the term.
The distinction that actually matters
Not whether there is a fleet — there always is. It is how it is run. A well-operated fleet has one line per account, redundancy, sensible rate governance, monitoring that catches a degraded line within minutes, and a plan for the day macOS changes something. A badly run one shares accounts across customers, pushes volume until things break, and finds out from you that a number has stopped delivering.
Questions that reveal how it is run
| Ask | What a good answer sounds like |
|---|---|
| Is my number exclusively mine? | On a dedicated plan, yes — one line, one account, no sharing with other customers. |
| What happens if my line stops delivering? | A named detection window, an alerting commitment, and a documented replacement process. |
| How quickly can I get a replacement number? | A concrete answer in hours or days. Vagueness here is the tell. |
| What are the real per-day limits? | Numbers. "Generous" or "unlimited" is not an answer — every fleet has limits. |
| Do you monitor delivered rate per line? | Yes, with thresholds, and they tell you rather than waiting for you to notice. |
| Can I keep my number if I leave? | Often no, and it is much better to learn that now. |
Why this shapes the pricing
Everything commercially odd about this category follows from the architecture. Pricing is per line rather than per message because the line is the scarce physical resource. Dedicated numbers cost more than shared ones because a dedicated number occupies capacity you are not sharing. Nobody offers unlimited free because every number has hardware behind it. The full economics.
It also explains the daily caps. A provider limiting you to a hundred or two hundred messages a day is not being stingy — they are protecting the account your line depends on, and by extension your delivery. Pacing a campaign around that.
The risk, stated plainly
Apple's terms do not contemplate commercial messaging fleets. Accounts can be restricted. A line can be lost, and providers replace lines because lines do get lost.
Mitigations exist and they are real: identity hygiene, conservative volumes, genuine two-way conversation rather than blasting, and — on your side — a fallback channel and customer records kept in your own systems. What does not exist is a provider who has engineered the risk away, and any vendor implying otherwise is telling you something about their sales process rather than their infrastructure.
Running your own
Some businesses do — a Mac mini, a spare Apple ID and an open-source bridge. It is genuinely free and it is a phone farm of one. You inherit the whole operational burden: uptime, OS updates, account challenges, no fallback, no support. And the Apple ID at risk is usually a real person's, with their photos and purchases attached to it.
For a personal project that is a fine trade. For a business it is worth being clear that you have not avoided the architecture — you have become the operator of it. The comparison in full.
What to establish before you sign
- Dedicated line, not shared, if the number represents your brand.
- Documented daily and per-minute limits, in numbers.
- Per-line delivery monitoring with alerting to you.
- A stated replacement process and time bound for a lost line.
- Number portability answered honestly, in writing.
- Your own fallback channel, tested.
- Customer records in your systems, not only in the provider's inbox.