Why iMessage agents are hard

If you have built a Telegram bot, a Discord bot, or a Slack app, the workflow is predictable. You create an app, get credentials, subscribe to events, receive messages, and send responses through an official API. The platform may have quirks, but it gives developers a clear surface to build on.

iMessage does not work that way.

Apple does not provide a public developer API for custom iMessage bots. There is no standard webhook system, no bot registration flow, and no official server-side way to receive and send iMessages the way you would on Telegram or Discord. Apple Messages for Business exists, but it is built for approved business support workflows, not for arbitrary AI agents with custom tools, memory, and application logic.

That is why every iMessage agent stack has tradeoffs. The real question is not simply "Can this send an iMessage?" It is whether the approach gives you enough reliability, identity, pricing, developer experience, and reach to ship something people can actually use.

For Photon, that is the starting point. We are not trying to make iMessage into a one-off trick. We are building the interaction layer for agents inside the messaging apps people already use.

Quick recommendation

If the agent is the product, choose Photon. If iMessage is only a sales outreach channel, Sendblue may fit better. If you are experimenting, BlueBubbles is a good way to learn the edges of the problem. The right answer depends on whether you are building a demo, an internal tool, or a user-facing agent experience.

What Photon is

Photon builds Spectrum, an open-source framework and managed cloud platform for bringing agents into messaging apps.

The idea is simple: your agent should not be trapped inside a dashboard, a browser tab, or a developer-only chat window. If the agent is useful, it should be able to live where people already talk — iMessage, WhatsApp, Telegram, Slack, Discord, Instagram, and whatever interface your users already open every day.

With Spectrum, iMessage is one provider in a broader agent interaction model. Your agent receives messages, replies in conversation spaces, sends rich content, reacts to events, and can expand across channels without rewriting the core product logic for each platform.

A minimal Spectrum agent looks like this:

import { Spectrum } from "spectrum-ts";
import { imessage } from "spectrum-ts/providers/imessage";

const app = await Spectrum({
  projectId: process.env.PROJECT_ID,
  projectSecret: process.env.PROJECT_SECRET,
  providers: [imessage.config()],
});

for await (const [space, message] of app.messages) {
  await space.responding(async () => {
    await message.reply("Hello from Spectrum.");
  });
}

import { Spectrum } from "spectrum-ts";
import { imessage } from "spectrum-ts/providers/imessage";

const app = await Spectrum({
  projectId: process.env.PROJECT_ID,
  projectSecret: process.env.PROJECT_SECRET,
  providers: [imessage.config()],
});

for await (const [space, message] of app.messages) {
  await space.responding(async () => {
    await message.reply("Hello from Spectrum.");
  });
}

import { Spectrum } from "spectrum-ts";
import { imessage } from "spectrum-ts/providers/imessage";

const app = await Spectrum({
  projectId: process.env.PROJECT_ID,
  projectSecret: process.env.PROJECT_SECRET,
  providers: [imessage.config()],
});

for await (const [space, message] of app.messages) {
  await space.responding(async () => {
    await message.reply("Hello from Spectrum.");
  });
}

That is the difference in philosophy. Photon is not only asking, "How do we send a text?" We are asking, "How do agents participate in real conversations, across the interfaces people already trust?"

For iMessage specifically, Photon gives teams a path to managed iMessage lines, SMS and RCS fallback, direct messaging, group messaging, real-time events, observability, and a developer model built around agents rather than one-off message delivery.

What Sendblue is

Sendblue is an iMessage API company that started with a strong focus on sales communication. Its positioning is around turning iMessage into a revenue channel, with features such as CRM integrations, sales workflows, a Chrome extension, and business messaging tools.

That makes Sendblue a good fit for a specific category: teams that want iMessage for sales outreach, lead follow-up, CRM-driven communication, and revenue operations. If your workflow starts in Salesforce or HubSpot and the goal is to help a sales team message prospects more effectively, Sendblue is worth evaluating.

