What we'd like to see at WWDC 2026 (for App Store webhooks, at least)

WWDC is next week. The keynote covers a lot of ground — frameworks, OS features, hardware sometimes — but every year there’s a handful of changes buried in the State of the Union and the dev session schedule that quietly improve the App Store webhook ecosystem. Sometimes a lot. Sometimes a little.

We live in this corner of the Apple platform. App Store Connect Webhooks and App Store Server Notifications V2 are the two systems we wake up every day worrying about, and we have opinions about where they could go. Here’s what we’re hoping for from WWDC 2026, and what we’d be pleasantly surprised to see.

This post will look pretty different in retrospect once we know what actually shipped. That’s the point — we’ll write the companion post next Wednesday walking through what Apple announced, and this one will be useful context for “did they ship the thing?”

More events we wish existed

Rejection reasons, not just state changes

appStoreVersionStateUpdated fires when an app transitions to REJECTED, but the webhook payload tells you the state and nothing else. The actual rejection reason — the guideline section, the message from the App Review team, the metadata field that needs fixing — lives in App Store Connect’s Resolution Center and in the email Apple sends, but it’s nowhere in the webhook.

For teams routing rejections to PagerDuty or a #app-review Slack channel, this is the most-requested feature by a country mile. “Build was rejected” is half the signal. The other half is “and here’s why.”

Customer reviews and ratings

There is no webhook event for a new review on the App Store. None. If you want real-time review monitoring, you poll the Customer Reviews API on a cron job. Apple knows when a review is submitted; they just don’t tell anyone.

A customerReviewCreated event (with the rating, the review text, the reviewer’s locale) would let teams route 1-star reviews to a triage channel within seconds. The data already exists in App Store Connect; surfacing it as a webhook would cost Apple roughly nothing.

Offer subtype granularity

OFFER_REDEEMED already exists, and Apple sends it with subtypes — but only the outcome subtypes (INITIAL_BUY, RESUBSCRIBE, UPGRADE, DOWNGRADE). What’s missing is the offer kind: was this a promotional offer code, an introductory price, a win-back offer, or a Family Sharing entitlement? You can dig that out of signedTransactionInfo and signedRenewalInfo, but it would be much easier to route notifications by offer kind if Apple emitted that as a top-level field (or a second subtype dimension).

The use case: marketing teams want different Slack channels for “promo code redemption” vs “introductory price conversion” vs “win-back save”, and right now you have to write your own classifier on top of the transaction payload to tell them apart.

Tester first-launch and crashes-in-production

TestFlight emits betaFeedbackCreated for explicit tester submissions. It does not emit anything for “tester installed the build and opened it” or “your shipped app crashed for a non-trivial number of users in the last hour.” Both signals exist in Apple’s data — the metrics dashboards prove it — both would be enormously useful as webhook events for teams that don’t want to instrument crashlytics-style tooling themselves.

Better tooling around what we already have

Webhook replay

Stripe lets you re-send any webhook event from the dashboard. Apple does not. If your endpoint was down for ten minutes during a deploy, you have to query the App Store Server API to figure out what you missed, and the API returns the current state of transactions, not the events you would have received. There’s no recovery path that doesn’t involve writing custom reconciliation code.

A “re-send notification” button in App Store Connect (or via API) would prevent so many incidents. Even just a “list the notifications we tried to deliver to your URL in the last 24h” view would be transformative.

Test event injection

You can test signature verification by pointing the App Store Server Notifications sandbox URL at a non-prod environment, but you can’t cause events on demand. To test a REFUND handler, you have to actually make a sandbox purchase and then actually refund it through the sandbox process. There’s no “send me a fake DID_FAIL_TO_RENEW so I can verify my retry logic” button.

A test-event injection tool — Stripe has one, Twilio has one, basically every modern webhook provider has one — would save thousands of cumulative hours of dev time across the iOS ecosystem.

Source-side event filtering

