We are currently planning to develop a third‑party hardware accessory that supports Wi‑Fi Aware using AccessorySetupKit on iOS, based on the official documentation: https://developer.apple.com/documentation/accessorysetupkit/ Before finalizing our hardware and firmware design, we would like to better understand the real‑world behavior and user experience of Wi‑Fi Aware in actual third‑party accessories. Specifically, we would like to ask: Existing Third‑Party Hardware Are there any commercially available third‑party accessories (not Apple products) that already support Wi‑Fi Aware via AccessorySetupKit? If so, are there any public examples, reference designs, or recommended products we can purchase to observe the real onboarding, discovery, and pairing experience? Reference or Evaluation Hardware Does Apple provide any reference hardware, evaluation kits, or recommended vendor solutions (for example, based on common Wi‑Fi chipsets) that are known to work well with Wi‑Fi Aware on iOS? Are there specific Wi‑Fi chipset vendors that have validated interoperability with AccessorySetupKit? Practical Behavior and Limitations In real usage, what are the typical discovery latency, reliability, and background/foreground behavior developers should expect? Are there known limitations or best practices when designing hardware that relies on Wi‑Fi Aware for initial accessory discovery and setup? Our goal is to evaluate the feasibility and user experience of Wi‑Fi Aware for third‑party accessories by testing against existing implementations or recommended hardware, before investing heavily in custom hardware development. Any guidance, examples, or pointers to existing accessories or partners would be greatly appreciated.

I want to add matter device to my own fabric,not same as to homeKit in Home APP I implemented a demo which add a matter support extension, and it can success, but I use MTRDeviceController to commission,it go wrong, blow is the log Couldn't read values in CFPrefsPlistSource<0x1062ec100> (Domain: group.wxx.MatterTest, User: kCFPreferencesAnyUser, ByHost: Yes, Container: (null), Contents Need Refresh: Yes): Using kCFPreferencesAnyUser with a container is only allowed for System Containers, detaching from cfprefsd <<5 [E:46634i S:0 M:188511265] (U) Msg Retransmission to 0:0000000000000000 failure (max retries:4) PASESession timed out while waiting for a response from the peer. Expected message type was 33 controller(:commissioningSessionEstablishmentDone:) error = nil Error on commissioning step 'AttestationVerification': 'src/controller/CHIPDeviceController.cpp:1288: CHIP Error 0x000000AC: Internal error' Failed verifying attestation information. Now checking DAC chain revoked status. Failed in verifying 'Attestation Information' command received from the device: err 101. Look at AttestationVerificationResult enum to understand the errors Error on commissioning step 'AttestationRevocationCheck': 'src/controller/CHIPDeviceController.cpp:1337: CHIP Error 0x000000AC: Internal error' Failed to send Solitary ack for MessageCounter:265529558 on exchange 46643i:src/messaging/ExchangeContext.cpp:99: CHIP Error 0x00000002: Connection aborted Creating NSError from src/controller/CHIPDeviceController.cpp:1337: CHIP Error 0x000000AC: Internal error (context: (null)) controller(:commissioningComplete:nodeID:metrics:) error = Optional(Error Domain=MTRErrorDomain Code=1 "General error: 172" UserInfo={NSLocalizedDescription=General error: 172, errorCode=172}) Is there any suggestion to me with the issue

Hello Apple Forums, We are developing an iOS application that connects to a custom BLE accessory and sends control commands to it. Our system architecture is as follows: A separate hardware device collects data and sends it to our backend server via Wi-Fi. The backend evaluates state changes and determines when the BLE accessory should update its display. The iOS app acts purely as a BLE command executor for this accessory. Our goal is to: Maintain a BLE connection with the accessory while the app is in the background. Receive state-change events from our backend server. Upon receiving such events, send a BLE command to the accessory to update its state. We understand that iOS does not allow arbitrary background execution. We would like to confirm whether there is any supported mechanism, entitlement, or program that allows: Long-running background execution for BLE control, or Server-originated events (other than APNs) to trigger background BLE actions. If this is not supported, we would appreciate confirmation that APNs (silent push) is the only supported way to trigger such background BLE actions, or guidance on any recommended alternative architectures. Thank you for your guidance.

