Post

Replies

Boosts

Views

Activity

ASMigrationDisplayItem migration fails after app reinstall, ASErrorDomain 500 "Picker already activated" until phone reboot
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?
2
0
295
Sep ’26
AccessorySetupKit + CBCentralManager migration & scanning regression after accessory picker authorization
Hello everyone: Description Environment iOS: 26.5 Xcode: 26.3 App version: 1.0 / 2.0 Scenario background App communicates with unpaired Bluetooth peripherals. App v1.0: Use only CBCentralManager for scanning and connecting peripherals(D2, D3…). No AccessorySetupKit involved. App v2.0: Hybrid approach: ASAccessorySession + CBCentralManager. CBCentralManager is initialized after ASAccessorySession becomes active. Info.plist configuration <key>NSAccessorySetupKitSupports</key> <array> <string>Bluetooth</string> </array> <key>NSAccessorySetupBluetoothServices</key> <array> <string>xxxx</string> </array> <key>NSAccessorySetupBluetoothNames</key> <array> <string>MyDevice</string> </array> Observed test behavior For users upgrading from v1.0 to v2.0: ASAccessorySession.accessories returns empty. Old CBCentralManager instance(C1) works fine: can scan and connect peripherals D1, D2, D3. Calling showPicker() while C1 is alive throws error: Error Domain=ASErrorDomain Code=550 Destroy C1 before invoking showPicker(). After user authorizes new accessory D1 via picker, create a brand‑new CBCentralManager instance(C2). Regression: C2 can only scan & communicate with authorized D1. Peripherals D2, D3 can no longer be discovered. Questions In v1.0 we stored CBPeripheral.identifier for unpaired devices D2, D3. How to implement seamless migration after upgrading to v2.0? After user authorizes D1 in v2.0, is there a callback trigger when D2 / D3 come into proximity? Can we auto‑launch showPicker() on that trigger? AccessorySetupKit workflow feels restrictive. Is multi‑device one‑tap authorization planned for peripherals like D2, D3 which may not be nearby at authorization time?
3
0
532
Aug ’26
BLE Broadcast Cannot Relaunch User-Force-Quit App via AccessorySetupKit (iOS 26+)
Hi everyone, I am trying to wake up/relaunch an app that was force-quit by the user via a BLE advertisement packet. According to TN3115 ("App Force Quit by the user" section), an app generally cannot be woken up after a user force-quit. However, Note 5 states that starting in iOS 26, an app authorized via AccessorySetupKit can indeed be relaunched. Environment iOS Version: iOS 26.5 (Note: revised to standard versioning) Xcode Version: Xcode 26.3 Implementation Details 1. Info.plist Configuration <key>NSBluetoothAlwaysUsageDescription</key> <string>We need Bluetooth to discover and connect to your accessory.</string> <key>UIBackgroundModes</key> <array> <string>bluetooth-central</string> </array> <key>NSAccessorySetupKitSupports</key> <array> <string>Bluetooth</string> </array> <key>NSAccessorySetupBluetoothServices</key> <array> <string>0000XXXX-0000-1000-8000-00805F9B34FB</string> </array> <key>NSAccessorySetupBluetoothNames</key> <array> <string>MyDeviceName</string> </array> 2. Workflow & Code Steps Initialize ASAccessorySession and call activate(). Pair/authorize the BLE peripheral using ASPickerDisplayItem. Initialize CBCentralManager with state restoration: let options: [String: Any] = [ CBCentralManagerOptionRestoreIdentifierKey: restoreIdentifier, CBCentralManagerOptionShowPowerAlertKey: true ] centralManager = CBCentralManager(delegate: self, queue: nil, options: options) Start scanning: let scanOptions = [CBCentralManagerScanOptionAllowDuplicatesKey: true] centralManager?.scanForPeripherals(withServices: serviceUUIDs, options: scanOptions) Handle state restoration: func centralManager(_ central: CBCentralManager, willRestoreState dict: [String : Any]) { if let services = dict[CBCentralManagerRestoredStateScanServicesKey] as? [CBUUID], let options = dict[CBCentralManagerRestoredStateScanOptionsKey] as? [String : Any] { central.scanForPeripherals(withServices: services, options: options) } } Receive discovery callback: func centralManager(_ central: CBCentralManager, didDiscover peripheral: CBPeripheral, advertisementData: [String : Any], rssi RSSI: NSNumber) { if peripheral.name == "MyDeviceName" { // Send a local notification } } Current Behavior Foreground: Local notification triggers as expected. Background: Local notification triggers as expected. Force Quit by User: No notification is received / App is not relaunched. Issue The app fails to relaunch when force-quit by the user, which seems to contradict the behavior described in TN3115 Note 5. Is there a specific configuration, entitlement, or additional CBCentralManager setup required to allow BLE advertisements to relaunch the app after a user force-quit via AccessorySetupKit? Any guidance would be greatly appreciated!
3
0
787
Aug ’26
App Review Rejection for Guidelines 3.1.1
Hi all, Our app has been rejected several times without any clear explanation of what we need to do. The latest rejection reason is as follows: The app accesses digital content purchased outside the app, such as Tracker data plans, but that content isn't available to purchase using in-app purchase. Apps must use in-app purchase to unlock features or functionality within the app. Apps on the United States storefront may include buttons, external links, or other calls to action to direct users to payment mechanisms other than in-app purchase. Next Steps The paid digital content, services, or subscriptions included in or accessed by your app must be available for purchase in the app using only in-app purchase. As noted above, apps on the United States storefront may include buttons, external links, or other calls to action to payment mechanisms other than in-app purchase. To learn more about the recent changes to the App Review Guidelines, see the News post on Apple Developer. We plan to implement payments outside of IAP, and here is the business scenario of our app: Our app is designed to control an external hardware device. However, the device has a built-in SIM card, so to use the device, a data plan must be activated for it to function properly. These data plans are used to pay mobile network operators. Different data plans incur different fees and activate different hardware features of the device. In addition, since the hardware device will only be linked to the app after successful activation, the control buttons in the app for managing the hardware remain disabled until activation is complete. Therefore, we believe using non-IAP payments is justified under Guideline 3.1.4 – Hardware-Specific Content: I have repeatedly explained these points to the App Review team, but they still rejected the submission. I have asked multiple times which specific details are considered violations of 3.1.1, but they have not provided any concrete explanation. They also have not clarified whether 3.1.4 is deemed inapplicable in our case. Therefore, I am reaching out here for help. Thank you very much.
2
0
397
Jul ’25
ASMigrationDisplayItem migration fails after app reinstall, ASErrorDomain 500 "Picker already activated" until phone reboot
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?
Replies
2
Boosts
0
Views
295
Activity
Sep ’26
AccessorySetupKit + CBCentralManager migration & scanning regression after accessory picker authorization
Hello everyone: Description Environment iOS: 26.5 Xcode: 26.3 App version: 1.0 / 2.0 Scenario background App communicates with unpaired Bluetooth peripherals. App v1.0: Use only CBCentralManager for scanning and connecting peripherals(D2, D3…). No AccessorySetupKit involved. App v2.0: Hybrid approach: ASAccessorySession + CBCentralManager. CBCentralManager is initialized after ASAccessorySession becomes active. Info.plist configuration <key>NSAccessorySetupKitSupports</key> <array> <string>Bluetooth</string> </array> <key>NSAccessorySetupBluetoothServices</key> <array> <string>xxxx</string> </array> <key>NSAccessorySetupBluetoothNames</key> <array> <string>MyDevice</string> </array> Observed test behavior For users upgrading from v1.0 to v2.0: ASAccessorySession.accessories returns empty. Old CBCentralManager instance(C1) works fine: can scan and connect peripherals D1, D2, D3. Calling showPicker() while C1 is alive throws error: Error Domain=ASErrorDomain Code=550 Destroy C1 before invoking showPicker(). After user authorizes new accessory D1 via picker, create a brand‑new CBCentralManager instance(C2). Regression: C2 can only scan & communicate with authorized D1. Peripherals D2, D3 can no longer be discovered. Questions In v1.0 we stored CBPeripheral.identifier for unpaired devices D2, D3. How to implement seamless migration after upgrading to v2.0? After user authorizes D1 in v2.0, is there a callback trigger when D2 / D3 come into proximity? Can we auto‑launch showPicker() on that trigger? AccessorySetupKit workflow feels restrictive. Is multi‑device one‑tap authorization planned for peripherals like D2, D3 which may not be nearby at authorization time?
Replies
3
Boosts
0
Views
532
Activity
Aug ’26
BLE Broadcast Cannot Relaunch User-Force-Quit App via AccessorySetupKit (iOS 26+)
Hi everyone, I am trying to wake up/relaunch an app that was force-quit by the user via a BLE advertisement packet. According to TN3115 ("App Force Quit by the user" section), an app generally cannot be woken up after a user force-quit. However, Note 5 states that starting in iOS 26, an app authorized via AccessorySetupKit can indeed be relaunched. Environment iOS Version: iOS 26.5 (Note: revised to standard versioning) Xcode Version: Xcode 26.3 Implementation Details 1. Info.plist Configuration <key>NSBluetoothAlwaysUsageDescription</key> <string>We need Bluetooth to discover and connect to your accessory.</string> <key>UIBackgroundModes</key> <array> <string>bluetooth-central</string> </array> <key>NSAccessorySetupKitSupports</key> <array> <string>Bluetooth</string> </array> <key>NSAccessorySetupBluetoothServices</key> <array> <string>0000XXXX-0000-1000-8000-00805F9B34FB</string> </array> <key>NSAccessorySetupBluetoothNames</key> <array> <string>MyDeviceName</string> </array> 2. Workflow & Code Steps Initialize ASAccessorySession and call activate(). Pair/authorize the BLE peripheral using ASPickerDisplayItem. Initialize CBCentralManager with state restoration: let options: [String: Any] = [ CBCentralManagerOptionRestoreIdentifierKey: restoreIdentifier, CBCentralManagerOptionShowPowerAlertKey: true ] centralManager = CBCentralManager(delegate: self, queue: nil, options: options) Start scanning: let scanOptions = [CBCentralManagerScanOptionAllowDuplicatesKey: true] centralManager?.scanForPeripherals(withServices: serviceUUIDs, options: scanOptions) Handle state restoration: func centralManager(_ central: CBCentralManager, willRestoreState dict: [String : Any]) { if let services = dict[CBCentralManagerRestoredStateScanServicesKey] as? [CBUUID], let options = dict[CBCentralManagerRestoredStateScanOptionsKey] as? [String : Any] { central.scanForPeripherals(withServices: services, options: options) } } Receive discovery callback: func centralManager(_ central: CBCentralManager, didDiscover peripheral: CBPeripheral, advertisementData: [String : Any], rssi RSSI: NSNumber) { if peripheral.name == "MyDeviceName" { // Send a local notification } } Current Behavior Foreground: Local notification triggers as expected. Background: Local notification triggers as expected. Force Quit by User: No notification is received / App is not relaunched. Issue The app fails to relaunch when force-quit by the user, which seems to contradict the behavior described in TN3115 Note 5. Is there a specific configuration, entitlement, or additional CBCentralManager setup required to allow BLE advertisements to relaunch the app after a user force-quit via AccessorySetupKit? Any guidance would be greatly appreciated!
Replies
3
Boosts
0
Views
787
Activity
Aug ’26
App Review Rejection for Guidelines 3.1.1
Hi all, Our app has been rejected several times without any clear explanation of what we need to do. The latest rejection reason is as follows: The app accesses digital content purchased outside the app, such as Tracker data plans, but that content isn't available to purchase using in-app purchase. Apps must use in-app purchase to unlock features or functionality within the app. Apps on the United States storefront may include buttons, external links, or other calls to action to direct users to payment mechanisms other than in-app purchase. Next Steps The paid digital content, services, or subscriptions included in or accessed by your app must be available for purchase in the app using only in-app purchase. As noted above, apps on the United States storefront may include buttons, external links, or other calls to action to payment mechanisms other than in-app purchase. To learn more about the recent changes to the App Review Guidelines, see the News post on Apple Developer. We plan to implement payments outside of IAP, and here is the business scenario of our app: Our app is designed to control an external hardware device. However, the device has a built-in SIM card, so to use the device, a data plan must be activated for it to function properly. These data plans are used to pay mobile network operators. Different data plans incur different fees and activate different hardware features of the device. In addition, since the hardware device will only be linked to the app after successful activation, the control buttons in the app for managing the hardware remain disabled until activation is complete. Therefore, we believe using non-IAP payments is justified under Guideline 3.1.4 – Hardware-Specific Content: I have repeatedly explained these points to the App Review team, but they still rejected the submission. I have asked multiple times which specific details are considered violations of 3.1.1, but they have not provided any concrete explanation. They also have not clarified whether 3.1.4 is deemed inapplicable in our case. Therefore, I am reaching out here for help. Thank you very much.
Replies
2
Boosts
0
Views
397
Activity
Jul ’25