DEV Community: Devin

Wiring an ACP agent into Xcode: the field notes

Devin — Mon, 26 Oct 2026 15:47:43 +0000

On 2026-10-26 we wired Claude Code into Xcode 27.1 (build 25183.120.5) using the built-in ACP support. Xcode's Add an ACP Agent dialog asks for five fields: Name, Executable, Interpreter, Arguments, and Environment Variables. No plugin, no project file: point Xcode at one executable and get the handshake right.

These notes cover what we ran, what came back, and four failures. Everything below was verified in a terminal. We did not verify the GUI session end to end.

What ACP is doing inside Xcode

ACP is the Agent Client Protocol. An editor acts as the client, driving an agent over JSON-RPC on stdio. Xcode 27.1 ships the client side as IDEIntelligenceACP.framework under Xcode.app/Contents/PlugIns/. It sends protocol requests and does not care what is on the other end.

The Claude Code CLI does not speak ACP. A small adapter translates ACP requests into something Claude Code understands and returns the result as ACP. The package you install is the adapter, not Claude Code itself.

Step 1: install the adapter under its current name

The old package is deprecated. Check it first:

npm view @zed-industries/claude-code-acp version deprecated
# 0.16.2
# This package has been renamed to @agentclientprotocol/claude-agent-acp.
# Please migrate to continue receiving updates.

Install the new one:

npm i -g @agentclientprotocol/claude-agent-acp
which claude-agent-acp
# /Users/<your-username>/.npm-global/bin/claude-agent-acp

If your npm prefix differs, run npm prefix -g and look under <prefix>/bin/. Our machine had 0.95.0 installed; the latest on npm at the time was 0.97.0.

Do not put npx in the Executable field. Xcode starts the agent in something closer to a clean shell; npx may download the package on the spot, stop at a prompt, or resolve a different version. A global install gives you one fixed entry point.

Confirm what npm produced:

ls -lL ~/.npm-global/bin/claude-agent-acp
file ~/.npm-global/bin/claude-agent-acp
# a /usr/bin/env node script text executable

It is a #!/usr/bin/env node script, not a native binary. That decides how you fill in Interpreter.

Step 2: fill the five fields

Field	Value	Why
Name	`Claude Agent`	Display name; avoid an existing agent's name
Executable	`/Users/<your-username>/.npm-global/bin/claude-agent-acp`	Absolute path; `~` is not guaranteed to expand
Interpreter	leave empty	The script has a shebang; the kernel finds node
Arguments	leave empty	The adapter reads ACP from stdio and needs no flags
Environment Variables	usually empty	Only needed if node is missing from Xcode's inherited PATH

Interpreter is the field people overfill. Xcode's help says to specify one only when the executable is a script that needs it; Xcode then runs the executable as an argument to that interpreter. This adapter already starts with #!/usr/bin/env node.

Point Executable at the bin/ entry, not lib/node_modules/.../dist/index.js; the bin/ symlink is npm-managed, while the dist path can move.

Arguments only appends flags. This adapter needs none, and extra values can be read as unknown options.

Step 3: probe the handshake before opening Xcode

The first ACP request is initialize. It does not create a session or read project files; it exchanges protocol version and capabilities. A small Python script proves the adapter launches:

import json
import subprocess

req = {
    "jsonrpc": "2.0",
    "id": 1,
    "method": "initialize",
    "params": {
        "protocolVersion": 1,
        "clientCapabilities": {
            "fs": {"readTextFile": True, "writeTextFile": True},
            "terminal": True,
        },
        "clientInfo": {"name": "acp-probe", "version": "0.1.0"},
    },
}

p = subprocess.Popen(
    ["/Users/<your-username>/.npm-global/bin/claude-agent-acp"],
    stdin=subprocess.PIPE,
    stdout=subprocess.PIPE,
    text=True,
    bufsize=1,
)
p.stdin.write(json.dumps(req) + "\n")
p.stdin.flush()
print(p.stdout.readline())
p.terminate()

ACP uses line-delimited JSON-RPC: one request per line, one response per line. You should see one JSON line immediately. This is the real response from the new package, version 0.95.0, on our machine:

