I’m developing a macOS app that reads a wired controller and publishes a generic BLE HID gamepad for an iPhone. BLE communication works, but iOS does not expose the device through GameController. I’m looking for guidance on supported device-identity publication and controller-admission requirements. Environment Apple Silicon MacBookPro17,1: macOS 27.0, build 26A428 iPhone 15 Pro Max: iOS 27.0, build 24A437 Xcode 27 Peripheral implemented using CBPeripheralManager What works The iPhone can connect, perform dynamic characteristic reads, and read encryption-required characteristics using the retained pairing. It discovers the application’s HID service and reads its Report Map, HID Information, Report Reference, and Input Report. The descriptor in the iPhone’s system HID record matches the application’s remotely read report map byte-for-byte. The peripheral also receives an input subscription, although I cannot independently identify the subscribing consumer. What fails An independent GCController.controllers() observer remains empty. During the recorded HID initialization, the iPhone logs: Un-authenticated game controller device attached Start failed: 0xe00002bc IOHIDEventDriver start failed. For the same registry device, gamecontrollerd records: vendorID = 0 productID = 0 version = 0 manufacturer = 'Apple Inc.' product = '[Mac device name]' transport = 'BluetoothLowEnergy' I am not assuming that “Un-authenticated” identifies a specific authentication requirement. I would like to understand which supported admission requirement is unmet. Device Information observations The iPhone’s CoreBluetooth discovery exposes two distinct Device Information service instances: System service Observed UUID: 180A Manufacturer: Apple Inc. Model: MacBookPro17,1 No PnP characteristic exposed by successful all-characteristic discovery Application service Observed UUID: 0000180A-0000-1000-8000-00805F9B34FB Manufacturer: PS3 Bridge Model: BLE Gamepad Prototype PnP bytes: 02 00 00 01 00 00 01 The application publishes expanded Bluetooth-base UUIDs. I understand these represent the same assigned UUIDs; I am preserving the observed representations because I have not established whether every host component handles them identically. The application PnP value represents vendor-ID source 2, vendor 0, product 1, and version 0x0100. The system HID record therefore does not simply reflect that value unchanged. The duplicate-DIS layout also appears inconsistent with the unique primary DIS expected by HOGP. I have not established that this causes the driver rejection. Questions Is there a supported macOS API or architecture for publishing a coherent BLE HID device identity when macOS already exposes its own Device Information service? How does iOS select DIS/PnP information when constructing a system HID device in this arrangement? Is a generic BLE HID gamepad published through macOS CoreBluetooth a supported path to iOS GameController recognition? If so, what additional profile, identity, or authentication requirements apply? What supported diagnostics would distinguish an identity-selection problem from a separate controller-admission requirement? Available evidence I have diagnostic source, corrected per-service-instance inventories, and redacted phone logs available. I also have a small standalone CoreBluetooth publication reproducer. It is reduced and has not been validated as independently reproducing the full bridge’s controller rejection. A later connection-only observation reused an existing shared Bluetooth link and still showed zero controllers. I am not treating that as a fresh HID initialization or admission attempt. I’m seeking a supported implementation path without private APIs, Bluetooth daemon modifications, or changes to system security.

On our telecommunication platform, D@niel mobile app, used for video meetings in education, training, we are able to activate two cameras simultaneously on Android devices using our D@niel software based on open source Bigbluebutton software. However, we haven't been able to do this on iPhones or Ipad so far. Will the new iPhone Duo allow us to enable dual-camera during a D@niel session call meeting, just like on Android. Please, watch the YouTube link. https://youtu.be/dwcmYZxuhD4?is=xVvkYvDxUrwJZWkn

