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?

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

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

The Problem When a user toggles radio buttons or checkboxes in a PDF using Preview, the widgets disappear following subsequent interactions after the file is saved and reopened. This renders the form fields unusable. Steps to Reproduce the Problem Open a PDF with radio buttons or checkboxes in Preview. Toggle a radio button or checkbox. Save and close the file. Re-open the PDF in Preview. Toggle the same button again. The button (and any others with the same field name) will disappear. Expected Results Toggling a radio button or checkbox should update the field value without causing the button (or related buttons) to disappear. This behavior is consistent with previous versions of PDFKit. What is Happening In Preview, interacting with radio buttons and checkboxes correctly updates their appearance as expected. Saving the PDF, however, causes the appearance dictionary to reference a new N entry that is a single appearance stream unassociated with any state. The annotation's AS entry is not updated. The original N entry remains but is no longer referenced. Subsequent interactions fail to update the visual presentation because the appearance stream is missing. Impact on User Experience Radio buttons and checkboxes may disappear and become unusable when toggled. PDF documents become irreparably altered after a button is toggled and the file is saved. PDF file size significantly increases when the file is saved. Users may believe they have successfully completed a form, only for the data to become inaccessible or invisible to recipients. Forms may need to be completely restarted or recreated from scratch if the original becomes unusable. The corrupted PDF structure might cause the file to render incorrectly or crash in third-party PDF viewers. Affected Apps/OSs Tested with Preview 11.0 (1147), as well as other apps that use PDFKit, on macOS Golden Gate 27.0 (26A428). This problem also affects PDFKit on iOS 27.0 and iPadOS 27.0. Feedback/bug report: FB24866826 Related Sample Output Original PDF File Checkbox widget annotation (6 0 obj), its appearance dictionary (17 0 obj), and normal appearance dictionary (18 0 obj). Button is not checked. 6 0 obj << /Border [ 0 0 0 ] /Rect [ 90 390 110 410 ] /T (button1) /F 4 /Subtype /Widget /DA (/.AppleSystemUIFont 13 Tf 0 g) /MK 16 0 R /C [ 0 ] /AP 17 0 R /V /Off /M (D:20260919225320Z00'00') /AS /Off /FT /Btn /Type /Annot /Ff 0 >> endobj 17 0 obj << /N 18 0 R >> endobj 18 0 obj << /Yes 20 0 R /Off 22 0 R >> endobj PDF File after Save Checkbox widget annotation object (6 0 obj), its new appearance dictionary object (8 0 obj), a new normal appearance stream object (20 0 obj), and the original appearance stream dictionary (now 21 0 obj). File saved after user checked button. 6 0 obj << /Ff 0 /Type /Annot /AS /Off /AP 8 0 R /MK 9 0 R /C [ 0 ] /FT /Btn /M (D:20260919225320Z00'00') /DA (/.AppleSystemUIFont 13 Tf 0 g) /Subtype /Widget /F 4 /Border [ 0 0 0 ] /Rect [ 90 390 110 410 ] /T (button1) /V (Yes) >> endobj 8 0 obj << /N 20 0 R >> endobj 20 0 obj << /Filter /FlateDecode /Resources << /ColorSpace << /CS1 [ /ICCBased 29 0 R ] /CS2 [ /ICCBased 30 0 R ] >> >> /BBox [ 0 0 20 20 ] /Type /XObject /Subtype /Form /Length 123 >> stream x UéA ¬0 Ô}≈|†≈nà¢úÛÇ* —SA =}Ïr(»ñµ≤w◊€YËà’|ÙÎŒç'óRï∂#SäÏÌü∞¢S‰Ì§ôRÌX }–É•åY Éçˆ BŒ H " *â´8™ˆZø6z⁄ÿ ”ú6ɀ੠"∫t˘‹;'¬ endstream endobj 21 0 obj << /Off 22 0 R /Yes 23 0 R >> endobj Note: No object references 21 0 obj in the PDF.

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

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.

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!

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?

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?

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.

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.

