Figment vs AirMessage for App Integrations
If you are building an app that reads or sends iMessages on behalf of your users, AirMessage is not the tool you are looking for. AirMessage is a personal relay: it lets one person access their own iMessages on Android or the web by running a server on their Mac at home. It has no REST API, no OAuth flow, and no mechanism for a third-party app to request scoped access on behalf of multiple users. Figment is built for exactly that problem—a developer authorization layer with per-user grants, scoped permissions, and a REST API your app calls from any server.
AirMessage: a personal relay, not a developer API
AirMessage (open source on GitHub, Apache-2.0) is a Mac background service that bridges the native Messages app and AirMessage's own client apps on Android and the web. When a message arrives on the Mac, the server forwards it to the connected client. When the user sends from Android, the server relays it through the Mac's Messages app.
The service uses Firebase for online relay coordination. It requires an always-on Mac connected to the internet. The repository targets developers who want to build AirMessage-compatible client apps, not developers building their own products on top of iMessage. There is no documented REST API or OAuth surface for external application code to call.
Apple's own official third-party authorization—the scheme described at support.apple.com/en-us/121539—covers iCloud Mail, Calendar, and Contacts. iMessage is outside that scope entirely. There is no Apple-issued iMessage authorization that any relay or API layer inherits.
Why AirMessage doesn't fit a developer workflow
The gap isn't a missing feature; it's a fundamental design difference. Here are the four places where AirMessage's architecture diverges from what a developer integration requires.
One Apple ID per server. AirMessage Server connects one iCloud account. A product serving multiple users would need one Mac server instance per user, plus infrastructure to provision, host, monitor, and recover those instances.
No app-level grant. AirMessage has no authorization flow through which your application receives a scoped, revocable token tied to a user's iMessage account. There is no way to separate "what my app is permitted to do" from "what the server owner is personally doing."
No stable API contract. AirMessage exposes no published HTTP endpoints, authentication scheme, or response schema your application can depend on. Any integration built against AirMessage's internal protocol has no support contract, no versioning guarantee, and no path to sandbox testing.
No sandbox. Testing requires a live Mac with an active Apple ID. There is no synthetic data mode that lets you build and validate error handling before touching a real account.
How Figment addresses each of those gaps
Figment uses a PKCE authorization flow to create a scoped connection per user. Your app registers once at /apple-connect/developers. When a user authorizes your app, they go through Figment's hosted consent screen: they sign into Figment and select an Apple connection they have already set up. Native Apple sign-in and trusted-device approval are separate steps that happen during Mac-side connection setup, before this authorization screen. Your app receives a Figment access token (never an Apple password) and uses it to call the iMessage REST API.
Two message scopes exist. messages:read covers conversation history and search across messages available on the connected Mac. messages:send covers posting to existing authorized conversations. These are separate grants that can be approved together within one app authorization. A user can authorize read without authorizing send, and a conversation visible through read is not automatically available for send.
A history request looks like this:
GET https://figment.so/api/apple-connect/v1/connections/con_abc/chats?limit=20
Authorization: Bearer ACCESS_TOKEN
Sending a message requires a stable Idempotency-Key generated before the first attempt and bound to that specific action and body. Figment returns receipt states—submitted, delivered, read, failed, unknown, and simulated (sandbox)—so your app tracks delivery without guessing. An unknown receipt should only be polled; it must never trigger a resend under a new key.
The sandbox environment is free, returns synthetic data, and cannot deliver to real people. You can build and test the full connection and messaging workflow before a live Apple account is ever involved.
Personal client vs developer connection workflow
This is the core distinction the two tools are built around.
| AirMessage | Figment | |
|---|---|---|
| Who it's for | One person, non-Apple device access | Developers building multi-user apps |
| Mac infrastructure | Your own always-on Mac | Figment-hosted |
| Multi-user model | One Apple ID per server instance | Per-user OAuth-style grants |
| Third-party app API | None documented | REST API with Figment tokens |
| Permission scopes | — | messages:read, messages:send |
| Sandbox / test mode | Requires live account | Free synthetic sandbox |
| Idempotency + receipts | — | Required; full receipt states |
| Developer cost | Self-hosted, free to run | $29/month per active live connection |
Where AirMessage still fits
If your goal is personal—reading your own iMessages on an Android phone or accessing your Messages history in a browser when you are away from your Mac—AirMessage is a reasonable, free, self-hosted option. The open-source model means you control the data path, and the Android and web clients are available on GitHub alongside the server.
AirMessage is not a good fit when any of the following apply: you are building for more than one person, you need a stable REST API, you need a development sandbox, or you need to separate app-level access from your own account.
For a comparison with a self-hosted option that does offer a developer-facing HTTP layer, see Figment vs BlueBubbles for iMessage Integration. For how a fully managed iMessage API compares to Figment on pricing and feature scope, see Figment vs Claw Messenger for iMessage Apps. If you are still deciding whether to build infrastructure yourself, Build or Buy Your iMessage Connection Service lays out the trade-offs directly.
Get started with Figment
Register your app at /apple-connect/developers. Sandbox access is free—you can build and test the full authorization and messaging workflow against synthetic data before connecting a live Apple account.
When you are ready for real users, the subscription is $29/month per active live connection. Access starts after setup. Your users authorize through Figment's hosted consent screen and never share an Apple password with your application. Each connection grant is separately revocable at /apple-connect/account.
For a broader overview of what Figment can connect—including the available iMessage API and synthetic sandbox for Contacts, Calendar, and Reminders—see OAuth for iCloud: Connect Apple Data to Your App.
