Hello, I’m currently working on a project that implements Bluetooth Low Energy (BLE) 5 Extended Advertising. We are experiencing an issue specifically on iOS 18.6.2. The device is visible/scannable, but we are unable to establish a connection with it. Initially, our advertising interval was set to 2 seconds. We suspected that this interval might be too long for reliable discovery on iOS, so we reduced it to 100 ms. With the same firmware and advertising configuration: iOS 26.5.2: the device is discovered and a connection can be established successfully. iOS 18.6.2: the device can be detected/scanned, but the connection cannot be established. Could you please clarify whether there are any known limitations, restrictions, or differences in the handling of Bluetooth 5 Extended Advertising between iOS 18.6.2 and newer iOS versions? In particular, we would like to know whether iOS 18.6.2 has any specific requirements regarding: BLE Extended Advertising / LE Extended Advertising Primary and secondary advertising channels Advertising intervals PHY configuration (1M / 2M / Coded PHY) Connectable Extended Advertising We would also appreciate any documentation or known issues related to Extended Advertising on iOS that could explain why the same device and configuration works correctly on iOS 26.5.2. Thank you in advance for your help.

Hello @all I'm develop a DriverKit driver extension and without entitlement checks by OS everything runs fine. But if the entitlements check is enabled in the NVRAM then I get an error due connecting my IOUserClient instance. Which entitlements are really and exactly required for my driver? My driver contains: one IOUserClient instance and multiple IOUserSerial instances The bundle identifier of the driver ist: org.eof.tools.VSPDriver The bundle identifier of the client app org.eof.tools.VSPInstall My entire source code is available on GitHub if any one want to dive deep in :) kernel[0:5107] () [VSPDriver]: NewUserClient called. kernel[0:5107] () [VSPDriver]: CreateUserClient: create VSP user client from Info.plist. kernel[0:5107] () [VSPUserClient]: init called. kernel[0:5107] () [VSPUserClient]: init finished. kernel[0:5107] () [VSPDriver]: CreateUserClient: check VSPUserClient type. kernel[0:5107] () [VSPDriver]: CreateUserClient: success. kernel[0:5107] () [VSPDriver]: NewUserClient finished. kernel[0:5107] () [VSPUserClient]: Start: called. kernel[0:5107] () [VSPUserClient]: User client successfully started. kernel[0:389f] DK: VSPUserClient-0x100001127:UC failed userclient-access check, needed bundle ID org.eof.tools.VSPDriver kernel[0:389f] DK: VSPUserClient-0x100001127:UC entitlements check failed kernel[0:5107] () [VSPUserClient]: Stop called. kernel[0:5107] () [VSPUserClient]: User client successfully removed. kernel[0:5107] () [VSPUserClient]: free called. Here my drivers entitlement file: <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>com.apple.developer.driverkit</key> <true/> <key>com.apple.developer.driverkit.allow-third-party-userclients</key> <true/> <key>com.apple.developer.driverkit.family.serial</key> <true/> </dict> </plist> Here my drivers Info.plist file <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>CFBundleDevelopmentRegion</key> <string>$(DEVELOPMENT_LANGUAGE)</string> <key>CFBundleExecutable</key> <string>$(EXECUTABLE_NAME)</string> <key>CFBundleIdentifier</key> <string>$(PRODUCT_BUNDLE_IDENTIFIER)</string> <key>CFBundleInfoDictionaryVersion</key> <string>6.0</string> <key>CFBundleName</key> <string>$(PRODUCT_NAME)</string> <key>CFBundlePackageType</key> <string>$(PRODUCT_BUNDLE_PACKAGE_TYPE)</string> <key>CFBundleShortVersionString</key> <string>1.0</string> <key>CFBundleVersion</key> <string>1</string> <key>NSHumanReadableCopyright</key> <string>Copyright © 2025 by EoF Software Labs</string> <key>OSBundleUsageDescription</key> <string>Provide virtual serial port</string> <key>com.apple.developer.driverkit</key> <true/> <key>com.apple.developer.driverkit.allow-any-userclient-access</key> <true/> <key>com.apple.developer.driverkit.communicates-with-drivers</key> <true/> <key>com.apple.developer.system-extension.redistributable</key> <true/> <key>OSBundleLibraries</key> <dict> <key>com.apple.iokit.IOSerialFamily</key> <string>1.0</string> </dict> <key>IOKitPersonalities</key> <dict> <key>VSPDriver</key> <dict> <key>CFBundleIdentifier</key> <string>$(PRODUCT_BUNDLE_IDENTIFIER)</string> <key>CFBundleIdentifierKernel</key> <string>com.apple.kpi.iokit</string> <key>IOMatchCategory</key> <string>$(PRODUCT_BUNDLE_IDENTIFIER)</string> <key>IOProviderClass</key> <string>IOUserResources</string> <key>IOResourceMatch</key> <string>IOKit</string> <key>IOProbeScore</key> <integer>0</integer> <key>IOClass</key> <string>IOUserService</string> <key>IOUserClass</key> <string>VSPDriver</string> <key>IOUserServerName</key> <string>$(PRODUCT_BUNDLE_IDENTIFIER)</string> <key>UserClientProperties</key> <dict> <key>IOClass</key> <string>IOUserUserClient</string> <key>IOUserClass</key> <string>VSPUserClient</string> </dict> <key>SerialPortProperties</key> <dict> <key>CFBundleIdentifierKernel</key> <string>com.apple.driver.driverkit.serial</string> <key>IOProviderClass</key> <string>IOSerialStreamSync</string> <key>IOClass</key> <string>IOUserSerial</string> <key>IOUserClass</key> <string>VSPSerialPort</string> <key>HiddenPort</key> <false/> <key>IOTTYBaseName</key> <string>vsp</string> <key>IOTTYSuffix</key> <string>0</string> </dict> </dict> </dict> </dict> </plist> Here the entitlements of the client app <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>com.apple.developer.driverkit</key> <true/> <key>com.apple.developer.driverkit.allow-third-party-userclients</key> <true/> <key>com.apple.developer.driverkit.communicates-with-drivers</key> <true/> <key>com.apple.developer.shared-with-you</key> <true/> <key>com.apple.developer.system-extension.install</key> <true/> <key>com.apple.security.application-groups</key> <array> <string>$(TeamIdentifierPrefix).org.eof.apps</string> </array> </dict> </plist> Here the Info.plist of the client app: <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>CFBundleDevelopmentRegion</key> <string>$(DEVELOPMENT_LANGUAGE)</string> <key>CFBundleExecutable</key> <string>$(EXECUTABLE_NAME)</string> <key>CFBundleIdentifier</key> <string>$(PRODUCT_BUNDLE_IDENTIFIER)</string> <key>CFBundleInfoDictionaryVersion</key> <string>6.0</string> <key>CFBundleName</key> <string>$(PRODUCT_NAME)</string> <key>CFBundlePackageType</key> <string>$(PRODUCT_BUNDLE_PACKAGE_TYPE)</string> <key>CFBundleShortVersionString</key> <string>1.0</string> <key>CFBundleVersion</key> <string>1</string> <key>LSMinimumSystemVersion</key> <string>$(MACOSX_DEPLOYMENT_TARGET)</string> <key>com.apple.developer.driverkit</key> <true/> <key>com.apple.developer.driverkit.install</key> <true/> <key>com.apple.developer.system-extension.install</key> <true/> <key>com.apple.developer.system-extension.uninstall</key> <true/> <key>com.apple.developer.driverkit.userclient-access</key> <array> <string>VSPDriver</string> </array> <key>com.apple.private.driverkit.driver-access</key> <array> <string>VSPDriver</string> </array> <key>com.apple.security.temporary-exception.iokit-user-client-class</key> <array> <string>IOUserUserClient</string> </array> </dict> </plist>

