I'm working on hardware that communicates wireless and wired with mobile systems. Anything non-i[Pad]OS we can connect via USB and achieve great bandwidth, in situations where this is necessary. Since i[pad]OS does not support FTDI class compliant devices through USB (and also omits the IOUSB framework), I wonder whether we have a way to "work around" this, e.g. how about (ab)using another protocol that i[pad]OS allows? Concretely, would you think it's possible to tunnel our serial data stream via USBHID?

Hello everyone, We're working on an iOS app that needs to connect to a non-Apple pre-operating system using USB for serial communication. Our goal is to send and receive data between an iPhone and a UEFI-based system directly over USB. We've created a proof of concept using the USBMux protocol, which let us exchange basic messages. However, we're running into problems with the USB endpoint setup. In some cases, the USB communication doesn't start or stay connected. Since this is for a pre-boot environment, it might not fit into the usual iOS USB communication frameworks. We're looking for help with the following: Any guidance or documentation on setting up USB serial communication between an iPhone and a non-Apple pre-boot system Information on system APIs, frameworks, or protocols that iOS supports for direct USB communication in this scenario Access to official USBMux documentation or specs to understand its limitations and capabilities better Whether this communication requires MFi certification or if there are other Apple-supported interfaces we can use Thank you!

Hello, I have an app for a research study that has been approved and authorized to use SensorKit. All my permissions, entitlements and authorizations are in order, but I still can't get any data. The didFetchResult is not being called even though didCompleteFetch is called. I have waited for over 24 hours, but it still returns no samples. Please, I would appreciate any help on this issue. Thank you func sensorReader( _ reader: SRSensorReader, fetchingRequest: SRFetchRequest, didFetchResult result: SRFetchResult<AnyObject> ) { receivedResultsInCurrentFetch = true print("✅ SensorKit fetch result received for: \(sensorKey)") AppLogger.shared.log("SensorKit fetch result received for \(sensorKey)") if let sample = result.sample as? T { print("✅ SensorKit sample matched expected type for \(sensorKey): \(T.self)") AppLogger.shared.log("SensorKit sample matched expected type for \(sensorKey): \(T.self)") processSample(sample) } else { print("❌ SensorKit sample did not match expected type for \(sensorKey): \(T.self)") AppLogger.shared.log("SensorKit sample did not match expected type for \(sensorKey): \(T.self)") } } func sensorReader(_ reader: SRSensorReader, didCompleteFetch request: SRFetchRequest) { if receivedResultsInCurrentFetch, let lastRequestedUpperBound { session.setSensorKitLastFetchTime(lastRequestedUpperBound, for: sensorKey) print("✅ SensorKit fetch completed with samples for \(sensorKey). Checkpoint updated.") } else { print("⚠️ SensorKit fetch completed for \(sensorKey) with no samples.") AppLogger.shared.log("SensorKit fetch completed for \(sensorKey) with no samples. Keeping previous checkpoint so delayed SensorKit data is not skipped.") } isFetchInFlight = false completePendingFetches(success: true) print("✅ SensorKit fetch completed for: \(sensorKey)") AppLogger.shared.log("Fetch request completed for sensor type: \(T.self)") }

We're seeing limitations in host -> macOS VM changes syncing. Were using Anka, but we've also tried others. We're actually doing the exact implementation that others (the ones we found that are open source) do. Here is a breakdown of what's supported: Operation Direction Supported Notes Create new file/folder Host → Guest ✅ Yes New paths appear in the guest Create new file/folder Guest → Host ✅ Yes New paths appear on the host Read existing contents Host → Guest ✅ Yes Contents present at mount time are visible Modify file in place Guest → Host ✅ Yes Guest edits are written through to the host Modify file in place Host → Guest ❌ No Guest keeps stale contents for already-accessed files (macOS virtiofs caching) Delete file/folder Guest → Host ✅ Yes Removal is reflected on the host Delete file/folder Host → Guest ❌ No Guest still sees the path after the host deletes it (cached) Replace via temp + rename() (atomic) Host → Guest ✅ Yes New inode/dentry; recommended way to update files from the host We're requesting a way to disable caching and/or allow the unsupported actions in the table to be supported. https://feedbackassistant.apple.com/feedback/22905515