We receive live relative-altitude updates from CMAltimeter.startRelativeAltitudeUpdates(to:withHandler:) on iPhone. CMAltitudeData inherits CMLogItem.timestamp, which the documentation describes as the time when the item is valid and as seconds since device boot. We need to determine whether a pressure measurement's event time falls inside an application operation bounded by a supported monotonic clock. Could Apple clarify the supported contract for CMAltitudeData.timestamp on iOS? Does CMAltitudeData.timestamp use the same epoch and rate as mach_absolute_time(), DispatchTime.uptimeNanoseconds, CACurrentMediaTime(), or ProcessInfo.systemUptime? If only some are compatible, which ones? Does it advance or pause during device sleep, device lock, application suspension, and background execution? In particular, are its sleep/suspension semantics guaranteed to match any of the clocks above? Is there a supported API for converting CMLogItem.timestamp to a host CMClock/Mach time, or for sampling “now” in the exact same clock domain used by CMAltitudeData.timestamp? Are the answers contractual across supported iPhone hardware and iOS releases, or are they implementation details that applications should not rely on? If direct comparison is not supported, what Apple-supported clock or conversion mechanism should an application use to compare a CMAltitudeData event time with two application-side monotonic operation boundaries? The question concerns clock semantics only. A minimal reproducer can be supplied if requested, but no application identifier, production data, sensor values, or user data is required to answer it.

Hello Apple Developer Forums, We are developing an iOS companion app that supports multiple Bluetooth earbud products, and we are evaluating AccessorySetupKit for one specific product family. Our current product situation is: EU: Earbud A → AccessorySetupKit Earbud B → legacy CoreBluetooth discovery Earbud C → legacy CoreBluetooth discovery Earbud D → legacy CoreBluetooth discovery Earbud E → legacy CoreBluetooth discovery Non-EU: Earbud A → legacy CoreBluetooth discovery Earbud B → legacy CoreBluetooth discovery Earbud C → legacy CoreBluetooth discovery Earbud D → legacy CoreBluetooth discovery Earbud E → legacy CoreBluetooth discovery Only Earbud A needs to adopt AccessorySetupKit. The other four products are existing products and need to keep their current CoreBluetooth discovery and authentication flow. According to Apple's AccessorySetupKit documentation, an app using AccessorySetupKit needs to declare: <key>NSAccessorySetupKitSupports</key> <array> <string>Bluetooth</string> </array> Apple's documentation also describes AccessorySetupKit as the mechanism for discovering and configuring Bluetooth accessories: https://developer.apple.com/documentation/accessorysetupkit/discovering-and-configuring-accessories Our concern is the interaction between this declaration and the existing CoreBluetooth discovery flow. For the AccessorySetupKit-managed product, the intended flow is: ASAccessorySession ↓ Accessory Picker ↓ User authorization ↓ CoreBluetooth communication For the other existing products, we need to retain: CBCentralManager ↓ scanForPeripherals() ↓ Discover nearby peripheral ↓ User selects device ↓ Existing authentication / binding flow We understand from Apple's WWDC24 AccessorySetupKit session that once AccessorySetupKit is involved, CoreBluetooth scanning is subject to the AccessorySetupKit authorization model. This raises an important compatibility question for us. If the application declares: <key>NSAccessorySetupKitSupports</key> <array> <string>Bluetooth</string> </array> but only one product family is intended to use AccessorySetupKit, can the same application continue to perform unrestricted CoreBluetooth discovery for the other four legacy Bluetooth products? For example: Nearby: Earbud A → ASK-managed Earbud B → legacy Earbud C → legacy Expected: ASK Picker → Earbud A CBCentralManager.scanForPeripherals() → Earbud B → Earbud C Or does declaring NSAccessorySetupKitSupports = Bluetooth cause CoreBluetooth discovery to be restricted to accessories that have already been authorized through AccessorySetupKit? We are particularly concerned about first-time discovery of a legacy accessory: User upgrades the app ↓ Earbud B has never been authorized through AccessorySetupKit ↓ Earbud B is nearby ↓ The app needs to discover Earbud B for the first time ↓ Existing CBCentralManager discovery flow If CoreBluetooth discovery is restricted after AccessorySetupKit is enabled, we don't see how the app can discover this new legacy accessory in order to continue using the existing flow. We are aware of ASMigrationDisplayItem and the AccessorySetupKit migration mechanism for existing Bluetooth accessories. However, migration appears to require an already-known peripheral identifier, so we are unsure how this applies to a new legacy accessory that has never been discovered or authorized through AccessorySetupKit. Questions Is it officially supported for one application to use AccessorySetupKit for only one Bluetooth product family while continuing unrestricted CoreBluetooth discovery for other Bluetooth product families? If yes, what is the recommended architecture/API configuration? Does NSAccessorySetupKitSupports = Bluetooth affect CoreBluetooth discovery globally for the application, or can its effect be limited to specific accessory families through ASDiscoveryDescriptor? How should an application discover a new, previously unauthorized legacy Bluetooth accessory after AccessorySetupKit has been enabled? Is there an Apple-recommended migration strategy for an application that has multiple existing Bluetooth product families, where only one product family is required to adopt AccessorySetupKit? Any clarification from Apple on the officially supported architecture would be greatly appreciated. Thank you.