I am developing a standard UAC 2.0 device and encountered an issue where the channel names do not update according to the iChannelNames field in the Class Specific AS Interface Descriptor when switching between different channel counts. For example: AS1 (6 channels) is configured with the following channel names: ADAT 1, ADAT 2, ADAT 3, ADAT 4, HP L, HP R AS2 (4 channels) is configured with: ADAT 1, ADAT 2, HP L, HP R However, when switching from AS1 (6 channels) to AS2 (4 channels), the channel names displayed in Audio MIDI Setup do not reflect the change as expected. The actual result is: ADAT 1, ADAT 2, ADAT 3, ADAT 4 The system simply hides the last two channels; the names of the remaining channels are not updated. Initial Topology My original topology was as follows: Later, I discovered that macOS uses the iChannelNames field from the Input Terminal to display channel names. Therefore, I modified the USB device descriptors and updated the topology to the following: To distinguish the channel names for different channel counts, each Input Terminal is assigned a unique iChannelNames value. This method worked perfectly on macOS 15. However, after updating to macOS 26, this topology no longer displays the correct channel names. Question On macOS 26, what is the correct method to ensure that the channel names update dynamically when switching between different audio channel configurations?

I am developing a standard UAC 2.0 device and encountered an issue where the channel names do not update according to the iChannelNames field in the Class Specific AS Interface Descriptor when switching between different channel counts. For example: AS1 (6 channels) is configured with the following channel names: ADAT 1, ADAT 2, ADAT 3, ADAT 4, HP L, HP R AS2 (4 channels) is configured with: ADAT 1, ADAT 2, HP L, HP R However, when switching from AS1 (6 channels) to AS2 (4 channels), the channel names displayed in Audio MIDI Setup do not reflect the change as expected. The actual result is: ADAT 1, ADAT 2, ADAT 3, ADAT 4 The system simply hides the last two channels; the names of the remaining channels are not updated. Initial Topology My original topology was as follows: Later, I discovered that macOS uses the iChannelNames field from the Input Terminal to display channel names. Therefore, I modified the USB device descriptors and updated the topology to the following: To distinguish the channel names for different channel counts, each Input Terminal is assigned a unique iChannelNames value. This method worked perfectly on macOS 15. However, after updating to macOS 26, this topology no longer displays the correct channel names. Question On macOS 26, what is the correct method to ensure that the channel names update dynamically when switching between different audio channel configurations?

Hello, I am an individual developer working on a macOS application using SwiftUI and RealityKit. I would like to understand the feasibility of face-related tracking on macOS when using an external USB camera, compared to iOS/iPadOS. Specifically: • Does macOS provide an ARKit Face Tracking–equivalent API (e.g., real-time facial expressions, gaze direction, depth)? • If not, is it common to rely on Vision / AVFoundation as alternatives for: • Facial expression coefficients • Gaze estimation • Depth approximation • In an environment without dedicated sensors such as TrueDepth, is it correct to assume that accurate depth data and high-fidelity blend shape extraction are realistically difficult? Any clarification on official limitations, recommended alternatives, or relevant documentation would be greatly appreciated. Thank you.

Hi all, I’m facing a device-specific issue in a live production iOS app distributed privately via the App Store . The app crashes immediately after login on one client’s iPhone, while the same account works fine on other devices. There’s no crash log generated in Analytics, and the app just pops to the home screen. Environment: App: Production app on App Store iOS version: 26.3 Devices: Only one device exhibits the crash; other iPhones work fine Login flow: App calls an API and writes the response to a local SQLite database immediately after login Distribution: App Store (Privately). The user is install via the redemption codes. Observations: All users on the problematic device crash immediately after login. The crash does not occur on any other devices, including the same iOS version. The client had already uninstalled and reinstalled the app via App Store cloud download, but the crash persisted. No crash log appears in Analytics or Xcode (process just terminates). Device restart had not been attempted before reinstall. App does not use Keychain tokens; local DB is only SQLite in the app sandbox. Hypotheses so far: Corrupted binary or cached app installation on that device SQLite database corruption or write failure Device-specific OS/environment issue (temp files, file locks, provisioning) iOS watchdog silently terminating the app during post-login DB write Language / region differences unlikely Questions: Is it possible for a device to retain a corrupted app binary or cached installation even after uninstall + cloud download reinstall from the App Store? Can uninstalling, restarting the device, and reinstalling guarantee a fresh binary and sandbox? Are there any known iOS behaviors where a local SQLite write could trigger an instant crash on one device only, without generating crash logs? Any other suggestions for diagnosing this device-specific post-login crash in a live production environment? Thanks in advance for any guidance — this issue is affecting a client’s live usage, and we’d like to understand the root cause and best way to resolve it safely.