Summary: Starting from iPadOS 26.4, the maximum memory available to a single app has been reduced from approximately 6GB to 3GB on an 8GB iPad. This change persists in iPadOS 26.5 and has not been addressed. This breaks core functionality of memory-intensive applications such as 3D scanning apps that require large amounts of RAM to process models. Device: iPad with 8GB RAM Affected versions: iPadOS 26.4, iPadOS 26.5 Working version: iPadOS 26.0 / 26.1 / 26.2 / 26.3 Measured Data: iPadOS 26.0–26.3: App available memory ≈ 6GB (75% of total RAM) iPadOS 26.4–26.5: App available memory ≈ 3GB (37.5% of total RAM) Measurement method: Apple system API Impact: This is a regression, not expected behavior. The available memory per app has been cut by 50% without any official documentation or release notes mentioning this change. As a result, our 3D scanning application crashes immediately when attempting to process 3D models on iPadOS 26.4 and later. The app requires substantial RAM to load and process 3D model data. With only 3GB available, memory allocation fails during model processing, causing the app to crash (EXC_RESOURCE / OOM kill). This core functionality was working correctly on iPadOS 26.3 and earlier with the same device and same app binary. This regression makes our app's primary feature completely unusable for all users on iPadOS 26.4+. Steps to Reproduce: On an 8GB iPad, install iPadOS 26.0 Measure available app memory using Apple system API Upgrade to iPadOS 26.4 or 26.5 Measure available app memory again Observe: available memory drops from ~6GB to ~3GB Expected Result: Available memory per app should remain consistent across minor OS updates, or any changes should be documented. Actual Result: Available memory per app dropped by 50% starting in iPadOS 26.4, with no documentation of this change. Additional Notes: Disabling Apple Intelligence does not resolve the issue This issue was not fixed in iPadOS 26.5 Other developers have reported increased crash rates starting in iPadOS 26.4 (Apple Developer Forums)

We tried to fetch the recorded PPG data using SensorKit with the following code, however the didFetchResult callback method is never called. let ppgReader = SRSensorReader(sensor: .photoplethysmogram) let request = SRFetchRequest() let nowDate = Date() let toDate = nowDate.addingTimeInterval(-25 * 60 * 60) let fromDate = toDate.addingTimeInterval(-24 * 60 * 60) request.from = SRAbsoluteTime.fromCFAbsoluteTime(_cf: fromDate.timeIntervalSinceReferenceDate) request.to = SRAbsoluteTime.fromCFAbsoluteTime(_cf: toDate.timeIntervalSinceReferenceDate) ppgReader.delegate = self; ppgReader.fetch(request) The delegate called the didComplete successfully: func sensorReader(_ reader: SRSensorReader, didCompleteFetch fetchRequest: SRFetchRequest) But never called the didFetchResult func sensorReader(_ reader: SRSensorReader, fetching fetchRequest: SRFetchRequest, didFetchResult result: SRFetchResult<AnyObject>) -> Bool Any ideas why ? (I am wearing the watch for couple days and ensure it has the data for the time period I am querying) One thing I notice is when Apple granted us the entitlement, it uses Uppercase for ECG and PPG, however the document use Lowercases in the plist https://developer.apple.com/documentation/sensorkit/srsensor/photoplethysmogram Dose it matter ?

We are implementing Apple Pay In-App Provisioning (EV_ECC_v2) for our EU app. The same codebase and encryption logic works successfully for our main app (different bundle ID and Adam ID), but the EU app consistently fails with HTTP 500. Environment: Entitlement: Granted (Case-ID: 18772317) Encryption scheme: EV_ECC_v2 Issue: During In-App Provisioning, the iOS app successfully obtains certificates, generates cryptographic material (encryptedCardData, activationData, ephemeralPublicKey), and POSTs to Apple's broker endpoint. The request fails at: Endpoint: POST /broker/v4/devices/{SEID}/cards Response: HTTP 500 with an HTML error page (not a JSON business error) <html> <head><title>500 Internal Server Error</title></head> <body> <center><h1>500 Internal Server Error</h1></center> <hr><center>Apple</center> </body> </html> Key observations: Our main app (different bundle ID/Adam ID) uses identical encryption code, private keys, and key alias — and works correctly in production. Manual card provisioning through Apple Wallet on the same device succeeds. The entitlement com.apple.developer.payment-pass-provisioning is confirmed present in the provisioning profile (verified via codesign). The 500 response is HTML rather than JSON, suggesting the request is rejected at the gateway level before reaching Apple Pay business logic. What we've verified: Entitlement correctly configured in provisioning profile ephemeralPublicKey is in uncompressed format (65 bytes, starts with 0x04) encryptionVersion is EV_ECC_v2 No double Base64 encoding Question: Could you please check whether Adam ID 6745866031 has been correctly added to the server-side allow list for In-App Provisioning in the production environment? Given the HTML 500 (not JSON) and that the identical code works for our other app, we suspect this may be an allow list or account configuration issue rather than a cryptography error. I will follow up with a Feedback Assistant ID including sysdiagnose logs shortly, per the steps outlined in https://developer.apple.com/forums/thread/762893