Hi, Does anyone know if Apple has released the SDK to enable 2K streaming in HomeKit for doorbells/cameras? I've not seen anything posted so far, wondered if I've missed it. Thanks

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

一部のiPadで電源が0%になるとどの充電器でも1%までおおよそ9時間もかかります

We can give permission to app for Mic and Camera. Can we build something by which an app doesn't get permission to receive any gamepad inputs but other app that have permission work regularly.

I’m investigating whether a consumer iPhone app can control AirPods Pro environmental listening settings using public APIs, while keeping all live audio processing inside the earbuds. On a real iPhone running iOS 26.6.1, with AirPods reporting model A3064 and firmware 8B41 in Settings: CoreBluetooth connects and successfully reads the manufacturer, model and firmware characteristics. Explicit discovery of service 7798082B-B7B7-45A6-9933-563492EFE04E returns no matching service. Unfiltered discovery completes without errors but also excludes that service. A system PacketLogger capture contains metadata mapping that service to handles 0x12–0x2B, and characteristic D5621CC1-F7AB-45DB-9403-9EAF744D5390 to value handle 0x18. System ATT reads of that handle receive responses. Our app performs no setting writes. We understand that system trace metadata does not establish third-party access. Is this service intentionally unavailable to third-party CoreBluetooth clients? Alternatively, is there a documented public connection, authorization or entitlement requirement that could explain its absence? If this service is unavailable, is there any supported API for controlling AirPods environmental amplification or frequency balance? A minimal Swift project and diagnostic report are available.

Hi, I'm testing DL-TDoA with Qorvo QM35 anchors and an iPhone 16 Pro running iOS 27 (24A5430a). A separate DWM3001C receiver successfully receives the QM35 anchor frames, with CRC, STS and MAC integrity checks passing. The app uses NIDLTDOAConfiguration with BLE discovery, as described in Apple’s DL-TDoA ranging guide . supportsDLTDOAMeasurement returns true, Location permission is granted, and the app stays foregrounded. Apple’s logs show our BLE discovery configuration being reassembled and parsed, followed by RangingStarted. Approximately 150 ms later, we see FatalChipError and a session suspension for ErrorHandling. The phone’s firmware report contains: ASSERTION FAILED: hmd.c:5723: nchains_enabled >= 2, 0, 0 The app receives no DL-TDoA measurements. We’ve reproduced the same assertion after rebooting the phone and with both QM35 UWB sessions stopped, leaving only BLE discovery active. Incoming anchor transmissions therefore aren’t required to trigger this failure. Has anyone encountered this assertion during DL-TDoA startup? Is there a discovery configuration requirement worth checking, or a known issue with this iOS build? Happy to share the exact discovery payload and diagnostic logs. Thanks! efad25a2-0aaf-49c9-85ee-74d4f384b3ab.rtf

