Hello, I’m integrating promotional offers for auto-renewable subscriptions using StoreKit 2. The offer is displayed correctly, the Apple purchase sheet appears, and I can start the payment flow. The sheet shows the correct discounted price and the end date of the offer. However, after confirming the purchase, an alert appears saying “Unable to Purchase - Contact the developer for more information” When dismissing the alert, Xcode logs the following: Purchase did not return a transaction: Error Domain=ASDServerErrorDomain Code=3902 "No se ha podido realizar la compra" UserInfo={ NSLocalizedFailureReason=No se ha podido realizar la compra, client-environment-type=Sandbox, AMSServerErrorCode=3902, storefront-country-code=ESP } Test environment: App installed from Xcode on a real iPhone Logged in with a Sandbox Apple ID Using StoreKit 2 Promotional offer applied using: Product.PurchaseOption.promotionalOffer(_:compactJWS:) On the server side, I generate the promotional offer signature exactly as described in Apple’s documentation: https://developer.apple.com/documentation/storekit/generating-a-signature-for-promotional-offers The signature is generated using a Subscription Key Signed with ECDSA + SHA256 Uses the correct invisible separator (U+2063) The signature is validated locally using the derived public key and verifies correctly The sandbox user has had previous subscriptions, which is why this promotional offer is eligible and shown. Given that: The offer is displayed correctly The purchase sheet shows the discounted price and duration The signature validates locally The error occurs only after confirming the purchase My question is: Is this a known limitation or issue with promotional offers in the Sandbox environment? Should promotional offers be tested exclusively via TestFlight instead of Sandbox? Any clarification would be greatly appreciated. Thank you!

Hello, This is my first post in the forums, and I'm still learning my way with iOS Development and Swift. My apologies if the formatting is not correct, or If I'm making any mistakes. I'm currently trying to implement an iOS App where the device needs to share the location with my server via an API call. The use case is as follows: the server expects location updates to determine if a device is inside/outside a geofence. If the device is stationary, no locations need to be sent. If the device begins moving, regardless of whether the app is in foreground, background, or terminated, the app should resume posting locations to the server. I've decided to use the CLLocationUpdate.liveUpdates() stream, together with CLBackgroundActivitySession(). However, I have not been able to achieve the behavior successfully. My app either maintains the blue CLActivitySession indicator active, regardless of whether the phone is stationary or not, or kills the Indicator (and the background capability) and does not restore it when moving again. Below I've attached my latest code snippet (the indicator disappears and does not come back). // This method is called in the didFinishLaunchingWithOptions func startLocationUpdates(precise: Bool) { // Show the location permission pop up requestAuthorization() // Stop any previous sessions stopLocationUpdates() Task { do { // If we have the right authorization, we will launch the updates in the background // using CLBackgroundActivitySession if self.manager.authorizationStatus == .authorizedAlways { self.backgroundActivity = true } else { self.backgroundActivity = false self.backgroundSession?.invalidate() } // We will start collecting live location updates for try await update in CLLocationUpdate.liveUpdates() { // Handle deprecation let stationary = if #available(iOS 18.0, *) { update.stationary } else { update.isStationary } // If the update is identified as stationary, we will skip this update // and turn off background location updates if stationary { self.backgroundSession?.invalidate() continue } // if background activity is enabled, we restore the Background Activity Session if backgroundActivity == true { self.backgroundSession = CLBackgroundActivitySession() } guard let location = update.location else { continue } // Do POST with location to server } } catch { print("Could not start location updates") } } } I'm not sure why the code does not work as expected, and I believe I may be misunderstanding how the libraries Work. My understanding is that the liveUpdates stream is capable of emitting values, even if the app has gone to the background/terminated, thus why I'm trying to stop/resume the Background Activity using the "stationary" or "isStationary" attribute coming from the update. Is the behavior I'm trying to achieve possible? If so, I'm I using the right libraries for it? Is my implementation correct? And If not, what would be the recommended approach? Regards