Hi, We’re testing Apple Pay In-App Provisioning in the production environment using a TestFlight build, and the provisioning flow fails before the Terms & Conditions screen is shown. From the device logs, the failure happens during the eligibility step: ProvisioningOperationComposer: Step 'eligibility' failed eligibility request failure Received HTTP 500 PKPaymentWebServiceErrorDomain We submitted a Feedback Assistant report with the sysdiagnose and all requested private details. Feedback ID: FB22911853 We also verified the exported IPA: It is signed with Store provisioning profiles. get-task-allow is false. ProvisionedDevices is absent. com.apple.developer.payment-pass-provisioning is present in both the app signature entitlements and the embedded provisioning profile entitlements. Could you please advise what we should check next? We’re trying to understand whether this points to a client payload issue, Apple Pay production configuration issue, allowlist issue, or payment network configuration issue. Thanks

We are investigating an intermittent package installation failure on macOS Tahoe 26.5 and are trying to understand the conditions under which PackageKit may return the following errors during an upgrade installation: PKInstallErrorDomain Code=120 NSPOSIXErrorDomain Code=1 ("Operation not permitted") The package successfully passes validation and authorization, and pre-install scripts complete successfully. The failure occurs during the final PackageKit commit phase when PackageKit attempts to move/relink content from the installer sandbox to the destination volume. Relevant log snippets: PackageKit: Shoving /Root to / Error relinking file (primary): .../Contents/_CodeSignature/CodeResources failed _relinkFile(...) Operation not permitted PackageKit: Install Failed: Error Domain=PKInstallErrorDomain Code=120 NSUnderlyingError: Error Domain=NSPOSIXErrorDomain Code=1 "Operation not permitted" The issue is intermittent and only affects a subset of systems. The same package installs successfully on many machines running the same macOS version. Has anyone encountered similar _relinkFile / CodeResources failures during package upgrades? In particular, we are interested in understanding: Common causes of NSPOSIXErrorDomain Code=1 during PackageKit relink operations. Whether existing signed application bundle metadata (CodeResources) can cause relink failures during upgrades. Any Installer or PackageKit changes in recent Tahoe releases that could affect bundle replacement during package installation. Any insights would be appreciated.

We are currently implementing a custom iCloud sync for our macOS and iOS apps using CloudKit. Syncing works fine as long as the number of record sends is relatively small. But when we test with a large number of changes ( 80,000+ CKRecords ) we start running into problems. Our sending strategy is very conservative to avoid rate limits: We send records sequentially in batches of 250 records With about 2 seconds pause between operations Records are small and contain no assets (assets are uploaded separately) At some point we start receiving: “Database commit size exceeds limit” After that, CloudKit begins returning rate-limit errors with retryAfter-Information in the error. We wait for the retry time and try again, but from this moment on, nothing progresses anymore. Every subsequent attempt fails. We could not find anything in the official documentation regarding such a “commit size” limit or what triggers this failure state. So my questions are: Are there undocumented limits on the total number of records that can exist in an iCloud database (private or shared)? Is there a maximum volume of record modifications a container can accept within a certain timeframe, even if operations are split into small batches with pauses? Is it possible that sending large numbers of records in a row can temporarily or permanently “stall” a CloudKit container? Any insights or experiences would be greatly 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.