{"jsonrpc":"2.0","id":1,"result":{"protocolVersion":1,"agentCapabilities":{"_meta":{"claudeCode":{"promptQueueing":true},"authStatus":{}},"promptCapabilities":{"image":true,"embeddedContext":true},"mcpCapabilities":{"http":true,"sse":true},"auth":{"logout":{}},"providers":{},"loadSession":true,"sessionCapabilities":{"additionalDirectories":{},"close":{},"delete":{},"fork":{},"list":{},"resume":{},"systemPrompt":{"mode":{"override":{}}}}},"agentInfo":{"name":"@agentclientprotocol/claude-agent-acp","title":"Claude Agent","version":"0.95.0"},"authMethods":[],"_meta":{"steering":{"supported":true}}}}

Run the same script against the old path, ~/.npm-global/bin/claude-code-acp, and the capability block differs:

The old package's sessionCapabilities has only fork, list, and resume; the new one adds close, delete, additionalDirectories, and systemPrompt.mode.override.
The new package adds claudeCode.promptQueueing, authStatus, auth.logout, and providers under agentCapabilities.
The old package returns one authMethods entry, claude-login; the new package returns [] and expresses login state through authStatus.

These fields are version-specific; do not treat this JSON as a contract.

Reading the response

promptCapabilities.image and embeddedContext: the client may send images and embedded context; whether Xcode does is separate.
mcpCapabilities.http and sse: the adapter accepts those MCP transports, not that it connects on its own.
loadSession: true and sessionCapabilities: reload and session operations. authMethods: [] means no ACP login method; check authStatus.

Together these identify the installed binary without trusting the version string.

Troubleshooting the four failures

1. Quarantine or permissions. Check extended attributes first:

xattr -l ~/.npm-global/bin/claude-agent-acp

If com.apple.quarantine is present, remove it with xattr -d com.apple.quarantine <path> and retry. On our machine the only attribute was com.apple.provenance — the provenance "ghost" attribute, not quarantine — and Gatekeeper did not block it. If Xcode raises a Files and Folders or Full Disk Access prompt, the prompt is usually attributed to Xcode, the parent process.

2. Node is not on PATH. The shebang uses the PATH inherited by the process, not the PATH after you source ~/.zshrc. which node working in your terminal does not prove Xcode can see it. Add PATH under Environment Variables and leave Interpreter empty, or set Interpreter to node's absolute path while Executable stays the script. Check first:

which node        # for example /usr/local/bin/node
node --version    # our machine: v24.12.0

3. The script is not executable. Inspect the symlink and its target:

ls -l ~/.npm-global/bin/claude-agent-acp
ls -lL ~/.npm-global/bin/claude-agent-acp
test -x ~/.npm-global/bin/claude-agent-acp && echo executable

If file says "script text executable" but test -x fails, the permission bits were lost. Run chmod +x on the target file. A normal npm global install is 755; upgrades and manual copies break this.

4. The handshake times out. The Python probe blocks on readline(). If nothing comes back: run the executable directly and see whether it exits with an error; confirm node --version works; confirm you are pointing at the bin/ entry and not a stale path from the old package. initialize does not require login. If a later session reports an unauthenticated state, run claude once in a terminal. "Xcode shows nothing" is not a diagnosis; the terminal probe is the minimal reproduction.

How we judged success

The terminal bar is simple: result.agentInfo.name matches the package you installed, protocolVersion is 1, and agentCapabilities is not empty. That proves the command Xcode will launch can start, read a request, and answer over ACP.

We then saved the configuration and created a session, but did not verify every GUI behavior, so we are not vouching for it. Once the handshake passes, the remaining problems tend to be PATH, permissions, or login.

Scope and caveats

Based on our own setup on 2026-10-26; Apple has not documented ACP in Xcode beyond the dialog. The commands and JSON response come from that machine's output, not a vendor walkthrough. ACP is changing quickly. Run the initialize probe against your installed version before debugging the dialog.

App Store review is backed up — what a developer can actually do this week

Devin — Mon, 26 Oct 2026 12:13:02 +0000

App Review is running weeks behind for some developers: through late October 2026, threads on Apple's developer forums describe apps stuck in "Waiting for Review" for three weeks, a month, and in one reported case since 19 September. The delays are concentrated in first submissions of new apps and in resubmissions after a rejection; developers shipping routine updates to established apps are mostly still seeing the usual day or two.

The advice differs by queue. Here is what is documented, what developers report, and what can change your week.

First, separate the average from the tail

Per Apple's documentation: "App Review works around the clock with the goal of reviewing at least 50% of submissions in less than 24 hours and 90% in less than 48 hours."

