Someone is using all of these tools to hack my phone I have several device and my daughters tabkets and androids are also compromised . Use my home hub / home kit : cloudy it / Xcode / swift ui and siri search . If anyone could help I’d highly appreciate it I have contacted the FBI and have an apt in October b it if someone or anyone could help me debug my phone in the mean time I’d highly appreciate it . Have used my doctors apps and changed iclouds . Used family sharing with my daughter and screen time and have used share across devices . Starting wi try my outlook account that Jeremy Walker had access to . Please help me it’s effects my mental and physical health and quality time with My daughter . Using ethernet and hardware keyboards / voice over and AI . Please assist as this is extremely exhausting help pls

Pinned 2 homes address for the same contact Steps Initial check in Apple Maps No saved places or pinned addresses appear. Open Personal Contacts You have two addresses stored in your contact card: Main and Home. Pin & Edit “Main” You pinned the Main address in Maps. Refined the location on the map. Renamed it (but still saved under the type “My Home”). Open “Home” Address in Contacts Refined the location again. Changed the type to “My Home.” Attempted to rename, but no option to change the label. Final Saved Places View Shows two entries both called “Main.” Opening either of them displays the same details for the Home address. Saved Places list only shows the full address text, without the ability to rename them inside Maps. Results Both addresses appear duplicated with the same name (“Main”), even though they point to different underlying addresses. When selecting either entry, Apple Maps incorrectly shows the same Home address details. The Saved Places section does not allow renaming; it defaults to showing the full address string. Issues Identified Sync Conflict Between Contacts & Maps Apple Maps pulls labels/types from Contacts, but the edits don’t update consistently across apps. Duplicate Naming Bug Both “Main” and “Home” collapse into “Main” in Saved Places, making them indistinguishable. One-to-One Mapping Failure Regardless of which saved place you open, Maps shows the same Home entry, meaning the system isn’t correctly binding each saved place to its respective contact address. Renaming Limitation Apple Maps doesn’t allow renaming saved addresses directly — it relies on Contacts. Since Contacts only supports preset labels (Home, Work, School, etc.), custom naming is blocked.