I am using an 11-inch M4 iPad Pro. I first noticed severe battery drain while the iPad was idle. After checking the device, I found that several unrelated functions had stopped working at the same time: Front and rear cameras show a black screen Face ID does not work LiDAR does not work Flashlight does not work Apple Pencil is not detected, paired, or charged through the magnetic charging area Apple Diagnostics at the Genius Bar also reported failures involving the front camera, rear camera, Face ID, and LiDAR. I was told at the Genius Bar that, because the device is outside the standard warranty period, it would be treated as an out-of-warranty hardware failure and would not qualify for free repair. There has been no drop or liquid damage. I have already performed multiple force restarts, updated iPadOS, and factory-reset the device several times, but the symptoms remain unchanged. What seems unusual is that several functionally separate systems became unavailable at nearly the same time, together with severe standby battery drain. Because of that, I am wondering whether this could be related to embedded software, firmware, power management, or low-level hardware control rather than several independent hardware components coincidentally failing at once. Has anyone seen a similar issue on an M4 iPad Pro, or is there any known firmware or system-level failure that could cause this pattern?

I have an app that uses CMHeadphoneMotionManager on macOS without playing any sound. I have noticed that when I start playing audio with Spatial Audio set to either Head Tracked or Fixed, the yaw appears to recenter as soon as I press play, which I’ve confirmed by logging the motion data returned. This has a knock-on effect on my app because the orientation that I previously considered the center is no longer the center. Is this intentional behavior? Is AirPods head-motion data designed so that the application currently using Spatial Audio takes precedence over other applications using the CMHeadphoneMotionManager or should multiple applications be able to use the motion data independently without affecting each other’s orientation reference?

Hello Apple Home/Matter team, our Matter product is CSA-certified, has a valid CD, and is listed in Compliance DCL. In testing with HomePod mini as border router, commissioning proceeds but Apple Home still shows “Uncertified Accessory.” We are an OEM/ODM manufacturer: product vendor_id/product_id belong to the brand owner, while dac_origin_vendor_id/dac_origin_product_id belong to us(manufacturer). The device also uses the brand owner’s product VID/PID at runtime. Our certification is Portfolio Family, so CD product_id is an array covering 6 SKUs. Is this model expected to pass Apple Home certification checks, and what are the most common causes of this warning? Emma

I'm building a Matter irrigation system and I've hit a device-type wall in the Home app. This is not a commissioning or pairing problem - the accessory is found, setup proceeds, and then Home declines to create the accessory, reporting that the device is not supported. The controlled comparison, which is why I'm confident it is the device type and nothing else: Endpoint declares 0x0042 Water Valve (Matter 1.3) with cluster 0x0081 Valve Configuration and Control -> Home: NOT SUPPORTED, accessory is not created. Endpoint declares 0x010A On/Off Plug-in Unit with cluster 0x0006 On/Off -> Home: created, works, valve opens and closes. Same hardware, same firmware image, same network, same iPhone. The only variable is the device type ID. Other Matter controllers accept the 0x0042 version and control it correctly. Water Valve (0x0042) - is this device type supported by the Home app in any current or announced iOS version? If not, is support planned? Right now I ship the plug-in-unit substitution because it is the only thing Home will accept. It works, but it misrepresents the device: the user sees a row of "plugs" that are actually irrigation valves, with no valve semantics and nothing telling Home - or an automation the user writes - that switching this on releases water into a garden. Soil Sensor (Matter 1.5) - same question. Matter 1.5 added soil sensing (moisture, optionally temperature), explicitly positioned for irrigation paired with Matter water valves. Is it supported or planned in Home? Today I publish soil moisture on a Relative Humidity Measurement endpoint (0x0405) because that is what Home renders, so garden soil moisture appears as air humidity and pollutes any humidity-based automation the user has. The general question, which is the one I actually want answered: is there an authoritative list of the Matter device type IDs the Home app accepts? The public support article describes categories in prose (lights, plugs, switches, thermostats, sensors...), but gives no device type IDs, so there is no way to check a design against it before building. I would like to design to the list rather than discover at pairing time that Home will not create my accessory. A related composition question: my controller is a single accessory with seven independently controlled valve endpoints, and endpoints exist only for valves the installer has enabled. When a valve is disabled and its endpoint disappears, Home keeps showing it until the accessory is removed and re-added. Is there a supported way to make Home re-read a device's composition in place - and for seven valves, does Apple prefer one accessory with seven endpoints, or a Bridge (0x000E) exposing seven accessories? Setup: Matter over Wi-Fi (2.4 GHz), esp-matter / connectedhomeip, test VID 0xFFF1 during development. iOS 17 and 18, iPhone 12, Home hub present. Happy to provide the full endpoint and cluster composition or logs if useful.