That is a target, not a promise for your submission. The useful context came from Apple's response to MobileGamer.biz on 20 October: over the previous 12 weeks, App Review processed an average of 378,000 submissions per week, with an average review time of 1.5 days for all apps and 14 hours for minor updates. Apple also said some new apps take longer when they need additional scrutiny, and that it had prioritized updates to existing apps, expanded automation, strengthened abuse detection, and added safeguards against repeated submissions with the same unresolved issues.

An average of 1.5 days is compatible with a long tail of three-week waits. The Information's April report of an 84% year-on-year jump in submissions is repeated by both outlets; it is secondhand, not an Apple metric.

Developers report: "Reviews often take 3–5 days, even when expedited, while feedback is frequently vague and appears not to reflect our app descriptions or testing instructions," one studio boss told MobileGamer.biz. The Register collected forum posts titled "Stuck in Waiting for Review for about 3 weeks" and "Stuck in 'Waiting for Review' since October 8"; one developer said they had been waiting since 19 September. MobileGamer.biz also spoke to a studio with a five-year-old game that had seen no change in update review times. The pattern is new apps and post-rejection resubmissions, not routine updates.

Seven actions for this week

1. Classify your submission before you do anything else.
A first submission of a new app, an update to a live app, and a resubmission after a rejection are not the same queue in practice. The reported pain is in the first and third. If you are in the update queue and within 48 hours, wait; if you are a new app at day seven, start the escalation path below.

2. Do not resubmit just to bump the queue.
Per Apple's documentation, a resubmission starts a new review rather than moving the existing one up; in the Bug Fix flow it says: "Do not resubmit the app at this time, as it will trigger a new review." Apple also told MobileGamer.biz that it had added safeguards against repeated submissions with the same unresolved issues, which is a strong hint that churn does not help.
Developers report: uploading replacement builds while waiting can move you to the back of the line. Apple has not documented this; treat it as a risk. One submission, then use the documented channels.

3. Use expedited review only if you meet one of two conditions.
Per Apple's documentation, only submissions already sent to App Review can be expedited, and the request goes through "Request an Expedited App Review" with the app and platform selected. The eligible reasons are a critical bug fix or a release that must align with a dated event. For a bug, put the specifics in the Notes field; for an event, give the event, its date, and how the app relates to it.
Two constraints are easy to miss. Apple decides "as allowed by availability and demand", and it warns that "Expedite requests should be reserved for matters of genuine urgency." A request that says "we would like to launch sooner" is not one of the two categories.

4. If you were rejected, reply before you resubmit.
Per Apple's documentation, "Using App Store Connect to contact App Review is the best way to receive assistance with an ongoing submission", and a specialist familiar with your app will reply. Be specific about the feature, guideline, or step. Do not use this window to appeal or to request an expedited review; Apple says to use the appropriate Contact Us form for those.
A reply that tends to get a useful answer looks like this:

Build 1.4.2 (318) is the submission under review. The feature you flagged is at Settings > Export > CSV. Demo account: review@example.com. The backend flag export_v2 is enabled for that account. Attached are a 40-second screen recording and a point-by-point mapping to Guideline 2.1. Could you confirm whether this resolves the issue?

If you need a call, request it in the same window with your time zone and language. Apple says calls typically complete within three to five business days.

5. Check the rejection for the Bug Fix Submission offer.
Per Apple's documentation, if the message begins "Bug Fix Submissions: The issues we've identified below are eligible to be resolved on your next update", you can reply to accept the current submission and fix the issues next time. The same page is explicit: "Do not resubmit the app at this time, as it will trigger a new review." All deferred issues must be fixed in the next update, and the same issue cannot be deferred twice in a row.
This is the fastest documented path for a live app with a fixable metadata problem. It does not cover legal or safety issues, and it is not available for a first submission.

6. Appeal once, and only after clarification fails.
Per Apple's documentation, an appeal to the App Review Board is for three situations: you believe a rejected or removed app follows the guidelines; your account faces termination but you believe it complies; or you believe the review was unfair or biased. Reply first, then appeal if the clarification does not resolve it. Submit one appeal per app, address every cited violation in that one appeal, and note that the form accepts up to five apps. Do not use an appeal to ask for a status update, an expedite, or reinstatement of an already-terminated account.

7. Build the review packet now, not after the rejection.
The cheapest delay to remove is a reviewer having to guess. Put a demo account or demo mode, the exact path to each flagged feature, backend flags or regional dependencies, and a short screen recording in the Notes field before submission. If a feature needs a server state that is hard to reach, say how to reach it. It does not speed up the queue, but it can cut a rejection loop from three round-trips to one.

A five-day plan