Hi! Short time lurker, and first time poster, but I will try to be as descriptive as possible. I have had my HomePod mini since 2021, and have been loving it. Recently, though, I am facing issues which have paralyzed it. Background: Running two HomePod Minis under a stereo pair on the same network in a room. Devices worked well, with the odd dropping of the sound once a while, not too big of an issue. Started running HomePod OS26 beta in July to see what the new updates have, and maybe if the audio issues would be resolved. Issue: Two weeks ago, the after the (then) latest update, there was a no response issue in the app. No big deal, let's just restart the HomePod pair. After restart, no bueno. I also got a new beta software update notification, so decided if I updated them both, the issue will probably be resolved. No dice. The issue persists. So I decided to pair the HomePods and factory reset them. Both HomePods disappeared from my home app. Regular behavior. Going to reset them with the old unplug for 30 s, replug into power, hold finger on the display had no issues for the first one. For the second HomePod, unplug, hold, and plug in. Problems. No display. Tried it a bunch of times, nothing. Waited a day, in case the capacitors needed to be discharged for it to do a cold boot. Nothing. Looking across the interwebs, I found that we can connect the HomePods to Macs, have them show up on Finder, and update from there. Connecting into the Mac, nothing. Waited for the caps to discharge before engaging again, nothing. Now, I fear I may have problems. So I scheduled a meeting at the Genius Bar. Genius Bar individual said no support as you are running beta software. We are not allowed to touch or diagnose those devices. They also said that there are no external facing endpoints for us to diagnose or check. I would have better luck with online Apple Support or over call with Apple Support. Okay, sounds good. Contacting Apple Support, they said that we will have to wait for the official release of HomePodOS 26 for us to support you, to which I agreed. During this time, I thought about seeing if I could troubleshoot and see if anything was coming out of the HomePod when connected to the Mac. So I wrote a script, querying and logging different aspects of the USB controller on the Mac and seeing what device connects. I removed all other USB devices connected to the Mac, and started the script. First, I connected and disconnected the HomePod a couple of times, and on the last connect, I left it in, and let the script record the readings. Reading the output told me that there was indeed a device that was connecting and disconnecting. Here are some of my findings: Port Readout Summary Apple's UVDM stack lights up on the Port-USB-C@2 (CC path, SOP) AppleUVDM driver tried to read identity VDOs, initially rejected, then carried on and the transport finished powering on successfully. Furthermore, the VDM read attempts itself are rejected, typical when the accessory is gating Apple specific commands The CC transport merged metadata for SOP with a 3-VDO identity set. The CC property change during the run indicates an active PD negotiations. USB link states also toggled on that port with driver status Ready Port-USB-C@2/SOP shows Vendor ID and Product ID (not sure if this is private information, so not sharing) Port-USB-C@1/SOP, the e-marker in the HomePod cable shows the same, with product type "Passive Cable" Only CC is flagged "TransportsActive" Apple's accessory authentication stack is present The USB speeds on the port flicker between Gen 3 and Gen 2, indicating to me some sort of handshake failing in the stack, which is preventing enumeration in the System Report and Finder This likely is indicating to me that the target isn't enumerating as a normal USB device, but rather as a USB-PD Vendor Defined Messaging (UVDM) protocol on the CC line. Furthermore, the signature is in a "hidden" service/update modes, which does not enumerate standard USB functions. So, having all this information available to me, I got on a call with Apple Support today, and they went through some of the troubleshooting steps and told me that they could neither escalate the issue (due to it being on a beta software that THEY DO NOT SUPPORT) nor remediate or troubleshoot the issue (as it is an accessory) and the only thing their support options say is to wipe the device, as it is something that is not supported. Upon my suggestion of this my USB logs being used to review the case, they said my personal USB logs would be detrimental towards my case. Their final recommendation was for me to reach out to Apple Developer support as I am running beta software on this HomePod Mini. So, here I am! I highly believe this is a Software issue, contrary to what Apple Consumer Support call representative indicated. All and any help/guidance and support is appreciated. All and any help in boosting the visibility of this issue on the forums would also be greatly appreciated. I have had these bad boys since my undergrad, and I would hate to lose one of them. For Apple Support, before you lock and close this post down and recommend I go to Apple Consumer Support, they said that they cannot help me, and consumer support steps start and end at resetting the device.

I’m running HomePod OS 26 on two HomePod minis and OS 18.6 on main HomePod (original) I’ve enabled Crossfade in the Home app. I’m playing Apple Music directly in the HomePod mini. Crossfade just doesn’t work on any HomePod. I can understand it not working on the HomePod - but why isn’t it working on the minis running OS 26? I’ve tried disabling and enabling Crossfade, rebooting HomePods etc but nothing?!

