← Danny Mundy

iMessage on Windows, Without a Mac

March 2026

TLDR: My Mac got stolen, so I reverse-engineered Phone Link and combined three Bluetooth profiles (ANCS, MAP, PBAP) into an open-source Windows daemon that lets you read and send iMessages and SMS from your iPhone, without a Mac or jailbreak. The result is adit.

My Mac got stolen last week. The week before that, I'd been building a channel for OpenClaw, and it needed access to my texts to work. I have an iPhone and use iMessage constantly. I assumed iMessage without a Mac was impossible, but I kept digging.

Every existing solution assumes you have a Mac. BlueBubbles runs a server on macOS that talks to Messages.app. AirMessage does the same thing. OpenClaw's iMessage channel routes through a Mac host. The reason is simple: Apple locks iMessage inside its own frameworks. There's no public API, no protocol you can speak from another platform. If you don't have a Mac, you don't get iMessage. That's what everyone says, and it's mostly right.

The one exception I could find was Phone Link, which gets partial iPhone access without a Mac (notifications and SMS, not real iMessage) but it's flaky, closed, and limited. I decompiled it to find out why it works at all.

It was using three separate Bluetooth profiles: ANCS for notifications, which includes iMessage previews; MAP for message access, which covers reading and sending SMS; and PBAP for contacts. None of those gives you full iMessage, and none of them is enough by itself, but together they give you notifications, names, numbers, read access, and a send path for the parts Apple still exposes. I couldn't find a public project that combined them into something open and programmable. Microsoft had already combined them inside Phone Link. I wanted the open version.

Two days later, with help from GPT 5.4 and Claude Opus 4.6, I had a Windows daemon pulling iMessage notifications, reading and sending SMS, syncing contacts, and exposing the result over a local API.

That still did not produce a true Apple-native iMessage client. What it gave me was a Windows messaging layer: SMS read/send, iMessage notification visibility, contacts, and enough local reconstruction to be useful.

I open-sourced it as adit: a local Windows daemon with a REST API, WebSocket stream, and thin JS/Python/MCP SDKs on top.

Phone Link Was the Spec

The first thing I wanted to know was whether Microsoft had some private path to the iPhone that I didn't. If Phone Link depended on a secret Apple API or some entitlement normal apps can't get, the project was dead before it started.

I decompiled it with ILSpy: YourPhone.Connectivity.Bluetooth.Managed.dll, YourPhone.YPP.Bluetooth.dll, and a few related assemblies. What I found was reassuring. Phone Link wasn't doing anything magical. It was using the same Windows Bluetooth APIs I could call, talking to the same profiles every iPhone already exposes. The ceiling I could hit was the same ceiling Microsoft was already working under.

ANCS was the first one I chased. Windows could see the service on my iPhone, but every attempt to subscribe to its characteristics died at AccessDenied. I tried the obvious fixes (Developer Mode, package identity, Bluetooth capabilities) and none of them changed it.

The fix was a single call I found in Phone Link's decompiled code: GattDeviceService.OpenAsync(). After I added it, the ANCS path opened up immediately and live iMessage notifications started streaming into a Windows terminal.

var access = await WaitAsync(service.RequestAccessAsync(), WinRtOperationTimeout, cancellationToken);
var openStatus = await WaitAsync(service.OpenAsync(GattSharingMode.SharedReadAndWrite), WinRtOperationTimeout, cancellationToken);
if (openStatus is GattOpenStatus.Success or GattOpenStatus.AlreadyOpened)
{
    return true;
}

var serviceAccess = await service.RequestAccessAsync();
var openStatus = serviceAccess == DeviceAccessStatus.Allowed
    ? await service.OpenAsync(GattSharingMode.SharedReadAndWrite)
    : GattOpenStatus.Unspecified;

[event_id][flags][category][count][notification_uid:u32_le]

Taking Over the MAP Session

ANCS gave me notifications, but notifications aren't messages. For real SMS read and send, I needed MAP, the Bluetooth Message Access Profile, an older standard that runs over classic Bluetooth instead of BLE.