Our SwiftData app (NSPersistentCloudKitContainer under the hood, Production environment, iOS 27.0, private database, default zone com.apple.coredata.cloudkit.zone, no sharing) can no longer export for one user account. On every launch, the first export is a RecordDelete of duplicate records (CD_HealthMetricsSnapshot / CD_DailyLog) that our deduplication removed locally. The CloudKit Console shows it failing with overallStatus: USER_ERROR, error: BAD_REQUEST, returnedRecordTypes: "_pcs_data". On device it surfaces as CKErrorDomain Code=2 "CKInternalErrorDomain: 1011" (partialFailure). After that, NSCloudKitMirroringDelegate reports "Never successfully initialized" and no further export happens in that process. Imports still succeed. It reproduces after deleting and reinstalling the app. On a fresh install, the initial import succeeds, and the very first export, deleting records that were only downloaded and never modified locally, fails the same way. Earlier delete batches from the same deduplication on the same account succeeded, so it seems tied to specific records or the zone's PCS state. Request IDs: E49E4252-99A6-4103-8C03-1D0738005AA3, 4BA5133D-A1F5-423F-BDE6-F65B76B66375, E8D27548-BED1-49A4-9214-3C1A35CDC8C7. Container: iCloud.com.backbonesvc.fastsignal.ios. Questions: What causes a RecordDelete to fail with BAD_REQUEST on _pcs_data? Is there a supported way to clear this without purging the zone? purgeObjectsAndRecordsInZone is documented to also delete local objects, which we must avoid. Can Apple inspect or repair the server-side state for these request IDs?