I’m implementing a subscription purchase flow using promo code redemption via an external App Store URL. Flow: User taps “Purchase” in the app (spinner shown) App opens the promo redemption URL (apps.apple.com/redeem) User completes redemption in the App Store User returns to the app The app must determine whether the subscription was purchased within a reasonable time window The app listens to Transaction.updates and also checks Transaction.currentEntitlements when the app returns to the foreground. Issue: After redeeming a subscription promo code via the App Store and returning to the app, the app cannot reliably determine whether the subscription was successfully purchased within a short, user-acceptable time window. In many cases, neither Transaction.updates nor Transaction.currentEntitlements reflects the newly redeemed subscription immediately after returning to the app. The entitlement may appear only after a significant delay, or not within a 60-second timeout at all, even though the promo code redemption succeeded. Expected: When the user returns to the app after completing promo code redemption, StoreKit 2 should report the updated subscription entitlement shortly thereafter (e.g. within a few seconds) via either Transaction.updates or Transaction.currentEntitlements. Below is the minimal interactor used in the sample project. The app considers the purchase successful if either a verified transaction for the product is received via Transaction.updates, or the product appears in Transaction.currentEntitlements when the app returns to the foreground. Otherwise, the flow fails after a 60-second timeout. Questions: Is this entitlement propagation delay expected when redeeming promo codes through the App Store? Is there a recommended API or flow for immediately determining whether a subscription has been successfully redeemed? Is there a more reliable way to detect entitlement changes after promo code redemption without triggering user authentication prompts (e.g., from AppStore.sync())? import UIKit import StoreKit final class PromoPurchaseInteractor { private let timeout: TimeInterval = 60 private struct PendingOfferRedemption { let productId: String let completion: (Result<Bool, Error>) -> Void } private var pendingRedemption: PendingOfferRedemption? private var updatesTask: Task<Void, Never>? private var timeoutTask: Task<Void, Never>? enum DefaultError: Error { case generic case timeout } init() { NotificationCenter.default.addObserver(self, selector: #selector(willEnterForeground), name: UIApplication.willEnterForegroundNotification, object: nil) } deinit { NotificationCenter.default.removeObserver(self) updatesTask?.cancel() timeoutTask?.cancel() } func purchaseProduct(using offerUrl: URL, productId: String, completion: @escaping (Result<Bool, Error>) -> Void) { guard pendingRedemption == nil else { completion(.failure(DefaultError.generic)) return } pendingRedemption = PendingOfferRedemption(productId: productId, completion: completion) startPurchase(using: offerUrl) } @objc private func willEnterForeground() { guard let pendingRedemption = pendingRedemption else { return } startTimeoutObserver() Task { if await hasEntitlement(for: pendingRedemption.productId) { await MainActor.run { self.completePurchase(result: .success(true)) } } } } private func startPurchase(using offerURL: URL) { startTransactionUpdatesObserver() UIApplication.shared.open(offerURL) { [weak self] success in guard let self = self else { return } if !success { self.completePurchase(result: .failure(DefaultError.generic)) } } } private func completePurchase(result: Result<Bool, Error>) { stopTransactionUpdatesObserver() stopTimeoutObserver() guard let _ = pendingRedemption else { return } pendingRedemption?.completion(result) pendingRedemption = nil } private func startTransactionUpdatesObserver() { updatesTask?.cancel() updatesTask = Task { for await update in Transaction.updates { guard case .verified(let transaction) = update else { continue } await MainActor.run { [weak self] in guard let self = self, let pending = self.pendingRedemption, transaction.productID == pending.productId else { return } self.completePurchase(result: .success(true)) } await transaction.finish() } } } private func stopTransactionUpdatesObserver() { updatesTask?.cancel() updatesTask = nil } private func startTimeoutObserver() { guard pendingRedemption != nil else { return } timeoutTask?.cancel() timeoutTask = Task { try? await Task.sleep(nanoseconds: UInt64(timeout * 1_000_000_000)) await MainActor.run { [weak self] in self?.completePurchase(result: .failure(DefaultError.timeout)) } } } private func stopTimeoutObserver() { timeoutTask?.cancel() timeoutTask = nil } private func hasEntitlement(for productId: String) async -> Bool { for await result in Transaction.currentEntitlements { guard case .verified(let transaction) = result else { continue } if transaction.productID == productId { return true } } return false } }

My main goal is to maximize BLE range at the moment, though eventually I would like to allow for greater throughput when updating firmware over the air as well. I understand that Coded PHY is not on the roadmap based on the support ticket I previously entered, but is there any way to force 1M PHY. Even when I request it, I get a phy renegotiation (update) of 2 PHY.

The universal links for my apps stopped working. The server where the AASA files where hosted worked on IPV4 exclusively, a few days ago i changed the configuration to IPV6 only. I´ve created new IPV6 entries, renewed all certifactes and deleted all IPV4 entries for the domains. All seemed fine, but at Saturday I realized that my universal links stopped working for new user. What i´ve done to find the issue: Example domain that was used for debugging: "https://developffw.burns.fun" I´ve verified the AASA file is hosted properly by using different browsers and Postman to retrieve it. The file can be accessed and the certificates look fine. Output of curl -v https://developffw.burns.fun/.well-known/apple-app-site-association * Host developffw.burns.fun:443 was resolved. * IPv6: 2a01:4f8:13b:340a::2 * IPv4: (none) * Trying [2a01:4f8:13b:340a::2]:443... * schannel: disabled automatic use of client certificate * ALPN: curl offers http/1.1 * ALPN: server accepted http/1.1 * Established connection to developffw.burns.fun (2a01:4f8:13b:340a::2 port 443) from 2a00:79c0:65c:8b00:80ee:175b:3e2a:1e7d port 61014 * using HTTP/1.x > GET /.well-known/apple-app-site-association HTTP/1.1 > Host: developffw.burns.fun > User-Agent: curl/8.16.0 > Accept: */* > * Request completely sent off < HTTP/1.1 200 OK < Server: nginx/1.22.1 < Date: Mon, 15 Dec 2025 11:34:22 GMT < Content-Type: application/octet-stream < Content-Length: 329 < Last-Modified: Sat, 21 Dec 2024 08:53:11 GMT < Connection: keep-alive < ETag: "676681f7-149" < Accept-Ranges: bytes < { "applinks": { "details": [ { "appIDs": [ "6LN7G8JEA5.burns.FFW-Manager-SwiftUI.Debug"], "components": [ { "/": "/onboard", "?": { "id": "*"}, "?": { "name": "*"}, "?": { "token": "*" } } ] } ] } } * Connection #0 to host developffw.burns.fun:443 left intact I took a look at the headers from the Apple CDN network response. These indicate some sort of connection error. The response code is 404 Response headers: Apple-Failure-Details: {"cause":"dial tcp [2a01:4f8:13b:340a::2]:443: connect: network is unreachable"} Apple-Failure-Reason: SWCERR00305 Network error Apple-From: https://betaffw.burns.fun/.well-known/apple-app-site-association Apple-Try-Direct: false Via: https/1.1 defra2-vp-vst-003.ts.apple.com (acdn/268.16305), https/1.1 defra2-vp-vfe-004.ts.apple.com (acdn/268.16305), http/1.1 defra2-xdc-mx-028.ts.apple.com (acdn/3.16363), https/1.1 defra1-edge-fx-021.ts.apple.com (acdn/3.16363) X-Cache: hit-stale, miss, hit-fresh, miss CDNUUID: 4321f35e-b73b-4031-a054-7c63af69e126-712221049 Took a look at the log files of the server. I can´t find any entry from the Apple servers neither in the default logs nor in the error log entries. The curl attempts are logged with response code 200. I´ve tried sudo swcutil dl -d https://developffw.burns.fun/onboard in the Terminal on my MAC. Output: The operation couldn´t be completed. (SWCErrorDomain error 8.) This indicates to me threre is an issue for the Apple servers accessing my server. But I don´t know what could be the reason. There is no firewall configuration that could block the requests. And there has been no change at all besides the IPV4 / IPV6 protocol change. This issue is the same for all the domain listed on this server. I´v even created a new app for this purpose and created a new AASA entry and associated link. Same issue. I´m pretty much lost here. Everything looks fine from my side. Google assetlinks.json seem to work fine. I would really appreciate some help on how to solve this, i´m at my wits end.

From the document https://developer.apple.com/documentation/sensorkit/srfetchrequest we know that "SensorKit places a 24-hour holding period on newly recorded data before an app can access it. This gives the user an opportunity to delete any data they don’t want to share with the app. A fetch request doesn’t return any results if its time range overlaps this holding period." Will this holding period reset each time when I called startRecording() ? Let's say I upgrade my app to a new version, do I need to call startRecording again to init the data collection process? will it be able to query the data collected from previous version's app ?

Bank Accounts details are outdated and status is stack on processing with error: "Your banking updates are processing, and you should see the changes in 24 hours. You won't be able to make any additional updates until then." This is now stack for a few years since we activated a previous Apple developer account. we must change banking details as it holds up development of an app with in-app purchases. Finance department has been contacted and they do not answer What shall we do? senior support staff keep referring to finance department and is not helping

My application is from a bank that provides payment passes, and when I try to retrieve passes already enrolled in the wallet, it always returns empty. Is there something I need to configure for it to work? This is what I've tried, and it hasn't worked

Scenario User is actively subscribed to Monthly Package From the Device App (Manage Subscriptions), user upgrades to Yearly Package Purchase completes successfully on device Issue Do not receive any server notification for this action Month Package Purchase Date: 2025-11-11 19:06:45.537 +0600 Month to Yearly Upgradation Date: 2025-12-11 paymentReferenceId: 510002270528780

We are developing a hybrid iOS app where Angular content is rendered inside a WKWebView, hosted by a native Swift application. We use the GameController framework to detect whether an external Bluetooth keyboard is connected to an iPad. The following code is executed when the app enters the foreground and also when requested by the web layer: func keyboardStatusHandler(){ let isKeyboardConnected = GCKeyboard.coalesced != nil if(!isKeyboardConnected){ //sent status to Angular } else { //sent status to Angular } } Crash details We are seeing intermittent crashes on iPad with the following stack trace: Crashed: GCDeviceSession.HID 0 libobjc.A.dylib 0x7db8 objc_retain_x8 + 16 1 libsystem_blocks.dylib 0xfb8 void HelperBase<ExtendedInline>::copyCapture<(HelperBase<ExtendedInline>::BlockCaptureKind)3>(unsigned int) + 48 2 libsystem_blocks.dylib 0xbc4 HelperBase<GenericInline>::copyBlock(Block_layout*, Block_layout*) + 108 3 libsystem_blocks.dylib 0xc94 _call_copy_helpers_excp + 60 4 libsystem_blocks.dylib 0xef8 _Block_copy + 412 5 libdispatch.dylib 0x1a70 _dispatch_Block_copy + 32 6 libdispatch.dylib 0x792c dispatch_async + 56 7 libdispatch.dylib 0x792c dispatch_channel_async + 56 8 GameController 0xea6dc -[GCKeyboardInput _handleKeyboardEvent:] + 324 9 GameController 0x22508 __53-[_GCKeyboardEventHIDAdapter initWithSource:service:]_block_invoke + 376 10 GameController 0x11d30 -[_GCHIDEventSubject publishHIDEvent:] + 268 11 GameController 0xb79cc __40-[_GCHIDEventUIKitClient initWithQueue:]_block_invoke_3 + 44 12 libdispatch.dylib 0x1b584 _dispatch_client_callout + 16 13 libdispatch.dylib 0x12088 _dispatch_async_and_wait_invoke_and_complete_recurse + 272 14 libdispatch.dylib 0x8448 _dispatch_async_and_wait_f + 108 15 GameController 0xb7984 __40-[_GCHIDEventUIKitClient initWithQueue:]_block_invoke_2 + 132 16 GameController 0xb746c __48-[__GCHIDEventUIKitClient _initWithApplication:]_block_invoke + 256 17 UIKitCore 0x11fd394 __61-[UIEventFetcher _setHIDGameControllerEventObserver:onQueue:]_block_invoke_3 + 40 18 libdispatch.dylib 0x1aac _dispatch_call_block_and_release + 32 19 libdispatch.dylib 0x1b584 _dispatch_client_callout + 16 20 libdispatch.dylib 0xa2d0 _dispatch_lane_serial_drain + 740 21 libdispatch.dylib 0xadac _dispatch_lane_invoke + 388 22 libdispatch.dylib 0x151dc _dispatch_root_queue_drain_deferred_wlh + 292 23 libdispatch.dylib 0x14a60 _dispatch_workloop_worker_thread + 540 24 libsystem_pthread.dylib 0xa0c _pthread_wqthread + 292 25 libsystem_pthread.dylib 0xaac start_wqthread + 8 Observed scenarios Crash occurs when the app transitions from background to foreground Crash also occurs when the Angular layer requests keyboard status, triggering the same code path Questions Has anyone encountered crashes related to GCKeyboard.coalesced or GCKeyboardInput like this? Are there known issues with the GameController framework when querying keyboard state during app lifecycle transitions? Is there a recommended or safer way to detect external keyboard connection status on iPad (especially when using WKWebView)? Any insights, known platform issues, or suggested workarounds would be greatly appreciated. Thanks!

当用户开启App自动更新后，自动更新App后，App有些功能会错乱。 1.有的会触发旧App代码功能，如旧版本有个选择框，在新版本选择框从界面移除了，但自动更新看，有的用户会还会触旧版本选择框的功能 2.数据错乱，如App录入数字6，发送到服务端变成5.4 现在发现这些问题。都是要把App删除，重新下载就可以。 请问要如何避免这样的问题。 App是有Objective-C，会不会与开启 BITCODE有关？

We are planning to develop an app that connects to a UVC camera to capture and display video via AVFoundation. Could you please advise on which iPhone models support UVC cameras?

is there a way to make a test subscription in-app purchase expire immediately, for faster testing? it seems exceedingly complicated to test subscriptions if we have to a) wait until the next day for expiry, or b) keep on creating new apple ids to get into a fully unsubscribed state? it is still kind of madness testing this stuff, after all the years it has been available.

Has anyone seen this issue? We have a user who changed their Apple ID password about 5 days ago. Now when they authenticate via MusicKit JS: authorize() succeeds and returns a user token Immediately calling any /me/ endpoint returns 403 "Invalid authentication" (code 40300) Developer token works fine on catalog endpoints User has active Apple Music subscription Other users work fine through the same flow App doesn't appear in user's "Apps Using Your Apple ID" We've tried: Calling unauthorize() before authorize() Clearing localStorage/sessionStorage/cookies Multiple re-auth attempts over several days The token is freshly issued but Apple's API immediately rejects it. Anyone encountered this after a password change? Any workarounds?

Trying to support undo & redo in an app that utilizes Swift Data and as with anything other than provided simplistic Apple demo examples the experience is not great. The problem: Im trying to build functionality that allows users to add items to an item group, where item and item group have a many-to-many relationship e.g. item group can hold many items and items can appear in multiple groups. When trying to do so with relatively simple setup of either adding or removing item group from items relationship array, I am pretty consistently met with a hard crash after performing undo & redo. Sometimes it works the first few undo & redos but 95% of the time would crash on the first one. Could not cast value of type 'Swift.Optional<Any>' (0x20a676be0) to 'Swift.Array<App.CodableStructModel>' (0x207a2bc08). Where CodableStructModel is a Codable Value type inside Item. Adding and removing this relationship should be undoable & redoable as typical for Mac interaction and is "supported" by SwiftData by default, meaning that the developer has to actively either wholly opt out of undo support in their modelContainer setup or do it on a per action scale with the only thing I know of: modelContext.processPendingChanges() modelContext.undoManager?.disableUndoRegistration() ..... modelContext.processPendingChanges() modelContext.undoManager?.enableUndoRegistration() General rant on SwiftData: Random crashes, inconsistencies, random cryptic errors thrown by the debugger and general lack of production level stability. Each update breaks something new and there is very little guidance and communication from the Swift Data team on how to adapt and more importantly consideration for developers that have adopted Swift Data. If SwiftData is not ready for production, it would go a long way to clearly communicate that and mark it as Beta product.

I paid for the program a few days ago , how long till I’m approved?

Hello! I’ve been trying to log in to my iCloud account, but I haven’t been able to access it. A message pops up saying, 'Couldn’t communicate with the server.' Additionally, I can’t update my phone to the latest iOS version. Please, how can I resolve this?

Hello, After being in the AppStore for more than a year with the app working perfectly, yesterday I started seeing that WeatherKit requests failed with Failed to generate jwt token for: com.apple.weatherkit.authservice with error: Error Domain=WeatherDaemon.WDSJWTAuthenticatorServiceListener.Errors Code=2 "(null)" Encountered an error when fetching weather data subset; location=<+41.40217108,+2.20023642> +/- 0.00m (speed -1.00 mps / course -1.00) @ 13/12/25, 12:20:35 Central European Standard Time, error=WeatherDaemon.WDSJWTAuthenticatorServiceListener.Errors 2 Error Domain=WeatherDaemon.WDSJWTAuthenticatorServiceListener.Errors Code=2 "(null)" I checked on developer.apple.com and we still have everything turned on and No changes were made from an already deployed app; and we pay 200$ a month for WeatherKit, this is unacceptable since it's not the first time WeatherKit randomly decides to stop working. More fun facts: the widget works fine...

Hello, I’d like to ask about best practices for handling interactive snippet intents when working with the user’s location. My use case is: 1. Get the user’s location 2. Fetch nearby data 3. Display it My current flow is: try to show the snippet view in "loading" state while waiting for Core Location Manager, then fetch data and reload() the view. BUT I’m running into an issue where I sometimes receive Core Location error 1 (not authorized), even though the main app has “While In Use” authorization. It seems that in some cases, especially when the app has been force-closed, App Intents are unable to start location updates, even though I’m using supportedModes = .foreground(.dynamic). Any guidance would be appreciated. Cheers, Ondrej

We are observing a reproducible issue on some (not all) iPad models equipped with A16, where BLE streaming from multiple peripherals at ≥33–40 Hz results in uneven packet distribution, burst delivery, and application-level lag. The same application, peripherals, firmware, iOS version, and physical environment do not exhibit this behaviour on A14-based iPads (iPad 10). Affected Hardware: • iPad 11" with A16 • iOS versions: identical across tested devices • Issue affects some devices of the same model, not all Internal field data • ~25 affected • ~5 unaffected • Customers actively prefer iPad 10 (A14) due to stability When two or more BLE peripherals stream data concurrently at frequencies ≥33–40 Hz, affected iPads exhibit: • Uneven packet arrival timing • Burst delivery instead of uniform intervals • Increasing latency over time • Observable application-level lag This does not present as simple packet loss. Instead, packets arrive in clusters, breaking real-time assumptions. At ≤30–33 Hz, the issue does not reproduce. We tested: • One affected iPad 11 • One unaffected iPad 11 • Same iOS version • Same app build • Same peripherals • Same firmware • Same physical location • Same Wi-Fi state Only the affected device reproduces the issue. This rules out: • App logic • Peripheral firmware • iOS version • Environmental RF noise • Wi-Fi coexistence configuration Evidence Available We can provide: • Screenshots from a minimal test app showing packet counts • CSV files of packet timestamps • Source code for the BLE test app • Side-by-side comparison logs (affected vs unaffected device) All evidence is from the same app, built solely to measure packet timing. Additional Technical Notes • Issue persists after factory reset • Occurs without third-party BLE libraries (CoreBluetooth only) • Occurs regardless of foreground/background state • Not correlated with MTU size • Appears threshold-based (~33–40 Hz) • Appears device-specific, not model-wide