Inside Phone Link's installed package were private Microsoft DLLs that already implemented the full MAP stack: Microsoft.Internal.Bluetooth.Map.dll, Microsoft.Internal.Bluetooth.Obex.dll, Microsoft.Internal.Bluetooth.Pbap.dll. They aren't documented and they aren't part of any public SDK. I loaded them with reflection.

Phone Link's background processes (PhoneExperienceHost.exe and CrossDeviceResume.exe) were already holding the MAP path open. The iPhone only accepts one MAP client at a time, so the fix was blunt: kill both processes before opening the session.

After that, MAP opened on the first try. PushMessageAsync came back Success, and the SMS showed up on my iPhone a few seconds later.

private static readonly string[] ProcessNames =
[
    "PhoneExperienceHost",
    "CrossDeviceResume"
];

var result = await client.PushMessageAsync(
    MapClientInterop.CreatePushMessageRequest(recipient, body),
    traceContext,
    cancellationToken);

var pushResult = await mapClient.PushMessageAsync(
    CreatePushMessageRequest(options.Recipient, options.MessageBody),
    CreateTraceContext(),
    cancellationToken);

The limitation showed up immediately. Every message MAP returned was typed SMS_GSM. Even when the same MobileSMS content also showed up through ANCS, MAP flattened it into SMS-shaped rows with no Apple-native thread or iMessage metadata. ANCS knew about iMessages as notifications. MAP gave me durable message bodies, but not a real iMessage surface. That gap defined most of the hard problems later.

The third profile was PBAP (Phone Book Access Profile) for contacts. Microsoft had a private DLL for that too. I loaded it the same way, pulled 95 contacts off my iPhone, and wrote a PhoneNumberNormalizer so +18002752273, (800) 275-2273, and 8002752273 all resolved to the same person. Without contacts, everything else is just raw phone numbers.

var contactsResult = await InvokePbapAsync(
    client,
    "PullPhoneBookAsync",
    new PullPhoneBookRequestParameters
    {
        ListStartOffset = 0,
        MaxListCount = 200,
        Name = "telecom/pb.vcf",
        Format = RequestFormat.VCard21,
        Filter = AttributeMask.FormattedName
            | AttributeMask.StructuredName
            | AttributeMask.PhoneNumber
            | AttributeMask.EmailAddress
            | AttributeMask.UID
    },
    cancellationToken);

var hasLeadingPlus = trimmed.StartsWith('+');
var digits = new string(trimmed.Where(char.IsDigit).ToArray());

if (hasLeadingPlus)
{
    return $"+{digits}";
}

if (digits.Length == 11 && digits.StartsWith(defaultCountryCode, StringComparison.Ordinal))
{
    return $"+{digits}";
}

if (digits.Length == 10 && !string.IsNullOrWhiteSpace(defaultCountryCode))
{
    return $"+{defaultCountryCode}{digits}";
}

With all three profiles working independently, the protocol side was proven. The next problem was turning those three partial views into one messaging system.

The Hard Part Was Threads

Getting data off the phone was only half the job. None of these channels gave me a real conversation model. ANCS had iMessage previews but no bodies. MAP had durable message bodies, but only in SMS-shaped records with no real thread structure. PBAP had names and numbers but no message context at all. If I wanted something an agent could actually use, I had to build the conversation layer myself.

That meant inventing stable local thread IDs, matching ANCS previews against later MAP rows, dealing with group messages that showed up differently across channels, and deciding when two fragments were really the same message. Bluetooth gave me slices. It didn't give me a messaging system.

The core of it was a ConversationSynthesizer that normalized MAP rows, ANCS notifications, and PBAP contact data into one observation stream, tried to resolve which fragments referred to the same people and messages, clustered them into candidate conversations, and assigned stable local thread IDs that survived daemon restarts.

Group chats were the worst part. MAP gave me no usable group model, and for iMessage groups it was basically blind. The only reliable hints came from ANCS notification subtitles, which sometimes included a group name or participant list. I was inferring group structure from notification metadata.

ANCS also created what I started calling shadow messages. An iMessage notification would come in through ANCS with a sender and preview text, but there'd be no matching durable row in MAP with the same structure because MAP only gave me SMS-shaped records. So the synthesizer would create a provisional message from the ANCS data alone, and if a matching MAP row showed up later, it would promote and merge them. If it didn't, the shadow stayed as the only evidence that message existed.