I am designing a bounded local diagnostic helper for macOS. It would run only purpose-built helpers supplied by the application, not third-party or untrusted code. The design question is how to stop exactly those helpers and their descendants on timeout, without affecting an unrelated process or incorrectly reporting that cleanup is complete. This is a public-API suitability question, not a report of a reproduced macOS bug. The intended diagnostic is not an antivirus or endpoint-detection product. The required properties are: Identify each owned process by its lifetime and association with this helper run, not a numeric PID or process-group ID alone. Account for descendants across fork/exec, parent exit or reparenting, and process-group/session changes. Observing that a descendant escaped is not equivalent to preventing an escape. Terminate only the still-owned processes without a stale-identity race between checking ownership and signaling. Report completion only when all owned descendants have stopped and no new owned descendants can appear. Leader exit, IPC disconnection, or an unauthenticated empty process list would not be sufficient. Lost events or uncertain membership must leave the outcome inconclusive. Which supported public API or service/containment architecture can provide these properties? If they cannot all be guaranteed, which constraint should be changed and what guarantee can the supported alternative actually provide? I have reviewed the documentation for es_new_descendants_client and es_sync_client. The remaining questions are: Is a descendant-scoped Endpoint Security client appropriate for this non-security-product diagnostic? If so, which documented entitlement and packaging route applies? I am asking about eligibility, not assuming it. Does any supported design combine lifetime-safe control with containment of the whole owned subtree, including concurrent descendant creation? Merely receiving events would not establish that property. What additional protocol, if any, makes a synchronization callback sufficient to establish complete termination when client destruction, event loss, and concurrent activity are possible? I am not treating that callback alone as proof that no owned process remains. I can redesign around a helper that cannot create descendants if that is the supported approach. In that case, what supported mechanism enforces that restriction and what termination guarantees remain? So far, a standalone C harness has passed eleven fabricated-input cases with assertions enabled. It exercised no Endpoint Security client, process-tree creation/enumeration/control, or application behavior. It is not a runtime reproducer for this API-design question and does not establish native lifecycle safety. Pointers to documented guarantees, limitations, or an Apple sample would help me choose the architecture before preparing a narrowly scoped native test. I am not seeking private APIs or a way to disable platform protections. No logs, source archive, or binary is attached.

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.

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?

Hello everyone, I am encountering a persistent date discrepancy between the subscription expiration date returned by the App Store Server API and the date displayed to the user in the native iOS Settings UI. Our app receives the renewal timestamp via the App Store Server Notifications in UTC milliseconds. For a recent transaction, we received renewalDate = 1820988823000, which is September 15, 2027, at 06:13 AM UTC. Following standard practices, our app formats this UTC timestamp to the user's local device timezone. On a device set to India Standard Time (IST, UTC+5:30), the app correctly displays the expiration as September 15. However, on the exact same device, navigating to iOS Settings > Apple ID > Subscriptions shows the expiration date as September 14. Converting 06:13 AM UTC to Pacific Time (PT) results in September 14 at 11:13 PM PDT. This leads me to suspect that the iOS Settings page anchors its display strictly to Cupertino/Pacific Time, completely bypassing the device's local timezone. I noticed another developer raised this exact issue regarding KST back in September 2025 (Thread ID: 800332), but that post remains unanswered. My questions for the community and Apple Engineers: Can anyone officially confirm if the native iOS Settings > Subscriptions screen intentionally displays dates anchored strictly to Pacific Time (PT) rather than the device's local timezone? If so, how are you handling user inquiries when your app correctly displays the local time, but Apple's UI displays the day prior? Any official references or guidance on this behavior would be greatly appreciated to help us clarify this for our QA teams and end-users.

Technology: Service Management (SMAppService), App Sandbox, launchd, Foundation file URLs. This is a documentation/support question based on a standalone signed probe. It is not an assertion of a confirmed Apple defect, and it is not a duplicate of the launchd enhancement FB24726121 referenced in DTS thread 844906. Request Please clarify the supported identity and persistent-storage architecture for this combination of requirements. We need a sandboxed Mac App Store app to install its bundled, sandboxed SMAppService LaunchDaemon through one in-app action and the required native approval. The LAN listener must be unprivileged and remain available after logout and at boot. On macOS 27.2 beta 1 (26B5086k), our signed app-like probe launches and accesses its private container as the default root identity. We have read DTS thread 844906’s single-process privilege-drop guidance; this request concerns the additional sandbox, storage, and distribution limits. Observations • UserName=nobody exits during sandbox initialization with /var/empty home and secinitd UID errors. • An existing non-root account control also traps in libsecinit before main. • SessionCreate=true with that existing non-root account still terminates in libsecinit before main. • Creating a new audit session did not resolve sandbox initialization in this probe. • A retained directory descriptor works with openat after dropping privileges, but ordinary container paths and /dev/fd/directory/child do not. • All diagnostic registrations were removed for these tests; no product data or network listener was involved. Questions Is a sandboxed bootstrap that permanently drops groups, GID, and UID before opening a LAN listener a supported architecture for the Mac App Store distribution lane? How should such a LaunchDaemon obtain an isolated service identity and persistent container with Foundation/MLX-compatible file URLs without an external installer, shared writable storage, manual account/ACL setup, or unsupported sandbox exceptions? Please identify the supported public-API path, and clearly distinguish Service Management support from App Review guideline 2.4.5 constraints. If these requirements cannot be combined, please state which ones are mutually exclusive. Reference: https://developer.apple.com/forums/thread/844906 Expected outcome: documented guidance on a supported arrangement, or a clear statement of which requirements cannot be combined. We are withholding the product’s Release host installation until the identity/storage design is qualified.

we are currently found the vulnerability about Python 3, but it is located under "/usr/bin/python3" does anyone know how to update this? we try to update python app, but it doesn't fix this, since it is under /usr/local/bin....