I am using the MatterSupport extension to commission devices for my own ecosystem. I use the extension to do the initial connection to the device (BLE, PASE, bring device onto wifi/thread) and then use the method commissionDevice(in home: MatterAddDeviceRequest.Home?, onboardingPayload: String, commissioningID: UUID) in MatterAddDeviceExtensionRequestHandler to send a request to my own hub on the local network where it then connects to the device via wifi/thread and fully commissions the device. This flow is working correctly for wifi enabled devices, however it fails for thread devices. For some context, I am using my own border router (and have already added the router's credentials to the phone using THClient's storeCredentials). Here are some device-specific results: ESP32 (WIFI): successful commission ESP32 (THREAD): failure Matter Certified ONVIS smart plug (THREAD): failure The ESP32's are running espressif matter examples. Example border router is a running OTBR docker container I believe that the entire PASE session is established and the device gets onto the thread network, but the process seems to stall after that. I have verified that selectThreadNetwork(...) and validateDeviceCredential(...) get called but the commissioning process seems to stall before it can get to commissionDevice(...) I am limited to 7k characters, but I'll try to include as many relevant log lines as I can near the error if anyone has any ideas. I've already created a bug report with ID: FB18985348 which includes the full logs from the esp32 and a sysdiagnose from an iPhone 12 Pro (iOS 18.5) using the following log profiles: Home app/HomeKit HomeThread ThreadNetwork When commissioning directly from my hub, the entire commissioning completes successfully 100% of the time. This failure only happens when I use MatterSupport to initiate commissioning for Matter over Thread devices specifically. Very condensed homed log overview for uncertified ESP32 thread example Next: 'SecurePairing' -> 'ReadCommissioningInfo' Step: 'ReadCommissioningInfo' Sending read requests for commissioning information NetworkCommissioning Features: has Thread. endpointid = 0 <MTRDeviceController_Concrete: ..., uuid: F9BB9F53-BF73-4B82-B00B-045E7709530E...> completed for nodeID 0x0000000055d193ec with status: Success ✔ 'ReadCommissioningInfo' Next: 'ReadCommissioningInfo' -> 'ArmFailSafe' Step: 'ArmFailSafe' ✔ 'ArmFailSafe' Next: 'ArmFailSafe' -> 'ConfigRegulatory' Step: 'ConfigRegulatory' ✔ 'ConfigRegulatory' Next: 'ConfigRegulatory' -> 'ConfigureTCAcknowledgments' Step: 'ConfigureTCAcknowledgments' ✔ 'ConfigureTCAcknowledgments' Next: 'ConfigureTCAcknowledgments' -> 'SendPAICertificateRequest' Step: 'SendPAICertificateRequest' ✔ 'SendPAICertificateRequest' Next: 'SendPAICertificateRequest' -> 'SendDACCertificateRequest' Step: 'SendDACCertificateRequest' ✔ 'SendDACCertificateRequest' Next: 'SendDACCertificateRequest' -> 'SendAttestationRequest' Step: 'SendAttestationRequest' ✔ 'SendAttestationRequest' Next: 'SendAttestationRequest' -> 'AttestationVerification' Step: 'AttestationVerification' Error on commissioning step 'AttestationVerification': Internal error Next: 'AttestationVerification' -> 'AttestationRevocationCheck' Step: 'AttestationRevocationCheck' (with error) Device attestation error: Integrity check failed. Continue commissioning (ignore attestation failure: YES) ✔ 'AttestationRevocationCheck' Next: 'AttestationRevocationCheck' -> 'SendOpCertSigningRequest' Step: 'SendOpCertSigningRequest' ✔ 'SendOpCertSigningRequest' Next: 'SendOpCertSigningRequest' -> 'ValidateCSR' Step: 'ValidateCSR' ✔ 'ValidateCSR' Next: 'ValidateCSR' -> 'GenerateNOCChain' Step: 'GenerateNOCChain' ✔ 'GenerateNOCChain' Step: 'SendTrustedRootCert' ✔ 'SendTrustedRootCert' Next: 'SendTrustedRootCert' -> 'SendNOC' Step: 'SendNOC' ✔ 'SendNOC' Next: 'SendNOC' -> 'ThreadNetworkSetup' Step: 'ThreadNetworkSetup' ✔ 'ThreadNetworkSetup' Next: 'ThreadNetworkSetup' -> 'FailsafeBeforeThreadEnable' Step: 'FailsafeBeforeThreadEnable' ✔ 'FailsafeBeforeThreadEnable' Next: 'FailsafeBeforeThreadEnable' -> 'ThreadNetworkEnable' Step: 'ThreadNetworkEnable' ✔ 'ThreadNetworkEnable' Next: 'ThreadNetworkEnable' -> 'kEvictPreviousCaseSessions' Step: 'kEvictPreviousCaseSessions' ✔ 'kEvictPreviousCaseSessions' Next: 'kEvictPreviousCaseSessions' -> 'kFindOperationalForStayActive' Step: 'kFindOperationalForStayActive' Error: Timeout Next: 'kFindOperationalForStayActive' -> 'Cleanup' Step: 'Cleanup' (with timeout error) ✔ 'Cleanup' Commissioning complete for node ID 0x0000000055D193EC with timeout error