Monday: classify the submission as new, update, or resubmission. Tuesday: rewrite the notes and record the demo path. Wednesday: submit the expedited request if you qualify, or send one precise reply. Thursday: fix what you can without a new build. Friday: reassess. One follow-up is reasonable; a daily ping is not.

What not to do

Do not file an appeal as a status check. Do not request an expedite without a critical bug or a dated event. Do not resubmit an unchanged binary and expect a different queue. Do not treat the 1.5-day average as a commitment. And do not assume "AI-generated" is a rejection reason: Apple says every app is held to the same standards; the backlog is about volume, not a ban.

None of this guarantees approval or shortens the queue. It keeps your submission from losing another week to a process mistake.

If you're already in a rejection loop, I packaged the 10-step 48-hour checklist and the two Resolution Center reply templates into one download. Get it here — App Store Rejection Response Kit — Free (free, email required).

A full checklist with source links is here: https://hhfa008.github.io/personal/app-store-rescue.html

CocoaPods Is Going Read-Only: Migrating a 20+ Dependency iOS App to Swift Package Manager

Devin — Mon, 26 Oct 2026 11:37:54 +0000

Your Podfile still installs. That is exactly why this is easy to postpone — and why a project with twenty-plus dependencies should start now rather than in December.

First, what actually changes

CocoaPods trunk is moving to a read-only state. In the official words:

"December 2nd 2026 — I will switch trunk to not accept new Podspecs permanently."

And from Firebase:

"Firebase 12 is the final major version published to CocoaPods, and Firebase will stop publishing new versions to CocoaPods in October 2026."

Read-only is not shut down. Existing pod versions stay downloadable, the Specs repo and CDN keep serving, and pod install keeps resolving what it resolves today. CocoaPods is explicit about this: "Making the switch will not break builds for people using CocoaPods in 2026 onwards." Firebase says the same about its own packages: existing versions "in CocoaPods will remain installable and functional as long as CocoaPods ecosystem support continues."

What you lose after December is the ability to receive new versions through trunk. For an app that ships quarterly, that is a slow, undramatic problem — the worst kind, because nothing pages you at 3 a.m.

Timeline

When	What happens
2024-11-30	CocoaPods announces the plan: "In two years we plan to turn CocoaPods trunk to be read-only."
Mid–late 2025	First email to everyone who contributed a Podspec
Sep–Oct 2026	Second email, roughly one month before the test run
Oct 2026	Firebase stops publishing to CocoaPods; Firebase 12 is the last major version
Nov 1–7, 2026	Test run of read-only, "giving automation a chance to break early"
Dec 2, 2026	Trunk permanently stops accepting new Podspecs
After	Existing versions remain installable; Specs repo and CDN keep serving

CocoaPods adds a caveat worth quoting: "These dates are not set in stone." Treat the December date as a planning deadline, not a hard API cutoff. Flutter has already moved in the same direction — starting with Flutter 3.44, Swift Package Manager replaces CocoaPods as the default for iOS and macOS apps — so the direction of travel is not in question.

Step 1: Inventory and freeze

Do this on a branch, and commit the current working state before you touch anything.

cd "$(git rev-parse --show-toplevel)"
git checkout -b spm-migration

grep -nE "^\s*pod " Podfile | tee /tmp/pods.txt
wc -l < /tmp/pods.txt

git add Podfile Podfile.lock
git commit -m "chore: snapshot CocoaPods state before SPM migration"

Then go through /tmp/pods.txt line by line and mark each dependency: has a Swift package, has a binary xcframework, or has neither. The third bucket decides your schedule. Twenty pods where eighteen migrate cleanly is a week; three pods with no package support can eat a month.

One thing people miss: CocoaPods subspecs do not map one-to-one onto Swift packages. A pod like Vendor/Core and Vendor/UI may become two products of a single package, or one product with everything included. Read the vendor's own SPM instructions.

Step 2: Deintegrate

Quit Xcode first. pod deintegrate rewrites the project file, and an open Xcode window will happily overwrite those changes when it saves.

pod deintegrate
pod clean

mkdir -p archive/cocoapods
git mv Podfile archive/cocoapods/Podfile
git mv Podfile.lock archive/cocoapods/Podfile.lock

rm -rf Pods *.xcworkspace
git status --short

Archive, do not delete. The Podfile.lock is your rollback artifact for the rest of the migration.

Step 3: Add the packages

