Live Assistance: Symbols in the Docs, Rules in the Contract

Apple revised the Apple Developer Program License Agreement on October 13, 2026. Two of the changes govern capabilities whose rules are written down nowhere else — and for one of them, Apple’s documentation gives you a complete technical picture and a wrong commercial one.

What the October 13 revision contains

Apple’s developer news post lists the changes verbatim. Section 3.2 got “updated security and related requirements.” Two new definitions and subsections arrived: §3.3.8(j), “terms for use of the Live Assistance API,” and §3.3.8(k), “terms for use of the App Replacement Entitlement.”

The rest of the list is easy to skim past and shouldn’t be. Sections 6.4, 6.4.1 and 6.4.2 cover iOS app widgets on Apple HomeView and availability of iOS apps for CarPlay on Apple HomeView. Schedules 2 and 3 add terms for offering multiple subscription seats through Group Purchases, and for subscriptions sold to Apple Business and Apple School Manager organizations through Volume Purchasing. Two further schedule changes state that Apple will report legally required tax, sales and contact details to tax authorities, and restrict developers’ use of any customer tax information Apple shares to purposes mandated by law.

One piece of citation hygiene. Checked on October 22, 2026, the agreements index page at developer.apple.com/support/terms/ showed “Last update: August 18, 2026” for the Program License Agreement, while the document’s own footer showed Schedules 1, 2 and 3 last updated October 13, 2026 — and the live body text contains §3.3.8(J) and (K). I’m not asserting a cause. The practical lesson is that the index date is not a reliable way to tell whether you’ve read the current agreement. The body text is.

§3.3.8(J) reads like a spec

Here is the entire subsection. Its brevity is the point.

3.3.8 (J) At an end user’s invitation, Your Application or Corresponding Product may use the Live Assistance API solely for the purpose of enabling an accessibility service provider to join the end user’s FaceTime call to provide accessibility services (e.g. captioning, translation, etc).

The definitions section adds: “Live Assistance API” means the Documented API that enables an Application or Corresponding Product to connect to an end user’s FaceTime call.

Read as a specification, that sentence contains four independent gates, all of which must hold.

At an end user’s invitation. The trigger comes from the person on the call. Not from your backend, not from an operator console, not from a scheduled job.
An accessibility service provider joins. The identity of the third party is constrained, not just the feature’s marketing label.
The end user’s FaceTime call. This is the most commercially consequential word in the clause.
To provide accessibility services (e.g. captioning, translation, etc). The “e.g.” and “etc” make the examples illustrative rather than closed, but the governing noun phrase is still “accessibility services.”

Nothing in Apple’s public API reference states any of this.

The reference tree exists; the prose doesn’t

As of October 22, 2026 there is a symbol-level reference on developer.apple.com: LiveAssistance, LiveAssistanceExtension, LiveAssistanceRequest, LiveAssistanceRequestError, LiveAssistanceLaunchReason, LiveAssistanceExtensionConfiguration, plus a documented entitlement, com.apple.developer.conversation-accessibility. All are marked 27.2 across iOS, iPadOS, Mac Catalyst, macOS and visionOS — and iOS 27.2 was at release candidate, seeded October 19, with the SDK bundled in Xcode 27.2. The newest release listed on Apple’s security-releases page as of October 22 was iOS 27.0.1 from September 28.

What does not exist: a guide article, a sample project, or a session. WWDC26 session 226 covers LiveCommunicationKit and never mentions this. At the Accessibility Technologies Group Lab (session 8005), an attendee asked exactly the right question — how sessions are initiated, and whether there are entitlements or API restrictions to be aware of. The panel’s answer: “that feature is not quite available in the iOS 27 beta… So stay tuned. More information coming.”

Apple also never publicly states that §3.3.8(J)’s “Live Assistance API” is this LiveAssistance family. That identification is an inference, though a strong one: the license defines the API as the one that connects to an end user’s FaceTime call, the entitlement abstract describes providing “live assistance services, such as sign language interpreting or captioning, during FaceTime calls,” and LiveAssistanceRequest.id is documented as relating the request to a conversation in the FaceTime framework.