Hello Apple Developers, I'm currently working on building a custom HomeKit Accessory using the HomeKit ADK v6.3 and running the Remote.OpenSSL sample on a Raspberry Pi 4 (64-bit Ubuntu / Linux Kernel 6.1.21-v8+). I'm trying to pair the accessory via the MFi HomeKit ADK pairing process. I've successfully compiled the ADK using: The application (Remote.OpenSSL) launches correctly, and the accessory server starts as expected, broadcasting via mDNS. However, when I attempt to initiate pairing via iOS (or simulate pairing), the following error occurs: Fault fatal error - HAPPlatformAccessorySetupLoadSetupInfo @ PAL/Linux/HAPPlatformAccessorySetup.c:93 This causes the application to crash.

I am integrating a camera with HomeKit. The audio and video streams work in the HomeKit Accessory Tester, but they do not work when using the Home app on an iPhone (Failed to select audio config – Could not find the right match in the supported list. Session is not in progress). I have a single audio configuration: Opus 16kHz mono with a constant bitrate of 24kbps.

I am working on an app (iOS, iPadOS & macOS (Mac Catalyst)) for a Home Automation device. I am using HomeKit APIs to access commissioned devices and provided APIs to get a MatterNodeID and then a MTRBaseDevice so I can query the device. Since the current APIs for accessing Matter devices this way do not support subscriptions I am using the readAttributes() method of the MTRBaseDevice to get information from the device. There can be significant lag time in these reads and I realize my network speed and congestion can contribute to this. The time lag makes me wonder how readAttributes() obtains the data? Does the method query the Home hub which replies using cached data, or does the hub in turn query the device to insure it is providing the latest data? I am pretty sure all this communication goes through the hub because it works whether I am on the same network as the device or in a location far, far away.

HomePod Mini running 18.6 build 22M5054/b - will not update to HomePod OS26 have tried un-enrollment, reset, removal, etc - no dice - anyone else seeing this ? Any known work arounds ? iPad is running iPadOS 26 Relase 2 - 23A5276f

I'm finding developing for HomeKit using the iOS Simulator utterly confounding. All of my home's actual HomeKit accessories show up fine when I run the HomeKit app I'm developing on my actual phone. But none show up when I run my app in the iOS Simulator. Maybe that's how it's supposed to be? I decided to run the HomeKit Accessory Simulator in an attempt to get something to show up in the iOS Simulator, but the accessories I've created there don't show up in the Simulator either. How do I get devices to show up in the iOS Simulator? Thanks.

Hi all, Since updating to iOS 18.4, I'm experiencing a regression with AppIntents triggered from Widgets. In my app, I use AppIntents inside a WidgetKit extension to control HomeKit devices. This setup was working perfectly up to iOS 18.3. However, starting with iOS 18.4, when the AppIntent is triggered from the widget and the main app is not running, the action fails with this error: Error Domain=HMErrorDomain Code=80 "Missing entitlement for API." UserInfo={ NSLocalizedFailureReason=Handler does not support background access, NSLocalizedDescription=Missing entitlement for API. } Interestingly, the exact same AppIntent works fine if the app is still alive in the background — it seems like the failure only occurs when the intent is handled by the widget process. This looks like a behavior change or new restriction introduced in iOS 18.4. Has anyone experienced the same? Is there a new entitlement needed, or a recommended workaround? Thanks in advance!

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 then add the device to the 2nd fabric). The issue is never seen 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.

Hi, I have tried to add Eve energy plug but still pairing failed, it reported always same error. Error Domain=com.apple.MatterSupport Code=1 "(null)" Could anyone help? Regards

How to remove Matter accessory connection artefacts? This appears after connecting and then removing a Matter test accessory. Please see attached screenshot:

