Hello Apple Developer Support / Community, I would like clarification regarding HealthKit observer behavior when comparing a Flutter-based iOS app with a fully native iOS app. We are using HealthKit background delivery with: HKObserverQuery enableBackgroundDelivery HKAnchoredObjectQuery We have observed that in a Flutter-based app, HKObserverQuery callbacks appear to execute multiple times or more frequently than expected for a single data update. In comparison, a native iOS implementation using similar HealthKit logic appears more stable and predictable. We would like to understand the expected platform behavior and whether there are any known considerations from Apple’s perspective. Specific questions: Does iOS treat HealthKit observer delivery differently for apps built with Flutter versus fully native UIKit / Swift apps? Are there known issues where app lifecycle handling, Flutter engine initialization, method channels, isolates, or plugin architecture could cause repeated observer callbacks? Can repeated HKObserverQuery executions occur if queries are registered multiple times during app launches or engine restarts? Does Apple recommend any specific observer management pattern for cross-platform frameworks such as Flutter? From the HealthKit system side, should observer callback frequency be identical regardless of whether the app is Flutter or native, assuming the same iOS code is used? We are trying to determine whether this behavior is due to HealthKit delivery semantics, duplicate observer registration, Flutter lifecycle integration, or framework-related limitations. Any guidance from Apple or developers who have implemented HealthKit successfully in Flutter would be appreciated. Thank you.

Hello Apple Developer Support / Community, I would like clarification regarding HealthKit data access behavior when an iPhone is locked. We are building an app that uses: HKObserverQuery enableBackgroundDelivery HKAnchoredObjectQuery Background execution to sync HealthKit data to our server Our specific question is: When the device is locked with passcode/Face ID protection enabled, can an app launched in the background through HKObserverQuery or other background mechanisms reliably access and read HealthKit data? We would like to understand the expected Apple-supported behavior for the following scenarios: If new HealthKit samples are written while the phone is locked, will HKObserverQuery still trigger immediately? If the observer callback is invoked while locked, can HKAnchoredObjectQuery successfully read the new samples? Is HealthKit data inaccessible while locked due to Data Protection / encrypted store behavior? Should developers expect delivery or data reads to be deferred until the user unlocks the device? We are trying to set correct expectations for background syncing and would appreciate official clarification on whether near real-time HealthKit sync is possible while the device remains locked. Relevant documentation mentions HealthKit store encryption, but we would appreciate direct confirmation for production behavior. Thank you.

Hello together, the user is able to do recordings with my app. The recordings also runs, while the App is in Background. I have Background Modes Audio & Background enabled. When the user accidentally terminates the App while the recording is still running, the whole recording is lost. I tried AppDelegate applicationWillTerminate on my iOS 26 App and it works perfectly to wrap up the LiveActivity that is shown while the recording is active. But it does not save the Audio and also doesn't update the Widgets (they are interactive and show a different state while recording and stay stuck in recording-state on accidental termination). Any ideas? Best wishes, Dominik

I'm developing an iOS application that relies on peer-to-peer discovery and connection using Bluetooth. The expected behavior is: Two iOS devices with the application installed. Both users marked as "visible". When within Bluetooth range, the devices should discover each other and establish a connection. However, the problem occurs when: The application is in the background (minimized) OR The device is locked (screen off). In these states: The devices can no longer be detected. The search returns no nearby devices. Connection could not be established. ChatGPT: What you want to do probably runs into a structural limitation of iOS — it's not a bug. And iOS: severely limits background BLE scanning. reduces advertising frequency. may even stop completely depending on the state (lock screen). In other words: 👉 iPhone was not designed to function as a "continuous radar" between background apps. Apps that do something similar (like AirDrop or Find My): use Apple's private or privileged APIs or combine BLE + Wi-Fi + Ultra Broadband. i need help : /