Hoping this might peak someones interest regarding proxy authorisation handling specifically during a device's SetupAssistant phase. Our problem in this instance relies with the AuthBroker's handling of proxy authorisation challenges. With Apple's devices proxy auth is handled through AuthBroker which will make subsequent calls to GSS/ keychain if applicable to handle proxy Auth with CFNetwork. Whilst this process functions quite well in the large part it's functionality around prompt suppression causes issues during the setupAssistant phase. To avoid prompt fatigue AuthBroker Agent has a flag for a given proxy authorisation host (combination of host + port) that's responsible for reporting if a system prompt has been raised in the past. If it has AuthBroker will suppress prompting for the active session. This creates a problem with SetupAssistant in that AuthBroker agent is not allowed to raise system prompts in this state. As a result it instaed triggers a default not now handling: default 2026-04-27 20:34:43.565424 -0700 AuthBrokerAgent [0x100a7ee60] activating connection: mach=false listener=false peer=true name=com.apple.cfnetwork.AuthBrokerAgent.peer[119].0x100a7ee60 default 2026-04-27 20:34:43.565608 -0700 AuthBrokerAgent [0x100a80350] activating connection: mach=false listener=false peer=true name=com.apple.cfnetwork.AuthBrokerAgent.peer[158].0x100a80350 default 2026-04-27 20:34:43.565924 -0700 AuthBrokerAgent Fetching proxy credential for query <private> default 2026-04-27 20:34:43.566135 -0700 AuthBrokerAgent Request <private> 0x65a873860 default 2026-04-27 20:34:43.567245 -0700 AuthBrokerAgent Not internal release, disabling SIRL default 2026-04-27 20:34:43.576369 -0700 AuthBrokerAgent CFNetwork Diagnostics [3:1] 20:34:43.575 { CopyDefaultCredential: (null) Store: shared credential storage 0x100a7d320, session 0xad7010040, persistent 0x100a7d3e0 Space: https://someproxy.example.com:3128/, NTLM (Hash 774a6617a1f9d1ae) Result: null } [3:1] default 2026-04-27 20:34:43.576451 -0700 AuthBrokerAgent Prompting user 0x65a873860 default 2026-04-27 20:34:43.578299 -0700 AuthBrokerAgent Cache loaded with 6300 pre-cached in CacheData and 69 items in CacheExtra. default 2026-04-27 20:34:43.606794 -0700 AuthBrokerAgent User selected alternate response, won't prompt again 0x65a873860 default 2026-04-27 20:34:43.606820 -0700 AuthBrokerAgent Not sending a credential 0x65a873860 default 2026-04-27 20:34:43.606829 -0700 AuthBrokerAgent Fetching proxy credential complete result (null) This flows onto Authbroker requests executed after setupAssistant and prevents the device from prompting until an effective restart: default 2026-04-28 13:37:46.710956 +1000 Setup Buddy exiting... default 2026-04-28 13:38:06.658658 +1000 AuthBrokerAgent [0xad6864000] activating connection: mach=false listener=false peer=true name=com.apple.cfnetwork.AuthBrokerAgent.peer[278].0xad6864000 default 2026-04-28 13:38:06.659238 +1000 AuthBrokerAgent Fetching proxy credential for query <private> default 2026-04-28 13:38:06.661957 +1000 AuthBrokerAgent Request <private> 0xa4eccc760 default 2026-04-28 13:38:06.662597 +1000 AuthBrokerAgent SecSecurityClientGet new thread! default 2026-04-28 13:38:06.813050 +1000 AuthBrokerAgent CFNetwork Diagnostics [3:7] 13:38:06.809 { CopyDefaultCredential: (null) Store: shared credential storage 0x100a7d320, session 0xad7010040, persistent 0x100a7d3e0 Space: https://someproxy.example.com:3128/, NTLM (Hash 774a6617a1f9d1ae) Result: null } [3:7] default 2026-04-28 13:38:06.813088 +1000 AuthBrokerAgent Will not prompt since user previously dismissed prompt 0xa4eccc760 default 2026-04-28 13:38:06.813091 +1000 AuthBrokerAgent Not sending a credential 0xa4eccc760 default 2026-04-28 13:38:06.814867 +1000 AuthBrokerAgent Fetching proxy credential complete result (null) Is there any chance to get this handling updated so that SetupAssistant reset AuthBroker's prompting state on conclusion to allow for system prompt exposure to the user without requiring a device restart.

What I'm building An FSUnaryFileSystem that projects a large, read-mostly tree of existing on-disk files into a sandbox namespace — a build sandbox that lays out an action's declared inputs and points outputs at host scratch. This is squarely the "replace a third-party kext (macFUSE-style) with FSKit" use case, and it's a projection/overlay filesystem: nearly every file the volume serves is just a view of a regular file that already exists on a local APFS volume. The problem For file content, the only available path for a file-backed (non-block-device) volume is FSVolumeReadWriteOperations — every read that misses UBC is an XPC round-trip into my extension, where I memcpy from the backing file into the kernel buffer. The kernel already has, or could trivially open, the backing file; instead each page-in becomes: pagein → IPC → extension read → copy → return. FSVolumeKernelOffloadedIOOperations looks like the intended fast path, but it's built around FSBlockDeviceResource — i.e. it assumes the volume is backed by a block device the kernel can do extent I/O against. A projection over regular files has no block device, so there's no way to say "this item is backed by host file X — kernel, please do I/O directly against X and skip my process." What I measured In one representative build action my volume serves ~440 files and the kernel issues ~630 read RPCs (cold). A real build runs thousands of such actions, so this is on the order of millions of round-trips and buffer copies per build, for data that is already sitting in the host page cache. UBC absorbs repeats, but cold reads, cache eviction under memory pressure, and large sequential reads all pay the full RPC+copy cost. It dominates the I/O profile. The ask A passthrough/offload API for file-backed volumes: let the extension associate an FSItem with a backing file descriptor (or vnode) and have the kernel perform reads — and optionally writes — directly against the backing file, bypassing the userspace round-trip. Per-item, opt-in, and read-only-only would already be a huge win for projection/overlay workloads. This is exactly the model that already exists on other platforms: Linux FUSE passthrough (FUSE_PASSTHROUGH, backing-id via FUSE_DEV_IOC_BACKING_OPEN, mainline since 6.9): a FUSE daemon registers a backing fd and the kernel routes I/O straight to it. Windows Projected File System (ProjFS): content is hydrated/served from a provider-supplied source without a per-read user-space hop. FSKit is positioned as the supported replacement for kext-based filesystems, and projection/overlay/caching filesystems are a primary motivation for it — yet those are precisely the volumes that need zero-copy passthrough to be viable at scale. The block-device offload path covers disk-image-style filesystems; the gap is the file-backed case.

We are implementing a Network Extension that uses NETransparentProxyProvider. For browser TCP flows we terminate in the extension and re‑originate traffic with NWConnection. Per documentation, we set NWParameters.preferNoProxies = true on that NWConnection so it should not use the system HTTP/HTTPS proxy configuration, including PAC‑selected explicit proxies. Observation: With System Settings → Network → Proxies → Automatic proxy configuration pointing at a PAC file that returns something like PROXY 127.0.0.1:8888 for relevant traffic, we still see our NWConnection traffic show up at the local explicit proxy as a normal CONNECT host:443 tunnel. That suggests PAC / explicit proxy selection is still being applied to sockets we believed were opted out via preferNoProxies. This is affecting interoperability: the browser may evaluate PAC with a hostname (e.g. a site configured as DIRECT), while a separate NWConnection may be evaluated in a context where the logical host is an IPv4 literal, so the same PAC script can return PROXY for what the user thinks is the “same” destination. We had expected preferNoProxies to remove the second leg from PAC/proxy entirely. Expected: NWConnection with preferNoProxies == true should connect without opening an explicit CONNECT session to the PAC‑configured proxy (unless there is documented behavior that NE‑originated traffic is intentionally exempt from this flag). Actual: Traffic from the NWConnection path still reaches the explicit proxy (we can log CONNECT … on a minimal local proxy). Environment: macOS Tahoe 26.5 (25F71), Network Extension / App Proxy provider, PAC served over local http, Safari as client. Questions: Is preferNoProxies guaranteed to bypass PAC‑selected explicit proxies for NWConnection from Network Extension processes, or are there known exceptions (e.g. certain interfaces, MDM, networkserviceproxy, etc.)? If this is by design, what is the supported way for an NE to open an outbound TCP connection that must not inherit system PAC/proxy?

NSE Filtering Entitlement — No Response After 4+ Weeks (Request ID: 7NPNCB7Q9P) We submitted a request for the Notification Service Extension Filtering Entitlement (com.apple.developer.usernotifications.filtering) over two weeks ago and have received no response. App: NoLink Bundle ID: io.nolink.ios NSE Bundle ID: io.nolink.ios.nse Team ID: V2E3A94DC9 Request ID: 7NPNCB7Q9P Support Case ID: 102886799629 NoLink is an end-to-end encrypted messaging app built on the Matrix protocol with voice and video calling. All push notifications arrive encrypted — the NSE decrypts them to determine if the event is a message or an incoming call. Without this entitlement, incoming VoIP calls cannot ring properly. Users receive a silent text notification instead of the native CallKit incoming call screen. The duplicate APNS notification for call events cannot be suppressed. Element X iOS (io.element.elementx) has been granted this exact entitlement for the identical use case — same Matrix protocol, same Matrix Rust SDK, same NSE architecture. NoLink is built on the same codebase. We also opened Support Case 102886799629 but received only a generic response directing us to the Developer Forums. Could someone from the Entitlements team please review our request? We are happy to provide any additional technical details or a demo. Thank you.

I'm building a macOS app and trying to confirm whether there's a way for me to remotely wake a Mac so my app can do a small amount of work (using APNs silent notifications or any other technique). Here's what I want to happen: User runs my app on their Mac User puts the Mac to sleep (Apple menu > Sleep) 30 minutes later, my server sends a push notification (content-available: 1, apns-push-type: background, apns-priority: 5) via APNs to the Mac Note: Power Nap and Wake for Network Access are enabled The Mac dark-wakes, delivers the notification to my app via application(_:didReceiveRemoteNotification:), my app gets ~30 seconds to open a WebSocket, do some work, and return Mac goes back to sleep So far, I've been able to send silent push notifications to a sleeping Mac, but my app only gets to take action on them after the Mac has been awoken manually. I've tried both silent pushes (content-available: 1, priority 5) and alert pushes (priority 10) with the same result. After trying every option I can find, I don't believe notifications can wake a sleeping Mac and allow my third-party app to process data, but I really want to be wrong. Can anyone confirm whether or not this is possible?

We are currently investigating a serious issue related to Wi-Fi Aware and AccessorySetupKit. We found that some devices which originally supported Wi-Fi Aware may suddenly report that Wi-Fi Aware is not supported. After this happens, calling the following API fails: ASAccessorySession.showPicker(for:completionHandler:) API documentation: https://developer.apple.com/documentation/accessorysetupkit/asaccessorysession/showpicker(for:completionhandler:) The error returned is: Error Domain=ASErrorDomain Code=450 "Current device is not Wi-Fi Aware capable.” Related logs: error: Error Domain=ASErrorDomain Code=450 "Current device is not Wi-Fi Aware capable." 21:27:33.116061+0800 deviceaccessd Activating DASession: CID 0x7FC70001, BundleID xxxx, PID 542, WiFiAwareSupported: no 2026-05-26 21:27:33.118<103>21:27:33.118[E][WiFiAware::WA]@"":[ASK] showPicker callback error: Error Domain=ASErrorDomain Code=450 "Current device is not Wi-Fi Aware capable." UserInfo={ NSDebugDescription=Current device is not Wi-Fi Aware capable., cuErrorMsg=Current device is not Wi-Fi Aware capable., NSLocalizedFailureReason=Current device is not Wi-Fi Aware capable. } Device information: Device: iPhone 16 Pro OS Version: 26.5 The device was previously able to use Wi-Fi Aware successfully. However, after the issue occurs, the system reports: WiFiAwareSupported: no The only known way to recover so far is to erase all content and settings / factory reset the device. This is not an acceptable workaround for end users and may cause a severe user experience issue. We would like to ask for your help with the following questions: Under what conditions would an iPhone that supports Wi-Fi Aware suddenly be reported as not Wi-Fi Aware capable? Is WiFiAwareSupported: no determined by hardware capability, system configuration, region setting, privacy/security policy, entitlement state, or some cached system state? Is there any known issue in AccessorySetupKit or Wi-Fi Aware on iOS 26.5 that could cause this behavior? Is there a way to recover the Wi-Fi Aware capability without requiring a factory reset? Are there any additional logs, sysdiagnose profiles, or diagnostic commands you recommend us to collect when this issue occurs? This issue is critical for us because users who encounter it will no longer be able to proceed with accessory setup, even though their device should support Wi-Fi Aware. Please let us know if you need a sysdiagnose, sample project, full device logs, or additional reproduction information. We would appreciate any guidance on the root cause and possible workaround.

Hello, We are implementing in-app provisioning in our banking app but are having trouble getting to the Terms & Conditions screen. User taps on “Add to Apple Wallet” > PKAddPaymentPassViewController > Next > the flow fails quickly with "Could Not Add Card -> Set Up Later" alert. The only notable thing in the logs, as far as I can see is the https://nc-pod12-smp-device.apple.com:443/broker/v4/devices/{SEID}/cards fails with: <html> <head><title>500 Internal Server Error</title></head> <body> <center><h1>500 Internal Server Error</h1></center> <hr><center>Apple</center> </body> </html> and maybe ProvisioningOperationComposer: Step 'eligibility' failed with error <PKProvisioningError: severity: 'terminal'; internalDebugDescriptions: '( "eligibility request failure", "Received HTTP 500" )'; underlyingError: 'Error Domain=PKPaymentWebServiceErrorDomain Code=0 "Unexpected error." UserInfo={PKErrorHTTPResponseStatusCodeKey=500, NSLocalizedDescription=Unexpected error.}'; userInfo: '{ PKErrorHTTPResponseStatusCodeKey = 500; }'; > Feedback Assistant ID: FB22932141 (Error during In-App Provisioning)

Hello, We are currently evaluating ways to reduce the app size of the my App. The app contains approximately 200~250 MB of bundled static resources, and we are considering converting these resources into On-Demand Resources（ODR） in order to reduce the initial download and installation size of the app. However, we noticed that ODR is currently marked by Apple as a Legacy Technology. Since we would like these resources to continue being hosted and distributed through Apple CDN / App Store infrastructure, the first alternative we considered is Managed Background Assets, rather than regular Background Assets. We understand that regular Background Assets are available on iOS 16 and later, but they mainly address background download scheduling for apps. What we are specifically looking for is the resource hosting and distribution capability, similar to ODR, where assets can be hosted and delivered through Apple’s infrastructure. This is why we are considering Managed Background Assets. However, my App currently supports devices starting from iOS 14, while the key capabilities of Managed Background Assets require newer iOS versions. As a result, this solution cannot fully cover users who are still on older iOS versions, such as iOS 14 through iOS 18. Given this background, we would like to ask Apple the following questions: Does Apple have any plan to discontinue ODR-related services in the future, especially the App Store-hosted ODR asset download service? If the ODR service is changed or discontinued in the future, would it affect already released App Store apps that rely on ODR asset downloads on older iOS versions? For apps that still need to support iOS 14 and later, while also relying on Apple CDN / App Store infrastructure for resource hosting and distribution, does Apple still recommend using ODR? For apps that cannot immediately raise their minimum supported iOS version to the version required by Managed Background Assets, is there a recommended transition strategy? If ODR services are discontinued in the future, will Apple provide an alternative resource distribution solution that supports older iOS versions, or would developers need to build and maintain their own resource hosting and download system? We would like to better understand the long-term availability and potential risks of using ODR on older iOS versions, so that we can make an appropriate decision for future app size reduction and asset delivery in the App. Thank you.

Actual Result: After showPicker(for:), the system AccessorySetupUI RemoteAlert brings up a remote keyboard. User taps are dispatched to AccessorySetupUI’s UIRemoteKeyboardWindow instead of the picker content window. App-side endEditing(true) / resignFirstResponder cannot dismiss it because the keyboard belongs to the system AccessorySetupUI remote scene. Key Evidence: 19:51:54.066: App window snapshot before showPicker has no UITextEffectsWindow. 19:51:54.009968: ASAccessorySession ### showPickerWithDisplayItems 19:51:54.013299: AccessorySetupUI showPickerWithOverrideBundleID 19:51:54.051591: AccessorySetupUI reports remote keyboard onscreen, frame {{0, 623}, {440, 333}} 19:51:54.095643: display layout shows com.apple.AccessorySetupUI foreground and com.osmo.tech obscured. 19:51:56.207/19:51:56.305: touch events are sent to and logged as KeyboardTouch touch down/up. Questions for Apple: Is AccessorySetupKit picker expected to show a keyboard when no text input is focused? Is it a system bug that UIRemoteKeyboardWindow covers/intercepts the “Find Accessories” action? Is there any public API for a third-party app to dismiss the keyboard inside AccessorySetupUI RemoteAlert? If this is expected behavior, what is the recommended workaround or required picker/display item configuration?