Hello, I'm developing Verde, a Matter irrigation system (soil moisture sensors, a hub, and a multi-valve irrigation controller). My question is about Matter device type support in Apple Home, not about hardware or commissioning. The failure: when an endpoint declares certain device type IDs, Home refuses to create the accessory and reports that the device is not supported. Change nothing but the device type ID, and the same accessory is created and works. So this is Home rejecting a device type, not a pairing, discovery or hardware problem. Water Valve — 0x0042 Device type 0x0042 Water Valve (Matter 1.3) Cluster 0x0081 Valve Configuration and Control Result in Apple Home Not supported — accessory is not created Result on other Matter controllers Created and controllable Substitute we now ship: device type 0x010A On/Off Plug-in Unit with cluster 0x0006 On/Off. Accepted by Home immediately, and toggling the endpoint operates the valve. The substitution works but is a misrepresentation: the user sees a row of "plugs" for a device that controls irrigation valves. There are no valve semantics, no open/close vocabulary, and nothing tells Home — or an automation the user writes — that switching this on releases water. Soil Sensor — Matter 1.5 Device type Soil Sensor / soil measurement, introduced in Matter 1.5 Result in Apple Home Not available Substitute we now ship: 0x0307 Humidity Sensor with cluster 0x0405 Relative Humidity Measurement, because that is what Home renders. Soil moisture therefore appears in Home as air humidity — conceptually wrong, wrong icon, and it contaminates any humidity-based automation the user has set up. The CSA positioned the 1.5 soil types explicitly for irrigation use with Matter water valves, so the two gaps above are the same gap for us. Multi-endpoint valve controller — composition Our controller is a single accessory exposing seven independently controlled valve endpoints (endpoint IDs 1–7). Endpoints exist only for valves the installer has enabled, so the composition can legitimately change after a configuration change. Two questions on this: Changed composition isn't picked up. When an endpoint is removed, Home keeps showing it until the accessory is deleted and re-added. Is there a supported way to make Home re-read a device's composition in place? Preferred shape. For seven valves, does Apple prefer one accessory with seven endpoints, or a Bridge (0x000E) exposing seven separate accessories? 4. What we're asking Is Water Valve 0x0042 planned for Apple Home, and is there a timeframe we can plan to? Is the Matter 1.5 Soil Sensor device type planned? Until then, is substituting On/Off Plug-in Unit for a valve, and Humidity Sensor for soil moisture, acceptable to Apple? We'd rather follow your guidance than ship a misrepresentation we later have to undo — and than have a valve presented to users and automations as a plug. For a multi-endpoint valve controller: guidance on composition, and on refreshing a changed endpoint list in Home. Is there an authoritative, current list of the Matter device type IDs Apple Home accepts, more specific than the general support article? Designing against it is far cheaper than building an accessory and discovering Home will not create it.

hi folks, im working on an application for downlink time of difference arrival. im using a DWM 3000 ultrawide band board to send DLTDoA pulses. i have followed the protocol in the FiRA 2.0 spec, and properly implemented the swift api, but im getting issues with the iPhones UWB radio chip(rose). i have no issues if i use another board as a receiver instead of my phone. specifically, im using the SP1 frame format, and am getting errors at the PHR stage. to my knowledge, the 0x18 SECDED error means that the PHR header could not be properly decoded. does anyone have advice on how to debug or next steps? its difficult since i cant get access to lower level logs of the chip to actually see whats going wrong. thanks.

