Overview

We are implementing Apple Pay In-App Provisioning in our issuer iOS application and are encountering a HTTP 500 error returned from Apple servers during the provisioning flow. The issue occurs after generating the encrypted payload and attempting to complete the provisioning process. The Apple service responds with 500 Internal Server Error, preventing the card from being added to Wallet. We would appreciate assistance identifying whether this is caused by: • a payload formatting issue, • cryptographic material mismatch, • entitlement / configuration issue, • or a server-side issue. Environment Platform • iOS: 26.3.1 • Device: iPhone 13 mini • Xcode: 26.3.1 Apple Pay configuration • In-App Provisioning entitlement enabled • Issuer app authorized by Apple for provisioning • Payment Network: Mastercard • Token Service Provider (TSP): MDES Testing environment • Production • App distribution method: TestFlight Provisioning Flow Overview Our implementation follows the standard Apple Pay In-App Provisioning flow: 1. User taps Add to Apple Wallet in issuer app. 2. App presents PKAddPaymentPassViewController. 3. App receives: • Apple public certificates • nonce • nonceSignature 4. Issuer backend generates: • encryptedPassData • activationData • ephemeralPublicKey 5. These values are returned to the app. 6. App constructs PKAddPaymentPassRequest. 7. Wallet attempts provisioning. At this point the request fails and Apple servers return HTTP 500. We see this in the system console, with the phone having Wallet debugging profile installed. Checklist – Common Issues Verified Based on the Apple Pay In-App Provisioning demo guidance, we verified the following configuration items. Entitlements • com.apple.developer.payment-pass-provisioning enabled • Apple Pay capability enabled in Xcode • Correct Team ID and bundle configuration App configuration • PKAddPaymentPassViewController used for provisioning • PKAddPaymentPassViewControllerDelegate implemented • generateRequestWithCertificateChain implemented correctly Cryptographic data • encryptedPassData • activationData • ephemeralPublicKey All values are generated by our issuer backend and returned to the app Feedback ID: FB22249031 (In app provisioning error 500)

Hello everyone, I would like to ask if other developers are currently experiencing long delays to approve an app. In my case, my macOS app update (version 1.1) has been stuck in “Ready for Review” for more than 8 days without entering the review phase. Timeline: • Feb 21 – Initial submission • Feb 22 – In Review • Feb 25 – Rejected • Feb 25 – Resubmitted • Mar 2 – In Review • Mar 2 – Rejected • Mar 5 (Wednesday) – Submitted again → Ready for Review • Today – Still Ready for Review, never entered In Review All issues mentioned in the previous rejections were fixed and the build was resubmitted successfully. What also confuses me is that in the App Review section I see a red exclamation mark, even though there are no unresolved messages and the build shows as submitted. I would like to ask: • Are others currently seeing unusually long delays? • Could this indicate a queue issue or system problem? • Has Apple changed something recently in the review pipeline? Normally my previous versions were reviewed and approved in a couple of days, so this delay seems quite unusual. Thanks in advance for any insight from other developers.

We are evaluating the new behavior mentioned in the Nearby Interaction documentation for iOS 18.4+, which states: “In iOS 18.4 and later, your app can continue ranging in the background with any supported device if the app starts a Live Activity as it goes to the background." Could you clarify what situations are considered “can continue ranging” versus cases where it will not continue? Specifically, if my app: starts a NISession in the foreground starts a Live Activity with that data then the app goes to background should the NI session still deliver ranging updates so the app can update the Live Activity? also, my app already enable Background Modes capability

I just started at a new company and I've been invited to access their Apple Developer Program. When I click the invite in the link I'm directed to a "Create Your Apple Account" page where I'm prompted to provide my email address. When I put my work email I receive an error saying that my Apple Account cannot end in the domain and to choose a different email address. When I try to use my personal Gmail, it says my email address is not available and to choose a different address. Even my iCloud email isn't allowed. I'm not sure what else to do to gain access.

Hi, I’m trying to enroll in the Apple Developer Program as an Individual. I attempted the payment several times, but the system says the purchase is already in the system. Under my profile the status shows “Pending”, and the payment has still not been charged from my bank account. It has been about one week since I started the enrollment, and the status hasn’t changed. I also contacted Apple Developer Support, but it has been 4 days and I haven’t received any response yet. Is this normal? Has anyone experienced a similar delay during enrollment? Thanks.