App Store Connect Webhooks send every event type to your URL. There’s no way to tell Apple “I only care about betaFeedbackCreated and appStoreVersionStateUpdated; please don’t bother my server with the others.” Filtering happens on the receive side, which is fine for systems like Juice Machine that handle it for you, but for teams running webhooks themselves it’s wasted bandwidth and unnecessary processing.

Visible signing key rotation

Apple rotates the signing keys for App Store Server Notifications occasionally, and when they do, your verification fails silently if your client library hasn’t refreshed its certificate cache. There’s no advance warning, no “we’re rotating on date X” announcement. Push-based rotation alerts, or at minimum a published rotation schedule, would prevent the few hours of “our webhooks suddenly broke” that happens every time it occurs.

Format and structural cleanup

App Store Server Notifications V3

V2 shipped in 2021. It’s better than V1 (the signing scheme is good, the structure is better) but it has accumulated quirks: nested JWS three layers deep, inconsistent field placement between signedTransactionInfo and signedRenewalInfo, optional fields that are sometimes mandatory in practice. A V3 that flattens the structure and rationalises the fields would be welcome — even at the cost of another migration.

We don’t actually expect this. Apple lets their data models accumulate cruft for a decade at a time. But if WWDC 2026 ships V3, we’ll be the first to write the migration guide.

Unified signing across both webhook systems

App Store Connect Webhooks use HMAC-SHA256 with a shared secret. App Store Server Notifications V2 use JWS. Both systems come from Apple, deliver Apple-signed messages, and have completely different verification code paths. Picking one (JWS, presumably, since it’s the modern choice) and using it everywhere would halve our signature-verification surface area — and everyone else’s.

API rate-limit visibility

When the App Store Connect API rate-limits you, you get a 429. There’s no advance warning, no “you’ve used 80% of your quota this hour” signal. Including remaining rate-limit budget in API response headers, or firing a pre-emptive event when you cross a usage threshold, would let teams ramp down their enrichment calls gracefully instead of hitting a wall.

Sandbox and production parity

More of a quality-of-life ask than a feature. ASSN V2 in sandbox doesn’t always emit the same events as production:

• REFUND events sometimes don’t fire in sandbox even when a sandbox refund is processed.
• Subscription lifecycle events (SUBSCRIBED → DID_RENEW) can be flakier in sandbox; renewals sometimes don’t trigger when you’d expect.
• The timing between events is much more variable in sandbox than production — you can’t reliably reason about ordering in tests.

We’d love to see sandbox treated as a first-class testing environment. Right now, the canonical advice from teams who’ve done this seriously is “your sandbox tests will catch happy-path bugs but for everything else, you’ll only really find out in production.” That’s not great.

What we’re not expecting

To stay honest: a few things we won’t see at WWDC, no matter how much we wish for them.

• Customer PII in webhooks. Apple has been clear and consistent for years that they don’t share customer identifiers, emails, or names with developers via the App Store. Subscription events will keep including the original transaction ID and the appAccountToken you set, and that’s it.
• Review-team comments via webhook. The metadata-rejection emails are written by humans on the App Review team, and we don’t expect those to ever be a stable enough output for Apple to commit to as a webhook event.
• A complete revenue dashboard via webhook. Apple wants you in App Store Connect for the analytics, not aggregating data yourself. Some of these wishes (rate limits, key rotation) are realistic; “give us all your aggregated metrics as a stream” is not.

What this all means for next week

Realistically, WWDC ships maybe one or two of these. The rest stay on the wishlist, and we’ll roll the post forward to next year with whatever’s still outstanding.

The companion post next Wednesday will walk through what Apple actually announced — the new event types, the StoreKit changes, the App Store Connect API surface updates — and tie back to which of the above (if any) got addressed.

In the meantime, if you’ve got your own wishlist items we missed, send them our way. We’d love to know what other teams are hitting that we haven’t run into yet.