var delta = CalculateMessageDelta(shadow.SortTimestampUtc, durable.SortTimestampUtc);
if (delta is null || delta > TimeSpan.FromMinutes(20))
{
    return int.MinValue;
}

var previewMatch = PreviewsLikelyMatch(shadowPreview, durablePreview)
    || ReactionSemanticsLikelyMatch(shadowPreview, durablePreview);
var senderMatch = MessagesLikelyShareSender(shadow, durable);
var participantOverlap = CountParticipantOverlap(shadow.Participants, durable.Participants);

return durable with
{
    ConversationDisplayName = durable.IsGroup
        ? durable.ConversationDisplayName
        : shadow.ConversationDisplayName.Length > durable.ConversationDisplayName.Length
            ? shadow.ConversationDisplayName
            : durable.ConversationDisplayName,
    IsGroup = durable.IsGroup || shadow.IsGroup,
    Participants = mergedParticipants,
    Message = durable.Message with

The synthesizer grew to about 4,000 lines. It handled a lot of cases. It also kept breaking.

When Heuristics Stopped Working

The bug that made me rethink the whole approach was a group thread. Direct messages from one person kept getting grouped into a group chat they were also in. The synthesizer would split them correctly on a fresh run, but after a daemon restart with persisted thread history, the direct conversation and the group would collapse back into one thread. I'd fix the rule, run the tests, watch them pass, restart the daemon on live data, and the same messages would end up in the wrong place again.

The root cause kept shifting. First it was a continuity bug: two conversations claiming the same historical thread ID. I fixed that. Then it was a sender-overlap issue: mom appeared in both the group and the direct thread, and the synthesizer couldn't tell the difference with low message counts. I fixed that. Then it was a scoring edge case where blank and reaction-only messages were inflating continuity scores. Every fix uncovered a new failure mode.

That's when I realized the problem wasn't any individual rule. The synthesizer was 4,000 lines of heuristics that worked on most inputs but couldn't generalize to the edge cases that actually mattered. Every new rule I added to fix one case risked breaking three others. Phone Link has the same problem. Its thread assignment is still broken, with users reporting messages landing in wrong conversations and phantom group chats for years. The abstraction was wrong. Thread assignment wasn't a rules problem. It was a classification problem.

I built a learned chooser alongside the heuristic core: a frozen Qwen encoder for the text, plus a small chooser model on top that ranked candidate threads. I trained it on synthetic MAP and ANCS fragments generated with Claude Opus, including the same kinds of corruption that kept breaking the rule-based system: bad timestamps, missing fields, ambiguous sender overlap, stale thread history.

The listwise approach was important. The model didn't score threads in isolation. It scored 3–8 candidate threads against each other, so it could learn that a message fit thread A better than thread B even when both looked plausible. That's the kind of judgment the heuristics couldn't express.

I didn't want to hand-wave the pivot, so I built evals for it. Qwen didn't solve threading by itself. What the evals showed was that a semantic branch, fused with the structural features I already had, bought the last ten points on the hard benchmark without regressing on the real anchors.

What I Ended Up Shipping

The shipping system is a Windows daemon that holds MAP, ANCS, and PBAP sessions open, fuses them into stable threads, and exposes the result over a local API. Thin Python and JavaScript SDKs sit on top so nothing downstream touches Bluetooth. The whole stack runs on stock hardware with no Mac, no jailbreak, no relay server.

It still isn't a true iMessage client. iMessages arrive as notifications, SMS has the real send/read path, and group structure is inferred locally. But even in that shape, it turns an iPhone into a programmable messaging surface from Windows, which is what I needed.

What I Learned

Agent software is going to be bottlenecked less by models than by ugly real-world integrations. Getting an LLM to write a reply is easy. Giving it a reliable, programmable view of who texted you, what they said, and whether it can respond is the hard part. Most of the interesting work is in those missing surfaces.

I also came away respecting Phone Link. The reverse engineering was clarifying. Microsoft had already found most of the same hard boundaries I did. They shipped a closed product on top of them; I wanted a programmable one.

If you want to talk about this, email me at [email protected]. Source is on GitHub. If you'd rather text, Phone.