Hello Apple Developer Technical Support Team, I’m working on an iOS banking/security SDK and we’re trying to match an Android feature that reads payment cards via NFC (EMV). On Android, this is implemented using an NFC scanning screen (e.g., “NfcScanActivity”) that can read EMV data from contactless credit/debit cards. Could you please clarify the current iOS capabilities and App Store policy around this? On iOS, is it currently possible for a third-party App Store app to read contactless credit/debit cards using Core NFC (i.e., accessing EMV application data/AIDs from payment cards)? If this is possible, what are the supported APIs/frameworks and any entitlement requirements (if applicable)? If this is not possible for App Store apps, could you recommend the closest acceptable alternatives for achieving a similar user outcome? For example: Using Apple Pay / PassKit flows for payment-related experiences Card scanning alternatives (camera-based OCR) for capturing card details (if allowed) Using an external certified card reader accessory (MFi) and required approach/entitlements Any other Apple-recommended approach for “card verification / identification” without reading EMV NFC data Our goal is not to bypass security restrictions, but to provide a compliant solution on iOS comparable to Android’s NFC-based card reading, or to adopt an Apple-approved alternative if direct EMV reading is not supported. If helpful, I can share a brief technical summary of the Android behavior and the exact data we need to obtain (e.g., whether it’s card presence verification vs. reading specific EMV tags). Thank you for your guidance. Best regards, Imran

Hello Apple Developer Technical Support Team, I’m working on an iOS banking/security SDK and we’re trying to match an Android feature that reads payment cards via NFC (EMV). On Android, this is implemented using an NFC scanning screen (e.g., “NfcScanActivity”) that can read EMV data from contactless credit/debit cards. Could you please clarify the current iOS capabilities and App Store policy around this? On iOS, is it currently possible for a third-party App Store app to read contactless credit/debit cards using Core NFC (i.e., accessing EMV application data/AIDs from payment cards)? If this is possible, what are the supported APIs/frameworks and any entitlement requirements (if applicable)? If this is not possible for App Store apps, could you recommend the closest acceptable alternatives for achieving a similar user outcome? For example: Using Apple Pay / PassKit flows for payment-related experiences Card scanning alternatives (camera-based OCR) for capturing card details (if allowed) Using an external certified card reader accessory (MFi) and required approach/entitlements Any other Apple-recommended approach for “card verification / identification” without reading EMV NFC data Our goal is not to bypass security restrictions, but to provide a compliant solution on iOS comparable to Android’s NFC-based card reading, or to adopt an Apple-approved alternative if direct EMV reading is not supported. If helpful, I can share a brief technical summary of the Android behavior and the exact data we need to obtain (e.g., whether it’s card presence verification vs. reading specific EMV tags). Thank you for your guidance. Best regards, Anis

** Every time after I downloaded an app this window opens and never closes how to close it?**

My audio and MIDI sequencer application consumes about 600 % of CPU power with 10 different instruments during playback. While idle approximately 100%. What is the maximum of CPU power that an application can consume? Are there any limits and could they be modified? I am asking because if I add more instruments the real-time behaviour gets bad at 700 % of CPU power. I have got following HW: MacBook Pro 14-inch, Nov 2024 Apple M4 Pro 24 GB

