Summary Our Share Extension works correctly on iOS 18 but silently fails on iOS 26. The app appears in the share sheet, the user taps it, the sheet dismisses — and nothing else happens. The containing app never opens. Environment App: com.yourcompany.app Extension: com.yourcompany.app.shareaudio (com.apple.share-services) Source app: Voice Memos Deployment target: iOS 17.0 iOS 18.x (TestFlight): ✅ works — extension runs, app opens, file imports iOS 26.x (same build): ❌ fails — share sheet closes, extension appears to terminate immediately What we've tried Activation rule — NSExtensionActivationRule with UTI-CONFORMS-TO covering com.apple.quicktime-audio, public.audio, public.mpeg-4-audio, com.apple.m4a-audio, public.file-url. Loading the file — tried loadFileRepresentation(forTypeIdentifier:), loadInPlaceFileRepresentation, and loadItem, with fallbacks prioritizing public.file-url and com.apple.quicktime-audio. Logged registeredTypeIdentifiers to confirm what the provider exposes. Opening the containing app — calling extensionContext?.open(url) before completeRequest. Also tested a secondary URL scheme. App Group is configured; we write a pending flag and check it in sceneDidBecomeActive. Voice Memos export modes — tested both Rendered (.m4a) and Editable (.qta). None of this changed the behavior on iOS 26. Specific questions What does NSItemProvider.registeredTypeIdentifiers return on iOS 26 for Voice Memos recordings, especially .qta files? Is com.apple.quicktime-audio still the correct UTI for .qta on iOS 26, or has it changed? Has the recommended API for loading shared audio changed in iOS 26 — loadFileRepresentation, loadInPlaceFileRepresentation, or loadItem? Is NSExtensionContext.open(_:completionHandler:) still the supported way to open the containing app from a Share Extension on iOS 26? Are there new entitlements or restrictions? Is there any WWDC25 session or updated documentation covering Share Extensions receiving Voice Memos exports (including AVFileType.qta)? Is this a known regression in iOS 26? Happy to share logs, a TestFlight build, or a minimal reproducible project if that helps.