A friend of mine said he applied for enrollment for an Organization. But during the process he did not type the code received for verifying the email. On the next day trying for enrollment there was a message of max tries. Plus he received an email with the title "developer agreement signed" How can he verify the agreement started or what can he do? He wants to know if it was succesful and he must wait or...

Hello, I enrolled in the Apple Developer Program and placed the $99 order. Shortly after, I received the email saying: “Thank you for your order. Your order request will be processed within 2 business days.” However, it has now been over two weeks and my membership has still not been activated. I also contacted Apple Developer Support about a week ago through the contact form, but unfortunately I have not received any reply so far. When I visit aninterestingwebsite.com, I still see the page prompting me to complete or place the order, even though I already placed it and received the confirmation email. Could someone from Apple please check the status of my enrollment or advise what I should do next? Thank you.

Why help

描述：低等级会员在 7 天免费期内订阅了高级会员 预期：低级会员的 7 天免费试用结束，高级会员直接扣费生效，苹果的升级通知如下： { "extra_info": { "quantity": 1, "expiresDate": 1754627893000, "purchaseDate": 1754623693000, "transactionId": "2000000979349440", "offerDiscountType": null, "originalTransactionId": "2000000979347229", // 升级前后没有变化 "subscriptionGroupIdentifier": "21729756" }, "decodedPayload": {}, "orgin_sku_name": "unlimited.minutes.per.year.v3", "payment_platform": "app_store", "decodedPayload_Renew": { "productId": "unlimited.minutes.per.year.v3", "autoRenewStatus": 1, "originalTransactionId": "2000000979347229" }, "decodedPayload_Trans": { "type": "Auto-Renewable Subscription", "price": 228000, "bundleId": "ai.plaud.ios.plaudzh", "currency": "CNY", "quantity": 1, "productId": "unlimited.minutes.per.year.v3", "signedDate": 1754623696459, "storefront": "CHN", "environment": "Sandbox", "expiresDate": 1754627293000, "purchaseDate": 1754623693000, "storefrontId": "143465", "transactionId": "2000000979349440", "appTransactionId": "704742096472000913", "transactionReason": "PURCHASE", "inAppOwnershipType": "PURCHASED", "webOrderLineItemId": "2000000107917134", "originalPurchaseDate": 1754623472000, "originalTransactionId": "2000000979347229", "subscriptionGroupIdentifier": "21729756" } } 异常 case：苹果通知升级到高级会员且继续剩余试用时间，例如：低等级会员7 天免费试用期剩余 4 天，升级到 4 天的高等级会员的免费试用，收到的通知消息如下： "extra_info": { "quantity": 1, "expiresDate": 1773109207000, "purchaseDate": 1772708455000, "transactionId": "550002836609836", "offerDiscountType": "FREE_TRIAL", "originalTransactionId": "550002832625469", //升级前后没有变化 "subscriptionGroupIdentifier": "21729756" }, "purchase_type": "upgrade", "decodedPayload": { "signedTransactionInfo": {}, "orgin_sku_name": "unlimited.minutes.per.year.v3", "payment_platform": "app_store", "decodedPayload_Renew": { "productId": "unlimited.minutes.per.year.v3", "autoRenewStatus": 1, "originalTransactionId": "550002832625469" }, "decodedPayload_Trans": { "type": "Auto-Renewable Subscription", "price": 0, "bundleId": "ai.plaud.ios.plaudzh", "currency": "CNY", "quantity": 1, "offerType": 1, "productId": "unlimited.minutes.per.year.v3", "signedDate": 1772708460325, "storefront": "CHN", "environment": "Production", "expiresDate": 1773108607000, "offerPeriod": "P7D", "purchaseDate": 1772708455000, "storefrontId": "143465", "transactionId": "550002836609836", "appTransactionId": "705330723507531368", "offerDiscountType": "FREE_TRIAL", "transactionReason": "PURCHASE", "inAppOwnershipType": "PURCHASED", "webOrderLineItemId": "550001244481732", "originalPurchaseDate": 1772507407000, "originalTransactionId": "550002832625469", "subscriptionGroupIdentifier": "21729756" } } 请问是苹果的会员试用的策略发生了变化吗

Hi I'm new here and trying so enroll in apple developers program and so I was met with problems like unable to create apple account, failed payment on 7 cards, 3 support tickets with no responds, and now I have enrolled in apple developers program (sort of, they just took payment and no news after that now running 3 days since payment. Is this some sort of a hazing ceremony or a sick joke apple is doing do new developers? or is there a secret email I can contact to get some decent support?

I signed up for the Developer Account Program, but I keep getting a message that my registration is under review. Obviously, I haven't paid yet because I couldn't find a link to pay the $99 when I signed up. I've sent two emails for support, but I haven't received a response. Has anyone else had the same problem? Thanks.

Considering how important smooth/continuous corners are for Apple throughout their various native platforms (and hardware), can we expect Safari to soon adopt this CSS feature? It's already live in Chrome https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/Properties/corner-shape For those who are unfamiliar with smooth corners and how Apple uses them: https://www.youtube.com/watch?v=YElVQqNwrJ4&t=110s

We built an open-source macOS menu bar app that turns speech into text and pastes it into the active app — using SpeechAnalyzer for on-device transcription, ScreenCaptureKit + Vision for screen-aware context, and FluidAudio for speaker diarization in meeting mode. Here's what we learned shipping it on macOS 26. GitHub: github.com/Marvinngg/ambient-voice Architecture The app has two modes: hotkey dictation (press to talk, release to inject) and meeting recording (continuous transcription with a floating panel). Dictation Mode Audio capture uses AVCaptureSession (more on why below). The captured audio feeds into SpeechAnalyzer via an AsyncStream: let transcriber = SpeechTranscriber( locale: locale, transcriptionOptions: [], reportingOptions: [.volatileResults, .alternativeTranscriptions], attributeOptions: [.audioTimeRange, .transcriptionConfidence] ) let analyzer = SpeechAnalyzer(modules: [transcriber]) let (inputSequence, inputBuilder) = AsyncStream.makeStream() try await analyzer.start(inputSequence: inputSequence) While recording, we capture a screenshot of the focused window using ScreenCaptureKit, run Vision OCR (VNRecognizeTextRequest), extract keywords, and inject them into SpeechAnalyzer as contextual bias: let context = AnalysisContext() context.contextualStrings[.general] = ocrKeywords try await analyzer.setContext(context) This improves accuracy for technical terms and proper nouns visible on screen. If your screen shows "SpeechAnalyzer", saying it out loud is more likely to be transcribed correctly. After transcription, an optional L2 step sends the text through a local LLM (ollama) for spoken-to-written cleanup, then CGEvent simulates Cmd+V to paste into the active app. Meeting Mode Meeting mode forks the same audio stream to two consumers: SpeechAnalyzer — real-time streaming transcription, displayed in a floating NSPanel FluidAudio buffer — accumulates 16kHz Float32 mono samples for batch speaker diarization after recording stops When the user ends the meeting, FluidAudio's performCompleteDiarization() runs on the accumulated audio. We align transcription segments with speaker segments using audioTimeRange overlap matching — each transcription segment gets assigned the speaker ID with the most time overlap. Results export to Markdown. Pitfalls We Hit on macOS 26 1. AVAudioEngine installTap doesn't fire with Bluetooth devices We started with AVAudioEngine.inputNode.installTap() for audio capture. It worked fine with built-in mics but the tap callback never fired with Bluetooth devices (tested with vivo TWS 4 Hi-Fi). Fix: switched to AVCaptureSession. The delegate callback captureOutput(_:didOutput:from:) fires reliably regardless of audio device. The tradeoff is you get CMSampleBuffer instead of AVAudioPCMBuffer, so you need a conversion step. 2. NSEvent addGlobalMonitorForEvents crashes Our global hotkey listener used NSEvent.addGlobalMonitorForEvents. On macOS 26, this crashes with a Bus error inside GlobalObserverHandler — appears to be a Swift actor runtime issue. Fix: switched to CGEventTap. Works reliably, but the callback runs on a CFRunLoop context, which Swift doesn't recognize as MainActor. 3. CGEventTap callbacks aren't on MainActor If your CGEventTap callback touches any @MainActor state, you'll get concurrency violations. The callback runs on whatever thread owns the CFRunLoop. Fix: bridge with DispatchQueue.main.async {} inside the tap callback before touching any MainActor state. 4. CGPreflightScreenCaptureAccess doesn't request permission We used CGPreflightScreenCaptureAccess() as a guard before calling ScreenCaptureKit. If it returned false, we'd bail out. The problem: this function only checks — it never triggers macOS to add your app to the Screen Recording permission list. Chicken-and-egg: you can't get permission because you never ask for it. Fix: call CGRequestScreenCaptureAccess() at app startup. This adds your app to System Settings → Screen Recording. Then let ScreenCaptureKit calls proceed without the preflight guard — SCShareableContent will also trigger the permission prompt on first use. 5. Ad-hoc signing breaks TCC permissions on every rebuild During development, codesign --sign - (ad-hoc) generates a different code directory hash on every build. macOS TCC tracks permissions by this hash, so every rebuild = new app identity = all permissions reset. Fix: sign with a stable certificate. If you have an Apple Development certificate, use that. The TeamIdentifier stays constant across rebuilds, so TCC permissions persist. We also discovered that launching via open WE.app (LaunchServices) instead of directly executing the binary is required — otherwise macOS attributes TCC permissions to Terminal, not your app. Benchmarks We ran end-to-end benchmarks on public datasets (Mac Mini M4 16GB, macOS 26): Transcription (SpeechAnalyzer, AliMeeting Chinese): • Near-field CER 34% (excluding outliers ~25%) • Far-field CER 40% (single channel, no beamforming, >30% overlap) • Processing speed 74-89x real-time Speaker diarization (FluidAudio offline): • AMI English 16 meetings: avg DER 23.2% (collar=0.25s, ignoreOverlap=True) • AliMeeting Chinese 8 meetings: DER 48.5% (including overlap regions) • Memory: RSS ~500MB, peak 730-930MB Full evaluation methodology, scripts, and raw results are in the repo. Open Source The project is MIT licensed: github.com/Marvinngg/ambient-voice It includes the macOS client (Swift 6.2, SPM), server-side distillation/training scripts (Python), and a complete evaluation framework with reproducible benchmarks. Feedback and contributions welcome.

When calling the verification interface for "whether the user belongs to a restricted region", the return value is always false; even if the Apple account is registered as an account belonging to a restricted region and the account is set to supervised mode, the interface return result remains unchanged, and it is impossible to verify a true result. The code for calling the interface is as follows: @available(iOS 26.2, *) @objc public func eligibleForAgeFeatures() async -> Bool { var isEligible = false do { isEligible = try await AgeRangeService.shared.isEligibleForAgeFeatures } catch { isEligible = false } return isEligible }

Thanks!

Hey everyone, I'm managing CI/CD pipelines for around 45 iOS apps across different Apple Developer accounts. One recurring pain point is blocked pipelines due to unsigned agreements. Things like the Paid Applications Agreement and the Apple Developer Program License Agreement. I built an internal dashboard to flag these before they block a release, but I'm hitting a wall with detection accuracy. Since there's no dedicated endpoint for agreement status, I'm running three probes per account and checking for 403 FORBIDDEN.REQUIRED_AGREEMENTS_MISSING_OR_EXPIRED: GET /v1/agreements GET /v1/bundleIds?filter[identifier]={bundleId}&filter[platform]=IOS GET /v1/certificates?limit=1 Case 1 : Works perfectly. Account has "Apple Developer Program License Agreement has been updated and needs to be reviewed" : All three endpoint return 403 (In this case, the step 1 is enough) # Step 1 /v1/agreements → HTTP 403 ⛔ BLOCKED # Step 2 /v1/bundleIds → HTTP 403 ⛔ BLOCKED # Step 3 /v1/certificates → HTTP 403 ⛔ BLOCKED # [Step 1 body] { "errors": [ { "id": "TXF6QUVS6OY66YVUNINVLKXZFA", "status": "403", "code": "FORBIDDEN.REQUIRED_AGREEMENTS_MISSING_OR_EXPIRED", "title": "A required agreement is missing or has expired.", "detail": "This request requires an in-effect agreement that has not been signed or has expired.", "links": { "see": "/business" } } ] } # [Step 2 body] { "errors": [ { "id": "MTDI5P37UTYQOOVJSMXCWUK42U", "status": "403", "code": "FORBIDDEN.REQUIRED_AGREEMENTS_MISSING_OR_EXPIRED", "title": "A required agreement is missing or has expired.", "detail": "This request requires an in-effect agreement that has not been signed or has expired.", "links": { "see": "/business" } } ] } # [Step 3 body] { "errors": [ { "id": "GI6EN2CMBFJIJJZM547LSW66KY", "status": "403", "code": "FORBIDDEN.REQUIRED_AGREEMENTS_MISSING_OR_EXPIRED", "title": "A required agreement is missing or has expired.", "detail": "This request requires an in-effect agreement that has not been signed or has expired.", "links": { "see": "/business" } } ] } Case 2 : Not detected. Different account, same message in App Store Connect UI. But v1/agreements endpoint return 404 while other 2 steps return 200 # Step 1 /v1/agreements → HTTP 404 ➖ 404 # Step 2 /v1/bundleIds → HTTP 200 ✅ OK # Step 3 /v1/certificates → HTTP 200 ✅ OK # [Step 1 body] { "errors": [ { "id": "37459578-8167-449c-ad22-e0ffa392df2d", "status": "404", "code": "NOT_FOUND", "title": "The specified resource does not exist", "detail": "The path provided does not match a defined resource type." } ] } # [Step 2 body] { "data": [ { "type": "bundleIds", "id": "xxx", "attributes": { "identifier": "xxx" }, "links": { "self": "https://api.appstoreconnect.apple.com/v1/bundleIds/[xxx]" } } ], "links": { "self": "https://api.appstoreconnect.apple.com/v1/bundleIds?fields%5BbundleIds%5D=identifier&filter%5Bplatform%5D=IOS&filter%5Bidentifier%5D=[xxx]&limit=1" }, "meta": { "paging": { "total": 1, "limit": 1 } } } # [Step 3 body] { "data": [ { "type": "certificates", "id": "xxx", "attributes": { "serialNumber": "xxx", "expirationDate": "2026-07-03T04:47:09.000+00:00", "certificateType": "DISTRIBUTION" }, "links": { "self": "https://api.appstoreconnect.apple.com/v1/certificates/[xxx]" } } ], "links": { "self": "https://api.appstoreconnect.apple.com/v1/certificates?fields%5Bcertificates%5D=serialNumber%2CcertificateType%2CexpirationDate&limit=1", "next": "https://api.appstoreconnect.apple.com/v1/certificates?fields%5Bcertificates%5D=serialNumber%2CcertificateType%2CexpirationDate&cursor=[xxx]&limit=1" }, "meta": { "paging": { "total": 4, "limit": 1 } } } Same agreement type, same UI warning, completely different API behaviour. My best guess is Apple enforces the agreement deadline progressively. The 403 gate only kicks in once the deadline is crossed or the account reaches a certain state, while the UI warning shows much earlier. What I'm looking for, Is there a supported API endpoint that reflects pending agreement status regardless of enforcement state? Or is the 403 gate genuinely the only signal available and some pending agreements just won't show up until Apple enforces them? Happy to hear "there's no API for this" if that's the reality. Just want to make sure I'm not missing something before I accept that limitation. Thanks.

One app submitted Feb 21st. The app is currently showing "Waiting for Review". It hasn’t been rejected and there hasn’t been any action taken yet. This is my first submission with this developer account, so I just want to confirm everything was submitted correctly and that I’m simply waiting on Apple’s review process. For anyone from Apple who might be able to look into it, the app details are: App name: Coop Keeper: Chore Cards SKU: com.lukaambros.coopkeeperchorecards Apple ID: 6759481708

We’re seeing a change in Spotlight search behavior on iOS 17 and later: Observation: User‑visible keywords we index (e.g. via Core Spotlight / CSSearchableItemAttributeSet with keywords) only start appearing in Spotlight suggestions after the user has typed more than 3 characters. With 1–3 characters, our app’s content often doesn’t show up at all, even when it clearly matches. Before iOS 17: The same indexed content could appear with fewer characters (e.g. 1–3 characters). Environment: Reproduced on multiple devices running iOS 17.x / 18.x; behavior is consistent. We’d like to confirm: Is this a documented change in iOS 17 (e.g. minimum character threshold for third‑party Spotlight results)? If yes, where is it documented? If it’s not intentional, could this be treated as a bug and considered for a fix in a future release? We’re happy to provide a sample project or more detail if that would help. Thank you.

I’m developing a text editor that provides a line number view. This view is placed next to the NSScrollView that contains the main text view, rather than inside the scroll view. The line number view updates its drawing in sync with the NSScrollView’s scrolling and text editing in the NSTextView, so it can display the correct line numbers. This approach worked fine through macOS 15, but on macOS 26 with Liquid Glass, the line numbers end up being drawn without the expected blur/soft edge effect under the window toolbar area. In AppKit, some view controllers provide APIs to switch edge effects between soft/hard, but I can’t find any API to control this for the window toolbar region. I considered simply not drawing the numbers outside the content area, but if possible I’d like to apply the Tahoe-style soft edge effect instead. Does anyone have ideas? Is this currently impossible, meaning the only option is to file a feedback/API request? Also, for various reasons, the traditional approach of implementing line numbers by subclassing NSRulerView is difficult for my app.

Error 8 in the NEHotspotConfigurationError domain is .internal, aka NEHotspotConfigurationErrorInternal. This error typically indicates that something went wrong in some sort of expected way, but we decided not to surface the exact cause [1]. This has come up a bunch of times before on the forums, and I have various titbits to share. To start, I want to address some specific cases: You’ll see this error if your app isn’t signed with the com.apple.developer.networking.HotspotConfiguration entitlement. To fix this, use Xcode’s Signing & Capabilities editor to add the Hotspot capability to your app. Historically developers reported a situation where once they encountered the error it would show up consistently, but then it would go away on restarting the device. If you see behaviour like that, that’s definitely a bug and I encourage you to file it as such. I have more about filing such bugs in Filing a Wi-Fi Bug Report. Of course, you have to wait to reproduce the error again before you’ll be able to file that bug, because the act of restarting cleared the issue. I’ve seen reports where such problems only occur on a specific type of device, for example, on iPhone 16 but not on earlier or later iPhones. That’s definitely something that Apple should investigate, and I recommend that you file a bug about it. If the problem is being reported by your users but you can’t reproduce it yourself, consider the various suggestions in Using a Sysdiagnose Log to Debug a Hard-to-Reproduce Problem. Assuming you’re still here (-: the next step is to determine whether the problem is specific to NEHotspotConfigurationManager or not. Try joining the accessory’s network from Settings > Wi-Fi. Does that also have problems? If so, that’s not something we can help you with here on the forums. The focus of the Apple Developer Forums is primarily to help developers with the APIs in Apple’s various platform SDKs [2]. We’re not set up to help accessory developers with Wi-Fi issues. However, there are still things you can do, as I explain in Filing a Wi-Fi Bug Report. At this point you have an error that: Persists across restarts Happens with all Apple devices You can reproduce Only affects NEHotspotConfigurationManager If that’s correct then there are a couple of things you might look at: Coerce the error to an NSError and print that. Does it reveal anything interesting? Also check the underlying error property (NSUnderlyingErrorKey) for hints. When reproducing the error, monitor the system log for log entries in the com.apple.networkextension subsystem. Do those offer any clues? Note For lots of hints and tips about the system log, see Your Friend the System Log. And finally, if you have questions about this case, feel free to start a thread here on the forums and we’ll try to help you out. Put it in the App & System Services > Networking subtopic and tag it with Network Extension. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com" [1] There’s also the .unknown error. See this post for a brief summary of the difference. [2] And with Apple tools and some developer-oriented services. Revision History 2026-03-18 Added a missing entitlement bullet to the specific case list. 2026-03-17 First posted.