Description: On iOS 27.0 (24A437) with Apple Intelligence enabled, sharing a Writing Tools result to a share extension fails as soon as the extension shows a keyboard. Steps: Safari (also Chrome, NAVER app): select a paragraph → Writing Tools → Proofread (or Rewrite / Summary). In the result panel tap Share → choose Notes (Apple) or any third-party extension whose sheet focuses a text view. In the extension's sheet, tap the text so the keyboard appears (for SLComposeServiceViewController-based extensions this happens automatically on presentation). Expected: the extension sheet stays open; the user edits and posts. Actual: about 0.3–1.0 s after the keyboard appears, the extension sheet, the share sheet and the Writing Tools panel are all dismissed. Nothing is saved. Apple Notes' own share extension shows the same behaviour when its text is tapped. Impact: no share extension can accept edits from the Writing Tools result panel; developers cannot detect the host or avoid the keyboard when the user wants to type. Device: iPhone 15 Pro (iPhone16,1), iOS 27.0 (24A437)

Hello fellow developers, I’ve been working with the CallKit framework in iOS, specifically handling incoming calls. One issue I’ve encountered is that Siri when "read caller name" is enabled announces the caller name/surname set via localizedCallerName and then reads the generic handle value (usually alphanumeric) too! Has anyone encountered a similar situation or if there’s a solution to prioritize the localizedCallerName over the generic handle value without using CXHandleType.emailAddress? Alternatively, any insights or workarounds you know would be greatly appreciated. TLDR: even when I correctly configure the localizedCallerName property, Siri persists in reading the CXHandleType.generic. The original Implementation with CXHandleType.generic: The issue arises when using CXHandleType.generic for alphanumeric IDs (or even URLs as stated by documentation https://developer.apple.com/documentation/callkit/cxhandle). Despite correctly setting the localizedCallerName, Siri continues to announce the generic handle value. Expected Behavior: Siri should read only the localizedCallerName when set and ignore the generic handle value when announcing incoming calls. Workaround: Currently, the only workaround is to use CXHandleType.emailAddress for alphanumeric IDs. However, this is not ideal since it repurposes an email-related handle type for a different purpose. Steps to Reproduce: Create a CallKit app that handles incoming calls (example app from documentation can be used too). On incoming call create CXCallUpdate object Create a CXHandle with CXHandleType.generic and an alphanumeric value (e.g., “ABC123”). Pass the CXHandle to the CXCallUpdate objects' remoteHandle. Set the localizedCallerName property of the CXCallUpdate object with a custom caller name/surname. Report the call with reportNewIncomingCallWithUUID Observe that Siri reads both the localizedCallerName and the generic handle value during call announcements. While we are here a Feature Request: Developers should be able to provide a user-friendly caller name without resorting to workarounds like using CXHandleType.emailAddress. I kindly request that Apple consider enhancing Siri’s behavior in the following ways: Allow developers to suppress the reading of generic handle values while still using the correct handle type. Introduce additional type options for call announcements that don't read the generic value. Both of the above. Thank you for your help! 🙌

We use ExternalAccessory to talk to a smart card, i.e. a YubiKey 5Ci, over Lightning. On iOS 27.0, most EASession objects we open are unable to receive. NSStreamEventHasBytesAvailable never fires on the input stream and not one byte arrives, yet the session reports no problem anywhere. Environment iPhone 11, iOS 27.0 build 24A437 (public release), YubiKey 5Ci on Lightning, protocol com.yubico.ylp. What we see on an affected session both streams streamStatus 2 (NSStreamStatusOpen) streamError on both nil NSStreamEventOpenCompleted fires on both hasSpaceAvailable before write YES write:maxLength: returns 18 of 18 NSStreamEventHasSpaceAvailable fires NSStreamEventErrorOccurred never NSStreamEventEndEncountered never NSStreamEventHasBytesAvailable never fires inputStream.hasBytesAvailable false on every poll over 10 s Everything reports success. Only the reply is missing. Behaviour A healthy session replies in single digit milliseconds. An affected one returns nothing at all, ever. The condition is set when the session is created and never changes. Opening another session on the same accessory is an independent roll of the dice. Quitting and relaunching the app does not help. Only physically detaching and reattaching the key does, after which connectionID increments and the next session works. 15 of 25 sessions affected on 24A437. Also 9 of 20 on the 24A5430a beta, so it predates the public release. Already ruled out Not a late reply, we waited 10 s. Not a missed event, we polled hasBytesAvailable directly about 200 times per failure. Not a leaked session, teardown is instrumented and every session deallocates exactly once. Not the hardware, another app on the same phone and key reads its serial and firmware every time, and that app opens one session and never closes it. The USB C interface of the same key, via CryptoTokenKit, never fails. Questions Is there any supported way to tell at creation time that an EASession input stream will not deliver data? Nothing we can read distinguishes the two cases. Is repeatedly creating and releasing EASession objects for the same accessory and protocol supported, and is any teardown step needed beyond clearing the delegates, closing the streams, removing them from the run loop and releasing the session? Is there a supported way to recover without asking the user to unplug the accessory?