High Power Mode setting is not applied by powerd (possibly related to migrateenergyprefs) Summary On a MacBook Pro (14-inch, M5 Max), enabling High Power Mode in System Settings has no effect on the actual power governor. The system continues to run at the default (Automatic-equivalent) power ceiling regardless of the High Power Mode setting. The same symptom has been reproduced on a different physical machine, a MacBook Pro (M4 Max), ruling out a single hardware defect. Environment Affected device: MacBook Pro 14-inch (Apple M5 Max, 12P+6S+40GPU, 128GB RAM) macOS version: macOS 26.5.1 (Build 25F80) Migration history: Intel Mac → MacBook Air (M2) → MacBook Pro (M4 Max) → MacBook Pro (M5 Max), using Migration Assistant at each step Same symptom also confirmed on the MacBook Pro (M4 Max), which had the same migration history Symptom Selecting "High Power" under System Settings → Battery → Power Mode has no effect on system_profiler SPPowerDataType, which always reports High Power Mode: No. pmset -g custom correctly shows powermode 2 (the High Power equivalent) for AC Power, confirming the user-facing setting is being written correctly. Low Power Mode in the same system_profiler output correctly toggles between Yes/No depending on the UI selection (Automatic / Low Power / High Power). Only High Power Mode fails to track the UI selection. Benchmarking with 3DMark Steel Nomad Stress Test (Metal API) reproduces the score pattern that third-party reviews report for High Power Mode OFF (stabilized score ~3100–3400), rather than the ON pattern reported for the same model (~3600+). This confirms the issue is not just cosmetic (a wrong status string) but reflects an actual difference in the power ceiling being enforced. Investigation steps taken 1. Preference file inspection Inspected /Library/Preferences/com.apple.PowerManagement.<UUID>.plist. Multiple UUID-keyed files exist, each corresponding to a previously used device (identified by battery serial number in the BatteryWarn key). All of them contained HighPowerMode = 0, including the file matching the current machine's serial number. The MacBook Air (M2) used earlier in this device's migration history does not support High Power Mode at all. It's suspected that HighPowerMode = 0 originated from that device and was carried forward through subsequent Migration Assistant transfers to devices that do support the feature, without ever being correctly re-evaluated. 2. Direct write test Used defaults write to directly set HighPowerMode = 1 in the relevant plist. system_profiler then reported High Power Mode: Yes, and this persisted across a reboot. However, a subsequent benchmark run showed no improvement — powermetrics Combined Power remained in the 27–30W range, and the Steel Nomad Stress Test stabilized score actually dropped slightly (~3134 average over the last 10 loops). This indicates the displayed value is decoupled from the actual power governor state. 3. File deletion / regeneration test Deleted the UUID-keyed plist (after backing it up) and let powerd regenerate it from scratch. The newly generated file still showed HighPowerMode stuck at No and unresponsive to UI changes, while LowPowerMode continued to track UI changes correctly. The same test was repeated with the non-UUID common file (com.apple.PowerManagement.plist), with no change in behavior. This rules out stale/corrupted preference data as the root cause. 4. Binary-level investigation Searched the system for files containing the string "HighPowerMode". Aside from unified logging symbol caches (uuidtext, not relevant), the following were found: /System/Library/CoreServices/powerd.bundle/powerd (Apple-signed, Signed Time: Apr 19, 2026, Platform identifier 26) /System/Library/CoreServices/powerd.bundle/migrateenergyprefs.bundle/ (com.apple.migrateenergyprefs, LSMinimumSystemVersion 26.5, built with Xcode 2630) /System/Library/SystemProfiler/SPPowerReporter.spreporter/ /System/Library/ExtensionKit/Extensions/BatterySettingsIntentsExtension.appex/ The presence of a dedicated com.apple.migrateenergyprefs component strongly suggests this is the code path responsible for carrying power preferences across device migrations. We suspect this migration logic fails to correctly initialize or re-evaluate HighPowerMode when migrating from a device that doesn't support the feature to one that does. Reproducibility Reproduced on two distinct physical machines (M4 Max and M5 Max), making a hardware fault unlikely. Reproduced after deleting and regenerating the preference files, ruling out simple cache corruption. Reproduced after a full reboot, ruling out a transient in-memory state issue alone. Impact Because High Power Mode is not actually engaged, sustained CPU/GPU performance under heavy load is capped at a lower power ceiling than intended, resulting in measurably lower benchmark scores and sustained performance compared to the documented behavior of the same hardware configuration. Questions for Apple Could the com.apple.migrateenergyprefs logic be reviewed for how it handles HighPowerMode when migrating from a device that does not support the feature (e.g., MacBook Air M2) to one that does? Is there a known issue with HighPowerMode specifically (as opposed to LowPowerMode, which behaves correctly) not being written back by powerd in response to UI changes? Are there other users with a similar multi-generation Migration Assistant history reporting the same symptom? Happy to provide a sysdiagnose or additional logs if useful.

model : iphone 17 ios version: 26.2 app used: https://developer.apple.com/documentation/wifiaware/building-peer-to-peer-apps Here is our observation when we tried to make wifi aware connection between iphone and our wifi device. note : we used iphone as subscriber ( view simulation) 1.pairing & bootstrapping was successfully done 2.Data path was successfully established between iphone and our device. after data path establishment ,within few seconds , DATA PATH TERMINATION was sent from iphone which leads to pairing verification with new NMI address. Same behaviour is noticed even when we try to establish connection between two iphone devices. Here we have few questions. Once we establish data path , Why iphone initiates data path termination instead using the same service for data path exchange. 2.Why do we go for PAIRING VERIFICATION everytime.

Since July 25, multiple production users have been unable to load previously saved records from a CloudKit private database. The query uses CKQueryOperation with: Record type: UserAnLi Predicate: category_sub_id == "1401" Sort descriptor: creationDate descending Results limit: 20 The requests consistently fail after approximately 10 seconds with: Error domain: CKErrorDomain Error code: 15 (CKErrorServerRejectedRequest) Underlying error: CKInternalErrorDomain Code=2000 HTTP status: 500 CKErrorRetryAfterKey: absent CKErrorShouldThrottleClient: absent Examples from two different users/devices: iOS 18.3.2 RequestUUID: 67890D6B-8076-4135-9635-7DCCFF38D94F OperationID: A796C6799FA69D66 CloudKit partition: 233 Edge response time: 10024 ms iOS 26.6 RequestUUID: 1249FEAE-9D5A-40CB-9076-DAD2D8396BCF OperationID: CEC87546C31D61E2 CloudKit partition: 227 Edge response time: 10086 ms Users are signed in to iCloud, iCloud Drive is enabled, and general network access works normally. According to TN3162, documented CloudKit throttling normally returns CKErrorServiceUnavailable or CKErrorRequestRateLimited with a retry-after value. These failures instead return CKErrorServerRejectedRequest, HTTP 500, and no retry-after information. The issue has been reported through Feedback Assistant: FB24046201 Could this indicate a production CloudKit query/index problem, a server-side query timeout, or an undocumented/misreported throttle? Is there any client-side mitigation, or does this require investigation by the CloudKit backend team?

