Posts under App & System Services topic

Post

Replies

Boosts

Views

Activity

Supported native alphabet navigation for CPListTemplate on iOS 27
We need to retain CarPlay's native A–Z button between the scroll arrows in an audio app. This is core navigation for an album/artist library. We use CPListSection(items:header:sectionIndexTitle:) with single-character labels. The sectionIndexTitle API is still documented and is not deprecated in the Xcode 27 SDK. We need the supported native implementation, not a custom picker. On a parked physical head unit with an iPhone running iOS 27, our app displays populated album rows and section headers but no A–Z. Apple Music displays A–Z on the same head unit. We do not know Apple Music's internal implementation. A standalone, public-API-only reproduction is prepared; its CarPlay scene code is included below. Each tab supplies four A/B/M/Z sections of ten synthetic rows. The variants are initially populated, updated after loading, the full section initializer, and securely archived and decoded sections. No network, authentication or artwork is required. The original app displays functioning native alphabet navigation on the iOS 26.5 CarPlay simulator. The public probe compiles. We cannot run an end-to-end iOS 27 CarPlay simulator session because Device Hub requires a physical device, as confirmed in developer forum thread 834440. Separately, an isolated local diagnostic hosted the native list renderer with CarPlay traits. Both runtimes receive four nonempty index labels and all 40 rows. On iOS 26.5 (23F77), its table data source returns A/B/M/Z. On iOS 27.0 (24A434), the attached UICollectionViewDiffableDataSource returns nil index titles. Both the full initializer and secure archive round-trip preserve titles but produce the same result. This diagnostic is not an end-to-end CarPlay session and does not establish the exact internals on the physical phone. A standard UIKit table supplied with index titles and CarPlay traits still displays the native A–Z button on the same iOS 27 runtime. The control itself still exists; the observed failure is the template-to-index connection. This control experiment is also hosted in a phone window, not a CarPlay session. A standard UIKit collection data source implementing indexTitles(for:) also shows index letters on this runtime; the unmodified template renderer's collection data source returns nil. We have not modified that renderer. Questions: Did iOS 27 move native CPListTemplate alphabet navigation to another API, configuration, or presentation requirement? What is the supported migration? If sectionIndexTitle remains the correct input, is this a known regression in the new list renderer, and what supported correction is available? How should third-party audio apps reproduce Apple Music's native alphabet navigation on iOS 27 without private API or replacing it with a custom control? Please provide a working public-API example or identify the relevant fix/version. Reproduction: use the audio CarPlay entitlement and configure CPTemplateApplicationScene with CarScene as its delegate. This is the scene code from the compiling standalone probe: import CarPlay import UIKit @MainActor func indexedSections() -> [CPListSection] { ["A", "B", "M", "Z"].map { letter in let items = (1...10).map { number in let item = CPListItem(text: "\(letter) Album \(number)", detailText: "Synthetic test entry") item.handler = { _, completion in completion() } return item } return CPListSection(items: items, header: letter, sectionIndexTitle: letter) } } final class CarScene: UIResponder, CPTemplateApplicationSceneDelegate { func templateApplicationScene(_ scene: CPTemplateApplicationScene, didConnect controller: CPInterfaceController) { let ready = CPListTemplate(title: "Ready", sections: indexedSections()) ready.tabTitle = "Ready" ready.tabImage = UIImage(systemName: "list.bullet") let updated = CPListTemplate(title: "Updated", sections: [CPListSection(items: [CPListItem(text: "Loading", detailText: nil)])]) updated.tabTitle = "Updated" updated.tabImage = UIImage(systemName: "arrow.clockwise") let full = CPListTemplate(title: "Full Init", sections: indexedSections().map { CPListSection(items: $0.items, header: $0.header ?? "", headerSubtitle: nil, headerImage: nil, headerButton: nil, sectionIndexTitle: $0.sectionIndexTitle) }) full.tabTitle = "Full Init" full.tabImage = UIImage(systemName: "list.bullet.rectangle") let decoded: CPListTemplate do { let sections = try indexedSections().map { section in let data = try NSKeyedArchiver.archivedData(withRootObject: section, requiringSecureCoding: true) guard let restored = try NSKeyedUnarchiver.unarchivedObject(ofClass: CPListSection.self, from: data) else { throw CocoaError(.coderReadCorrupt) } return restored } decoded = CPListTemplate(title: "Decoded", sections: sections) } catch { decoded = CPListTemplate(title: "Decode failed", sections: [CPListSection(items: [ CPListItem(text: "Section decoding failed", detailText: String(describing: error)) ])]) } decoded.tabTitle = "Decoded" decoded.tabImage = UIImage(systemName: "shippingbox") controller.setRootTemplate(CPTabBarTemplate(templates: [ready, updated, full, decoded]), animated: false) { _, _ in } Task { @MainActor in try? await Task.sleep(for: .seconds(2)) updated.updateSections(indexedSections()) } } }
0
0
111
1w
NSMenuItem.separator() appears as blank space in Finder Sync extension context menu
Hi, I’m developing a macOS Finder Sync extension and noticed that NSMenuItem.separator() does not appear to render as a standard separator line when used inside the menu returned from FIFinderSyncController. In a normal AppKit NSMenu, the separator renders as expected. However, when the same kind of menu is returned from the Finder Sync extension, the separator appears as a blank/full-height empty row rather than a thin dividing line. Example: override func menu(for menuKind: FIMenuKind) -> NSMenu { let menu = NSMenu(title: "") menu.addItem(NSMenuItem( title: "First Action", action: #selector(firstAction(_:)), keyEquivalent: "" )) menu.addItem(NSMenuItem.separator()) menu.addItem(NSMenuItem( title: "Second Action", action: #selector(secondAction(_:)), keyEquivalent: "" )) return menu } Expected result: The separator should render as a normal macOS menu separator line between the two menu items. Actual result: In Finder’s context menu, the separator is displayed as blank vertical space / an empty menu row. I understand that Finder Sync menus are rendered by Finder and may not support every NSMenuItem feature. However, NSMenuItem.separator() is a very standard way to visually group menu commands, so I wanted to ask: Is this a known limitation of Finder Sync extension menus? Is there a supported way to display a real separator line in Finder Sync context menus? Should this be filed as a Feedback Assistant issue against Finder Sync / AppKit? I’m trying to avoid fake separators such as disabled menu items with "────" as the title, since that does not feel native and may not behave well with different fonts, accessibility settings, or appearance modes. Thanks!
1
1
646
1w
SwiftData with CloudKit Error: Error updating background task request
Hi, Overview I have a SwiftData project which automatically syncs with CloudKit. When I run the app, I see the following error in Xcode logs. Error updating background task request: Error Domain=BGSystemTaskSchedulerErrorDomain Code=3 "(null)" My attempt I can enable Background processing (under Signing & Capabilities > Background modes), but I don't know the BGTaskSchedulerPermittedIdentifiers to add in the Info.plist Questions How can I resolve this? If I should enable background processing, what are the BGTaskSchedulerPermittedIdentifiers to add in Info.plist?
19
0
2.4k
1w
Widget color looks dull / washed out
Hi, Problem I have a widget which displays a bright red. When I display the same view inside the app, the red is bright. However when I use the same view on the widget, the color looks a bit dull. Note: Widget Style: Default (Always) It is the same dull red when in focus and when not in focus This happens on iOS (device and simulator) and macOS Questions How can I fix it on the widget? Does widget support Display P3 colors? Any help on this would be much appreciated.
0
0
372
1w
PassKit silently rejects every .pkpass from one Team ID — client-side ruled out, DTS silent 5 weeks — how to escalate?
Looking for guidance on how to escalate a PassKit issue that appears to be at the team-account level, after two months of exhausting every client-side variable. SYMPTOM Every .pkpass I sign under team XMJKFS3D66 (Mesh Community AS, Norway) is silently rejected on install with: "Sorry, your Pass cannot be installed to Passbook at this time." The rejection is silent — no user-facing hint at what iOS objects to. WHAT I'VE RULED OUT Reproduced across: 3 separate Pass Type IDs (pass.com.meshcommunity.membership original, .membership after re-issue, brand-new pass.com.meshcommunity.kiosk) 2 independently-issued signing certs on the same identifier 3 iPhone testers on 3 different iOS builds with different Apple IDs Paris Pinkney (WWDR DTS) sent me the standard 6-item team-wide checklist on Aug 5, and I'm verifiably clean on all six: Cert not expired — notBefore 2026-07-08, notAfter 2027-08-07 Cert not revoked — OCSP status "good" from ocsp.apple.com/ocsp03-wwdrg404 WWDR G4 intermediate matches cert issuer OU Program membership active, latest PLA accepted Both Pass Type IDs Active in Portal Team ID XMJKFS3D66 matches everywhere (pass.json.teamIdentifier + cert OU) Also verified: openssl smime -verify -in signature -inform DER -content manifest.json -noverify → "Verification successful" Full chain in signature: Pass Type ID cert → WWDR G4 → Apple Root CA PKCS#7 detached, DER, SHA-256, -noattr CDN serves application/vnd.apple.pkpass THE DEFINITIVE TEST To rule out the last remaining plausible client-side hypothesis (missing primaryFields causing a silent layout rejection, suggested by an independent review), I built a minimal known-good pass: { "formatVersion": 1, "passTypeIdentifier": "pass.com.meshcommunity.kiosk", "teamIdentifier": "XMJKFS3D66", "organizationName": "Mesh Community", "serialNumber": "10001", "description": "Mesh Kiosk Pass", "logoText": "Mesh Community", "foregroundColor": "rgb(255, 255, 255)", "backgroundColor": "rgb(25, 25, 25)", "barcodes": [ { "format": "PKBarcodeFormatQR", "message": "10001", "messageEncoding": "iso-8859-1" } ], "generic": { "primaryFields": [ { "key": "name", "label": "MEMBER", "value": "Test User" } ] } } ASCII-only, no emoji, no hyphenated serial, includes primaryFields, minimal fields Same signing recipe, same G4 chain, verify clean Same 6 standard PNG assets (icon + logo, 1x/2x/3x) Result on a fresh iPhone: identical silent rejection. Same "Sorry, your Pass cannot be installed to Passbook at this time." dialog. At this point every plausible client-side variable has been isolated and eliminated. The block appears to be at team level inside Apple's PassKit backend — invisible from the Developer Portal. WHAT APPLE HAS DONE SO FAR DTS Case-ID: 21008005 — opened 2026-07-13, reproducer.zip attached same day Assigned engineer: Paris Pinkney (WWDR, DTS) since 2026-08-05 Sysdiagnose: filed via Feedback Assistant as FB24516356 on 2026-08-26 (device Serial HWT3HQ2F9F, SEID captured, iOS 23G71, reproduction timestamp 2026-08-13 11:02:15 +0200) with Wallet debug profile installed on the device before reproduction Radio silence since 2026-08-17 — 5 weeks and counting, including no reply to a polite check-in on 2026-09-08 WHAT I'M ASKING Anyone at Apple engineering seeing this: is there a way to accelerate the Case-ID 21008005 / FB24516356 log review? The PassbookUIService / PassKit / PassKitCore entries around the timestamp above would settle this in minutes on your end. Any developer who's hit team-wide PassKit rejection before: what unblocked it? Was it a PLA re-acceptance, a Developer Program Support ticket (separate from DTS), a re-provisioning request, something else? Any way to inspect a team's backend PassKit entitlement state from outside (a Portal page, an endpoint, an xcrun command), so I can either confirm my suspicion or eliminate it myself? Any known-good published .pkpass from a Norwegian-registered (C=NO) Developer Team I can diff against, just to eliminate country-registration as a factor? Working Apple Wallet is a launch-blocker for the Mesh Community Workbar Kiosk rollout — we're currently shipping Google Wallet + QR-in-email as a full fallback and it works everywhere including iPhone, so no user is being turned away. But we'd like to close the Apple Wallet loop, and after 2 months I've run out of things to try from my side. Any pointer welcome. Happy to share the full evidence bundle privately with anyone at Apple who can help. Thanks, Mesh Community AS · Team ID: XMJKFS3D66
1
0
274
1w
-paymentQueue:updatedTransactions: called continuously every time app is in foreground
-(void)paymentQueue:(SKPaymentQueue*)queue updatedTransactions:(NSArray<SKPaymentTransaction*>*)transactions In the sandbox environment this is called continuously every time my enters the foreground. I call -finishTransaction on approximately 22 transactions. Confirmed by: NSUInteger finishCount = 0; NSUInteger transactionCount = transactions.count; for (SKPaymentTransaction *aTransaction in transactions) { // Check state..if purchased or restored.. [[SKPaymentQueue defaultQueue]finishTransaction:aTransaction]; finishCount++; // Post notification telling everyone here! } NSLog(@"Finsihed %lu of %lu",finishCount,transactionCount); The log at the bottom says - finished 22 of 22 transactions. But every time the app enters the foreground the -paymentQueue:updatedTransactions: is called again with another batch of transactions. How Over and over again. Not sure how this is possible but the transactions seem to never clear from the queue. I hope this may be limited to the sandboxed environment. In this loop after finish transaction is called I then post a notification which kicks off receipt validation...and then I even store something in the keychain. Doing this work over and over again in a tight loop is very unexpected and causes my app to lock up. Yea I know this is deprecated. Will move to my Objective-C storekit 2 wrapper but breaking SK1 on purpose seems kind of um, rude. Hope this is only in the sandbox environment. This app got sidelined even though I got some plans to resurrect it in the back of my head.
0
0
220
1w
Product.products(for:) returns empty for live subs since 2026-09-01
Live App Store app. Since 2026-09-01 PDT, StoreKit no longer returns our approved auto-renewable subscriptions on signed builds. The same SKUs load normally in Xcode when using a local StoreKit configuration file. New purchases are blocked. Monthly auto-renewals that were collecting normally through August 31 began failing their renewal attempts starting September 1, with all observed attempts entering Billing Grace / Billing Retry. App Name: Moonlit Bundle ID: moonlit.reading Versions affected: 1.1.1 — App Store version that was already live and working normally before September 1 1.1.2 — subsequently released to the App Store specifically to test whether a fresh production release would restore StoreKit behavior. It did not. Approved auto-renewable subscriptions, both in the same subscription group: moonlit.monthly.subscription moonlit.yearly.subscription Paid Apps Agreement, banking, and tax are Active in App Store Connect. We use an explicit App ID with the In-App Purchase capability enabled. Distribution builds do not contain a StoreKit Configuration file. The local .storekit file is used only for Xcode Run. Through August 31, 2026, Product.products(for:) and SubscriptionStoreView returned both SKUs and their prices correctly on production builds. Beginning September 1, 2026, and continuing through at least September 11: Every production paywall we can measure receives an empty StoreKit catalog with no product IDs, no prices, and no thrown StoreKit error. SubscriptionStoreView remains on its loading state. Our Terms / Privacy footer still renders because it does not depend on StoreKit. showManageSubscriptions / manageSubscriptionsSheet also hangs or fails to connect on the same signed builds. App Store Connect subscription events for the monthly SKU show a complete reversal beginning September 1. All observed renewal attempts in the affected window entered Grace from Paid, with no successful renewals, whereas the comparable August window showed normal successful renewals. Sales reports show no IAP proceeds for the affected September window. App downloads continue to appear normally, so the app itself remains available for sale. What still works Xcode + local StoreKit Configuration: Both products load Prices display The purchase sheet presents normally Analytics and logging continue to function, so this is not an app crash or missing paywall UI. The subscriptions are not Rejected and are not in Developer Action Needed. TN3186 / TN3188 checks have already been completed. This appears similar to other recent reports where App Store Connect contains a valid product catalog but StoreKit does not serve the products to signed builds: https://developer.apple.com/forums/thread/838171 https://developer.apple.com/forums/thread/841722 https://developer.apple.com/forums/thread/838773 https://developer.apple.com/forums/thread/836183 Developer Support case: 102959783559 Request Could an App Store Commerce or StoreKit engineer verify whether the app-to-IAP catalog association for moonlit.reading is populated and being served correctly on Apple’s side, and refresh or reprocess the production catalog if appropriate?
2
0
376
1w
Find My People on macOS 27 cannot show locations shared from iPhone 6, while iOS/iPadOS 26 can
After upgrading to macOS 27.0, I noticed a specific issue in Find My > People. Two people who share their location with me use iPhone 6 devices. Their locations are unavailable in Find My on my Mac running macOS 27.0. The same location-sharing relationships work correctly on my other devices: iPhone running iOS 26: locations are visible iPad running iPadOS 26: locations are visible Mac running macOS 27.0: locations are unavailable Other people using newer iPhones are displayed correctly on the same Mac. This suggests that location sharing itself and my Apple Account are working correctly. The issue appears specific to Find My > People on macOS 27 when receiving location shared from older iPhone/iOS devices. I can reproduce this independently with two different iPhone 6 users. macOS 27.0 is the public release, not a beta. I have submitted this to Apple through Feedback Assistant: FB24761605 Has anyone else seen this specifically with iPhone 6 or devices running older iOS versions after upgrading to macOS 27?
1
1
159
1w
DriverKit USB Transport VendorID request still "Submitted" after 8 weeks
Hello, On July 30, 2026 we submitted a DriverKit USB Transport - VendorID capability request for our iPadOS driver extension. The request ID is 83H9997N3G, team ID W33S637JJQ. Eight weeks later it still shows "Submitted". Developer Support (case 20000135736763) told us a separate team handles these requests and will contact us. We have not heard from that team yet. The driver works with development signing. Without the distribution entitlement we cannot upload a build to TestFlight. Is there anything else we should provide, or a way to find out where the request is in the queue? Thanks, Stepan
1
0
142
1w
CLLocation.altitude under CarPlay reports 0.0 with a positive verticalAccuracy, and a second altitude outlier, both reproducible in Apple's Compass app
Hello, I'm Greg, the developer of EV Dashboard, an app for electric vehicle owners. I'm extending it with features that help drivers understand their efficiency, including elevation and grade along a drive. It works for most of my beta testers, but two behaviors have me stuck, and they raise the same question: both hand my app an altitude that is wrong by hundreds or thousands of meters while reporting a small, positive verticalAccuracy, so I have no field I can test to distinguish a measurement from a value that is not one. Both also reproduce in Apple's Compass app on a tester's phone, with none of my code in the path. A 35-second screen recording he sent me, at the same spot in Eagan, Minnesota, shows Compass reading 889ft (the true elevation, 271m), then 5996ft for about a second, then 889ft again, and then 0ft at the moment the "CarPlay - AirPlay Connected" banner appears. Screenshots attached. Setup in my app: one CLLocationManager per active scene, desiredAccuracy kCLLocationAccuracyBestForNavigation, standard location updates (not significant-change), authorization When In Use or Always depending on the tester. Elevation comes from CLLocation.altitude, with CMAltimeter relative altitude used to carry a known altitude between fixes. Case 1: accessory fixes under CarPlay report altitude 0.0 with a positive verticalAccuracy (FB24778173) On several vehicles, every fix whose sourceInformation.isProducedByAccessory is true arrives with altitude exactly 0.0 and a verticalAccuracy that is positive and constant for the whole session (19.0 on the cars I have traces from). In the same drives, the phone's own fixes read the true altitude, around 1,345m on one tester's route. ellipsoidalAltitude does not distinguish them either: it comes back as the geoid correction applied to the 0 (-16.5 to -17.4), so both fields agree on sea level. This is not fleet-wide, which is what makes it testable. Other vehicles deliver real altitude on accessory fixes, on the same app build, with verticalAccuracy 9.5 and values that agree with the phone within a few meters. So it appears to depend on the head unit, and an app cannot ask iOS for the phone's own fix while CarPlay is connected. The Compass recording above is the same behavior in a first-party app: 889ft before the connection, 0ft after it. Case 2: a fix with an altitude about 1,550m too high The same tester's iPhone has twice delivered fixes with altitude 1823.8 where the true elevation is about 271m, an error of roughly 1,552m, with verticalAccuracy 30.0 and horizontalAccuracy 5. These fixes report no speed and no course. The same value appeared on two separate days five days apart, at the same coordinates, identical to the tenth of a meter in both altitude (1823.8) and ellipsoidalAltitude (1796.4). Both times it was the first fix after a location manager started, with the vehicle at rest. Every other fix at that spot in his logs, 76 of them across a week, reads between 269.2m and 272.6m, most with verticalAccuracy 3.0. Compass showed 5996ft (1,827.6m) at that spot in the recording, within 4m of the value my app receives. Because the value repeats exactly across days, it does not look like a measurement. What I'm asking Are either of these known issues? My reading of the documentation is that a positive verticalAccuracy means the altitude is valid, with that value as one standard deviation. In both cases the error is 50 times the stated accuracy or more. Is there any supported way to recognize an altitude that CoreLocation did not measure? Should an accessory that supplies no altitude produce a negative verticalAccuracy, as an invalid altitude does elsewhere in CoreLocation? Is a fix with no speed and no course a reliable signal that it is not a live GNSS solution, and are cached or non-GNSS positions expected to carry an altitude at all? More generally, is there current guidance for obtaining elevation along a drive that I may have missed, particularly how CLLocation.altitude and CMAltimeter are intended to be combined, and what to expect from accessory-produced fixes under CarPlay? Happy to provide traces, the recording, or sysdiagnose for either case. Thanks, Greg
12
0
294
1w
NSURL appends '..' path component on returned url from URLByDeletingLastPathComponent which seems to contradict the documentation
The documentation for URLByDeletingLastPathComponent states the following: If the receiver’s URL represents the root path, this property contains a copy of the original URL. Otherwise, if the original URL has only one path component, this property contains the empty string. So maybe this is new in Foundation with the Golden Gate or maybe I just noticed this but the documentation above doesn't seem to be true. This will create an infinite loop: NSURL *fileURL = [NSURL fileURLWithPath:@"/Users/MyUsername/Desktop/AFolder" isDirectory:YES]; NSLog(@"%@",fileURL); NSURL *ancestorURL = fileURL.URLByDeletingLastPathComponent; while (ancestorURL != nil) { NSURL *nextAncestor = ancestorURL.URLByDeletingLastPathComponent; NSLog(@"Next: %@",nextAncestor); if ([nextAncestor isEqual:ancestorURL]) { NSLog(@"Hit the root - got a copy of the same url"); break; } else if ([nextAncestor.absoluteString isEqualToString:@""] || [nextAncestor.path isEqualToString:@""]) { NSLog(@"Empty string means we had only 1 path component."); break; } else if (nextAncestor == nil) { NSLog(@"Got nil"); break; } ancestorURL = nextAncestor; } The infinite loop can be avoided by adding the following condition: else if (nextAncestor.pathComponents.count == 1) { // One path component. NSURL *sneakPeak = nextAncestor.URLByDeletingLastPathComponent; NSLog(@"%lu",sneakPeak.pathComponents.count); // Logs 2. break; } When you get to one path component URLByDeletingLastPathComponent appends a .. path component rather than deleting a path component or returning a copy of the receiver or a url with an empty string.. If this sounds like a bug let me know. When I call URLByDeletingLastPathComponent on a url with only one path component I'd like to get nil. I think that would be a cleaner design.
5
0
497
1w
Apple Watch Health data stopped syncing to iPhone — FB24923176
Health and Workout data stopped syncing from my Apple Watch to my iPhone on 21 September while both devices were on the public releases. The Watch continues recording the data and the missing data remains on the Watch. Activity Sharing also continues to work. I’ve since installed the matching iOS/watchOS developer betas in an attempt to resolve the pre-existing issue, but it remains. And now I cannot get assistance via the usual Apple Support route. I’ve submitted a Feedback Assistant report with both iOS and watchOS sysdiagnoses: FB24923176. Multiple users are also reporting this issue here - https://www.reddit.com/r/AppleWatch/comments/1whu0at/apple_watch_workoutshealth_data_stopped_syncing/ Could someone advise whether this can be reviewed by the appropriate HealthKit/watchOS team? I am deliberately avoiding unpairing the Watch because the unsynced data is currently only stored on the Watch. Thanks so much!
0
0
156
1w
Title: Background location deliveries stop after 2-5 minutes on iOS 27 despite guidance-compliant configuration
Title: Background location deliveries stop after 2-5 minutes on iOS 27 despite guidance-compliant configuration iOS 27.0, iPhone 17 Pro Max. Always authorization, Precise on, Low Power off. React Native / expo-location 19.0.8. While recording a GPS trail with the app backgrounded and the screen locked, deliveries stop after roughly 2-5 minutes. The JS runtime stops executing entirely — no logging of any kind during the gap. Deliveries resume only on a significant-location-change event or when the user foregrounds the app. Gaps of 6-7 minutes are typical on a 15-minute drive. Walking does not reproduce it. A stationary phone does not reproduce it. Only driving. Configuration (expo-location calls both startUpdatingLocation and startMonitoringSignificantLocationChanges on the same manager): desiredAccuracy = kCLLocationAccuracyBestForNavigation distanceFilter = kCLDistanceFilterNone pausesLocationUpdatesAutomatically = NO showsBackgroundLocationIndicator = YES allowsBackgroundLocationUpdates = YES activityType = CLActivityTypeOtherNavigation UIBackgroundModes includes "location" (verified at runtime) This matches the settings described as compliant in threads 726945 and 776698 regarding the iOS 16.4 change. Ruled out with logs: the app never stops the session; no app-side filter runs during the gaps; no crash or memory kill (same process before and after); queue length under 20 and handler time ~3 ms. Tested BestForNavigation + 5 m filter, Best + no filter, and BestForNavigation no filter — all three show gaps, the last is best but not cured. Two observations that may matter: immediately after each gap the first fixes have horizontal accuracy of 170-1950 m, consistent with a cold session start rather than a resume. And on one occasion a foreground watcher callback delivered a fix 264 seconds old on resume. Questions: Under what conditions does iOS 27 suspend an app with an active standard location session configured this way? Does calling startMonitoringSignificantLocationChanges alongside startUpdatingLocation affect suspension behaviour? Is CLBackgroundActivitySession or CLLocationUpdate.liveUpdates the supported path for sustained background recording on iOS 17+? Can an app detect that its session has been suspended, so it can report honestly to the user?
7
0
681
1w
CKError 10/2007 "Invalid bundle ID for container" although the container is assigned to the App ID
Every CloudKit request from my app fails with CKError "Permission Failure" (10/2007), server message "Invalid bundle ID for container". Setup: SwiftData / NSPersistentCloudKitContainer, private database, Development environment, explicit container identifier (not the default container). What I verified, following TN3164: The App ID has iCloud with CloudKit enabled and exactly this container assigned. The container is visible in CloudKit Console under the same team. The Xcode-managed provisioning profiles contain the container in both the production and the development container identifier lists. The signed entitlements of the app match: application-identifier, team identifier, container identifiers, environment Development, CloudKit service, get-task-allow. The error occurs on two different devices and in two independent code paths: initializeCloudKitSchema and the normal SwiftData store. It fails while setting up the record zone com.apple.coredata.cloudkit.zone. Per TN3164 this means the association is not synchronized to the CloudKit server. The app is already on the App Store (the current version does not use CloudKit yet) and the next version must keep this container identifier, so switching to a new container is not an option. I have reported this through Feedback Assistant and to Developer Support. I can provide the App ID, container identifier and the failing request IDs privately to anyone from Apple who needs them. Is there anything else I can check on my side, or does this need a manual fix on the CloudKit server?
0
0
94
1w
UWB firmware crash (FatalChipError / FirmwareCrash) immediately after FiRa DL-TDOA ranging starts
Hi all, We are testing an indoor navigation app using Nearby Interaction / FiRa DL-TDOA on iPhone. In this sysdiagnose, the anchor is successfully discovered and ranging starts, but the UWB firmware crashes almost immediately. Device / OS: iPhone: 15 iOS: 27 Key timeline (redacted): text 18:09:22.969 nearbyd #dltdoa-ble-oob,Started BLE OOB scanning for FiRa DL-TDOA service 18:09:22.970 bluetoothd Received 'start active Unspecified scan' request, UUIDs [ 0xFFF3 0xFFF4 ] on 1M PHY 18:09:24.122 nearbyd #ses-loc,Scanned OOB: Mac addr: [0x], uwb session id: [0x], details: 18:09:24.122 nearbyd #ses-loc,_buildOOBConfigFromOOBMessage for anchor mac_address: [0x], payload 18:09:24.508 nearbyd #ses-loc,Selected anchor 0x (round-robin oldest in 2min window) 18:09:24.516 nearbyd Built FiRa localization packet V2: { ... } 18:09:24.516 nearbyd Built clientStartService packet: { ... } 18:09:24.520 nearbyd [RoseScheduler] RangingDidStart 18:09:24.664 nearbyd Error state - FatalChipError. Start error handling. 18:09:24.664 nearbyd #roseprovider,Got RoseState Event: FirmwareCrash 18:09:24.665 nearbyd [RoseServiceProvider] RoseInfrastructureEvent::Error 18:09:24.667 nearbyd #ses-container,#interrupt Interrupt session with reason: 18:09:24.741 nearbyd fwStateChangeReceived: FW is in FirmwareCrashed 18:09:24.742 nearbyd crashReceived 18:09:24.742 nearbyd Firmware logs are disabled 18:09:24.742 nearbyd Crash log saving is disabled 18:09:24.742 nearbyd Core dump saving is disabled 18:09:25.926 nearbyd PRRose: Resetting chip. Previous counter: 18:09:27.681 nearbyd fwStateChangeReceived: FW is in FirmwareRunning 18:09:31.333 nearbyd #roseprovider,Got RoseState Event: Ready UWB versions from the log: text RoseUpdater Version: RoseUpdater-133~26833 host interface version 0x223 (2.35) hardware version 0x6 UWB_AP version 0x8d UWB_DSP version 0x47 modem init version 0x563cfdf1 board ID 0x8 Important: this is not the earlier BLE OOB fragmentation issue. In this log, OOB scanning, OOB parsing, anchor selection, and ranging start all succeed. The failure occurs right after RangingDidStart, with FatalChipError / FirmwareCrash. We also see this secondary error, but it does not seem to be the main cause: text nearbyd SpatialPlaceLookup ticket submission failed. Too many parameters: 1 max allowed: 0 Questions: Has anyone seen FatalChipError / FirmwareCrash immediately after DL-TDOA ranging starts? Could specific FiRa localization packet V2 parameters (channel, preamble, sfd_id, slot/round/block config, static_sts_iv, etc.) trigger this firmware crash? Are there any known iOS / nearbyd / UWB firmware issues or workarounds for this? Any help would be appreciated.
2
0
80
1w
StoreKit External Purchase Link entitlement granted by Support but not appearing in App ID / provisioning profile (Xcode signing blocked)
Hello, We have a critical, release-blocking issue with the StoreKit External Purchase Link entitlement (com.apple.developer.storekit.external-purchase-link) and would appreciate an engineer's help. We submitted a request for the External Purchase Link entitlement earlier this year. After no updates since February, we followed up with Apple Developer Support. Support confirmed the entitlement has already been granted to our account, but advised that Xcode is unable to display/select it and directed us to Feedback Assistant / the Developer Forums. However, the capability still does not appear as enabled on our App ID, and it is not included in our provisioning profiles. Current impact We cannot build or sign the app. Automatic signing fails because the provisioning profile is missing the entitlement, which blocks both development builds and release. What we're seeing Xcode – Signing & Capabilities Automatic signing fails with: Provisioning profile "iOS Team Provisioning Profile: ...." doesn't include the StoreKit External Purchase Link capability. StoreKit External Purchase Link capability needs to be assigned to your team and bundle identifier by Apple in order to be included in a profile. And: Entitlement com.apple.developer.storekit.external-purchase-link requires approval from Apple to include in a profile. Please request access to the associated capability. To continue building for device during request processing, remove entitlement and add upon approval. Provisioning profile detail (Xcode) The managed profile shows: Capabilities: 4 Included, 1 Missing → Missing StoreKit External Purchase Link, and Entitlements: 7 Included, 1 Missing → Missing com.apple.developer.storekit.external-purchase-link. Local entitlement configuration The entitlement is correctly added in our Xcode project, but builds fail due to the missing support in the provisioning profile. Apple Developer Portal – Edit App ID Configuration In the capability list, "StoreKit External Purchase Link" shows "No Requests" and cannot be selected/enabled. (The separate "StoreKit External Purchase" entry shows "No Status".) So the capability is not actually attached to the App ID on the portal, despite Support confirming the grant at the account level. What we've already tried Confirmed the entitlement is present in the app's .entitlements file. "Try Again" / regenerating the automatically managed provisioning profile in Xcode. Verified with Apple Developer Support, who confirmed the grant but could not enable it in Xcode/portal and referred us here. Question / request Since Support confirms the entitlement is granted at the account level but it does not appear as an assignable capability on the App ID or in the provisioning profiles, could an engineer please: Confirm whether the External Purchase Link entitlement is actually associated with our Team and this specific App ID, and Assign/enable the capability so it can be selected on the App ID and included in the provisioning profile? Environment: Xcode version: 27.0 macOS version: 26.6.2 Screenshots of the Xcode signing error, the provisioning profile detail, the local entitlement configuration, and the Developer Portal capability list are attached. Thank you very much for any assistance.
0
0
158
1w
iOS 27: system-wide registered fonts disappear from Settings > General > Fonts after every reboot
Hello, We ship a font provider app that installs fonts system-wide on iOS, delivering the font files through On-Demand Resources. Since iOS 27 shipped, customers have been reporting that their installed fonts vanish from the system font list after every restart. I would like to know whether the restore path for system-wide font registrations changed in iOS 27, and what a font provider app is expected to do after a device reboot. Environment iOS 27.0 and 27.0.0 only. We have no reports on iOS 26 or earlier. iPhone 18 Pro and iPhone 18 Pro Max Fonts delivered through On-Demand Resources and registered for system-wide installation using CoreText Steps to reproduce Activate a font in the app. It appears in Settings > General > Fonts. Reboot the device. Without launching the app, open Settings > General > Fonts. The font is gone. The app still shows the font as active, because it keeps its own activation state. Deactivate and reactivate the font in the app. It comes back. Reboot again. It disappears again. This happens on every reboot. It also happens with a single font activated, and it persists after updating or reinstalling the app. Because the font is missing from the system font list, it is also missing in other apps that use system fonts. What we have ruled out Not low storage. These are new devices with plenty of free space. The documented purge trigger for On-Demand Resources is low storage, which does not explain a result this consistent. Not a crash. Our crash data for the affected app version shows no elevated crash rate on iOS 27 compared to iOS 18. Not specific to one font or one app version. Questions Did the restore path for system-wide font registrations change in iOS 27? Are registrations that reference files inside On-Demand Resources still restored at boot? If a font provider app now has to re-register after a reboot, when and how should it do that? There is no natural launch point, since someone may use the font in another app without opening ours first. Is there a supported way for the app to detect that a font it installed is no longer present in the system font list, so it can repair the registration quietly? Context We deliver several thousand fonts this way, and Apple increased our On-Demand Resources limit for that reason (Case-ID 17273913, December 2025). On-Demand Resources is deprecated as of iOS 27. We have separately confirmed that fonts delivered through Background Assets cannot be registered system-wide: registration fails with CTFontManagerErrorDomain code 306, both from the Background Assets container and after copying the files into the app sandbox, because CoreText requires the file to sit inside the app bundle or On-Demand Resources. We have a separate question open about that migration path, so this post is only about the reboot behavior on iOS 27. Happy to provide a sysdiagnose from an affected device and a sample project. Thank you.
1
0
201
1w
400 error is returned for the request sent to the External Purchase Server API.
Hello. I am having trouble because when I send a request to the External Purchase Server API from my own server, I receive a 400 error, but the response does not specify a reason. ・Sent data (some information is masked with ) marketplaceToken received from the client: eyJhcHBBcHBsZUlkIjo2NzU5MTg2MjcyLCJidW5kbGVJZCI6ImNvbS5IYWJiaXQuQW5hRG9zLlBh**************************************************************************************************************************************************************************************************************************CJ0b2tlblR5cGUiOiJDT1JFX1RFQ0hOT0xPR1kifQ== The content of the Bearer Token used when performing a cancellation operation for this payment transaction: {"iss":"a5******---****-3c08","iat":1790134367,"exp":1790135567,"aud":"appstoreconnect-v1","bid":"com...Pal"} The JWT actually sent: eyJ0eXAiOiJKV1QiLCJhbGciOiJFUzI1NiIsImtpZCI6Ikg5N1dOOTRLNjYifQ.eyJpc3MiOiJhNTU*************************************************************************************************************************N0LXYxIiwiYmlkIjoiY29tL********************************************************************************************************************************************************KVfupOI4wW-gMWjHSq2rppbzezTqqiHl0Q The request body actually sent: {"requestIdentifier":"01a0cc52-b3b4-71d4-99c9-e1df27c6193b","externalPurchaseId":"98******---****-****903174ab","status":"NO_LINE_ITEM"} ・Request endpoint (Production) PUT https://api.storekit.apple.com/externalPurchase/v1/reports ・Request endpoint (Sandbox) PUT https://api.storekit-sandbox.apple.com/externalPurchase/v1/reports ・API response response: ( 'status' => 400, 'content_length' => '0', 'body_size' => 0, 'body_position' => 0, 'body_string' => '', ) Whether the request is sent to the production environment or the sandbox environment, a "400 Bad Request" response is returned with an empty response body, making it impossible to determine the cause of the issue. Could you please point out what the problem might be?
0
0
53
1w
Supported native alphabet navigation for CPListTemplate on iOS 27
We need to retain CarPlay's native A–Z button between the scroll arrows in an audio app. This is core navigation for an album/artist library. We use CPListSection(items:header:sectionIndexTitle:) with single-character labels. The sectionIndexTitle API is still documented and is not deprecated in the Xcode 27 SDK. We need the supported native implementation, not a custom picker. On a parked physical head unit with an iPhone running iOS 27, our app displays populated album rows and section headers but no A–Z. Apple Music displays A–Z on the same head unit. We do not know Apple Music's internal implementation. A standalone, public-API-only reproduction is prepared; its CarPlay scene code is included below. Each tab supplies four A/B/M/Z sections of ten synthetic rows. The variants are initially populated, updated after loading, the full section initializer, and securely archived and decoded sections. No network, authentication or artwork is required. The original app displays functioning native alphabet navigation on the iOS 26.5 CarPlay simulator. The public probe compiles. We cannot run an end-to-end iOS 27 CarPlay simulator session because Device Hub requires a physical device, as confirmed in developer forum thread 834440. Separately, an isolated local diagnostic hosted the native list renderer with CarPlay traits. Both runtimes receive four nonempty index labels and all 40 rows. On iOS 26.5 (23F77), its table data source returns A/B/M/Z. On iOS 27.0 (24A434), the attached UICollectionViewDiffableDataSource returns nil index titles. Both the full initializer and secure archive round-trip preserve titles but produce the same result. This diagnostic is not an end-to-end CarPlay session and does not establish the exact internals on the physical phone. A standard UIKit table supplied with index titles and CarPlay traits still displays the native A–Z button on the same iOS 27 runtime. The control itself still exists; the observed failure is the template-to-index connection. This control experiment is also hosted in a phone window, not a CarPlay session. A standard UIKit collection data source implementing indexTitles(for:) also shows index letters on this runtime; the unmodified template renderer's collection data source returns nil. We have not modified that renderer. Questions: Did iOS 27 move native CPListTemplate alphabet navigation to another API, configuration, or presentation requirement? What is the supported migration? If sectionIndexTitle remains the correct input, is this a known regression in the new list renderer, and what supported correction is available? How should third-party audio apps reproduce Apple Music's native alphabet navigation on iOS 27 without private API or replacing it with a custom control? Please provide a working public-API example or identify the relevant fix/version. Reproduction: use the audio CarPlay entitlement and configure CPTemplateApplicationScene with CarScene as its delegate. This is the scene code from the compiling standalone probe: import CarPlay import UIKit @MainActor func indexedSections() -> [CPListSection] { ["A", "B", "M", "Z"].map { letter in let items = (1...10).map { number in let item = CPListItem(text: "\(letter) Album \(number)", detailText: "Synthetic test entry") item.handler = { _, completion in completion() } return item } return CPListSection(items: items, header: letter, sectionIndexTitle: letter) } } final class CarScene: UIResponder, CPTemplateApplicationSceneDelegate { func templateApplicationScene(_ scene: CPTemplateApplicationScene, didConnect controller: CPInterfaceController) { let ready = CPListTemplate(title: "Ready", sections: indexedSections()) ready.tabTitle = "Ready" ready.tabImage = UIImage(systemName: "list.bullet") let updated = CPListTemplate(title: "Updated", sections: [CPListSection(items: [CPListItem(text: "Loading", detailText: nil)])]) updated.tabTitle = "Updated" updated.tabImage = UIImage(systemName: "arrow.clockwise") let full = CPListTemplate(title: "Full Init", sections: indexedSections().map { CPListSection(items: $0.items, header: $0.header ?? "", headerSubtitle: nil, headerImage: nil, headerButton: nil, sectionIndexTitle: $0.sectionIndexTitle) }) full.tabTitle = "Full Init" full.tabImage = UIImage(systemName: "list.bullet.rectangle") let decoded: CPListTemplate do { let sections = try indexedSections().map { section in let data = try NSKeyedArchiver.archivedData(withRootObject: section, requiringSecureCoding: true) guard let restored = try NSKeyedUnarchiver.unarchivedObject(ofClass: CPListSection.self, from: data) else { throw CocoaError(.coderReadCorrupt) } return restored } decoded = CPListTemplate(title: "Decoded", sections: sections) } catch { decoded = CPListTemplate(title: "Decode failed", sections: [CPListSection(items: [ CPListItem(text: "Section decoding failed", detailText: String(describing: error)) ])]) } decoded.tabTitle = "Decoded" decoded.tabImage = UIImage(systemName: "shippingbox") controller.setRootTemplate(CPTabBarTemplate(templates: [ready, updated, full, decoded]), animated: false) { _, _ in } Task { @MainActor in try? await Task.sleep(for: .seconds(2)) updated.updateSections(indexedSections()) } } }
Replies
0
Boosts
0
Views
111
Activity
1w
Offline Maps for App via MapKit
I’m building an iOS app using MapKit that allows users to create and navigate trails. I need offline map functionality, I was wondering if MapKit supports that. If not I was wondering if MapBox is a viable alternative to MapKit though I would prefer using MapKit. Thanks!
Replies
3
Boosts
3
Views
1.2k
Activity
1w
NSMenuItem.separator() appears as blank space in Finder Sync extension context menu
Hi, I’m developing a macOS Finder Sync extension and noticed that NSMenuItem.separator() does not appear to render as a standard separator line when used inside the menu returned from FIFinderSyncController. In a normal AppKit NSMenu, the separator renders as expected. However, when the same kind of menu is returned from the Finder Sync extension, the separator appears as a blank/full-height empty row rather than a thin dividing line. Example: override func menu(for menuKind: FIMenuKind) -> NSMenu { let menu = NSMenu(title: "") menu.addItem(NSMenuItem( title: "First Action", action: #selector(firstAction(_:)), keyEquivalent: "" )) menu.addItem(NSMenuItem.separator()) menu.addItem(NSMenuItem( title: "Second Action", action: #selector(secondAction(_:)), keyEquivalent: "" )) return menu } Expected result: The separator should render as a normal macOS menu separator line between the two menu items. Actual result: In Finder’s context menu, the separator is displayed as blank vertical space / an empty menu row. I understand that Finder Sync menus are rendered by Finder and may not support every NSMenuItem feature. However, NSMenuItem.separator() is a very standard way to visually group menu commands, so I wanted to ask: Is this a known limitation of Finder Sync extension menus? Is there a supported way to display a real separator line in Finder Sync context menus? Should this be filed as a Feedback Assistant issue against Finder Sync / AppKit? I’m trying to avoid fake separators such as disabled menu items with "────" as the title, since that does not feel native and may not behave well with different fonts, accessibility settings, or appearance modes. Thanks!
Replies
1
Boosts
1
Views
646
Activity
1w
SwiftData with CloudKit Error: Error updating background task request
Hi, Overview I have a SwiftData project which automatically syncs with CloudKit. When I run the app, I see the following error in Xcode logs. Error updating background task request: Error Domain=BGSystemTaskSchedulerErrorDomain Code=3 "(null)" My attempt I can enable Background processing (under Signing & Capabilities > Background modes), but I don't know the BGTaskSchedulerPermittedIdentifiers to add in the Info.plist Questions How can I resolve this? If I should enable background processing, what are the BGTaskSchedulerPermittedIdentifiers to add in Info.plist?
Replies
19
Boosts
0
Views
2.4k
Activity
1w
Widget color looks dull / washed out
Hi, Problem I have a widget which displays a bright red. When I display the same view inside the app, the red is bright. However when I use the same view on the widget, the color looks a bit dull. Note: Widget Style: Default (Always) It is the same dull red when in focus and when not in focus This happens on iOS (device and simulator) and macOS Questions How can I fix it on the widget? Does widget support Display P3 colors? Any help on this would be much appreciated.
Replies
0
Boosts
0
Views
372
Activity
1w
PassKit silently rejects every .pkpass from one Team ID — client-side ruled out, DTS silent 5 weeks — how to escalate?
Looking for guidance on how to escalate a PassKit issue that appears to be at the team-account level, after two months of exhausting every client-side variable. SYMPTOM Every .pkpass I sign under team XMJKFS3D66 (Mesh Community AS, Norway) is silently rejected on install with: "Sorry, your Pass cannot be installed to Passbook at this time." The rejection is silent — no user-facing hint at what iOS objects to. WHAT I'VE RULED OUT Reproduced across: 3 separate Pass Type IDs (pass.com.meshcommunity.membership original, .membership after re-issue, brand-new pass.com.meshcommunity.kiosk) 2 independently-issued signing certs on the same identifier 3 iPhone testers on 3 different iOS builds with different Apple IDs Paris Pinkney (WWDR DTS) sent me the standard 6-item team-wide checklist on Aug 5, and I'm verifiably clean on all six: Cert not expired — notBefore 2026-07-08, notAfter 2027-08-07 Cert not revoked — OCSP status "good" from ocsp.apple.com/ocsp03-wwdrg404 WWDR G4 intermediate matches cert issuer OU Program membership active, latest PLA accepted Both Pass Type IDs Active in Portal Team ID XMJKFS3D66 matches everywhere (pass.json.teamIdentifier + cert OU) Also verified: openssl smime -verify -in signature -inform DER -content manifest.json -noverify → "Verification successful" Full chain in signature: Pass Type ID cert → WWDR G4 → Apple Root CA PKCS#7 detached, DER, SHA-256, -noattr CDN serves application/vnd.apple.pkpass THE DEFINITIVE TEST To rule out the last remaining plausible client-side hypothesis (missing primaryFields causing a silent layout rejection, suggested by an independent review), I built a minimal known-good pass: { "formatVersion": 1, "passTypeIdentifier": "pass.com.meshcommunity.kiosk", "teamIdentifier": "XMJKFS3D66", "organizationName": "Mesh Community", "serialNumber": "10001", "description": "Mesh Kiosk Pass", "logoText": "Mesh Community", "foregroundColor": "rgb(255, 255, 255)", "backgroundColor": "rgb(25, 25, 25)", "barcodes": [ { "format": "PKBarcodeFormatQR", "message": "10001", "messageEncoding": "iso-8859-1" } ], "generic": { "primaryFields": [ { "key": "name", "label": "MEMBER", "value": "Test User" } ] } } ASCII-only, no emoji, no hyphenated serial, includes primaryFields, minimal fields Same signing recipe, same G4 chain, verify clean Same 6 standard PNG assets (icon + logo, 1x/2x/3x) Result on a fresh iPhone: identical silent rejection. Same "Sorry, your Pass cannot be installed to Passbook at this time." dialog. At this point every plausible client-side variable has been isolated and eliminated. The block appears to be at team level inside Apple's PassKit backend — invisible from the Developer Portal. WHAT APPLE HAS DONE SO FAR DTS Case-ID: 21008005 — opened 2026-07-13, reproducer.zip attached same day Assigned engineer: Paris Pinkney (WWDR, DTS) since 2026-08-05 Sysdiagnose: filed via Feedback Assistant as FB24516356 on 2026-08-26 (device Serial HWT3HQ2F9F, SEID captured, iOS 23G71, reproduction timestamp 2026-08-13 11:02:15 +0200) with Wallet debug profile installed on the device before reproduction Radio silence since 2026-08-17 — 5 weeks and counting, including no reply to a polite check-in on 2026-09-08 WHAT I'M ASKING Anyone at Apple engineering seeing this: is there a way to accelerate the Case-ID 21008005 / FB24516356 log review? The PassbookUIService / PassKit / PassKitCore entries around the timestamp above would settle this in minutes on your end. Any developer who's hit team-wide PassKit rejection before: what unblocked it? Was it a PLA re-acceptance, a Developer Program Support ticket (separate from DTS), a re-provisioning request, something else? Any way to inspect a team's backend PassKit entitlement state from outside (a Portal page, an endpoint, an xcrun command), so I can either confirm my suspicion or eliminate it myself? Any known-good published .pkpass from a Norwegian-registered (C=NO) Developer Team I can diff against, just to eliminate country-registration as a factor? Working Apple Wallet is a launch-blocker for the Mesh Community Workbar Kiosk rollout — we're currently shipping Google Wallet + QR-in-email as a full fallback and it works everywhere including iPhone, so no user is being turned away. But we'd like to close the Apple Wallet loop, and after 2 months I've run out of things to try from my side. Any pointer welcome. Happy to share the full evidence bundle privately with anyone at Apple who can help. Thanks, Mesh Community AS · Team ID: XMJKFS3D66
Replies
1
Boosts
0
Views
274
Activity
1w
-paymentQueue:updatedTransactions: called continuously every time app is in foreground
-(void)paymentQueue:(SKPaymentQueue*)queue updatedTransactions:(NSArray<SKPaymentTransaction*>*)transactions In the sandbox environment this is called continuously every time my enters the foreground. I call -finishTransaction on approximately 22 transactions. Confirmed by: NSUInteger finishCount = 0; NSUInteger transactionCount = transactions.count; for (SKPaymentTransaction *aTransaction in transactions) { // Check state..if purchased or restored.. [[SKPaymentQueue defaultQueue]finishTransaction:aTransaction]; finishCount++; // Post notification telling everyone here! } NSLog(@"Finsihed %lu of %lu",finishCount,transactionCount); The log at the bottom says - finished 22 of 22 transactions. But every time the app enters the foreground the -paymentQueue:updatedTransactions: is called again with another batch of transactions. How Over and over again. Not sure how this is possible but the transactions seem to never clear from the queue. I hope this may be limited to the sandboxed environment. In this loop after finish transaction is called I then post a notification which kicks off receipt validation...and then I even store something in the keychain. Doing this work over and over again in a tight loop is very unexpected and causes my app to lock up. Yea I know this is deprecated. Will move to my Objective-C storekit 2 wrapper but breaking SK1 on purpose seems kind of um, rude. Hope this is only in the sandbox environment. This app got sidelined even though I got some plans to resurrect it in the back of my head.
Replies
0
Boosts
0
Views
220
Activity
1w
Product.products(for:) returns empty for live subs since 2026-09-01
Live App Store app. Since 2026-09-01 PDT, StoreKit no longer returns our approved auto-renewable subscriptions on signed builds. The same SKUs load normally in Xcode when using a local StoreKit configuration file. New purchases are blocked. Monthly auto-renewals that were collecting normally through August 31 began failing their renewal attempts starting September 1, with all observed attempts entering Billing Grace / Billing Retry. App Name: Moonlit Bundle ID: moonlit.reading Versions affected: 1.1.1 — App Store version that was already live and working normally before September 1 1.1.2 — subsequently released to the App Store specifically to test whether a fresh production release would restore StoreKit behavior. It did not. Approved auto-renewable subscriptions, both in the same subscription group: moonlit.monthly.subscription moonlit.yearly.subscription Paid Apps Agreement, banking, and tax are Active in App Store Connect. We use an explicit App ID with the In-App Purchase capability enabled. Distribution builds do not contain a StoreKit Configuration file. The local .storekit file is used only for Xcode Run. Through August 31, 2026, Product.products(for:) and SubscriptionStoreView returned both SKUs and their prices correctly on production builds. Beginning September 1, 2026, and continuing through at least September 11: Every production paywall we can measure receives an empty StoreKit catalog with no product IDs, no prices, and no thrown StoreKit error. SubscriptionStoreView remains on its loading state. Our Terms / Privacy footer still renders because it does not depend on StoreKit. showManageSubscriptions / manageSubscriptionsSheet also hangs or fails to connect on the same signed builds. App Store Connect subscription events for the monthly SKU show a complete reversal beginning September 1. All observed renewal attempts in the affected window entered Grace from Paid, with no successful renewals, whereas the comparable August window showed normal successful renewals. Sales reports show no IAP proceeds for the affected September window. App downloads continue to appear normally, so the app itself remains available for sale. What still works Xcode + local StoreKit Configuration: Both products load Prices display The purchase sheet presents normally Analytics and logging continue to function, so this is not an app crash or missing paywall UI. The subscriptions are not Rejected and are not in Developer Action Needed. TN3186 / TN3188 checks have already been completed. This appears similar to other recent reports where App Store Connect contains a valid product catalog but StoreKit does not serve the products to signed builds: https://developer.apple.com/forums/thread/838171 https://developer.apple.com/forums/thread/841722 https://developer.apple.com/forums/thread/838773 https://developer.apple.com/forums/thread/836183 Developer Support case: 102959783559 Request Could an App Store Commerce or StoreKit engineer verify whether the app-to-IAP catalog association for moonlit.reading is populated and being served correctly on Apple’s side, and refresh or reprocess the production catalog if appropriate?
Replies
2
Boosts
0
Views
376
Activity
1w
Find My People on macOS 27 cannot show locations shared from iPhone 6, while iOS/iPadOS 26 can
After upgrading to macOS 27.0, I noticed a specific issue in Find My > People. Two people who share their location with me use iPhone 6 devices. Their locations are unavailable in Find My on my Mac running macOS 27.0. The same location-sharing relationships work correctly on my other devices: iPhone running iOS 26: locations are visible iPad running iPadOS 26: locations are visible Mac running macOS 27.0: locations are unavailable Other people using newer iPhones are displayed correctly on the same Mac. This suggests that location sharing itself and my Apple Account are working correctly. The issue appears specific to Find My > People on macOS 27 when receiving location shared from older iPhone/iOS devices. I can reproduce this independently with two different iPhone 6 users. macOS 27.0 is the public release, not a beta. I have submitted this to Apple through Feedback Assistant: FB24761605 Has anyone else seen this specifically with iPhone 6 or devices running older iOS versions after upgrading to macOS 27?
Replies
1
Boosts
1
Views
159
Activity
1w
Streaming 2K HomeKit
Hi, Does anyone know if Apple has released the SDK to enable 2K streaming in HomeKit for doorbells/cameras? I've not seen anything posted so far, wondered if I've missed it. Thanks
Replies
1
Boosts
0
Views
149
Activity
1w
DriverKit USB Transport VendorID request still "Submitted" after 8 weeks
Hello, On July 30, 2026 we submitted a DriverKit USB Transport - VendorID capability request for our iPadOS driver extension. The request ID is 83H9997N3G, team ID W33S637JJQ. Eight weeks later it still shows "Submitted". Developer Support (case 20000135736763) told us a separate team handles these requests and will contact us. We have not heard from that team yet. The driver works with development signing. Without the distribution entitlement we cannot upload a build to TestFlight. Is there anything else we should provide, or a way to find out where the request is in the queue? Thanks, Stepan
Replies
1
Boosts
0
Views
142
Activity
1w
CLLocation.altitude under CarPlay reports 0.0 with a positive verticalAccuracy, and a second altitude outlier, both reproducible in Apple's Compass app
Hello, I'm Greg, the developer of EV Dashboard, an app for electric vehicle owners. I'm extending it with features that help drivers understand their efficiency, including elevation and grade along a drive. It works for most of my beta testers, but two behaviors have me stuck, and they raise the same question: both hand my app an altitude that is wrong by hundreds or thousands of meters while reporting a small, positive verticalAccuracy, so I have no field I can test to distinguish a measurement from a value that is not one. Both also reproduce in Apple's Compass app on a tester's phone, with none of my code in the path. A 35-second screen recording he sent me, at the same spot in Eagan, Minnesota, shows Compass reading 889ft (the true elevation, 271m), then 5996ft for about a second, then 889ft again, and then 0ft at the moment the "CarPlay - AirPlay Connected" banner appears. Screenshots attached. Setup in my app: one CLLocationManager per active scene, desiredAccuracy kCLLocationAccuracyBestForNavigation, standard location updates (not significant-change), authorization When In Use or Always depending on the tester. Elevation comes from CLLocation.altitude, with CMAltimeter relative altitude used to carry a known altitude between fixes. Case 1: accessory fixes under CarPlay report altitude 0.0 with a positive verticalAccuracy (FB24778173) On several vehicles, every fix whose sourceInformation.isProducedByAccessory is true arrives with altitude exactly 0.0 and a verticalAccuracy that is positive and constant for the whole session (19.0 on the cars I have traces from). In the same drives, the phone's own fixes read the true altitude, around 1,345m on one tester's route. ellipsoidalAltitude does not distinguish them either: it comes back as the geoid correction applied to the 0 (-16.5 to -17.4), so both fields agree on sea level. This is not fleet-wide, which is what makes it testable. Other vehicles deliver real altitude on accessory fixes, on the same app build, with verticalAccuracy 9.5 and values that agree with the phone within a few meters. So it appears to depend on the head unit, and an app cannot ask iOS for the phone's own fix while CarPlay is connected. The Compass recording above is the same behavior in a first-party app: 889ft before the connection, 0ft after it. Case 2: a fix with an altitude about 1,550m too high The same tester's iPhone has twice delivered fixes with altitude 1823.8 where the true elevation is about 271m, an error of roughly 1,552m, with verticalAccuracy 30.0 and horizontalAccuracy 5. These fixes report no speed and no course. The same value appeared on two separate days five days apart, at the same coordinates, identical to the tenth of a meter in both altitude (1823.8) and ellipsoidalAltitude (1796.4). Both times it was the first fix after a location manager started, with the vehicle at rest. Every other fix at that spot in his logs, 76 of them across a week, reads between 269.2m and 272.6m, most with verticalAccuracy 3.0. Compass showed 5996ft (1,827.6m) at that spot in the recording, within 4m of the value my app receives. Because the value repeats exactly across days, it does not look like a measurement. What I'm asking Are either of these known issues? My reading of the documentation is that a positive verticalAccuracy means the altitude is valid, with that value as one standard deviation. In both cases the error is 50 times the stated accuracy or more. Is there any supported way to recognize an altitude that CoreLocation did not measure? Should an accessory that supplies no altitude produce a negative verticalAccuracy, as an invalid altitude does elsewhere in CoreLocation? Is a fix with no speed and no course a reliable signal that it is not a live GNSS solution, and are cached or non-GNSS positions expected to carry an altitude at all? More generally, is there current guidance for obtaining elevation along a drive that I may have missed, particularly how CLLocation.altitude and CMAltimeter are intended to be combined, and what to expect from accessory-produced fixes under CarPlay? Happy to provide traces, the recording, or sysdiagnose for either case. Thanks, Greg
Replies
12
Boosts
0
Views
294
Activity
1w
NSURL appends '..' path component on returned url from URLByDeletingLastPathComponent which seems to contradict the documentation
The documentation for URLByDeletingLastPathComponent states the following: If the receiver’s URL represents the root path, this property contains a copy of the original URL. Otherwise, if the original URL has only one path component, this property contains the empty string. So maybe this is new in Foundation with the Golden Gate or maybe I just noticed this but the documentation above doesn't seem to be true. This will create an infinite loop: NSURL *fileURL = [NSURL fileURLWithPath:@"/Users/MyUsername/Desktop/AFolder" isDirectory:YES]; NSLog(@"%@",fileURL); NSURL *ancestorURL = fileURL.URLByDeletingLastPathComponent; while (ancestorURL != nil) { NSURL *nextAncestor = ancestorURL.URLByDeletingLastPathComponent; NSLog(@"Next: %@",nextAncestor); if ([nextAncestor isEqual:ancestorURL]) { NSLog(@"Hit the root - got a copy of the same url"); break; } else if ([nextAncestor.absoluteString isEqualToString:@""] || [nextAncestor.path isEqualToString:@""]) { NSLog(@"Empty string means we had only 1 path component."); break; } else if (nextAncestor == nil) { NSLog(@"Got nil"); break; } ancestorURL = nextAncestor; } The infinite loop can be avoided by adding the following condition: else if (nextAncestor.pathComponents.count == 1) { // One path component. NSURL *sneakPeak = nextAncestor.URLByDeletingLastPathComponent; NSLog(@"%lu",sneakPeak.pathComponents.count); // Logs 2. break; } When you get to one path component URLByDeletingLastPathComponent appends a .. path component rather than deleting a path component or returning a copy of the receiver or a url with an empty string.. If this sounds like a bug let me know. When I call URLByDeletingLastPathComponent on a url with only one path component I'd like to get nil. I think that would be a cleaner design.
Replies
5
Boosts
0
Views
497
Activity
1w
Apple Watch Health data stopped syncing to iPhone — FB24923176
Health and Workout data stopped syncing from my Apple Watch to my iPhone on 21 September while both devices were on the public releases. The Watch continues recording the data and the missing data remains on the Watch. Activity Sharing also continues to work. I’ve since installed the matching iOS/watchOS developer betas in an attempt to resolve the pre-existing issue, but it remains. And now I cannot get assistance via the usual Apple Support route. I’ve submitted a Feedback Assistant report with both iOS and watchOS sysdiagnoses: FB24923176. Multiple users are also reporting this issue here - https://www.reddit.com/r/AppleWatch/comments/1whu0at/apple_watch_workoutshealth_data_stopped_syncing/ Could someone advise whether this can be reviewed by the appropriate HealthKit/watchOS team? I am deliberately avoiding unpairing the Watch because the unsynced data is currently only stored on the Watch. Thanks so much!
Replies
0
Boosts
0
Views
156
Activity
1w
Title: Background location deliveries stop after 2-5 minutes on iOS 27 despite guidance-compliant configuration
Title: Background location deliveries stop after 2-5 minutes on iOS 27 despite guidance-compliant configuration iOS 27.0, iPhone 17 Pro Max. Always authorization, Precise on, Low Power off. React Native / expo-location 19.0.8. While recording a GPS trail with the app backgrounded and the screen locked, deliveries stop after roughly 2-5 minutes. The JS runtime stops executing entirely — no logging of any kind during the gap. Deliveries resume only on a significant-location-change event or when the user foregrounds the app. Gaps of 6-7 minutes are typical on a 15-minute drive. Walking does not reproduce it. A stationary phone does not reproduce it. Only driving. Configuration (expo-location calls both startUpdatingLocation and startMonitoringSignificantLocationChanges on the same manager): desiredAccuracy = kCLLocationAccuracyBestForNavigation distanceFilter = kCLDistanceFilterNone pausesLocationUpdatesAutomatically = NO showsBackgroundLocationIndicator = YES allowsBackgroundLocationUpdates = YES activityType = CLActivityTypeOtherNavigation UIBackgroundModes includes "location" (verified at runtime) This matches the settings described as compliant in threads 726945 and 776698 regarding the iOS 16.4 change. Ruled out with logs: the app never stops the session; no app-side filter runs during the gaps; no crash or memory kill (same process before and after); queue length under 20 and handler time ~3 ms. Tested BestForNavigation + 5 m filter, Best + no filter, and BestForNavigation no filter — all three show gaps, the last is best but not cured. Two observations that may matter: immediately after each gap the first fixes have horizontal accuracy of 170-1950 m, consistent with a cold session start rather than a resume. And on one occasion a foreground watcher callback delivered a fix 264 seconds old on resume. Questions: Under what conditions does iOS 27 suspend an app with an active standard location session configured this way? Does calling startMonitoringSignificantLocationChanges alongside startUpdatingLocation affect suspension behaviour? Is CLBackgroundActivitySession or CLLocationUpdate.liveUpdates the supported path for sustained background recording on iOS 17+? Can an app detect that its session has been suspended, so it can report honestly to the user?
Replies
7
Boosts
0
Views
681
Activity
1w
CKError 10/2007 "Invalid bundle ID for container" although the container is assigned to the App ID
Every CloudKit request from my app fails with CKError "Permission Failure" (10/2007), server message "Invalid bundle ID for container". Setup: SwiftData / NSPersistentCloudKitContainer, private database, Development environment, explicit container identifier (not the default container). What I verified, following TN3164: The App ID has iCloud with CloudKit enabled and exactly this container assigned. The container is visible in CloudKit Console under the same team. The Xcode-managed provisioning profiles contain the container in both the production and the development container identifier lists. The signed entitlements of the app match: application-identifier, team identifier, container identifiers, environment Development, CloudKit service, get-task-allow. The error occurs on two different devices and in two independent code paths: initializeCloudKitSchema and the normal SwiftData store. It fails while setting up the record zone com.apple.coredata.cloudkit.zone. Per TN3164 this means the association is not synchronized to the CloudKit server. The app is already on the App Store (the current version does not use CloudKit yet) and the next version must keep this container identifier, so switching to a new container is not an option. I have reported this through Feedback Assistant and to Developer Support. I can provide the App ID, container identifier and the failing request IDs privately to anyone from Apple who needs them. Is there anything else I can check on my side, or does this need a manual fix on the CloudKit server?
Replies
0
Boosts
0
Views
94
Activity
1w
UWB firmware crash (FatalChipError / FirmwareCrash) immediately after FiRa DL-TDOA ranging starts
Hi all, We are testing an indoor navigation app using Nearby Interaction / FiRa DL-TDOA on iPhone. In this sysdiagnose, the anchor is successfully discovered and ranging starts, but the UWB firmware crashes almost immediately. Device / OS: iPhone: 15 iOS: 27 Key timeline (redacted): text 18:09:22.969 nearbyd #dltdoa-ble-oob,Started BLE OOB scanning for FiRa DL-TDOA service 18:09:22.970 bluetoothd Received 'start active Unspecified scan' request, UUIDs [ 0xFFF3 0xFFF4 ] on 1M PHY 18:09:24.122 nearbyd #ses-loc,Scanned OOB: Mac addr: [0x], uwb session id: [0x], details: 18:09:24.122 nearbyd #ses-loc,_buildOOBConfigFromOOBMessage for anchor mac_address: [0x], payload 18:09:24.508 nearbyd #ses-loc,Selected anchor 0x (round-robin oldest in 2min window) 18:09:24.516 nearbyd Built FiRa localization packet V2: { ... } 18:09:24.516 nearbyd Built clientStartService packet: { ... } 18:09:24.520 nearbyd [RoseScheduler] RangingDidStart 18:09:24.664 nearbyd Error state - FatalChipError. Start error handling. 18:09:24.664 nearbyd #roseprovider,Got RoseState Event: FirmwareCrash 18:09:24.665 nearbyd [RoseServiceProvider] RoseInfrastructureEvent::Error 18:09:24.667 nearbyd #ses-container,#interrupt Interrupt session with reason: 18:09:24.741 nearbyd fwStateChangeReceived: FW is in FirmwareCrashed 18:09:24.742 nearbyd crashReceived 18:09:24.742 nearbyd Firmware logs are disabled 18:09:24.742 nearbyd Crash log saving is disabled 18:09:24.742 nearbyd Core dump saving is disabled 18:09:25.926 nearbyd PRRose: Resetting chip. Previous counter: 18:09:27.681 nearbyd fwStateChangeReceived: FW is in FirmwareRunning 18:09:31.333 nearbyd #roseprovider,Got RoseState Event: Ready UWB versions from the log: text RoseUpdater Version: RoseUpdater-133~26833 host interface version 0x223 (2.35) hardware version 0x6 UWB_AP version 0x8d UWB_DSP version 0x47 modem init version 0x563cfdf1 board ID 0x8 Important: this is not the earlier BLE OOB fragmentation issue. In this log, OOB scanning, OOB parsing, anchor selection, and ranging start all succeed. The failure occurs right after RangingDidStart, with FatalChipError / FirmwareCrash. We also see this secondary error, but it does not seem to be the main cause: text nearbyd SpatialPlaceLookup ticket submission failed. Too many parameters: 1 max allowed: 0 Questions: Has anyone seen FatalChipError / FirmwareCrash immediately after DL-TDOA ranging starts? Could specific FiRa localization packet V2 parameters (channel, preamble, sfd_id, slot/round/block config, static_sts_iv, etc.) trigger this firmware crash? Are there any known iOS / nearbyd / UWB firmware issues or workarounds for this? Any help would be appreciated.
Replies
2
Boosts
0
Views
80
Activity
1w
StoreKit External Purchase Link entitlement granted by Support but not appearing in App ID / provisioning profile (Xcode signing blocked)
Hello, We have a critical, release-blocking issue with the StoreKit External Purchase Link entitlement (com.apple.developer.storekit.external-purchase-link) and would appreciate an engineer's help. We submitted a request for the External Purchase Link entitlement earlier this year. After no updates since February, we followed up with Apple Developer Support. Support confirmed the entitlement has already been granted to our account, but advised that Xcode is unable to display/select it and directed us to Feedback Assistant / the Developer Forums. However, the capability still does not appear as enabled on our App ID, and it is not included in our provisioning profiles. Current impact We cannot build or sign the app. Automatic signing fails because the provisioning profile is missing the entitlement, which blocks both development builds and release. What we're seeing Xcode – Signing & Capabilities Automatic signing fails with: Provisioning profile "iOS Team Provisioning Profile: ...." doesn't include the StoreKit External Purchase Link capability. StoreKit External Purchase Link capability needs to be assigned to your team and bundle identifier by Apple in order to be included in a profile. And: Entitlement com.apple.developer.storekit.external-purchase-link requires approval from Apple to include in a profile. Please request access to the associated capability. To continue building for device during request processing, remove entitlement and add upon approval. Provisioning profile detail (Xcode) The managed profile shows: Capabilities: 4 Included, 1 Missing → Missing StoreKit External Purchase Link, and Entitlements: 7 Included, 1 Missing → Missing com.apple.developer.storekit.external-purchase-link. Local entitlement configuration The entitlement is correctly added in our Xcode project, but builds fail due to the missing support in the provisioning profile. Apple Developer Portal – Edit App ID Configuration In the capability list, "StoreKit External Purchase Link" shows "No Requests" and cannot be selected/enabled. (The separate "StoreKit External Purchase" entry shows "No Status".) So the capability is not actually attached to the App ID on the portal, despite Support confirming the grant at the account level. What we've already tried Confirmed the entitlement is present in the app's .entitlements file. "Try Again" / regenerating the automatically managed provisioning profile in Xcode. Verified with Apple Developer Support, who confirmed the grant but could not enable it in Xcode/portal and referred us here. Question / request Since Support confirms the entitlement is granted at the account level but it does not appear as an assignable capability on the App ID or in the provisioning profiles, could an engineer please: Confirm whether the External Purchase Link entitlement is actually associated with our Team and this specific App ID, and Assign/enable the capability so it can be selected on the App ID and included in the provisioning profile? Environment: Xcode version: 27.0 macOS version: 26.6.2 Screenshots of the Xcode signing error, the provisioning profile detail, the local entitlement configuration, and the Developer Portal capability list are attached. Thank you very much for any assistance.
Replies
0
Boosts
0
Views
158
Activity
1w
iOS 27: system-wide registered fonts disappear from Settings > General > Fonts after every reboot
Hello, We ship a font provider app that installs fonts system-wide on iOS, delivering the font files through On-Demand Resources. Since iOS 27 shipped, customers have been reporting that their installed fonts vanish from the system font list after every restart. I would like to know whether the restore path for system-wide font registrations changed in iOS 27, and what a font provider app is expected to do after a device reboot. Environment iOS 27.0 and 27.0.0 only. We have no reports on iOS 26 or earlier. iPhone 18 Pro and iPhone 18 Pro Max Fonts delivered through On-Demand Resources and registered for system-wide installation using CoreText Steps to reproduce Activate a font in the app. It appears in Settings > General > Fonts. Reboot the device. Without launching the app, open Settings > General > Fonts. The font is gone. The app still shows the font as active, because it keeps its own activation state. Deactivate and reactivate the font in the app. It comes back. Reboot again. It disappears again. This happens on every reboot. It also happens with a single font activated, and it persists after updating or reinstalling the app. Because the font is missing from the system font list, it is also missing in other apps that use system fonts. What we have ruled out Not low storage. These are new devices with plenty of free space. The documented purge trigger for On-Demand Resources is low storage, which does not explain a result this consistent. Not a crash. Our crash data for the affected app version shows no elevated crash rate on iOS 27 compared to iOS 18. Not specific to one font or one app version. Questions Did the restore path for system-wide font registrations change in iOS 27? Are registrations that reference files inside On-Demand Resources still restored at boot? If a font provider app now has to re-register after a reboot, when and how should it do that? There is no natural launch point, since someone may use the font in another app without opening ours first. Is there a supported way for the app to detect that a font it installed is no longer present in the system font list, so it can repair the registration quietly? Context We deliver several thousand fonts this way, and Apple increased our On-Demand Resources limit for that reason (Case-ID 17273913, December 2025). On-Demand Resources is deprecated as of iOS 27. We have separately confirmed that fonts delivered through Background Assets cannot be registered system-wide: registration fails with CTFontManagerErrorDomain code 306, both from the Background Assets container and after copying the files into the app sandbox, because CoreText requires the file to sit inside the app bundle or On-Demand Resources. We have a separate question open about that migration path, so this post is only about the reboot behavior on iOS 27. Happy to provide a sysdiagnose from an affected device and a sample project. Thank you.
Replies
1
Boosts
0
Views
201
Activity
1w
400 error is returned for the request sent to the External Purchase Server API.
Hello. I am having trouble because when I send a request to the External Purchase Server API from my own server, I receive a 400 error, but the response does not specify a reason. ・Sent data (some information is masked with ) marketplaceToken received from the client: eyJhcHBBcHBsZUlkIjo2NzU5MTg2MjcyLCJidW5kbGVJZCI6ImNvbS5IYWJiaXQuQW5hRG9zLlBh**************************************************************************************************************************************************************************************************************************CJ0b2tlblR5cGUiOiJDT1JFX1RFQ0hOT0xPR1kifQ== The content of the Bearer Token used when performing a cancellation operation for this payment transaction: {"iss":"a5******---****-3c08","iat":1790134367,"exp":1790135567,"aud":"appstoreconnect-v1","bid":"com...Pal"} The JWT actually sent: eyJ0eXAiOiJKV1QiLCJhbGciOiJFUzI1NiIsImtpZCI6Ikg5N1dOOTRLNjYifQ.eyJpc3MiOiJhNTU*************************************************************************************************************************N0LXYxIiwiYmlkIjoiY29tL********************************************************************************************************************************************************KVfupOI4wW-gMWjHSq2rppbzezTqqiHl0Q The request body actually sent: {"requestIdentifier":"01a0cc52-b3b4-71d4-99c9-e1df27c6193b","externalPurchaseId":"98******---****-****903174ab","status":"NO_LINE_ITEM"} ・Request endpoint (Production) PUT https://api.storekit.apple.com/externalPurchase/v1/reports ・Request endpoint (Sandbox) PUT https://api.storekit-sandbox.apple.com/externalPurchase/v1/reports ・API response response: ( 'status' => 400, 'content_length' => '0', 'body_size' => 0, 'body_position' => 0, 'body_string' => '', ) Whether the request is sent to the production environment or the sandbox environment, a "400 Bad Request" response is returned with an empty response body, making it impossible to determine the cause of the issue. Could you please point out what the problem might be?
Replies
0
Boosts
0
Views
53
Activity
1w