Hi everyone. I've been at this for about 9 hours already but I just needed to ask this somewhere where somebody with experience might pop up. As usual, I left my iPhone backing up its photos and videos to a Photos library in an APFS 1TB Western Digital HDD drive. Today I woke up with an error window saying that the drive is corrupted in some way. Here are the steps that followed: 1- Tried to mount the drive in Disk Utility -> doesn't work 2- Ran first aid in Disk Utility -> doesn't work 3- fsck_apfs with multiple different options in Terminal -> doesn't work 4- Used ddrescue to clone the corrupted hard drive to a 2TB drive -> worked fine with no unreadable/corrupt sectors. 5- I downloaded the WD Drive Utilities and the quick drive test passed -> no error. 6- Called Apple Support (shout out to Imelda for being incredibly nice and experienced) but it seems the only solution is to erase the drive or contact WD. This is not an option for me since it's got my photos library from the last decade. I had a backup in another drive but it's very out of date. I just bought a NAS to transfer it all to a safer place, so the timing for this to happen is the worst case. 7- I noticed that in the Library folder in my Mac, I got a 1.3GB Photos library with many thumbnails of the pictures I was importing last night. The filename is Syndication.photoslibrary. Here's the log from fsck_apfs fsck_apfs Log After all the steps I took, it seems to me that: A- The hard drive is completely fine hardware-wise, evidenced by points 4 and 5. So I would assume that WD can't really help me recover my data. B- The "only" thing that's broken is the apfs_root. So my question is if there is some sort of way to reconstruct the root tree somehow. I would assume that this structure is only partially broken and that there are addresses that it should point to properly, that can support some sort of more involved recovery process. I tried reading the APFS documentation but I'm currently very emotionally distressed at the potential loss of my data that I can't parse that information right now. Does anybody have any clue if something can be done about this? Some sort of script? Literally anything. Many thanks in advance. Best, Andres PS: Please let me know if this forum is the appropriate place for this question. I'm mostly posting here since I feel this is a more advanced subject and I need all the help I can get.

Hello Apple Home / Matter Engineering Team, We are developing a Matter-enabled indoor air quality monitoring device that includes radon measurement. The device can be successfully commissioned into Apple Home, and Apple Home correctly recognizes and displays the overall Air Quality information. However, the actual Radon concentration measurement is not displayed in the Apple Home app. We would like to clarify whether this is expected behavior in the current Apple Home implementation. Specifically: Does Apple Home currently support displaying the Matter Radon Concentration Measurement separately from the overall Air Quality value? If supported, which Matter cluster/attributes and device configuration does Apple Home expect? If our device correctly exposes the applicable Matter Radon Concentration Measurement cluster, should Apple Home display the measured value in the accessory UI? If Apple Home currently does not expose the Radon concentration in its UI, is there a recommended implementation for Matter accessory manufacturers? Commissioning and other Matter functionality are working correctly. We are specifically trying to determine whether this behavior is an Apple Home UI/support limitation or whether our Matter implementation needs to be modified. We can provide our Matter specification version, device type, endpoint/cluster configuration, screenshots, logs, and certification information if needed. Thank you, JS

hi folks, hobbyist here working on developing with DL-TDoA on ios. i was trying to find the DL-TDoA interoperability spec online at https://developer.apple.com/nearby-interaction/. but its missing from the latest one for iOS 27 preview. (R6) when do we expect to have access to an interoperability spec? thanks.

Environment iOS: 26.6 Xcode: 26.3 I’m encountering an issue migrating legacy Bluetooth peripherals using ASMigrationDisplayItem from AccessorySetupKit. I have verified that both bluetoothServiceUUID and peripheralIdentifier are correct. On the first‑time use of ASMigrationDisplayItem, the peripheral migrates successfully and shows up in iOS Settings. After deleting the app, the accessory authorization list is cleared. Upon reinstalling the app, migration attempts do nothing — no device appears in Settings. Occasionally I get this error: Error Domain=ASErrorDomain Code=500 "(null)" Picker already activated All subsequent migration attempts keep failing. The migration only works again after a full phone reboot. My hypothesis: When AccessorySetupKit is first used, a system daemon is spawned to handle AccessorySetupKit‑related tasks. After app deletion, this daemon is not properly terminated. Reinstalling the app later causes interference that breaks ASMigrationDisplayItem. This issue has blocked my development for a long time. I found a similar unresolved thread on Apple Developer Forums: https://developer.apple.com/forums/thread/839512 Questions: Is there any workaround I can adopt right now? Could Apple please investigate and fix this bug?