I've been investigating an issue with the SO_OOBINLINE socket option. When that option is disabled, the expectation is that out-of-band data that is sent on the socket will not be available through the use of read() or recv() calls on that socket. What we have been noticing is that when the socket is bound to a non-loopback address (and the communication is happening over that non-loopback address), then even when SO_OOBINLINE is disabled for the socket, the read()/recv() calls both return the out-of-band data. The issue however isn't reproducible with loopback address, and read()/recv() both correctly exclude the out-of-band data. This issue is only noticed on macos. I have been able to reproduce on macos M1, following version, but the original report which prompted me to look into this was reported on macos x64. My M1 OS version is: sw_vers ProductName: macOS ProductVersion: 14.3.1 BuildVersion: 23D60 Attached is a reproducer (main.c.txt - rename it to main.c after downloading) that I have been able to develop which reproduces this issue on macos. When you compile and run that: ./a.out it binds to a non-loopback address by default and you should see the failure log, resembling: ... ERROR: expected: 1234512345 but received: 12345U12345 To run the same reproducer against loopback address, run it as: ./a.out loopback and that should succeed (i.e. no out-of-band data) with logs resembling: ... SUCCESS: completed successfully, expected: 1234512345, received: 1234512345 Is this a bug in the OS? I would have reported this directly through feedback assistant, but my past few open issues (since more than a year) have not even seen an acknowledgement or a reply, so I decided to check here first. main.c.txt

The Problem On opening a PDF document in the Preview app, PDF widget annotations appear pixelated/rasterized. This problem exists with button, text, and choice widget subtypes. The pixelation becomes more apparent when zoomed in. Expected Results PDF widgets should appear sharp and smooth, without pixelation. In previous versions of the Preview app, widgets appear vector-based as expected. Impact on User Experience PDF widgets appear pixelated and inconsistent with text content in the same PDF document. Widgets do not look like elements of an interactive form but, instead, resemble low-quality embedded images. Affected Apps/OSs: Preview 11.0 (1147), as well as other apps that use PDFKit, on macOS Golden Gate 27.0 (26A428). A similar problem appears to affect PDFKit on iOS 27.0 and iPadOS 27.0 as well. Feedback/bug report: FB24843022

I'm testing an In-App Purchase for the Indonesian storefront. In App Store Connect, the price is configured as Rp 1,299,000, and it is displayed correctly there. However, in the Sandbox purchase sheet, the price is shown as "Rp 1,299 juta" instead. I understand that "juta" means million in Indonesian. However, I'm not sure whether displaying the price as "Rp 1,299 juta" is the expected localization for users. Any confirmation or experience would be appreciated. Thank you!

I mistakenly deleted a subscription in App Store Connect, I know Apple permanently retains that Product ID in its system records to prevent reuse or conflicts but can Apple support purge or restore the deleted record? The app is still in review....

Filed as FB24834050. Still reproducible on watchOS 27.0.1 (24R365). Posting here in case an Apple engineer can help route it, and to see whether other developers are seeing the same behavior through HealthKit. Minimal reproduction (under 3 minutes, no distance involved) Apple Watch Series 10 (GPS) running watchOS 27.0.1 (24R365), paired to an iPhone 15 running iOS 27. Start an Other workout. Move your arms continuously for about 2 minutes (I use air punches). No treadmill, GPS, or distance calculation involved. End the workout and review the heart rate samples. Result: One heart rate sample at approximately 0:05, then no additional samples for the rest of the workout. Expected: Continuous heart rate sampling every few seconds, which is how the same watch behaved on watchOS 26. This reproduces 100% of the time across every workout type I've tried since updating to watchOS 27.0. It did not occur on watchOS 26 using the same watch, same wrist, and same fit. Key diagnostic: the sensor is working, the workout session path is not. The Heart Rate app reads immediately and continues updating every few seconds, even while a workout is running. Background heart rate sampling outside workout sessions works normally. Active energy for my daily 65-minute session is accurate when no workout is started (405 calories on 9/22/26, consistent with watchOS 26). Recording that same session as an Indoor Walk workout results in roughly half the active calories (typically 185-200 versus high-300s/low-400s before the update). Starting a workout appears to suppress a working measurement path and replace it with one that is failing. Downstream impact A 1:06:13 session has been credited as 9, 35, and 55 exercise minutes on different days. Since exercise-minute credit for walking is heart-rate driven, the lack of heart rate samples appears to directly affect exercise credit. Separate issue in the same build (not the subject of this post) Indoor distance is consistently about 50% low. A 1:06:13 walk at a constant 4.1 mph should be 4.52 miles, but the watch reports roughly 2-3 miles even though step counts are correct. The watchOS 27 User Guide describes a redesigned pedometer model using new machine-learning algorithms for treadmill distance. Series 12 and Ultra 4 owners are reporting the same shortfall with matching step counts, including on clean installs, so this does not appear to be hardware-specific. The heart rate dropout reproduces in the Other workout type, which performs no distance calculation, so the two issues appear to be independent regressions. Already ruled out Health details are correct Wrist Detection enabled Power Saving Mode off on both watch and iPhone Heart Rate and Fitness Tracking permissions enabled Motion Calibration & Distance enabled Watch fit and position unchanged Both devices restarted Fitness Calibration Data reset Full unpair/re-pair Multiple workout types tested Pause/resume mid-workout (heart rate briefly shows "Searching" and then drops out again) FB24834050 includes two sysdiagnoses from watchOS 27.0 and currently shows "Recent Similar Reports: More than 10." Status remains Open with no response. Ask Can anyone from Apple confirm whether this is a known/tracked issue? Also, would a sysdiagnose captured using the watchOS logging profile from the Apple bug-reporting site be useful? I'm happy to install the profile, reproduce the issue in under three minutes, and attach fresh logs. I'm also interested in hearing from developers using HKWorkoutSession. Are you seeing the same heart-rate sample gaps on watchOS 27 in your own apps? That would help determine whether this is specific to the Workout app or a regression in the workout session layer underneath it. Thanks!