The tradeoff is that AI agents are not the center of the product model. You can connect an agent to a REST API and webhook flow, but the product is not primarily a multi-channel agent framework. It is closer to a communication platform for sales teams that also exposes messaging APIs.

Use Sendblue when your main problem is sales messaging. Use Photon when your main problem is building an agent that needs to feel native in messaging apps.

Other ways to build an iMessage agent

BlueBubbles

BlueBubbles is one of the most practical DIY approaches. It runs on a Mac, connects to the local Messages environment, and exposes APIs that other services can use. If you already own a Mac and want full local control, BlueBubbles can be a good starting point.

The cost is operational. A Mac has to stay online. Permissions have to keep working. macOS updates can change behavior. Someone has to notice when delivery breaks. If your agent depends on a personal Apple ID or a machine under someone's desk, that machine has quietly become production infrastructure.

BlueBubbles is a good tool for learning, prototyping, and personal setups. It is less ideal when the agent is a product that users depend on.

AppleScript and macOS automation

AppleScript is the fastest way to send a simple message from a Mac. For one-way notifications, local scripts, or personal automation, it can be enough.

It is not a complete agent platform. There is no clean real-time incoming message model, no managed identity, no multi-user routing, and no obvious path to reliability. Once your agent needs to receive messages, maintain context, use tools, handle errors, and respond to real users, local automation becomes the wrong layer.

pypush and protocol experiments

Projects that explore the lower-level iMessage protocol are technically interesting. They can be useful for research and for understanding how messaging systems work under the hood.

They are not usually where you want to place a production agent. Experimental protocol work can change quickly, require unusual setup, and create operational or legal questions that most product teams do not want to own. If your goal is to learn, experiment. If your goal is to ship, choose a more stable path.

Feature comparison

The table makes the positioning clear. Sendblue is strongest when iMessage is a sales channel. BlueBubbles is strongest when you want local control and already accept the Mac requirement. Photon is strongest when the agent itself is the product and messaging is the interface layer around it.

Pricing and cost

Pricing is easy to compare on the surface and harder to compare honestly.

A Mac-based bridge can look free because the software has no license fee. But if you need to buy hardware, keep it online, maintain it, debug it, and design fallbacks around it, the real cost is not zero. It is paid in engineering time.

Sendblue is typically positioned for teams that can justify a higher per-line cost because the messages are tied to sales workflows and revenue operations. That pricing can make sense if one closed deal pays for the tool, or if the CRM workflow is the main value.

Photon is built for teams that care about more than the first iMessage. You are paying for a production path: managed messaging infrastructure, fallback behavior, real-time agent interaction, and the ability to use the same agent model across multiple interfaces. If your roadmap includes WhatsApp, Slack, Telegram, Discord, or other messaging surfaces, the cost comparison should include the integrations you do not have to build later.

The question is not "What is the cheapest way to send one iMessage from code?" The better question is "What is the cheapest way to build a reliable agent experience that can grow?"

For many teams, that answer is Photon.

API design: webhooks are not the whole story

Most messaging APIs are designed around sending and receiving messages. That is necessary, but it is not enough for agents.

Agents need a conversation model. They need to understand the space they are in, reply in context, send rich content when the platform supports it, adapt output to channel constraints, and connect messaging events to tools, memory, and human review. If you only have a raw webhook and a send endpoint, you still need to build the agent interaction layer yourself.

Photon's Spectrum model starts one level higher. Your code works with messages and conversation spaces, while providers handle platform-specific behavior. That means iMessage can be one surface instead of a special-case integration that slowly takes over the architecture.

That matters most after the first launch. The first iMessage demo is exciting, but real products need more than a demo. They need retries, logs, fallbacks, identity, internal testing, user controls, and a path to new channels. The less of that you build from scratch, the more time you can spend on the agent.

When to use Photon

Use Photon when you are building an agent that people are supposed to rely on.