Hello, Since updating to iOS 18.3.1, the rear camera on my iPhone 13 Pro Max has not been functioning properly. The Camera app displays a black screen and becomes unresponsive. I analyzed the crash logs and found that the issue is related to the cameracaptured process, which handles image and video capture on iOS. Here are the key details from the crash log: 📌 Memory Error: "Address size fault" 📌 Impacted Thread: com.apple.coremedia.capturesession.workerQueue The "Address size fault" error suggests a memory access issue, likely causing the cameracaptured process to crash. This could be due to a bug in the video capture thread management introduced in the update. What do you think? name":"cameracaptured","timestamp":"2025-03-12 10:37:31.00 +0100","app_version":"1.0","slice_uuid":"cc45251e-92fc-329d-a3e9-d1c8c019e59e","build_version":"587.82.13","platform":2,"share_with_app_devs":0,"is_first_party":1,"bug_type":"309","os_version":"iPhone OS 18.3.2 (22D82)","roots_installed":0,"incident_id":"E97F5B3A-345F-42A6-97E8-28D175C8C5A9","name":"cameracaptured"} { "uptime" : 820, "procRole" : "Unspecified", "version" : 2, "userID" : 501, "deployVersion" : 210, "modelCode" : "iPhone14,3", "coalitionID" : 75, "osVersion" : { "isEmbedded" : true, "train" : "iPhone OS 18.3.2", "releaseType" : "User", "build" : "22D82" }, "captureTime" : "2025-03-12 10:37:30.1093 +0100", "codeSigningMonitor" : 2, "incident" : "E97F5B3A-345F-42A6-97E8-28D175C8C5A9", "pid" : 68, "translated" : false, "cpuType" : "ARM-64", "roots_installed" : 0, "bug_type" : "309", "procLaunch" : "2025-03-12 10:04:03.7137 +0100", "procStartAbsTime" : 225890551, "procExitAbsTime" : 19918403953, "procName" : "cameracaptured", "procPath" : "/usr/libexec/cameracaptured", "bundleInfo" : {"CFBundleVersion":"587.82.13","CFBundleShortVersionString":"1.0"}, "parentProc" : "launchd", "parentPid" : 1, "coalitionName" : "com.apple.cameracaptured", "crashReporterKey" : "137125638e43c62173057ae3dc983089b1f083cf", "appleIntelligenceStatus" : {"state":"unavailable","reasons":["siriAssetIsNotReady","selectedLanguageIneligible","selectedLanguageDoesNotMatchSelectedSiriLanguage","notOptedIn","deviceNotCapable","selectedSiriLanguageIneligible","countryLocationIneligible","unableToFetchAvailability","assetIsNotReady"]}, "wasUnlockedSinceBoot" : 1, "isLocked" : 0, "throttleTimeout" : 5, "codeSigningID" : "com.apple.cameracaptured", "codeSigningTeamID" : "", "codeSigningFlags" : 570434305, "codeSigningValidationCategory" : 1, "codeSigningTrustLevel" : 7, "instructionByteStream" : {"beforePC":"BgCA0hUnFpTgAxOqIaSGUiFLu3KJJBaU4AMTqqfYDZTozSGQAFEC+Q==","atPC":"IAAg1KiDW/jJkB+QKd1B+SkBQPk/AQjrAQEAVP17Uqn0T1Gp9ldQqQ=="}, "bootSessionUUID" : "33672FC1-99EC-48FC-8BCD-2B96DF170CC3", "basebandVersion" : "4.20.03", "exception" : {"codes":"0x0000000000000001, 0x00000001a93909f0","rawCodes":[1,7134054896],"type":"EXC_BREAKPOINT","signal":"SIGTRAP"}, "termination" : {"flags":0,"code":5,"namespace":"SIGNAL","indicator":"Trace/BPT trap: 5","byProc":"exc handler","byPid":68}, "os_fault" : {"process":"cameracaptured"}, "faultingThread" : 4, "threads" : [{"id":1699,"threadState":{"x":[{"value":268451845},{"value":21592279046},{"value":8589934592},{"value":28600187224064},{"value":0},{"value":28600187224064},{"value":2},{"value":4294967295},{"value":18446744073709550527},{"value":2},{"value":0},{"value":0},{"value":0},{"value":6659},{"value":0},{"value":0},{"value":18446744073709551569},{"value":6677212688,"symbolLocation":56,"symbol":"clock_gettime"},{"value":0},{"value":4294967295},{"value":2},{"value":28600187224064},{"value":0},{"value":28600187224064},{"value":6126594600},{"value":8589934592},{"value":21592279046},{"value":21592279046},{"value":4412409862}],"flavor":"ARM_THREAD_STATE64","lr":{"value":7911718552},"cpsr":{"value":4096},"fp":{"value":6126594448},"sp":{"value":6126594368},"esr":{"value":1442840704,"description":" Address size fault"},"pc":{"value":7911704456},pc":{"value":7911704456},"far":{"value":0}},"queue":"com.apple.main-thread","frames":[{"imageOffset":6024,"symbol":"mach_msg2_trap","symbolLocation":8,"imageIndex":10},{"imageOffset":20120,"symbol":"mach_msg2_internal","symbolLocation":80,"imageIndex":10},{"imageOffset":19888,"symbol":"mach_msg_overwrite","symbolLocation":424,"imageIndex":10},{"imageOffset":19452,"symbol":"mach_msg","symbolL

Ever since the last update i have issues with my camera app. Sometimes when I open the app the forward facing cameras don’t work and it’s just a Black screen. I also get a warning that I may not have genuine iPhone parts installed. I have to reboot the phone every time just to have it app function again. It’s annoying. Please fix this. I never had any issues with the camera or its app up until after the update.

We just updated our ATS to the latest 8.3.0 version and tried to run the iAP2 Session Test via BPA100 Bluetooth Analyzer and we are experiencing this EXC_BAD_INSTRUCTION. This same test still seems to work on ATS version 6. Please advise. Process: ATS [1782] Path: /private/var/folders/*/ATS.app/Contents/MacOS/ATS Identifier: com.apple.ATSMacApp Version: 8.3.0 (1826) Build Info: ATSMacApp-1826000000000000~2 (1A613) Code Type: X86-64 (Native) Parent Process: launchd [1] User ID: 501 Date/Time: 2025-01-27 11:05:21.1334 -0800 OS Version: macOS 15.2 (24C101) Report Version: 12 Bridge OS Version: 9.2 (22P2093) Anonymous UUID: 098E2BB5-CB98-CA1C-CEFE-188AF6EFE8CF Time Awake Since Boot: 9700 seconds System Integrity Protection: enabled Crashed Thread: 2 com.apple.ATSMacApp.FrontlineFrameworkInterface Exception Type: EXC_BAD_INSTRUCTION (SIGILL) Exception Codes: 0x0000000000000001, 0x0000000000000000 Termination Reason: Namespace SIGNAL, Code 4 Illegal instruction: 4 Terminating Process: exc handler [1782]

I'm developing a ticket app with Host card emulation. The session starts correctly the first time, but when trying to emulate a second ticket, after the first one has been read by the reader, or after the emulation has been canceled by the user, it doesn't work correctly for a while. This is my CardSessionManager: import CoreNFC @available(iOS 17.4, *) class CardSessionManager { private static var cardSession: CardSession? = nil private static var presentmentIntent: NFCPresentmentIntentAssertion? = nil static func initCardSession(_ accessCode: String) { cardSession?.invalidate() cardSession = nil let ProcessAPDU: (_: Data) -> Data = { capdu in var response = Data(accessCode.utf8) response.append(0x90) response.append(0x00) return response } Task { guard NFCReaderSession.readingAvailable, CardSession.isSupported, await CardSession.isEligible else { return } do { presentmentIntent = try await NFCPresentmentIntentAssertion.acquire() cardSession = try await CardSession() } catch { return } if let cardSession { for try await event in cardSession.eventStream { switch event { case .sessionStarted: cardSession.alertMessage = String(localized: "Searching reader...") try await cardSession.startEmulation() case .readerDetected: cardSession.alertMessage = String(localized: "Reading...") case .readerDeselected: cardSession.alertMessage = String(localized: "Successful reading!") await cardSession.stopEmulation(status: .success) case .received(let cardAPDU): cardSession.alertMessage = String(localized: "Communicating with reader.") do { try await cardAPDU.respond(response: ProcessAPDU(cardAPDU.payload)) } catch { cardSession.alertMessage = error.localizedDescription } case .sessionInvalidated(reason: _): cardSession.alertMessage = String(localized: "Ending communication with reader.") presentmentIntent = nil @unknown default: break } } } } } }

你好，有个问题想请教一下： 我们的app是一款与CGM实时血糖相关的app，app支持在后台通过蓝牙跟CGM血糖设备保持连接。 现在遇到一个问题： 首先，app在后台运行期间，蓝牙是开启状态的，跟CGM设备也是连接的状态。 某个时刻，监听到蓝牙的状态突然从 poweredOn 变为了 resetting ，然后蓝牙又恢复了，状态变为了 poweredOn 这时候，问题出现了：之前连接的那个CGM血糖设备一直无法扫描到了！！ 我想问一下： 什么情况下，蓝牙状态会变为resetting 蓝牙状态恢复为poweredOn后，之前连接的那个CGM血糖设备一直无法扫描到了，为什么？我要怎么做才能恢复，重新扫描到之前连接的这个设备？

My iPhone 16 pro max when on the magnetic charger at home or in my car. My phone just powers down and reboots on its own. This has happened several times a day since updating to iOS 18.4. Anyone else having this problem ?

Today, I submitted the following proposal to Apple through the Feedback Assistant app. I'm not confident in how I phrased it—I'd appreciate any thoughts or feedback from fellow developers. Proposal: "Apple Silicon.app" for macOS with Apple Silicon – Enhancing Performance and Swap Memory Control This suggestion has been machine translated into English, so there may be some discrepancies. If you need the actual text, please feel free to reply to this or ask at the email address below. <mail address> If the author of this proposal is to be credited, I would appreciate being listed under the nickname “DiamondGotCat,” where possible. Summary: - Currently, Apple Silicon-equipped Macs have many system-level features locked down or restricted. - This proposal suggests a new application that enables certain advanced controls for power users. - Tentatively named "Apple Silicon.app", the name may be subject to change if a more suitable alternative arises. - I propose this application be added as a pre-installed utility on compatible systems: macOS (M-series), iPadOS (A-series and M-series), and iOS (iPhones with Apple-designed A5 and newer chips, provided the latest OS is available for them). Overview: This proposal introduces "Apple Silicon.app", a new system-level utility designed to offer power users greater flexibility and control over Apple Silicon behavior, as part of a broader feature update for Apple devices. I propose that Apple Silicon.app be automatically installed as a pre-installed application on Apple Silicon devices (Mac, iPad, iPhone, and select Vision devices) that support upcoming major system updates. Suggested Features of Apple Silicon.app: 1. Performance Core Control To describe this functionality, the following terminology will be used: - P-cores: Performance cores - E-cores: Efficiency cores I understand that Apple Silicon emphasizes energy efficiency, but I believe there are users—myself included—who prioritize maximum performance regardless of power usage. Therefore, I propose that the app offer a drop-down menu with the following six modes for performance core usage: A. Automatic (Recommended) – Default macOS behavior; automatically switches between P/E cores based on workload. B. Performance Priority – Prioritizes P-cores for high-demand tasks, restricts E-cores. Ideal for developers, video editors. C. Power Saving – Uses E-cores only whenever possible; limits P-core usage. Great for battery saving. D. P-Core Exclusive Mode – User-defined processes always run on P-cores. Suitable for benchmarks or low-latency tasks. E. E-Core Exclusive Mode – Prioritizes background tasks and thermal efficiency. F. Manual Assignment (Advanced) – Users can manually assign P/E cores per application in a dedicated settings screen. Additionally, I propose the following optional checkbox settings: - Thermal Safety Mode: Automatically switches from P- to E-cores when system heat exceeds a threshold. - Restore Core Settings on Wake: Remembers P/E settings after sleep/wake. - Power Source Adaptive Mode: Switches to power-saving on battery, and performance mode when plugged in. 2. Swap Memory Configuration The app should also enable user-level control over swap memory (i.e., using part of the SSD as virtual memory). Currently, macOS manages swap space automatically with no user customization available. I propose the ability to manually configure the swap system with the following options: - Enable Manual Configuration: Checkbox to switch from automatic to manual control. - Swap Size: Adjustable in GB units, allowing users to allocate desired swap capacity. 3. Other Settings At this point, these are the core features I propose. If additional useful features exist that align with this concept, I welcome further suggestions or expansion. As users—at least speaking for myself—we look forward to such customization options becoming available.

While compiling nRF5340 target of Dockkit ADK 1.0 following the guide of README.md, I selected the latest Nordic SDK, because there is no specified SDK version in the README.md. But it seems that ADK and SDK are not compatible with each others. For example, it calls nrfx_gpiote_channel_alloc() with one argument in PAL\NCS\HAPPlatformExperience.c. But the difinition of this function needs two arguments. Also I found that in some older version of Nordic SDK, this function needs only one argument. So could you please make sure which version of Nordic SDK should developer use?

After hardware and mobile phone hid mode pairing, the first connection is successful, after a while disconnect and reconnect,APP monitoring Bluetooth error NSLocalizedDescription = "Peer removed pairing information"; Failed to connect Hardware engineers detect the pairing information and find that the local pairing information of the iPhone has changed, which is a non-mandatory phenomenon