WWDC Quick Look đź’“ By SwiftGGTeam
中文 EN 日本語
Automate your development process with the App Store Connect API

Automate your development process with the App Store Connect API

App StoreDistribution & Marketing
Watch original video

Highlight

App Store Connect added three new APIs this year: Webhook, Build Upload, and Feedback. They replace all polling and manual steps in the “upload build → distribute → collect feedback” loop with event-driven automation.

Core Content

App development is an iterative process: write features or fix bugs, upload builds to App Store Connect, distribute to beta testers, collect feedback, then repeat. Dajinsol Jeon opens the session (01:04) by identifying the problem: this loop should run as fast as possible—if users report crashes, you want to fix them quickly. But to make this happen before, CI systems had to constantly poll ASC: “is the build ready?” “any new feedback?” Or you had to rely on Xcode or Transporter to manually upload builds. Both approaches are slow and hard to integrate into automated pipelines.

This year, App Store Connect connects the entire loop. Webhooks let ASC push events to you. Build Upload API lets any language and any CI platform upload builds. Feedback API brings TestFlight screenshot feedback and crash reports directly into your development tools. Together, when CI receives a webhook it can proceed to the next step—no more sleeping 30 seconds and calling GET again.

Details

Register a webhook listener. Configure it in the ASC web UI at Users and Access → Integrations → Webhooks, or use the API (06:04). The API approach shines when you manage many apps and need to auto-register new apps in one shot.

POST /v1/webhooks
{
  "data": {
    "type": "webhooks",
    "attributes": {
      "name": "My CI Webhook",
      "url": "https://ci.example.com/asc-hook",
      "secret": "<your-shared-secret>",
      "eventTypes": [
        "buildUploads.stateChanged",
        "buildBetaDetails.stateChanged",
        "betaFeedbackScreenshotSubmissions.created"
      ]
    },
    "relationships": {
      "scope": { "data": { "type": "apps", "id": "<app-id>" } }
    }
  }
}

Key points:

  • url is your webhook listener endpoint. ASC POSTs event payloads to it.
  • secret is a shared key between you and ASC. It can be any string that only you and ASC know. Used for HMAC-SHA256 signature verification.
  • eventTypes selects from five event types: Build Upload State, Build Beta State, TestFlight Feedback, App Version State, Apple-Hosted Background Asset State (04:07).
  • Returns 201 CREATED on success. Body contains the webhook ID you’ll need to manage this webhook later.

Uploading a build takes four steps. Create BuildUpload → Create BuildUploadFile → Upload binary via upload operations → PATCH to mark complete (07:42).

POST /v1/buildUploads
{
  "data": {
    "type": "buildUploads",
    "attributes": {
      "cfBundleVersion": "42",
      "platform": "IOS"
    }
  }
}

Key points:

  • First step only declares build metadata: bundle version and target platform.
  • Returns 201 CREATED with a BuildUpload ID in the body.
  • Use that ID to create BuildUploadFile, telling ASC the filename, byte count, and asset type. ASC responds with upload operations containing target URLs, required PUT method, and required headers (09:01).
  • For large files, the operations array may contain multiple entries. Split the file into chunks by byte range and PUT each separately. Don’t assume a single chunk.
  • After all chunks upload, PATCH the BuildUpload with uploaded: true. Only then does ASC start processing. Returns 200 OK on success with state = COMPLETE.

Verify webhook signatures. Requests from ASC include an X-Apple-SIGNATURE header using HMAC-SHA256 (10:51).

signature = HMAC_SHA256(secret, raw_request_body)
verify   : signature == X-Apple-SIGNATURE

Key points:

  • Compute HMAC-SHA256 using the secret from registration and the raw request body.
  • Compare against the header. If they match, the request came from Apple.
  • Use raw body. Re-serializing after deserialization may change string order and break signature validation.

Webhook payloads are minimal. Fetch details via API. When new screenshot feedback arrives, the payload only contains feedback type and instance ID (13:46). Call GET /v1/betaFeedbackScreenshotSubmissions/{id} to get device info and screenshot URL. Download the screenshot separately from that URL. Crash feedback works similarly—there’s a crashLog endpoint for downloading crash logs (14:32).

Build beta state events are particularly useful (12:12). External testing required Beta App Review, and you couldn’t tell when it finished. Now ASC pushes a webhook the moment review passes. CI can immediately trigger the “notify testers” flow.

Takeaways

  • Build a minimal ASC webhook gateway

    • Why: Five event types cover build upload, beta review, version state, feedback, and Apple-Hosted Assets. Connect once, and your entire pipeline gets a real-time signal source.
    • How: Start an HTTP service exposing /asc-hook. Implement HMAC-SHA256 verification first—return 401 on failure. On success, persist the raw payload or queue it, then return 200 immediately. Don’t do heavy work in the request thread to avoid ASC timeouts and retries.

  • Move build uploads from Xcode to CI

    • Why: Build Upload API is standard REST. Any language and any CI can call it. No more Mac runners with Xcode altool or Transporter. Error messages are structured and retry-friendly.
    • How: Write an upload script that calls the four API steps in order. When upload operations returns an array, iterate and PUT chunks by byte range. Finally PATCH uploaded=true, then wait for the COMPLETE webhook before proceeding.

  • Pipe TestFlight feedback into your issue tracker

    • Why: Screenshot and crash feedback are direct user voices. Scattered across the ASC dashboard, they’re easy to miss. Integrated into Jira/Linear/GitHub Issues, each feedback comes with device info and screenshots—nothing gets dropped.
    • How: Listen for betaFeedbackScreenshotSubmissions.created and crash events. On receipt, call the Feedback API with the ID to fetch details, download screenshots or crash logs, then call your issue tracker API to auto-create tickets with reporter, device, and version fields populated.

  • Automate “notify on build review approval”

    • Why: Build beta state webhook is new this year. External tester release delays mainly wait on review. Instantly knowing review is complete means zero-delay notifications.
    • How: Subscribe to buildBetaDetails.stateChanged. Payload contains build ID and latest state. When state becomes “available for external testing,” call TestFlight API to distribute to external groups, then email or IM your testers.

Comments

GitHub Issues · utterances