On the first connection after pairing, our accessory acts as an ANCS client over GATT over BR/EDR. After service discovery, we enable notifications by writing the CCCDs of both the Notification Source and Data Source characteristics. This succeeds, but the iPhone does not send notifications for existing unread notifications. It only sends Notification Source notifications for newly received notifications (for example, new instant messaging notifications), which is the behavior we expect. After disconnecting and reconnecting the BR/EDR connection, our accessory performs the same ANCS initialization sequence and enables the same CCCDs again. If there are a large number of unread notifications on the iPhone (approximately 30 or more), the iPhone immediately starts sending Notification Source notifications for many existing unread notifications. During this process, the GATT over BR/EDR connection becomes unresponsive. Our accessory sends an ATT Write Request to the ANCS Control Point characteristic to retrieve notification attributes. The iPhone HCI log shows that the Write Request is received by the iPhone, but no corresponding ATT Write Response is ever sent. About 30 seconds later, the iPhone disconnects the GATT over BR/EDR L2CAP channel. This issue is reproducible only when there are many unread notifications (approximately 30 or more). If there are only a few unread notifications, the problem does not occur. Expected Behavior The iPhone should continue processing ANCS requests normally regardless of the number of unread notifications. After receiving the ATT Write Request to the ANCS Control Point characteristic, it should return the corresponding ATT Write Response and continue sending Data Source notifications containing the requested notification attributes.

Has anyone run into an expired access grant on Apple Business Register for "Tap to Pay on iPhone for Payment Providers"? Context: I work on a Tap to Pay on iPhone integration at a payment service provider. I was granted access to the PSP section of Apple Business Register roughly six months ago and had been using it without issue. Steps to reproduce: Sign in to register.apple.com with the Apple Account that originally received access. Open the Tap to Pay on iPhone for Payment Providers section. A dialog appears: "Your access to the connection expired. Contact your organization admin to renew your access for Tap to Pay on iPhone for Payment Providers." The dialog only has an OK button. Dismissing it leaves a blank page — there is no renewal link or request option anywhere in the interface. What I've already ruled out: Signed in with the correct Apple Account (not a personal one) Full sign out and sign back in Tested in a different browser with extensions disabled Same result every time. What I'm hoping to learn from anyone who's been through this: Was your Account Holder able to re-grant access to a member directly inside Apple Business Register? If so, roughly where in the interface? Or did it require Apple to restore it on their side — and how long did that take? Is the access window a fixed six months for everyone, and does Apple send any warning before it lapses? I've opened a case with Apple Developer Support in parallel, but I'd like to hear whether others have hit the same wall and what actually resolved it. Thanks.