I've managed to put together a WebSocket client in Swift using NWProtocolWebSocket (though the documentation does not make it easy.) The point I'm stuck on is how to get a meaningful error if the server rejects the HTTP request, for example with a 404 or 403 status. The error reported to my stateUpdateHandler is a low-level POSIXErrorCode(rawValue: 53): Software caused connection abort). Additionally, how can I add custom headers to the HTTP request, like authorization or cookies? (I'm kind of wondering whether good ol' NSURLSession would have been a better choice -- TN3151 says: "Unless you have a specific reason to use URLSession, use Network framework for new WebSocket code", but at this point I feel that's bad advice.)

I'm working on a MailKit extension and I'm getting a full Mail crash every time I click the Primary Action button in my message banner. I have filed a feedback: FB22513160 Apple's own unsubscribe banner successfully presents a confirmation modal when its primary action is clicked, demonstrating that this flow is intended to work. That behavior does not appear to be accessible to third-party extensions via the documented EMessageSecurityHandler API. Or if it is and I'm missing something, I'd love to know. Thanks!

In the latest 26.5, when creating a VM we can no longer disable SIP. We have confirmed we're using the proper admin user (anka) and its proper password (same one we log into the GUI with). It just keeps asking for the password as if it's wrong. It's critical we can disable SIP for VMs like we have been in previous versions.

Hi Everyone, In libproc, there is a flavour for proc_pidinfo() PROC_PIDUNIQIDENTIFIERINFO, which as the name suggests, returns a struct of values that uniquely identify a process - more reliably than a pid. In particular, it seems to have a 64 bit value that appears to be unique forever (or at least until system restart), thus shouldn't suffer from pid reuse races. The problem is that this interface is gated behind #ifdef PRIVATE, and as such is pretty much the antithesis of 'published api'. So I guess my question is, is there a 'legit' way of accessing this value (or an equivalent) ? The call seems to work fine, and the number appears unique.. thanks, nick

Hi, I am looking for help. I submitted my request for Family Conotrols Distribution using the form. I have been waiting for days and didn't get any reply or confirmation email. Thanks.

I have a custom-developed USB NCM device for a networking use case. My device is successfully enumerated by macOS at the USB layer, and it issues a USB SET_INTERFACE(altsetting = 1) to enable the NCM layer, but sometimes (about 50% of the time), the Mac then issues a USB SET_INTERFACE(altsetting = 0), which disables the interface. It never issues a SET_INTERFACE(altsetting = 1) command to re-enable it. In Network settings, the device just stays in the "Disconnected" state forever. For context, the NCM specification says that all NCM devices must have two "alternate settings" at the USB interface level. Altsetting 0 is the default "disabled" startup state where no data endpoints are enabled, and altsetting 1 is the "enabled" state where data IN/OUT endpoints are enabled and packets can be transferred. The NCM spec also says that SET_INTERFACE(altsetting=0) can be used by the host to 'reset' the NCM layer of the device back to known settings. I suspect this is what the Mac is trying to do, though it only does it 50% of the time. The remainder of the time, the device stays in altsetting 1 and traffic works just fine. My question is, how can I get to the bottom of why the Mac is sometimes sending the SET_INTERFACE(altsetting=0) command or, if this behavior is usual, why is it not then re-enabling using SET_INTERFACE(altsetting=1) ? "log stream --info --debug" shows no information on this, and the NCM driver is a closed-source kernel extension so I have no visibility of what it's doing and why. I've sniffed the USB bus using a packet analyzer and can't see anything odd there (no timing issues or dropped packets etc). Any tips would be appreciated. I'm on Tahoe 26.4.1. I really don't want to develop a custom driver for this device and would prefer to operate with the native NCM driver.

Hello, We are designing an iOS application for a vehicle safety use case. The app connects to a local network device (a DVR installed in the vehicle) and processes image frames to detect passenger-left-behind items, then alerts the driver if needed. We would like to better understand the recommended and App Store-compliant architecture for handling this scenario, especially when the app is not in the foreground. Current Requirements The app communicates with a local network device over Wi-Fi The device can provide image data The app performs or triggers AI inference based on the received data When a relevant event is detected, the app needs to notify the user (e.g., audio alert) Questions Background Execution Model For a near-real-time monitoring scenario, what architectural patterns are recommended on iOS when the app is running in the background? Background Modes Consideration In this type of use case, are any existing background modes (such as location or external accessory) considered appropriate when used strictly within their intended purpose? Enterprise / Managed Deployment Are there any specific entitlements or capabilities available in enterprise or commercial deployments that may allow more persistent local network communication under certain conditions?

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

I’m investigating Core Data lightweight migration behavior with SQLite and ran into a performance issue. Scenario: Model V1: EntityA has one fetchIndex Model V2: EntityA adds a new optional attribute timestamp (Integer 64), with no changes to existing attributes or fetchIndex definitions From a SQLite perspective, this change should be handled by a simple: ALTER TABLE ZENTITYA ADD COLUMN ZTIMESTAMP INTEGER But I observe that Core Data rebuilds the existing index, which becomes a significant performance issue for large databases. CoreData: sql: DROP INDEX IF EXISTS Z_EntityA_id CoreData: sql: ALTER TABLE ZENTITYA ADD COLUMN ZTIMESTAMP INTEGER CoreData: sql: CREATE INDEX IF NOT EXISTS Z_EntityA_byID ON ZENTITYA Question: Is there any way to avoid or bypass index rebuilding for this kind of schema changes?

Our app runs offline-first focus sessions using FamilyControls / ManagedSettings shielding and DeviceActivity monitoring. The in-app session timer is protected against wall-clock manipulation by using monotonic elapsed time, and the shield remains active correctly when the user manually changes the iPhone clock. However, the Live Activity and Dynamic Island countdown appear to use the device's wall clock for their timer rendering. If the user changes the device time from Settings during an active session, the Live Activity / Dynamic Island countdown immediately jumps forward or backwards, even though the underlying session has not changed. Is there a recommended ActivityKit approach for rendering a Live Activity / Dynamic Island countdown that is resistant to manual device clock changes? If not, is this an expected limitation of Live Activity timer rendering? And is there any supported way for the host app or widget extension to detect wall-clock manipulation so the Live Activity can be corrected, dismissed, or replaced with a safer non-countdown state?

Hello, I have submitted multiple requests for the Family Controls Distribution Entitlement through this form: https://developer.apple.com/contact/request/family-controls-distribution After submitting my requests, I waited for about 1 week but did not receive any response. Since I heard nothing, I contacted Apple Developer Support by email. After that, I finally received a response from an advisor asking for additional information, including my follow-up number. I replied with all the requested information immediately, but it has now been 5 more days and I still have not received any further response. In total, I have been waiting for about 2 weeks for this entitlement request. My app is a Screen Time control / digital wellbeing application that helps users reduce screen time through exercise-based challenges and healthy habits. My app uses the FamilyControls, ManagedSettings, and DeviceActivity frameworks and requires the Distribution Entitlement for App Store release. Here are my details: Case Number: 102866460896 Request Type: Family Controls Distribution Entitlement I understand the team may be busy, but I would appreciate any help checking the status of my request or escalating it if possible. Thank you very much.

Looks like the Weather Kit API is not responding. I experience the same with Weather App - API is returning 504 HTTP errors I was wondering if I was alone on this situation In this example: in my app the weather complication is consuming my weather provider which is based on Weather Kit Thank you for your answers. Ilyes

I’m experiencing an issue with subscriptions that behave differently between Xcode builds and TestFlight. Subscriptions work correctly when running the app directly from Xcode in a sandbox environment, but they do not work as expected when testing the same build through TestFlight. Has anyone experienced a similar issue with subscriptions working in Xcode but failing in TestFlight? Any guidance on what to check or debug would be appreciated. Additional details: iOS version: [ IOS 26] StoreKit version: [ StoreKit 2] TestFlight: When attempting to load the subscription products, the app returns “Product not found”. In some cases, it also shows the error “The subscription is unavailable in the current storefront”. This happens consistently in TestFlight, even though the same products load and work correctly when running the app from Xcode in the sandbox environment. Thanks

Hello Apple Developer Forums, We are building an iOS app that needs to receive images and PDFs shared from the system share sheet. The sources include Screenshots, Photos, Files, and third-party apps. The desired user experience is similar to apps such as ChatGPT or Claude: when the user taps our app in the share sheet, the main containing app opens and starts importing or uploading the shared image or PDF. We are trying to understand the supported public API for this behavior. Why opening the containing app is important For our use case, it is important that the containing app opens during the share flow. The import/upload operation depends on the user’s authenticated session. If the Share Extension attempts to upload the file directly, the auth token available to the extension could be missing, expired, or invalid. We would prefer not to make the Share Extension responsible for authentication-dependent behavior such as: validating the user session refreshing tokens handling expired credentials presenting login or re-authentication UI owning upload retry logic tied to auth state In our architecture, authentication and token refresh are owned by the containing app. The Share Extension should ideally only receive the shared file, persist it in an app group container, and hand off to the main app. The main app would then validate auth state, refresh tokens if needed, and perform the import/upload. So the desired flow is: Share Extension receives image/PDF → Share Extension stores file in app group container → Containing app opens → Containing app validates auth/session state → Containing app imports/uploads the file The alternative flow is problematic for us: Share Extension receives image/PDF → Share Extension attempts upload directly → Upload may fail if auth token is expired or unavailable → Share Extension would need auth/session responsibilities We are trying to avoid having an authentication dependency inside the Share Extension implementation. What we have tried CFBundleDocumentTypes We added document type support for: public.image public.png public.jpeg public.heic public.heif com.adobe.pdf This works for some document-open flows, such as opening files from Files or Photos in certain cases. However, it does not make the app appear reliably as a share target from Screenshot Share or from some third-party app share sheets. App Intents We tried using App Intents with IntentFile and: static var openAppWhenRun: Bool = true However, this does not seem to create a general-purpose share-sheet receiver for arbitrary image or PDF NSItemProvider payloads. Share Extension We also implemented a Share Extension that: Receives the shared NSItemProvider. Stores the image or PDF in an app group container. Attempts to open the containing app. However: NSExtensionContext.open(_:completionHandler:) does not appear to foreground the containing app from a Share Extension in the way we need. We also tested responder-chain openURL: trampoline approaches, but those do not work reliably and appear to be unsupported as a public API contract. Questions Is there a supported public API for an iOS app to appear as a share target for arbitrary image/PDF NSItemProvider payloads and then directly open the containing app? If apps such as ChatGPT or Claude appear to switch directly into the main app from the share sheet, is that behavior achievable using public APIs available to third-party developers? If directly opening the containing app is not supported, what is the recommended architecture when the import/upload depends on authenticated app state? Is Apple’s recommended design that the Share Extension itself must perform the full import/upload operation, even when that operation depends on auth validation or token refresh? Is there a supported handoff mechanism where the Share Extension can persist the file in an app group container and then ask the system to open the containing app to continue the flow? Are App Intents intended to support this kind of share-sheet attachment import flow, either currently or in a future iOS version? Reproduction Steps We created a focused sample project to reproduce the issue. Build and run the app on a physical iPhone. Leave the app installed. Capture a screenshot. Tap the screenshot thumbnail. Tap the Share button. Choose the app’s Share Extension from the share sheet. Observe that the Share Extension receives the image payload. Attempt to open the containing app from the extension. Expected Result The Share Extension receives the shared image or PDF, stores it in an app group container, and the containing app foregrounds. The containing app then validates the user’s authenticated session, refreshes tokens if needed, and performs the import/upload. Actual Result The Share Extension receives the image payload and logs the provider type identifiers, but the containing app does not reliably foreground. NSExtensionContext.open does not provide the desired transition, and responder-chain URL-opening workarounds do not appear to be supported or reliable. Minimal Question For image/PDF imports from the iOS share sheet, where upload/import requires authenticated app state, what is the supported implementation? Is it expected to be: Share Extension receives the file → Share Extension performs auth-dependent upload/import itself or is there a supported way to implement: Share Extension receives the file → Share Extension stores the file in app group container → Share Extension opens or hands off to containing app → Main app performs auth validation and upload/import Any guidance on the supported architecture would be appreciated. Thank you.

Here’s a polished Apple Developer Forums post you can use. I removed personal identifiers such as email, Person ID, Team ID, and DTS Case ID because the forums are public. The post is based on your DTS request and Apple’s response directing you to ask in the Developer Forums.  ⸻ Title Supported public API to open containing iOS app from Share Extension for image/PDF share sheet imports Tags iOS Share Extension UIKit App Intents Uniform Type Identifiers Post Body Hello Apple Developer Forums, We are building an iOS app that needs to receive images and PDFs shared from the system share sheet. The sources include Screenshots, Photos, Files, and third-party apps. The desired user experience is similar to apps such as ChatGPT or Claude: when the user taps our app in the share sheet, the main containing app opens and starts importing or uploading the shared image or PDF. We are trying to understand the supported public API for this behavior. What we have tried CFBundleDocumentTypes We added document type support for: public.image public.png public.jpeg public.heic public.heif com.adobe.pdf This works for some document-open flows, such as opening files from Files or Photos in certain cases. However, it does not make the app appear reliably as a share target from Screenshot Share or from some third-party app share sheets. App Intents We tried using App Intents with IntentFile and: static var openAppWhenRun: Bool = true However, this does not seem to create a general-purpose share-sheet receiver for arbitrary image or PDF NSItemProvider payloads. Share Extension We also implemented a Share Extension that: Receives the shared NSItemProvider. Stores the image or PDF in an app group container. Attempts to open the containing app. However: NSExtensionContext.open(_:completionHandler:) does not appear to foreground the containing app from a Share Extension in the way we need. We also tested responder-chain openURL: trampoline approaches, but those do not work reliably and appear to be unsupported as a public API contract. Questions Is there a supported public API for an iOS app to appear as a share target for arbitrary image/PDF NSItemProvider payloads and then directly open the containing app? If apps such as ChatGPT or Claude appear to switch directly into the main app from the share sheet, is that behavior achievable using public APIs available to third-party developers? If directly opening the containing app is not supported, is the recommended design to perform all upload/import work inside the Share Extension itself? Are App Intents intended to support this kind of share-sheet attachment import flow, either currently or in a future iOS version? Reproduction Steps We created a focused sample project to reproduce the issue. Build and run the app on a physical iPhone. Leave the app installed. Capture a screenshot. Tap the screenshot thumbnail. Tap the Share button. Choose the app’s Share Extension from the share sheet. Observe that the Share Extension receives the image payload. Attempt to open the containing app from the extension. Expected Result The containing app should foreground and receive a URL or other handoff signal indicating that a shared file is available for import. Actual Result The Share Extension receives the image payload and logs the provider type identifiers, but the containing app does not reliably foreground. NSExtensionContext.open does not provide the desired transition, and responder-chain URL-opening workarounds do not appear to be supported or reliable. Minimal Question For image/PDF imports from the iOS share sheet, should the supported implementation be: Share Extension receives the file → Share Extension performs the upload/import itself rather than: Share Extension receives the file → Share Extension opens containing app → Main app performs upload/import Any guidance on the supported architecture would be appreciated. Thank you.

Platform: iOS 26 (23E254) Xcode: 26.0 Reproduces on: Debug builds AND TestFlight Summary: I'm using Apple-Hosted Managed Background Assets with on-demand download policy. The .aar archives download successfully (correct file size, status = downloaded), but the contents are never extracted into the asset pack namespace. AssetPackManager.shared.contents(at:) returns fileNotFound for all path variants, and url(for: FilePath(".")) returns a URL that exists but contains zero children. Root Cause from Sysdiagnose: The backgroundassets.user daemon logs reveal this error on every download attempt: A bundle record couldn't be looked up for the application identifier "AtlasDrift.SnapTrail": Error Domain=NSOSStatusErrorDomain Code=-10814 "(null)" UserInfo={_LSFile=LSBindingEvaluator.mm, _LSLine=1973, _LSFunction=runEvaluator} Error code -10814 is kLSApplicationNotFoundErr. The BA daemon downloads the .aar blob, then attempts to find the app bundle via LaunchServices to locate the extension for extraction — but the LS lookup fails. Without the extension, extraction never occurs. Verified Configuration Everything matches the documentation and WWDC sessions: Extension embedded at SnapTrail.app/Extensions/BackgroundDownloadExtension.appex Bundle IDs: App = AtlasDrift.SnapTrail, Extension = AtlasDrift.SnapTrail.BackgroundDownloadExtension (correct parent-child pattern) Extension point: com.apple.background-asset-downloader-extension Product type: com.apple.product-type.extensionkit-extension Protocol: StoreDownloaderExtension from StoreKit (for Apple-hosted packs) App group: group.AtlasDrift.SnapTrail (matching in both app and extension entitlements) Info.plist keys: BAAppGroupID, BAHasManagedAssetPacks = YES BAUsesAppleHosting = YES (no BAInitialDownloadRestrictions or other BA keys) .aar Packaging Archives built with xcrun ba-package from the Assets directory. Manifest format: { "assetPackID": "ireland", "downloadPolicy": { "onDemand": {} }, "fileSelectors": [{ "directory": "POIRegions/ireland/IR" }], "platforms": ["iOS"] } Uploaded via App Store Connect API with assetType: "ASSET". Diagnostic Observations AssetPackManager.shared.assetPack(withID:) returns valid metadata (correct download size) ensureLocalAvailability(of:) completes without error assetPackIsAvailableLocally(withID:) returns true url(for: FilePath(".")) returns a URL that exists but has zero children (empty namespace) contents(at:) returns fileNotFound for all path variants tested The extension never runs — breadcrumb file written in init() is never created The -10814 error appears in daemon logs for every download cycle Questions Has anyone successfully used Apple-Hosted Managed Background Assets on iOS 26 beta? Is the daemon's LaunchServices integration known to be broken in this seed? Is there anything about the bundle identifier format or provisioning profile setup that could cause the BA daemon's LS lookup to fail, even though the app installs and runs fine otherwise? Are there any additional Info.plist keys or entitlements beyond what's documented that might be required for the daemon to locate the app bundle? Any guidance would be appreciated. I've filed a Feedback report with the full sysdiagnose attached.