The architecture is documented clearly enough to design against. You ship a container app plus an app extension conforming to LiveAssistanceExtension. When a person on a call chooses your app, the framework launches the extension and calls prepareAssistanceRequest(_:). If you need more from the user, you return requiresUserInput(reason:), which launches the container app; when it’s done it calls LiveAssistance.returnToCall(requestID:), and the framework calls resumeRequest(_:).

Two constraints Apple spells out are worth internalising early. Each invocation runs in a fresh process context, so no instance state survives between calls — Apple’s guidance is the keychain or App Group defaults. And if the extension process crashes mid-invocation, the request fails immediately; the framework does not re-invoke the handler.

A sketch, assembled from the reference

The following is stitched together from the documented declarations. It is not compile-verified, and two parts are inferred rather than documented: the @main shape, which follows AppExtension convention rather than any Live Assistance page, and how the extension obtains the join URL — the prose says it “can retrieve a URL from the framework,” and LiveAssistanceRequest exposes let url: URL, but no page names the retrieval call.

@main
struct InterpreterAssistanceExtension: LiveAssistanceExtension {
    func prepareAssistanceRequest(
        _ request: LiveAssistanceRequest
    ) async throws -> LiveAssistanceRequest.Response {
        // Fresh process each invocation: keychain or App Group defaults.
        guard let session = SharedCredentialStore.currentVRSSession() else {
            return .requiresUserInput(reason: .signIn)
        }
        guard session.hasRequiredCallerInfo else {
            return .requiresUserInput(reason: .additionalInfo)
        }
        do {
            try await InterpreterBackend.dispatch(joinURL: request.url,
                                                  requestID: request.id)
        } catch {
            // Throwing is terminal; the request ends immediately.
            throw LiveAssistanceRequestError.cannotFulfill(message: "No interpreter available")
        }
        return .proceed
    }
}

The launch reasons are the most revealing detail in the whole doc set. LiveAssistanceLaunchReason.signIn is documented as indicating the person “isn’t signed into the VRS provider service” — Video Relay Service. Apple’s own API reference names the intended customer category, which lines up with the May 19, 2026 Newsroom line about an API for sign language interpretation app developers adding a human interpreter to an ongoing FaceTime call. No source verifies that any named provider has adopted it; no public adoption announcements were found.

Two smaller traps. Both LiveAssistanceRequest.Response and LiveAssistanceRequestError are documented as not frozen, so any switch over them needs an @unknown default. And there are two near-identical strings that are not interchangeable: the entitlement key is com.apple.developer.conversation-accessibility, while the NSUserActivityTypes value the container app must declare is com.apple.conversation-accessibility.container-app-launch — no .developer.

Which gate the obvious requests fail

Most requests for “put another person into the call” fail §3.3.8(J) on more than one gate at once.

A support agent joining a customer’s FaceTime call to troubleshoot fails on joiner identity and on purpose. A sales rep joining to co-browse fails the same two. An automated agent joining to transcribe or summarise runs into “accessibility service provider” — a provider is an entity, and the one documented launch reason is a VRS provider sign-in. A supervisor silently monitoring a call fails the invitation gate outright, and also collides with §3.2’s prohibition on deceiving “regarding the identity, purpose, or behavior of the product.”

What matches the clause and the documented design: a remote sign language interpreter, a live captioning service, or a translation service joining at the user’s request. Captioning and translation are Apple’s own examples.

Say the next part out loud to anyone reasoning about risk here, because it is where expectations break. A license restriction is not a compiler error. The entitlement is a documented Boolean defaulting to NO, with no published approval process. And because the symbols are published Apple documentation, they are Documented APIs under §3.3.1(A) — using them outside the accessibility scope is a contractual and review problem, not a private-API violation. “It compiles” was never the same thing as “it ships.”

If the requirement is really a human in your own call

Then Live Assistance was never the right component. §3.3.8(J) restricts an API defined as connecting to an end user’s FaceTime call. It says nothing about conversations your own app originates and owns, where you set the participant rules.