Overview We are developing a BLE + UWB accessory. We need to initiate UWB ranging as quickly as possible after establishing a BLE connection with an iPhone. However, it consistently takes approximately 900–1000 ms from centralManager(_:didConnect:) until the notification subscription (setNotifyValue) reaches the accessory. Most of this delay does not appear to be caused by ATT throughput or accessory response times, but rather by internal iOS processing. Details (Observed Behavior and Measurements) We tested this by implementing code on the app side to delay calling discoverServices by 1 second, measuring the processing times for both scenarios (with vs. without delay). Elapsed time for each phase measured on the app side (CBPeripheralDelegate): Phase Calling discoverServices immediately after connection Delaying discoverServices by 1 second didConnect → discoverServices call 0.1 ms (1000 ms delay) discoverServices → didDiscoverServices 416 ms 26 ms didDiscoverServices → didDiscoverCharacteristics 90 ms 60 ms Key Observations: The most notable finding is that simply delaying the discoverServices call by 1 second reduces the discoverServices → didDiscoverServices duration from 416 ms to 26 ms. This suggests that iOS is performing some internal processing right after connection, during which ATT service discovery responses appear to be delayed/postponed. Pure ATT discovery (Services + Characteristics) completes in about 86 ms when delayed. The app calls setNotifyValue(true, for:) immediately without delay inside peripheral(_:didDiscoverCharacteristicsFor:error:). However, the accessory receives the CCCD write approximately 400 ms after discovery completes. (Note: This 400 ms is an estimate based on the difference with accessory-side measurements). On the accessory side, completion of the ATT MTU exchange was observed around 380 ms after connection. Hypothesis We hypothesize that during the "first ~1 second after connection," iOS is sequentially executing link-layer control procedures (e.g., Feature Exchange, Version Exchange, Data Length Update, PHY Update) as well as ATT MTU exchange. Because these procedures are processed sequentially, ATT service discovery responses may be deprioritized or queued behind them. We have isolated the issue on the accessory side: the peripheral responds immediately to all requests, confirming that accessory processing delays or ATT throughput limitations are not the cause. Questions Is taking several hundred milliseconds to ~1 second from connection establishment (didConnect) to the completion of service discovery and notification subscription expected behavior in iOS? Is our understanding correct that iOS (CoreBluetooth / Bluetooth Controller) is executing link-layer control procedures during this initial period? If not, what specifically is taking place? Are there any means to shorten this duration from the app side or via peripheral connection parameters? Given the significant difference in response time between calling discoverServices immediately vs. delaying it, is there any way to prioritize ATT traffic right after connection or accelerate these procedures? For accessories that need to begin ranging immediately after connecting, what are the recommended best practices to minimize latency before data communication can start?

Hello, I’m experiencing what appears to be an app-specific Sandbox catalog propagation issue. Environment: Bundle ID: com.auroradrama.app App Store Connect App ID: 6786937298 StoreKit 2 Testing with a Sandbox Apple Account on a physical device An older product can still be fetched successfully: com.heroon.aurora.vip.year However, all newly created products return an empty result from Product.products(for:). Examples: com.auroradrama.pay.en.a.vip.week com.auroradrama.pay.en.a.coin.t1 com.auroradrama.test.coin001 The last product was created manually in the App Store Connect web interface, while the others were created through the App Store Connect API. Therefore, this does not appear to be specific to API-created products. Example result: Bundle ID: com.auroradrama.app Requested products: com.auroradrama.pay.en.a.vip.week com.auroradrama.pay.en.a.coin.t1 Returned product count: 0 Missing product IDs: com.auroradrama.pay.en.a.vip.week com.auroradrama.pay.en.a.coin.t1 I also tested the new product IDs using: Settings → Developer → Sandbox Apple Account → Manage → Initiate Purchase The system reports that the new product IDs are invalid. Therefore, the issue can be reproduced outside of my application code. I have verified through the App Store Connect API that the new products have: READY_TO_SUBMIT state Product versions in PREPARE_FOR_SUBMISSION Localization metadata A price configured for the United States Availability in 175 territories availableInNewTerritories enabled Valid subscription groups and subscription periods where applicable The Paid Applications Agreement, banking information, and tax information are all active. The app has the In-App Purchase capability enabled. Since an older product still works with the same app, Bundle ID, signing configuration, device, Sandbox account, and StoreKit code, these settings appear to be correct. The new products have remained unavailable for more than eight hours, which is well beyond the documented Sandbox metadata propagation period. Has anyone experienced a situation where old products remain available but every newly created product fails to enter the Sandbox StoreKit catalog? Could an Apple engineer please check whether the device-facing Sandbox catalog/index for App ID 6786937298 needs to be reprocessed or re-propagated? I can provide the App Store Connect resource IDs, timestamps, StoreKit logs, and a sysdiagnose privately if needed. Thank you.

We have an iOS app (Alamofire 5.9+, backed by URLSession) that talks to a LAN dashcam: HTTP/1.1 TLS 1.2 The device runs an embedded C HTTPS server Responses commonly include Connection: close (a new TCP connection is opened for each request) From Wireshark, looking at Client Hello, we observe: First connection: full handshake; a Session ID is negotiated Next new TCP connection: Client Hello carries that Session ID and completes an abbreviated handshake (resumption succeeds) After that: the same Session ID is not reused again Questions we want to confirm For TLS 1.2 Session ID resumption (RFC 5246), does iOS / URLSession intentionally allow a cached session to be resumed at most once? Or can the same Session ID be resumed multiple times until it expires / is evicted from the cache? Without changing the overall LAN dashcam product model, how should the server be configured—e.g. moving to TLS 1.3 and/or HTTP/2—so that iOS clients can resume via Session Ticket and/or Session ID multiple times? What we have already ruled out / observed The client already uses a shared long-lived URLSession / Alamofire Session (we do not create a new session per request) The server often returns Connection: close, so each request uses a new TCP connection; we are discussing TLS session resumption across connections, not HTTP keep-alive We occasionally see TLS time of only ~10–20 ms, which suggests at least one successful session resumption has occurred