Hello, I'm developing an iPhone alarm app with AlarmKit. The alert's secondary "Snooze" button uses secondaryButtonBehavior: .custom. Its secondaryIntent is a LiveActivityIntent with supportedModes: .background and authenticationPolicy: .alwaysAllowed. In perform(), the app saves an in-progress record, schedules a new fixed alarm with AlarmManager.shared.schedule(id:configuration:), cancels the original alarm only after scheduling succeeds, and then saves completion. If something fails partway, the original alarm may remain, with or without the newly scheduled one. Simplified configuration (not a standalone sample): let presentation = AlarmPresentation( alert: AlarmPresentation.Alert( title: "Alarm", secondaryButton: AlarmButton( text: "Snooze", textColor: .white, systemImageName: "repeat"), secondaryButtonBehavior: .custom)) let attributes = AlarmAttributes<ExampleMetadata>( presentation: presentation, tintColor: .indigo) let configuration = AlarmManager.AlarmConfiguration( schedule: .fixed(fireDate), attributes: attributes, stopIntent: StopIntent(id: alarmID), secondaryIntent: SnoozeIntent(id: alarmID), sound: .named(soundName)) What we observed We deliberately injected an app-side error inside the intent, using two different test apps on a spare iPad: Observations 1 and 2: a small standalone AlarmKit probe app (iPadOS 26.2.1, default alarm sound). It does not use our app's core logic. Observation 3: a separate validation app that uses our app's core logic (iPadOS 26.7, bundled alarm sound). Each condition was observed only once, so these are not reproducible causal claims. Error before scheduling the new alarm (probe app, device locked): The original alarm kept sounding, and snooze could be tapped again. We recorded several intent entries after the first error, but we can't tell which were user taps and which were system redeliveries. The alarm read as .alerting until the system Stop control was used. Error after the new alarm was scheduled successfully (probe app): The original kept sounding for about 15 seconds until system Stop. The new alarm remained and fired at its scheduled time about three minutes later. Error before scheduling (validation app, device unlocked with the app in the foreground): The alert appeared as a compact banner. After the failed snooze, the app was terminated and relaunched as part of the test procedure, and a test-only control allowed one retry. After that, the banner controls were no longer available, and reads over the next few minutes still reported the original as .alerting. About two hours later, cancelling it with the app's OFF action succeeded. We can't separate the effects of the intent failure, foreground presentation, relaunch, and test-only retry. About hardware buttons: I understand from the AlarmKit FAQ that a physical button stops the currently alerting alarm and that stopIntent is called on dismissal. In observation 3, a volume button was pressed after the banner controls were gone, and audio was no longer heard. Our logs did not capture a stop-intent execution, though that doesn't prove it wasn't invoked. I'm not asking about the general hardware-button behavior. My question is only whether that guidance also applies to an alarm in the state left by a failed custom intent (question 3 below). Questions When a custom secondary LiveActivityIntent.perform() throws, what behavior should an app expect for the original alarm's state and alert presentation? Are there documented limitations or differences between the locked and foreground (banner) presentations? What's the recommended way to report an unsuccessful snooze? Should the intent propagate the error, or catch it and return .result() while tracking the failure in the app? If the original stays .alerting, is invoking the same secondary intent again for the same alarm ID supported, and what concurrency or redelivery assumptions should the app avoid? If an alarm reads as .alerting but has no visible controls or audio after such a failure, which public APIs or user actions are recommended for recovery? Does the FAQ's physical-button and stopIntent guidance still apply in that state? How should an app choose among stop(id:), cancel(id:), or a new schedule without cancelling a valid future alarm? I've read the AlarmKit documentation and the AlarmKit FAQ (https://developer.apple.com/forums/thread/797158), but couldn't find guidance on this failure case. Any advice is appreciated. Thank you!

Under Xcode 27 beta (27A5194q) the built-in CarPlay external screen from iOS simulator can be launched but shows an empty black screen every time on iOS27 device configurations. I have tested many different simulated devices (iPhone 17, 17 pro, 17 pro max) and different screen resolutions. Under iOS26.3 it works as expected. Is this a known issue? Is there any workaround or fix?

The Transferable protocol is Apple’s modern, Swift-native way to allow data to be shared across your app or between different apps. It standardizes how objects are serialized (converted to exportable data) and deserialized (imported back into objects) during operations like drag and drop, copy/paste, and system sharing sheets. Here is a breakdown of how it works and its core concepts: 1. Basic Requirements To make a custom type conform to Transferable, you implement a single static property called transferRepresentation. This property defines the rules for how your data is converted depending on how it is stored or shared. 2. Types of Transfer Representations Depending on your model's underlying structure, Core Transferable provides built-in representation wrappers: CodableRepresentation: Best for custom data models that already conform to Swift’s Codable protocol. It handles JSON/property-list encoding and decoding automatically. DataRepresentation: Best for raw data blobs held in memory (e.g., custom byte buffers or image data). FileRepresentation: Best for large files or assets on disk (e.g., videos, PDFs) so they can be streamed directly from a file path rather than loaded entirely into RAM. You can also use a TransferRepresentationBuilder to chain multiple representations together, declaring fallback formats in order of preference. 3. Proxy Representations If your model object doesn't need its own direct serialization format, you can use a ProxyRepresentation. This converts your custom object into another type that is already transferable (e.g., exporting a complex Document model as a plain String or URL). 4. SwiftUI Integration SwiftUI natively supports Transferable types, simplifying UI interaction features: Drag and Drop: Views can easily act as drag sources using modifiers like draggable(_:) or drop destinations using dropDestination(for:action:). Built-in Support: Common Swift and Apple framework types like String, URL, Data, and Image already conform to Transferable out of the box, making standard sharing seamless.

Hello, I'm doing the in-app purchase tests with a local .storekit file. When I declined a pending transaction on the "Manage Transactions..." form, my code got a record from the Transaction.updates immediately. This transaction was in 'verified' state and the 'revocationDate' was also nil. So my code treated this transaction as approved and went into wrong logic. In the apple online document about the storekit test, it mentioned that "Your app doesn’t receive a transaction because you declined Ask to Buy.". But in my tests, it always sent a 'approved' transaction to me after transaction declined on the "Manage Transactions..." form. Does any know why this happened? Any advice will be appreciated. Thanks in advance. Best, Steven

In one observed Restore Purchases attempt from a Release build distributed through TestFlight on a physical iPhone, try await AppStore.sync() threw an error that our Swift classifier matched to StoreKitError.unknown. Our Restore handler did not reach its subsequent entitlement-enumeration or backend-verification steps. Environment: iPhone 17 Pro Max. The device was independently checked afterward and was running iOS 26.7 (23H24); the OS version was not independently recorded at the exact failure time. Intended handler flow The user explicitly taps Restore Purchases. Call try await AppStore.sync(). Enumerate Transaction.currentEntitlements and accept only verified, eligible transactions for the expected subscription. Send the eligible signed transactions to our backend for verification. Observed attempt Narrow native Console events and a memory-only, sanitized in-app report matched the same attempt. The sync failure was recorded roughly 16 seconds after sync started. We are not treating that duration as evidence of a timeout. The owner reports completing Apple's authentication prompt during this specific attempt. The app displayed: “Purchases could not be restored. Please try again.” Existing Premium access remained displayed before and afterward. We do not count that as successful restoration. We have not retried since this captured attempt. The error matched StoreKitError.unknown. Our sanitized report did not capture an underlying error or numeric error code; this does not establish that no additional diagnostic information exists elsewhere. Current App Store Connect checks show the expected app/subscription-group association, subscription status Ready for Review, all countries or regions selected, and an active Paid Apps Agreement. These status checks do not establish that the configuration is the cause or that every configuration detail is correct. Question What supported, privacy-safe diagnostic should we collect to distinguish causes when AppStore.sync() throws StoreKitError.unknown, without exposing account details, transaction identifiers, receipts, or tokens? If a focused reproducer is needed, is there a recommended way to isolate this TestFlight StoreKit context without weakening transaction verification or changing account/purchase history? We are not asserting an Apple defect or an account/configuration problem. No raw logs or account/transaction data are attached.

I'm using an XPCSession to send a message to a service/agent. When calling session.cancel(reason: "stop") the connection is not immediately canceled. The session seems to wait for any pending replies from the service. According to the docs for XPCSession.cancel: When you cancel a session, it discards any unsent messages and invalidates its connection. If there are messages awaiting replies, the session calls the reply handlers with an appropriate XPCRichError. This does seem to imply that messages waiting for replies are immediately canceled, however that's not the case. The service may be busy and may take a while to respond, or it may not reply at all. The session is only canceled after all enqueued messages get a reply from the service. let session = try XPCSession(xpcService: "com.example.listener", cancellationHandler: { print("client session canceled") }) try session.send("Test", replyHandler: { reply in print("reply", reply) }) print("cancel") session.cancel(reason: "cancel") // calls cancellationHandler *after* receiving reply Is that expected behaviour? If the service does not respond at all the XPCService will never be canceled. Compared to xpc_connection_create + xpc_connection_cancel(connection) this does seem to immediately cancel the connection and call the reply_handler and event_handler. This does not wait for pending replies from the service. Is there an alternative way to force cancel an XPCSession? Main goal is to protect against two potential issues: The service is busy and doesn't respond in time. The client fires a timeout and wants to disconnect/reconnect, but the cancellationHandler is not called until service responds. So the timeout is not useful, client needs to wait for a reply anyway. The service does not respond at all. This could for example happen if a Launch Agent is improperly configured. The mach service is registered, but the agent may not launch. Sending a message on the XPCSession will never receive a reply.

Hello, We are developing a macOS app using Apple-Hosted Managed Background Assets (MBA). Our resources are strictly coupled to specific app binary versions (e.g., App v1.0 is incompatible with Asset Pack v2.0 due to data schema and data format changes). We plan to use Essential asset packs, but also plan to provide an in-app fallback using ensureLocalAvailability during initial launch to handle cases where background downloads fail or are delayed. We have questions regarding the version-resolution behavior and Apple's recommended architecture for version-coupled assets. Scenario A user installs App v1.0 (which targets Asset v1.0). The initial Essential download fails (e.g., network disconnect). The user opens the app without local assets. Later, Asset v2.0 is released to the App Store alongside App v2.0. The user on App v1.0 launches the app and calls ensureLocalAvailability. Questions [1] Version Resolution & Fallback Behavior When an app has no local asset pack installed and calls: try await AssetPackManager.shared.ensureLocalAvailability( of: appResources01, requireLatestVersion: false // or the legacy ensureLocalAvailability(of:) ) Does the system always fetch the latest live version in the App Store (v2.0), or is there any mechanism to retrieve the historical version compatible with App v1.0? Is it possible for an app to explicitly request a specific Asset Pack version rather than the currently active App Store version? [2] Scope of shouldDownload(_:) Does ManagedDownloaderExtension.shouldDownload(_:) get invoked during an explicit in-app call to ensureLocalAvailability? Or is shouldDownload(_:) exclusively called for system-initiated background download cycles? [3] Recommended Architecture for Version-Coupled Resources If an application cannot maintain backward compatibility within a single continuously versioned Asset Pack (v1 → v2 → v3), what is Apple's recommended design pattern? Option A (Separate Identifiers): Define distinct Asset Pack identifiers for each incompatible app generation (e.g., AppResources-v1, AppResources-v2)? Option B (Forced App Update): Use a single Asset Pack identifier and require older app versions to prompt a forced app update via the Mac App Store if assets are missing and incompatible? Option C: Is there another recommended mechanism within Background Assets for managing strict asset-binary version coupling? Thank you for your guidance!

I’m looking for clarification on how Apple retrieves the apple-app-site-association (AASA) file for Universal Links / Associated Domains. Assume a domain exposes the AASA file at: https://example.com/.well-known/apple-app-site-association The domain is protected by Geo-Blocking, where access from certain countries/regions is restricted. I would like to understand the expected network behavior for AASA retrieval: Can requests to retrieve the AASA file originate from Apple infrastructure in different countries or regions globally? Does Apple publish a list of source countries, IP addresses, IP ranges, or network ranges specifically used for AASA retrieval? Can the source country or IP address change over time due to Apple's infrastructure, CDN, or routing? Is there any supported way to force AASA retrieval through a particular region, such as the US? If certain countries are blocked, is there any way to determine whether Apple may use infrastructure from those countries for AASA retrieval? Is the recommended approach to allow the following endpoint to be publicly reachable regardless of source geography? The objective is to restrict access as much as possible while ensuring that Universal Links continue to work reliably. If there is any official Apple documentation covering the source network, IP ranges, geographic locations, or accessibility requirements for AASA retrieval, a reference would be greatly appreciated.

I am evaluating a disposable Linux VM for bounded local test execution on an Apple Silicon Mac running macOS 15.7.9. Before integrating it, I need to establish the supported VM lifetime and termination-observation contract when its native owner fails. The synthetic configuration is intentionally small: VZLinuxBootLoader, two vCPUs, 512 MiB RAM, one serial port, and no storage, network, shared directories or socket devices. The native owner creates the VZVirtualMachine and invokes the forced stop(completionHandler:) API on its designated queue. With that owner alive and responsive, our recorded checks obtain a successful stop completion and the stopped state on the original VM object. We have also checked controller/watchdog/collector loss and a fixed, recoverable owner-queue delay. Those checks do not cover actual native-owner death or a permanent stall. The intended failure behavior is to reject all candidate output and block further attempts whenever termination is unconfirmed. We also need a supported way to end the original VM's execution; simply retaining a blocked record is not a termination mechanism. Could you clarify these points for macOS 15.7.9, including any minimum-version differences? If the process that created a VZVirtualMachine crashes or is forcibly terminated, what public contract covers cessation of every associated vCPU and any out-of-process VM/device execution? Is teardown guaranteed, and what can another trusted process observe to confirm completion for that exact VM? If that owner remains alive but is permanently suspended, deadlocked or cannot service its VZ queue, is there a supported external operation to stop that exact VM and receive an authoritative completion result? What privileges or entitlements are required? Would hosting the owner in an XPC service provide a supported VM-level lifetime guarantee when the initiating app exits? How would a surviving or later controller establish the same VM's terminal state? I understand that service termination by itself may be a different observation from VM teardown. If Virtualization.framework cannot provide this contract, does direct Hypervisor.framework document abrupt host-task teardown of every associated vCPU/VM and a supported external completion observation? Process/thread resource mapping alone leaves that question unresolved for this design. For context, the Apple DTS answer at https://developer.apple.com/forums/thread/845944 distinguishes XPC service lifetime from LaunchAgent lifetime and explains the absence of a launchd wall-clock limit. I am asking specifically about the VM lifetime and observable completion condition, rather than adding another application timer. We do not treat PID disappearance, successful signal delivery, guest silence, journal EOF, or the initial stopped state of a new VM object as proof that the original VM has ended. We have not run a real owner-kill experiment while the recovery and observation contract is unresolved. A reference to the supported API/OS guarantee, or confirmation that this combination is not supported, would help us choose the architecture. This is a contract question, not a report of a demonstrated Apple VM teardown bug.

Hello, We received a customer report about intermittent missing historical step-count data when using HKStatisticsCollectionQuery on iOS 27 beta. When the query was executed on August 16, only the most recent two days—August 16 and August 15—returned correct step counts. Earlier dates returned nil from sumQuantity() and were consequently treated as zero. However, queries executed on August 14 and August 18 returned the expected data. Therefore, the problem appears to be intermittent rather than consistently reproducible. The customer confirmed that all affected historical step counts were visible in the Apple Health app, including the dates returned as zero by our query. We have not received the same type of customer report from devices running iOS 26 or earlier. Here is a simplified version of our query: guard let stepType = HKObjectType.quantityType( forIdentifier: .stepCount ) else { return } var calendar = Calendar(identifier: .gregorian) calendar.timeZone = TimeZone(identifier: "Asia/Seoul")! let queryStartDate = calendar.startOfDay(for: parsedStartDate) let tomorrow = calendar.date(byAdding: .day, value: 1, to: Date())! let queryEndDate = calendar.startOfDay(for: tomorrow) let datePredicate = HKQuery.predicateForSamples( withStart: queryStartDate, end: queryEndDate, options: .strictStartDate ) let nonUserEnteredPredicate = HKQuery.predicateForObjects( withMetadataKey: HKMetadataKeyWasUserEntered, operatorType: .notEqualTo, value: NSNumber(value: true) ) let predicate = NSCompoundPredicate( andPredicateWithSubpredicates: [ datePredicate, nonUserEnteredPredicate ] ) let anchorDate = calendar.startOfDay(for: Date()) var interval = DateComponents() interval.day = 1 let query = HKStatisticsCollectionQuery( quantityType: stepType, quantitySamplePredicate: predicate, options: .cumulativeSum, anchorDate: anchorDate, intervalComponents: interval ) query.initialResultsHandler = { _, results, error in guard let results, error == nil else { print("Query error: \(String(describing: error))") return } results.enumerateStatistics( from: queryStartDate, to: queryEndDate ) { statistics, _ in let steps = statistics .sumQuantity()? .doubleValue(for: .count()) ?? 0 print(statistics.startDate, statistics.endDate, steps) } } healthStore.execute(query) Observed behavior Query executed on August 14: historical step counts returned correctly Query executed on August 16: August 16 and August 15 returned correctly August 14 and earlier returned nil from sumQuantity() Query executed on August 18: historical step counts returned correctly again No query error was reported All step counts remained visible in the customer's Apple Health app Expected behavior The query should consistently return cumulative daily step counts when matching HealthKit samples exist and are visible in the Health app. Because this was reported through customer support, we do not currently know the exact iOS 27 beta build number. We are also unable to reproduce it consistently on our own test devices. Questions Is there a known intermittent issue with historical .stepCount queries on iOS 27 beta? Can HealthKit temporarily return incomplete statistics while data is being indexed, synchronized, or migrated? Is there a recommended way to detect that the returned statistics are temporarily incomplete? Should applications retry the query when older statistics unexpectedly return nil without an error? We have not received reports of this behavior from customers using iOS 26 or earlier. Thank you.

We are seeing inconsistent results from HKStatisticsCollectionQueryDescriptor on iOS 27. Using the same quantity type, statistics options, anchor date, interval components, and predicate configuration, some date ranges return the expected statistics, while other ranges unexpectedly return empty results or buckets with no quantity. The affected ranges do contain HealthKit samples: HKSampleQueryDescriptor finds samples in the same date range. HKStatisticsQueryDescriptor returns the expected value when run separately for an affected bucket. HKStatisticsCollectionQueryDescriptor returns no quantity for that same bucket. Slightly expanding or shifting the date range may cause the collection query to return data again. A simplified version of the query looks like this: let datePredicate = HKQuery.predicateForSamples( withStart: startDate, end: endDate, options: .strictStartDate ) let descriptor = HKStatisticsCollectionQueryDescriptor( predicate: .quantitySample( type: quantityType, predicate: datePredicate ), options: .cumulativeSum, anchorDate: anchorDate, intervalComponents: DateComponents(day: 1) ) let collection = try await descriptor.result(for: healthStore) collection.enumerateStatistics(from: startDate, to: endDate) { statistics, _ in let quantity = statistics.sumQuantity() print(statistics.startDate, quantity as Any) } Expected behavior Every interval containing matching samples should return the corresponding statistics, regardless of the overall requested date range. Actual behavior Some date ranges produce missing or empty buckets even though matching samples exist and an individual HKStatisticsQueryDescriptor can calculate the expected value. Changing only the date range can make the data appear or disappear. The samples are visible to the app in the affected range, so this does not appear to be explained solely by iOS 27’s Limited History authorization. This behavior was not observed with the same query flow on earlier iOS versions. Is this a known regression in HKStatisticsCollectionQueryDescriptor on iOS 27, or has the expected date-range or predicate behavior changed?

Hello, I'm developing an iPhone alarm app with AlarmKit. The alert has a custom secondary button whose intent conforms to LiveActivityIntent, declares supportedModes: .background and authenticationPolicy: .alwaysAllowed, and passes an alarm ID to app code from a @MainActor perform() implementation. The intent lives in the app target. It is not shared with a widget or an App Intents extension. The operation persists an in-progress record, awaits scheduling a new alarm, cancels the original only after scheduling succeeds, and then persists completion. After an interruption or relaunch, recovery reads the persisted original and candidate IDs and checks the system's alarm inventory. I want to understand which execution guarantees the app can rely on, so that recovery never schedules a duplicate alarm or cancels a valid candidate. I've read the LiveActivityIntent and App Intents runtime documentation. I understand how execution placement and foreground/background modes are described, but I couldn't find a public guarantee about overlap or redelivery when the app process is replaced. To be clear, I have not observed two simultaneous processes or duplicate execution in this setup. This is a question about what the app may assume, not a bug report. Questions For this app-target LiveActivityIntent configuration on iOS/iPadOS 26.x, can an older process of the same app still be executing an alarm-button intent while a newly launched process begins another invocation? Is there a documented single-process or handover guarantee an app may rely on? I'd appreciate it if the answer could distinguish multiple concurrent invocations within one process from overlap between an old and a newly launched process. Can the same alarm-button action be redelivered after an interruption or relaunch, including after perform() has thrown or returned? Which serialization or at-most-once guarantees, if any, apply to invocations for the same alarm ID, and which duplicate-delivery defenses must the app provide? I'm not assuming that every invocation comes from a new user tap. If the process that issued an AlarmKit scheduling or cancellation request terminates, may the app assume that the request has either completed or been abandoned before a newly launched process calls AlarmKit? If not, which public API checks or sequencing are recommended before recovery modifies the original or candidate alarm? I'm looking for supported app-level assumptions and recommended safeguards, not internal process lifecycle details. The app must preserve valid alarms and must never report an uncertain result as success. The shipping target is iPhone, with a minimum deployment target of 26.1. Earlier isolated testing on an iPad (9th generation, including iPadOS 26.7) did not show the overlap described above. Related question about the alert presentation after an intent error: [https://developer.apple.com/forums/thread/849075] Thank you!