And this issue is happen randomly

Thank you for your detailed response and questions. Here are my answers: Pairing through Home.app: We cannot use the same configuration to set up in Home.app since we did not form a thread mesh network with the HomePod. The thread network is created by the border router with its own dataset. From our understanding, the Home.app uses the dataset of the HomePod. While it is possible to change the dataset of our border router to match the HomePod's, it is not preferred. The thread network can be created before the user uses iOS (e.g., setup using Android with thread devices already connected to the thread border router using the original dataset). Changing it would require reconfiguring all devices. Therefore, using Home.app will only add the thread device to the HomePod instead of our border router even thoguh both are in homepod and our border router are in same local wifi network. Thread Credentials Configuration: My app has confirmed that the correct thread credentials are configured using THClient. This validation was done before starting MatterSupport pairing, as I understand that the extension cannot preceed if this data is unavailable. Could you please advise on how we should verify that the thread credentials are configured correctly or if there is anything we cannot check? The dataset & Border Agent ID given to the device during commissioning is definitely correct, or else the device would not join the thread network of our border router to create the first matter fabric. or will MatterSupport check whether the device's thread network matches the preferred network in THClient before moving forward or other requirement checking? eg. Google Matter SDK has this requirement of using the preferred network only, and we have to change the preferred network in GMS before the setup.

@DTS Engineer sorry that we may have give you the wrong log in the 19/Apr. But the latest log in FB17357284. should be one of the topics is case we that we presenting. Fabric1 complete (matter thread network created) 默认 2025-04-25 11:14:33.354895 +0800 homed Received Command Response Data, Endpoint=0 Cluster=0x0000_0030 Command=0x0000_0005 默认 2025-04-25 11:14:33.354903 +0800 homed Received CommissioningComplete response, errorCode=0 . . . (Report unable to add device ) 错误 2025-04-25 11:14:33.539798 +0800 homed [188914BD-5163-425C-9E59-CAE9BFA1A288] Could not find system commissioner pairing for newly staged server with identifier 6f:d6:63:43:b5:b9 in all pairings: ( "<MTSSystemCommissionerPairing, Uuid: 34355356-AAFA-4604-B It is only 0.2s between the 2 events, so we suspected that there is some problem with HomeD in the process. Thank you and look forward for your reply

I have a similar question as @Manju24 . My team has developed an app with a Matter commissioner feature (for own ecosystem) using the Matter framework on the MatterSupport extension. Recently, we've noticed that commissioning Matter devices with the MatterSupport extension has become very unstable. Occasionally, the HomeUIService stops the flow after commissioning to the first fabric successfully, displaying the error: "Failed to perform Matter device setup: Error Domain=HMErrorDomain Code=2." (normally, it should send open commissioning window to the device and than add the device to the 2nd fabric). The issue is never see before until recently few weeks and there is no code changes in the app. We are suspected that there is some data that fail to download from the icloud or apple account that cause this problem. For evaluation, we tried removing the HomeSupport extension and run the Matter framework directly in developer mode, this issue disappears, and commissioning works without any problems. Given this result, we are considering using the Matter framework directly for our iOS app's App Store release. Can anyone confirm if this is a viable approach? Thanks!