Hi, Overview I am trying to write a unit test case to buy a storekit product. SKTestSession.buyProduct(identifier: options:) throws the error StoreKit.StoreKitError.notEntitled Testcase Code @Test func example() async throws { let session = try SKTestSession(configurationFileNamed: "VehicleStore") session.disableDialogs = true session.clearTransactions() do { let transaction = try await session.buyProduct(identifier: "nonconsumable.car", options: []) print(transaction) } catch { // Throws StoreKit.StoreKitError.notEntitled print("Error: \(error)") } } Storekit configuration file Note In-App purchases capability is added StoreKit configuration file is used in testcase Environment: macOS 26.5.2 (25F84) Xcode 26.6 (17F113)

I am preparing to save CLLocation data to CloudKit. In the dashboard, when you create a location object, you only can specify lat/long. In the archived CloudKit web services reference, the location dictionary shows more than that is being saved. https://developer.apple.com/library/archive/documentation/DataManagement/Conceptual/CloudKitWebServicesReference/Types.html#//apple_ref/doc/uid/TP40015240-CH3-SW5 However, this is in the archive. I want to know via documentation if all of the current properties of a CLLocation are saved, and if it is reasonable to assume future fields would be too. The documentation was likely archived BEFORE properties like speedAccuracy, courseAccuracy, source, information floor, and ellipsoidal altitude. FB24049646 - CloudKit: Do all properties of CLLocation get persisted in CloudKit when setting a record value as CLLocation - CKWS archive reference Location Dictionary doesn't show new fields (speed/course accuracy, source info, floor, ellipsoidalAltitude)

userlog.txt We've run into some HTTP request errors, details as follows: We're currently at a loss because restarting the app doesn't help, only rebooting the phone restores things to normal. Based on tracking data, the occurrence rate for users is about 0.033%, and it's only happening on iOS, Android is fine. iOS operating system versions: 14-27 are all affected. The same issue appears in Rust, Flutter, and C/C++. Rust： 2026-07-11-19:39:22.252+0800|F4E26069-2D7E-4D5F-8B53-664E012B2CA7|UPLogDefaultLogger|DEBUG|测试模式|1023629905|[userdomain_rust/rust_userdomain/src/operator/device_ops/refresh_device_list_op.rs:61]query_device_list error: HttpRequstFaild(Reqwest(reqwest::Error { kind: Request, url: "https://zj.haier.net/api-gw/wisdomdevice/device/v11/family/devices?familyId=ALL&filterFlag=false", source: hyper_util::client::legacy::Error(Connect, ConnectError("tcp connect error", 36.156.179.34:443, Os { code: 49, kind: AddrNotAvailable, message: "Can't assign requested address" })) })) Flutter： 2026-07-11-15:29:02.718371+0800|b2257ae8-f7d8-41d0-8811-2ff1824f95d9|UpPlugins|ERROR|正常模式|1023629905|level:error tag:smart_home msg:getWholeHousePreferenceSetting err: DioException [unknown]: null Error: SocketException: Connection failed (OS Error: Can't assign requested address, errno = 49), address = zj.haier.net, port = 443 C/C++： 2026-07-11-19:39:15.247588+0800|a991af96-bf02-4b94-a437-d4f7efc249ff|uSDK|ERROR|正常模式|1023629905|[CAE][[cae_sock_no_ssl_last_err:869][connect fd 122 ret -1 err 49: Can't assign requested address] ] Native iOS HTTP interface requests work fine, for example when using AFNetworking. Looking for your help~

We have an application which is written in Swift, which activates Transparent Proxy network extension. Our Transparent Proxy module is a system extension, which is exposing an app proxy provider interface (We are using NETransparentProxyProvider class and in extension’s Info.plist we use com.apple.networkextension.app-proxy key.) Sometimes we have observed that on starting the transparent proxy extension, the startProxy overridden delegate method(override func startProxy(options: [String : Any]?, completionHandler: @escaping (Error?) -> Void) {) in our AppProxyProvider class which is derived from NETransparentProxyProvider being called more than once for the same extension(pid). This leads to Over-resume of an object crash as we invoke setTunnelNetworkSettings inside the startProxy delegate. As this is controlled by the system, we are not sure why this delegate being called more than once sometimes even if we call the start TransparentProxy only once. Note that, this issue is seen only in Mac OS Tahoe. Apple Feedback ticket: FB21464147 (startProxy delegate for NETransparentProxyProvider class is being called twice for the same pid extension sometimes)

Since January 28, 2026, we’ve noticed an increase in StoreKit-related errors during purchase flows. Specifically, we’re seeing a spike in errors reported as “Unable to Complete Request”, categorized as unknown StoreKit errors. This correlates with a noticeable drop in the overall purchase success rate. A few observations: The issue is not limited to the latest app version, it also affects older versions. It appears to occur only on iOS 17+. The impact seems country-specific: some regions are affected more heavily, while others show no significant change compared to previous days. At the moment, there are no related incidents reported on Apple’s System Status page. Given these symptoms, this looks like a potential StoreKit / Apple API issue, but we haven’t found any official confirmation yet. Has anyone else observed similar StoreKit behavior recently on iOS 17+? Any insights or known issues would be greatly appreciated.

The total physical memory of 3GB iOS devices is very tight. After system memory occupation, the available memory for third-party apps is extremely insufficient, leading to frequent OOM termination. Enabling or disabling JavaScriptCore causes a huge difference in app memory crash threshold. Without JSC, the app will crash at only 1.52GB memory usage, which severely restricts normal business running. The common 4MB and 8MB memory allocation used in our project falls into the high memory fragmentation range defined by libmalloc, resulting in the lowest memory crash limit and worst stability. Our core business relies heavily on JSC environment for JS interaction, resource rendering and dynamic logic execution. We cannot shut down JSC, but 3GB devices still face serious memory shortage even with JSC enabled. Mass users with 3GB RAM old iOS devices suffer from frequent app crashes, freeze, background kill and loading failure, which badly damage user experience and product reputation. We have finished all app-level memory optimization: adjust allocation size, optimize memory release, reduce resident memory, but still cannot break through the fixed memory crash limit. There is no effective solution on application layer. We sincerely ask Apple official engineers to provide official suggestions, system-level memory tuning solutions and JSC memory scheduling optimization guidance to solve the memory limit bottleneck on 3GB RAM iOS devices.

We are implementing in-app provisioning in our fintech app; We are reaching out to ask for your help in understanding what is going wrong so we can fix it. What happens: User taps “Add to Apple Wallet” → we present PKAddPaymentPassViewController → they tap Next → after a few seconds the flow fails with "Set Up Later" alert. Device log: "eligibility request failure", "Received HTTP 500" )'; underlyingError: 'Error Domain=PKPaymentWebServiceErrorDomain Code=0 "Unexpected error." UserInfo={PKErrorHTTPResponseStatusCodeKey=500, NSLocalizedDescription=Unexpected error.}'; userInfo: '{ PKErrorHTTPResponseStatusCodeKey = 500; }'; > Feedback Assistant ID: FB22176928 (In-App Provisioning issue 500 Internal Server Error)

Summary On a physical iPhone, the app never receives an APNs device token (application:didRegisterForRemoteNotificationsWithDeviceToken: never fires, even after waiting 60 seconds after login and calling registerForRemoteNotifications). The symptom reproduces identically in two different apps (different bundle IDs, same Team), over both WiFi and cellular data, even after a full device restart. Other apps on the same device (WhatsApp, Gmail, etc.) receive push notifications normally. Account details Team ID: 6NJN39FM4A Program: Apple Developer Program (Individual), active through June 26, 2027, no pending payments or agreements Signing Apple ID: my developer Apple ID (account in good standing) Affected apps (same issue in both) com.movicolombia.driver com.movicolombia.passenger For both App IDs, in Certificates, Identifiers & Profiles, the Push Notifications capability is checked/enabled (Environment: Sandbox & Production, Key Restriction: Team Scoped). Test device Physical iPhone, iOS 26.5.2, installed directly via Xcode (flutter run --release, automatic signing, development provisioning profile — not TestFlight or App Store) Configuration already verified as correct Correctly signed entitlements: confirmed by inspecting the device system log at launch time — the embedded entitlement includes aps-environment: development and the correct application-identifier. Push Notifications capability added in Xcode (Signing & Capabilities) for both targets, with Automatically manage signing on, no signing/provisioning errors in the build. APNs authentication key (.p8) uploaded in Firebase Console → Cloud Messaging → Apple app configuration, applied to both the development and production rows. Notification permission granted by the user (confirmed in Settings). No active Content & Privacy Restrictions. No VPN or device management profiles installed. Active iCloud account on the device with the same development Apple ID. Troubleshooting already performed (all unsuccessful) Full app reinstall Full device restart Test over WiFi — getAPNSToken() nil after 60s Test over cellular data (WiFi off) — same result Full build cache wipe (flutter clean + deleting ~/Library/Developer/Xcode/DerivedData) and rebuild from scratch, to rule out a stale binary Test with a second app (different bundle ID) on the same device — same exact failure Technical detail After registerForRemoteNotifications is invoked (automatically, by the Firebase Messaging SDK on app launch), neither didRegisterForRemoteNotificationsWithDeviceToken: nor didFailToRegisterForRemoteNotificationsWithError: is ever called. As a result, FirebaseMessaging.getAPNSToken() (Flutter/FlutterFire) returns nil indefinitely, and getToken() throws: [firebase_messaging/apns-token-not-set] APNS token has not been set yet. Please ensure the APNS token is available by calling getAPNSToken(). I instrumented a polling loop calling getAPNSToken() every second for 60 seconds after login — across more than 10 test runs (WiFi, cellular, before/after device restart) it never returned a non-nil value. What I'm hoping to learn Whether there's something on Apple's side (APNs service state, account/ Team status, or this specific device) preventing this iPhone from completing push registration for apps signed with this Team ID — since I've ruled out every app-level, Xcode-level, and Firebase-level configuration issue I could think of.

Hello, I am developing a native CarPlay application and would appreciate some clarification regarding AVAudioSession behaviour when using the vehicle microphone. The application is intentionally simple and designed to minimise driver distraction. The user presses a single button on the CarPlay screen, the application performs a brief (approximately five second) audio capture, performs application-specific processing on the captured audio, displays a simple confirmation to the user, and immediately releases the audio session. The goal is to allow the driver to continue their journey with as little interaction as possible. Because the audio being captured is often originating from the vehicle’s native DAB/FM radio rather than from the iPhone itself, preserving the existing listening experience during the brief capture is fundamental to the intended design. To better understand what is supported by CarPlay, I have carried out a number of controlled experiments. Test Environment Native CarPlay application Swift AVFoundation AVAudioSession AVAudioRecorder Vehicle connected via CarPlay Vehicle playing its native DAB radio Experiment 1 Configuration Category: AVAudioSession.Category.playAndRecord Mode: AVAudioSession.Mode.default Observed Route Input: CarPlay — CarAudio Output: CarPlay — CarAudio Result Recording succeeds using the vehicle microphone. Native DAB audio is muted during recording. The vehicle changes from “Audio Volume” to “Voice Volume”. When recording finishes and the AVAudioSession is deactivated, DAB resumes normally. Experiment 2 Changed only the session mode to: AVAudioSession.Mode.measurement Result Behaviour was identical to Experiment 1. Experiment 3 Changed only the session mode to: AVAudioSession.Mode.videoRecording Observed Route Input: iPhone microphone Output: CarPlay — CarAudio Result Input automatically switched from the vehicle microphone to the iPhone microphone. The vehicle remained in normal “Audio Volume”. However, the head unit switched away from its native DAB source to the CarPlay media source. Observation These experiments appear to suggest that the behaviour is specifically related to using the CarPlay “CarAudio” microphone route, rather than audio recording itself. Question Is this the expected behaviour for third-party CarPlay applications? More specifically: Is there any supported AVAudioSession configuration or CarPlay API that allows a third-party CarPlay application to perform a brief, user-initiated audio capture using the vehicle microphone without causing the head unit to enter its communications/voice audio mode or interrupt the vehicle’s native radio playback? If this behaviour is by design and no supported mechanism exists to achieve this, confirmation of that would be extremely valuable, as it would allow us to design the application accordingly. If additional information, sample code, AVAudioSession logs or detailed reproduction steps would be helpful, I would be more than happy to provide them. Thank you very much for your time. Kind regards, Neil Jenner Developer, HearSave

Hello everyone, I am currently refining our server-side transaction verification and purchase tracking using StoreKit 2 and the App Store Server API. We are looking into how our backend can accurately track the specific App Store commission rate applied to each individual transaction. With potential future regulatory changes in various markets that might introduce different fee structures between device types, it is becoming crucial for our system to distinguish these details at the transaction level. I contacted Apple Support regarding this but couldn't get a technical clarification, so I would like to ask the community and Apple engineers here: (1) Commission Rate: Is there any standard field in the StoreKit 2 Transaction payload or the JWS payload from the App Store Server API (V2) that explicitly indicates the applied commission rate (e.g., 15%, 30%) or a specific commission tier for that transaction? (2) Device Type: If the commission rate is not directly included, is there a native field in the real-time transaction payload to identify whether the purchase was made on an iPhone or an iPad? (I understand we can use appAccountToken as a workaround to link client-side device info to our backend, but I am wondering if there is a built-in identifier.) (3) Official Verification Method: If real-time API payloads contain neither, would using the App Store Connect API to retrieve the "Summary Sales Report" or "Subscriber Report"—and deriving the commission rate from Customer Price and Developer Proceeds—be the recommended approach? Are there any other best practices for handling this at scale? Any insights from Apple engineers or developers who have implemented similar tracking would be highly appreciated. Thank you in advance!

I'm trying to explore accessory setup kit and migrate an existing CoreBluetooth-paired BLE device into AccessorySetupKit using ASMigrationDisplayItem. The regular ASPickerDisplayItem discovery picker works perfectly on the same device/session/Info.plist. But ASMigrationDisplayItem consistently fails. Code let descriptor = ASDiscoveryDescriptor() descriptor.bluetoothServiceUUID = CBUUID(string: "0xFDEE") let migrationItem = ASMigrationDisplayItem( name: "HUAWEI FreeClip 2", productImage: productImage, descriptor: descriptor ) migrationItem.peripheralIdentifier = peripheralIdentifier // peripheralIdentifier is a valid CBPeripheral.identifier UUID // CBCentralManager is suspended before this call (suspendForASK) session?.showPicker(for: [migrationItem]) { error in // Completion is either called with error 500, or NEVER called (silent no-op) } Test Results (8 rounds) # Approach Result 1 suspendForASK → immediate showPicker Silent no-op 2 suspendForASK → 0.6s delay → showPicker Silent no-op 3 .activated event → showPicker (no CBManager exists yet) Silent no-op 4 viewDidAppear → 0.5s delay → showPicker Silent no-op 5 User taps alert button (explicit gesture context) → showPicker Silent no-op 6 Clear pickerDisplaySettings before migration showPicker Error 500 (pickerAlreadyActive) 7 invalidate() → activate() → immediate showPicker (fresh session) Silent no-op 8 invalidate() → activate() → wait for .activated → showPicker Silent no-op Round 6 logs (Error 500): [ASK] Starting migration for peripheral: D0F13212-**** Picker already activated ← System message [ASK] Migration picker failed: ASErrorDomain error 500. Round 8 logs (Silent no-op, cleanest test): XPC connection invalid ← System message [ASK] Session invalidated: no error [ASK] Session activated ← New session .activated [ASK] Executing pending migration showPicker after .activated // → NO pickerDidPresent, NO migrationComplete, NO completion callback, NO error, NO UI Ruled Out Info.plist — regular ASPickerDisplayItem works with identical config Session state — .activated confirmed, session non-nil CBManager conflict — suspended before migration; round 3 ran before any CBManager existed User gesture — round 5 inside button tap handler (same context as working picker) Timing — delayed to viewDidAppear, waited for .activated event peripheralIdentifier — valid UUID, device is actively connected via CoreBluetooth Questions Is ASMigrationDisplayItem fully functional on iOS 26.x? Across 8 different invocation patterns, it either returns error 500 or silently no-ops — no UI ever appears. What causes the residual "Picker already activated" state (error 500), and how do we properly reset it? The XPC connection invalid system message appears consistently. Does this indicate the daemon is rejecting the migration request? Are there prerequisites we're missing? E.g., must the device be disconnected from CB? Must NSBluetoothAlwaysUsageDescription be removed? Is there a different descriptor requirement for migration vs discovery?