The documented path for that is the VoIP side of LiveCommunicationKit, available since iOS 17.4 and carrying no accessibility restriction. Apple’s framing: it “enables you to add VoIP capabilities to your app,” displaying the same interface as the Phone app and responding to system behaviours like Do Not Disturb. Session 226 is also explicit about direction of travel: “If you have an app that uses traditional approaches, like the CXProvider API, now is a great time to move over to LiveCommunicationKit.”

One thing not to misread. LiveCommunicationKit is the system-integration layer, not a media stack. Apple’s own sample comment says “initiate a VoIP conversation using your VoIP services” — transport stays yours. The framework handles call UI, conversation lifecycle, and actions like SetTranslatingAction, which starts or stops translation inside a conversation you own. That is a different mechanism from translation inside someone else’s FaceTime call, and the two should not be quoted as one estimate.

The capability that really is terms-only

§3.3.8(K) covers the App Replacement Entitlement, and it is short:

Your replacement Application may use the App Replacement Entitlement only if both it and Your original Application are under Your Developer Program membership, and have substantively the same primary purpose and functionality.

The definition describes a system sheet shown at first launch of the replacement app, offering to move data and settings from the original app and delete it. The definition calls this “the documented entitlement.” Checked on October 22, 2026, Apple’s entitlements index contained no entry matching “replacement,” and I could not locate a documentation page for it. No key string, no framework. This, rather than Live Assistance, is the capability that currently exists only in the contract.

Don’t confuse it with AppMigrationKit (iOS and iPadOS 26.1+), whose key is com.apple.developer.app-migration.data-container-access and whose documentation states it “only supports migration to and from non-Apple platforms, such as Android” — the system does not use it between iOS or iPadOS devices. Different direction, different problem.

The two-part test in §3.3.8(K) also forecloses the obvious growth hack. Both apps must sit under the same membership — common ownership across two memberships does not qualify on the face of the text — and they must have “substantively the same primary purpose and functionality.” Apple publishes no interpretation of “substantively,” so that ambiguity should not be assumed in your favour.

The gates that are people, not code

Two bottlenecks here are a single named human, and neither is usually an engineer.

First, agreement acceptance. Apple’s roles documentation states that when an agreement is updated, the Account Holder “must accept the agreement on behalf of your organization,” and that to maintain full access to membership resources — Certificates, Identifiers & Profiles, App Store Connect, and the App Store Connect API — they must agree “by the date noted on your developer account landing page.” That deadline is account-specific, so go look at yours rather than trusting a date from a blog post. Apple documents acceptance as an Account Holder responsibility; I found no statement about whether Admins can do it, so check the role tables in Users and Access rather than assuming.

Second, managed capabilities. Some entitlements must be assigned to your account by Apple before you can enable them, via Certificates, Identifiers & Profiles → Identifiers → the App ID → Capability Requests, and for organizations the Account Holder submits the request. Whether com.apple.developer.conversation-accessibility is one of these is an open question: the entitlement page carries no approval note, and nothing in the public record enumerates it. Given how narrow §3.3.8(J) is, a gate would not be surprising — but unsurprising is not verified. If you build under someone else’s Developer Program membership, find out who holds that role before a release depends on them.

And the tempting workaround is now explicitly closed. The App Review Guidelines updated on October 16, 2026 added 2.5.19: “Don’t include any hidden, dormant, or undocumented features in your app… Attempting to hide undocumented features in your app binary, such as through code obfuscation or other methods, is grounds for removal of your app from the App Store and termination of your developer account.” It carries the Notarization icon, so it reaches iOS and iPadOS apps distributed outside the App Store too. Read alongside §3.2’s prohibition on “post-review modifications that would cause harm to others,” shipping a 27.2-only, license-restricted capability dark and flipping a flag later is off the table.

So: build now against a published symbol set with no guide and an unknown approval path, or wait? There is no authoritative source and no documented community consensus on that trade-off — the inputs above are the honest version of the answer. What is not a judgement call is the scope. Plan against §3.3.8(J) as written, because for now it is the only text that exists.