My app has been working fine until just recently, now it can not add Matter devices over Thread (Wifi commissioning still works). I didn't change anything on my side, so not sure if an update maybe changed things? In any case, reading through my logs (and i have the matter/thread debug profiles installed). it seems like the device is added to the thread network fine, and it looks to me like the phone is successfully commissioning the device to the Apple setup fabric, but then it seems to choke on this line and i don't think the device is actually added to the keychain/matter db, so it fails later on . error 12:18:03.369036-0700 homed [2610726604/1195614123(679130348)] failed to find metric hmmtrAccessoryMetricNameCommissioningAccessory to complete I can confirm the device does join my thread border router as its pingable, and it does not seem to be in setup mode anymore (light stops flashing), so i assume it thinks its commissioned. The device i'm pairing is a Onvis (matter certified) outlet to an espressif build of a OTBR. My phone is running 18.4.1 if that matters (no pun intended) . I have also cleared out existing Matter pairings from the phone, as well ensured the device was factory reset before every try. Here is a snippet of the log towards the end where is looks like pairing works, but then errors out. I would post more but my post has a 7k character limit. default 12:18:02.836555-0700 homed Success status report received. Session was established default 12:18:02.836734-0700 homed SecureSession[0x9bb100f00, LSID:64711]: State change 'kEstablishing' --> 'kActive' default 12:18:02.837438-0700 homed Successfully finished commissioning step 'kFindOperationalForStayActive' default 12:18:02.837467-0700 homed Commissioning stage next step: 'kFindOperationalForStayActive' -> 'ICDSendStayActive' default 12:18:02.837500-0700 homed Performing next commissioning step 'ICDSendStayActive' default 12:18:02.837574-0700 homed Skipping kICDSendStayActive default 12:18:02.837627-0700 homed Successfully finished commissioning step 'ICDSendStayActive' default 12:18:02.837650-0700 homed Commissioning stage next step: 'ICDSendStayActive' -> 'kFindOperationalForCommissioningComplete' default 12:18:02.837670-0700 homed Performing next commissioning step 'kFindOperationalForCommissioningComplete' default 12:18:02.838036-0700 homed Found an existing secure session to [2:000000009B9C86CC]! default 12:18:02.838149-0700 homed Successfully finished commissioning step 'kFindOperationalForCommissioningComplete' default 12:18:02.838697-0700 homed Commissioning stage next step: 'kFindOperationalForCommissioningComplete' -> 'SendComplete' default 12:18:02.838893-0700 homed Performing next commissioning step 'SendComplete' default 12:18:02.839092-0700 homed <<< [E:35494i S:64711 M:193726318] (S) Msg TX from 0000000086BCA241 to 2:000000009B9C86CC [47A0] [UDP:[fd01:11b8:de1c:1:968a:c465:6fe8:e12a]:5540] --- Type 0001:08 (IM:InvokeCommandRequest) (B:59) default 12:18:02.839133-0700 homed ??1 [E:35494i S:64711 M:193726318] (S) Msg Retransmission to 2:000000009B9C86CC scheduled for 2910ms from now [State:Active II:800 AI:800 AT:4000] default 12:18:02.839257-0700 homed <<< [E:35493i S:0 M:19014618 (Ack:7538941)] (U) Msg TX from 3251BD376C43B658 to 0:0000000000000000 [0000] [UDP:[fd01:11b8:de1c:1:968a:c465:6fe8:e12a]:5540] --- Type 0000:10 (SecureChannel:StandaloneAck) (B:26) default 12:18:03.356373-0700 homed >>> [E:35494i S:64711 M:174417481 (Ack:193726318)] (S) Msg RX from 2:000000009B9C86CC [47A0] to 0000000086BCA241 --- Type 0001:09 (IM:InvokeCommandResponse) (B:70) default 12:18:03.356559-0700 homed Received Command Response Data, Endpoint=0 Cluster=0x0000_0030 Command=0x0000_0005 default 12:18:03.356584-0700 homed Received CommissioningComplete response, errorCode=0 default 12:18:03.356622-0700 homed Successfully finished commissioning step 'SendComplete' default 12:18:03.356648-0700 homed Commissioning stage next step: 'SendComplete' -> 'Cleanup' default 12:18:03.356746-0700 homed Performing next commissioning step 'Cleanup' default 12:18:03.356803-0700 homed Successfully finished commissioning step 'Cleanup' default 12:18:03.356916-0700 homed Closing all BLE connections default 12:18:03.357084-0700 homed Auto-closing end point's BLE connection. default 12:18:03.358146-0700 homed SecureSession[0x9bb1003c0, LSID:64710]: State change 'kActive' --> 'kPendingEviction' default 12:18:03.358652-0700 homed Commissioning complete for node ID 0x000000009B9C86CC: success default 12:18:03.358678-0700 homed <MTRDeviceController_Concrete: 0x9b8e33100, uuid: 3F6C2281-D873-4D82-BE3E-722446EA66E7, suspended: NO> DeviceControllerDelegate Commissioning complete. NodeId 0x000000009b9c86cc Status src/controller/CHIPDeviceController.cpp:2932: Success ... default 12:18:03.367999-0700 homed <MTRDeviceController_Concrete: 0x9b8e33100, uuid: 3F6C2281-D873-4D82-BE3E-722446EA66E7, suspended: NO> 1 delegates called for -[MTRDeviceController controller:commissioningComplete:nodeID:metrics:] error 12:18:03.369036-0700 homed [2610726604/1195614123(679130348)] failed to find metric hmmtrAccessoryMetricNameCommissioningAccessory to complete error 12:18:03.426636-0700 HomeUIService Unexpected accessory setup progress CASE Session Sanity Check Passed default 12:18:03.426850-0700 homed Could not find home with valid fabric ID corresponding to fabric UUID: FB19AA02-5E34-40C5-BB9D-B1B1AF51E08B ... error 12:18:03.460841-0700 homed [188914BD-5163-425C-9E59-CAE9BFA1A288] Could not find system commissioner pairing for newly staged server with identifier f1:64:16:3f:79:b8 in all pairings: ( .. default 12:18:03.460906-0700 homed Answering incoming message HMASC.m.confirmDeviceCredential (186EE57F-330B-435F-A949-0E4C5D6954AB) from client 'HomeUIService' that expects a response with error Error Domain=HMErrorDomain Code=2 "(null)" error 12:18:03.461167-0700 HomeUIService [BD890E19] Failed to stage CHIP accessory pairing in steps: Error Domain=HMErrorDomain Code=2 "(null)" error 12:18:03.462121-0700 HomeUIService -[HSSetupStateMachineCHIPPartnerConfiguration stageCHIPAccessory]_block_invoke Failed to stage CHIP accessory: Error Domain=HMErrorDomain Code=2 "(null)" default 12:18:03.462172-0700 HomeUIService -[HSSetupStateMachineConfiguration setPairingError:] *** Setting pairingError *** = Error Domain=HMErrorDomain Code=2 "(null)"

I'm developing a Matter-over-thread generic switch with 2 generic switch endpoints. This is configured as an Intermittently Connected Device with Long Idle Time. I have an Apple TV serving as the thread border router. I'm able to commission the device successfully in the Home app and assign actions to each of the buttons however when the device is rebooted the subscription doesn't appear to resume successfully and the buttons no longer work. I've tested this on various SOC's with their respective SDKs including ESP32-C6, nrf52840 and EFR32MG24 and the behaviour was consistent across all of them. It was working originally when I first started out on the ESP32-C6, then the issue popped up first when I was testing the nrf52840. In that SDK I set persistent subscriptions explicitly and it seemed to resolve the issue until it popped up again when I found that unplugging and restarting the Apple TV completely which appeared to fix the issue with subscriptions not resuming. Recently I've added a Home Pod Mini Gen 2 to the matter fabric so there are now two TBR on the network and restarting both the Apple TV and the HomePod doesn't appear to resolve the issue anymore and the subscriptions are not resuming across all three SOC's on device reboot I'm wondering if there might be something preventing the subscriptions from resuming?

I'm device manufacturer and in future planning to get my device matter certified. If I want my device data for analytics purpose into my cloud than what is the best way possible. My research says that the most latest approach suggested by apple is, developing a custom mobile app using device homekit sdk and subscribe to device state and send it to my cloud. If I go that route, will it work even though the device was onboarded via homekit app and homekit hub device is also there. I want to make sure that both path will be active, device to hub to home app and device to custom app to my cloud, and both on matter ecosystem. The homekit sdk and matter support mentioned here https://developer.apple.com/apple-home/matter, are these two same thing?

Apologies in advance for the long post. I'm new to HomeKit and Matter but not to development, I'm trying to write a SwiftUI app for my smart home to store all of my HomeKit and Matter setup barcodes along with other bits of information. The intention is to scan the QR codes with my App and then save that QR payload in a simple Database along with other manually entered device details. Example payloads: X-HM://00GWIN0B5PHPG <-- Eufy V120 HomeKit Camera MT:GE.01-C-03FOPP6B110 <-- Moes GU10 Matter Bulb I have it 99% working, my app is even able to discern the manual pairing code from the above payloads. However one of the key feature of this is that I want to open a device entry in my app and tap the HomeKit or Matter code displayed in my app and and either: a) Ideally pass it off to the Apple Home app to initiate pairing just like the native Camera App can. b) Create a custom flow in my app using the HomeKit or Matter API's to initiate paring from within my app. So ideally just like the flow that happens when you scan a setup QR with the normal camera and tap "Open in Home". However I want to trigger this flow with just knowing the Payload and not with scanning it via the camera. I was hoping there might be something as simple as a URL scheme that I could call with the payload as a variable and it then deep links and switches to the Home app, but I haven't found any info relating to this that actually works. This is some code I have tried with the HomeKit API but this also results in an error: import HomeKit func startHomePairing(with setupCode: String) { // Handle HomeKit setup guard let payload = HMAccessorySetupPayload(url: URL(string: setupCode)!) else { print("Invalid HomeKit setup code or format.") return } let setupRequest = HMAccessorySetupRequest() setupRequest.payload = payload let setupManager = HMAccessorySetupManager() // Perform the setup request and handle the result setupManager.performAccessorySetup(using: setupRequest) { result, error in if let error = error { // Error handling: print the error details print("Error starting setup: \(error.localizedDescription)") // Print more details for debugging print("Full Error: \(error)") } else { // Success: pairing was successful print("Successfully launched Home app for HomeKit setup.") } } } But when passing in the QR payloads above it give the following .. HomeKit Code [0CAB3B05] Failed to perform accessory setup using request: Error Domain=HMErrorDomain Code=17 "(null)" Matter Code Failed to create HMSetupAccessoryPayload from setup payload URL MT:GE.01-C-03FOPP6B110: Error Domain=HMErrorDomain Code=3 "(null)" I have added the "HomeKit" and "Matter Allow Setup Payload" capabilities to my app, I have also ensured I have these in the .plist .. <key>NSHomeKitUsageDescription</key> <string>Access required to HomeKit to initiate pairing for new accessories</string> I also added a call to ensure my app appears in the Settings / Privacy / HomeKit section. I originally thought was a seemingly simple task, but I am really struggling with how to make it work!

March 2025. I’ve reached a point where so much about the Apple ecosystem is broken that I have stopped caring. My lights stopped working properly in HomeKit shortly after the last update. They work in the Wiz native app but not HomeKit. Device automations are now spotting and random; bad when they are alarms. When Apple was less, it was more. I have an iPhone 12 and see no reason to upgrade. Why pay a premium for suboptimal products and services. Anyone notice that calls to Apple Support are now fielded by non-professionals? I’ve asked. Just random applicants, typing my question(s) into Safari for solutions. No idea why government is getting cut when private is t any better. Humans are on a downward slope.

I am calling InvokeCommand on a MTRBaseDevice I received from HomeKit. The device receiving the command is using Matter 1.3 and is expecting a Boolean State Configuration new to that version of the spec. That may be the reason why I get the following error: MTRInteractionErrorDomain Code=133 "The cluster command is malformed, has missing fields, or fields with invalid values.Command not carried out." I am sending the following as the commandField parameter: ["type": "UnsignedInteger", "value": 1] When I look into those values more deeply, the value is specified as an NSNumber holding an Int16 value of 1. I created the NSNumber using a Uint8(1). The docs suggest this should result in an NSNumber treated as an unsigned char, but the debugger reports it as a Int16. I tried changing the type in the command field to "SignedInteger" and this had no effect on the error I receive. So I suppose the problem could also be that my parameters always get a signed value when an unsigned value is expected. Is this something I can correct using the current APIs, or do I need to wait for Matter 1.3 support?