For an app target, the path of least resistance is Xcode: open the .xcodeproj, choose File → Add Package Dependencies, paste the repository URL, pick the products, and confirm they are added to the target's "Frameworks, Libraries, and Embedded Content."

If your app is split into local Swift packages, declare the dependency in Package.swift instead:

// swift-tools-version: 6.0
import PackageDescription

let package = Package(
    name: "AppCore",
    platforms: [.iOS(.v17)],
    dependencies: [
        .package(
            url: "https://github.com/firebase/firebase-ios-sdk",
            from: "12.0.0"
        )
    ],
    targets: [
        .target(
            name: "AppCore",
            dependencies: [
                .product(name: "FirebaseAuth", package: "firebase-ios-sdk"),
                .product(name: "FirebaseFirestore", package: "firebase-ios-sdk")
            ]
        )
    ]
)

Commit Package.resolved alongside Package.swift. It is the SPM equivalent of Podfile.lock, and without it your CI and your laptop can resolve different revisions of the same branch-based dependency.

Step 4: Clean the leftovers

CocoaPods leaves more behind than the Pods/ directory. Check for:

grep -n "PODS_ROOT\|Pods/" App.xcodeproj/project.pbxproj

You are looking for build settings pointing at ${PODS_ROOT}, and build phases named [CP] Check Pods Manifest.lock, [CP] Embed Pods Frameworks, and [CP] Copy Pods Resources. Remove them.

Keep the Crashlytics dSYM upload run script, but note that Firebase documents a different script path for SPM checkouts than for CocoaPods installs. Copy the current version from the Crashlytics setup page rather than editing the old path by hand. A stale path here fails silently: uploads just stop, and you find out weeks later when a crash report has no symbols.

Step 5: CI

The failure mode in CI is almost always cache, not code. Old caches still contain a Pods/ directory and a stale workspace that no longer exists in the repo.

- name: Resolve packages
  run: |
    rm -rf ~/Library/Caches/CocoaPods
    rm -rf ~/Library/Caches/org.swift.swiftpm
    xcodebuild -resolvePackageDependencies \
      -project App.xcodeproj \
      -scheme App \
      -clonedSourcePackagesDirPath "$PWD/.spm-cache"

- name: Build
  run: |
    xcodebuild -project App.xcodeproj \
      -scheme App \
      -destination 'generic/platform=iOS' \
      -clonedSourcePackagesDirPath "$PWD/.spm-cache" \
      -onlyUsePackageVersionsFromResolvedFile \
      build

Cache .spm-cache with the hash of Package.resolved as the key, and drop any cache keyed on Podfile.lock. -onlyUsePackageVersionsFromResolvedFile makes CI fail loudly on a resolution mismatch instead of quietly pulling something newer.

Step 6: Verify, then keep the exit open

Run a clean build from an empty derived data directory, then exercise the paths that dependency managers actually break: login, a database read, push registration, a crash upload, and one analytics event. Those five cover most of what a migration silently damages.

Rollback stays cheap for as long as you keep the branch: git revert the migration commit, restore archive/cocoapods/, and pod install. Once you delete that archive, rollback becomes a rewrite.

Three pitfalls that cost real time

Private pods. A private pod becomes a Swift package hosted in a private Git repository. Xcode will prompt for credentials locally; CI needs an SSH key or a token wired into git. If the private pod ships as a prebuilt binary, it cannot become a normal package — it becomes a .binaryTarget, and the artifact must be an xcframework.

Binary dependencies. For a local artifact:

.binaryTarget(name: "VendorSDK", path: "Vendor/VendorSDK.xcframework")

For a remote one you need both url and checksum, and the checksum must be recomputed every time the artifact changes. Plain .framework files and static .a libraries are not accepted; they have to be repackaged as an xcframework first.

Resource bundles. CocoaPods resource_bundles become SPM resources on the target:

.target(
    name: "DesignSystem",
    resources: [.process("Resources")]
)

Use .process for images and asset catalogs so they get optimized, .copy for directories whose structure must be preserved. Access them with Bundle.module — and remember that Bundle.module only exists inside the package that declares the resources. If the app needs to reach them, expose a small accessor from the package instead of referring to Bundle.module from app code, which will not compile.

One judgment

This is a registry freeze, not a shutdown: nothing you shipped breaks on December 2. But a twenty-dependency migration is a multi-week job with a binary-artifact worst case, and the November test run is when other people's automation finds its bugs. If CocoaPods is still in your Podfile, put the branch on the calendar this month.

More iOS migration write-ups and project notes: https://hhfa008.github.io/personal/cases.html