That could be a personal AI assistant, a concierge agent, a customer support agent, a coding companion, a scheduling assistant, a community bot, or a product that starts in iMessage because that is where your users already are. In each case, the hard part is not only message delivery. The hard part is making the agent feel present, responsive, and trustworthy inside a familiar conversation.

Photon is a strong fit when:

• You want iMessage without maintaining your own Mac infrastructure.

• You want SMS and RCS fallback for users who are not on iMessage.

• You want a dedicated messaging identity for the agent.

• You expect to support more than one messaging app over time.

• You want an open-source SDK with managed cloud infrastructure available when you need it.

• You care about observability, audit logs, message history, and human-in-the-loop controls.

• You are building a product, not just a script.

The most important reason is simple: Photon lets you focus on the agent. Messaging should be infrastructure, not the project.

When to use Sendblue

Use Sendblue when your primary use case is sales communication.

If you need CRM integrations, a Chrome extension, sales workflows, lead follow-up, or revenue-team tooling, Sendblue may be the better fit. It is designed around that world, and those features matter when the users are sales teams rather than developers building agent products.

Sendblue can still be used with AI systems, but the center of gravity is different. You will likely be connecting your agent into a messaging API rather than building inside an agent-native framework.

When to use BlueBubbles

Use BlueBubbles when you want to experiment, learn, or keep everything under your control.

If you already own a Mac that can stay online, and if you are comfortable treating it as part of your infrastructure, BlueBubbles is one of the most useful DIY options. It is especially good for personal projects, internal demos, and understanding the shape of iMessage automation directly.

The mistake is not choosing BlueBubbles. The mistake is pretending that a local bridge and a production agent platform are the same thing.

Frequently asked questions

Does Apple have an official iMessage bot API?

No. Apple does not provide a public developer API for custom iMessage bots. Apple Messages for Business exists for approved business messaging flows, but it is not the same as a general-purpose bot API for custom agents.

Can I build an iMessage agent without a Mac?

Yes. Managed platforms such as Photon and Sendblue let you build iMessage experiences without running your own Mac bridge. Photon is the best fit when you want the iMessage agent to be part of a broader multi-channel agent architecture.

Is Photon only for iMessage?

No. Photon Spectrum is built for agents across messaging interfaces. iMessage is one important provider, but the broader goal is to connect agents to the apps people already use, including WhatsApp, Telegram, Slack, Discord, and more.

How is Photon different from Sendblue?

Sendblue is mainly built around sales communication and CRM workflows. Photon is built around AI agents and multi-channel messaging. If your main user is a sales team, Sendblue may fit. If your main product is an agent that needs to live in messaging apps, Photon is the stronger foundation.

How is Photon different from BlueBubbles?

BlueBubbles is a Mac-based bridge that you operate yourself. Photon gives you managed infrastructure and an agent-first SDK so you can build the conversation experience without maintaining local iMessage hardware.

Is this only for notifications?

No. Notifications are the narrow version of the problem. Photon is designed for two-way agent interaction: receiving messages, replying in context, participating in conversations, and connecting those conversations to your agent logic.

What is the best iMessage API for AI agents?

If you only need sales workflows, Sendblue is a strong option. If you want to build a real agent product that starts in iMessage and can expand across messaging apps, Photon is the best foundation.

Build where people already talk

People are not going to download a new app for every agent. They are not going to check another dashboard just because the model is smart. They are going to keep living in the interfaces they already trust.

That is why iMessage matters. It is not just another channel. For many users, it is where conversations already happen, where plans get made, where reminders land, and where people expect quick, natural responses.

Photon exists to put agents there.

With Spectrum, you can build the agent once, bring it to iMessage, support SMS and RCS fallback, and keep expanding to the other messaging apps your users already use. You do not have to start with a Mac under a desk, a pile of webhooks, or a channel-specific rewrite every time the product grows.

If you are building an AI agent that should feel less like software and more like something people can actually talk to, start with Photon.