Hi, Selecting Auto mode in the Home app on a Matter Room AC device results in Cool being sent over Matter. Off, Heat and Cool work correctly. The reverse also fails: selecting Auto from another ecosystem (e.g. Samsung SmartThings) goes out correctly over Matter, but the Home app shows Cool. The issue is specific to the Room AC device type — with the same device exposed as Thermostat, everything works. In the logs, the Home app parses the requested mode correctly and sends it to the home hub; on the hub side the logs show Cool going out over Matter. Filed as FB25164477 (logs and repro attached). Is this a known issue? Thanks!

I am developing a noncommercial graduation project for display color measurement with an iPhone Air. Is there a supported public API or entitlement for real-time chromaticity and illuminance readings from the built-in ambient light sensor? SensorKit's 24-hour data holding period does not fit this use. If this is unavailable, where should I submit an API enhancement request?

Summary Our app uses CBPeer.identifier in Core Bluetooth to identify BLE peripherals. For the same non-bonded BLE peripheral, we have observed the following behavior: On iOS 18, CBPeer.identifier did not change across OS updates or device reboots. On devices updated to iOS 27.0, the CBPeer.identifier of the same peripheral became a different value after the OS update. On iOS 27.0, we have also confirmed that CBPeer.identifier changes after a device reboot. API documentation: https://developer.apple.com/documentation/corebluetooth/cbpeer/identifier We would like to confirm whether this is a specification change in iOS 27 and whether it is intended behavior. Questions Is it intended behavior in iOS 27 that CBPeer.identifier for a non-bonded BLE peripheral changes after an OS update or device reboot? If this is by design, is there any documentation (release notes, technical documents, API reference, etc.) that describes this change? Under what conditions can the CBPeer.identifier of a non-bonded BLE peripheral change? (e.g., OS update, device reboot, resetting Bluetooth settings, reinstalling the app, after a certain period of time, etc.) If we need to keep identifying the same non-bonded BLE peripheral across reboots and OS updates, what implementation approach do you recommend? Any information would be greatly appreciated. Thank you.

I recently updated my iPhone SE (2020) to the iOS 27 beta, and initially the experience was excellent. The phone felt noticeably faster and more responsive, and I was genuinely impressed with the update. However, after about a day of usage, I started experiencing a charging-related issue. One night, I left my phone connected to the charger before going to sleep when the battery was at 55%. The next morning, I found that the battery had dropped to 42% instead of charging. I checked all connections and confirmed that the charger, cable, and power source were properly connected. When I disconnected and reconnected the charger, the charging lightning bolt icon would briefly appear, then turn grey after about two seconds, and finally disappear completely a couple of seconds later. The phone would not charge. Assuming it might be a faulty charger or cable, I tested with: A different Apple charger A different Lightning cable The same issue persisted. Next, I connected the phone to my Mac. Surprisingly, it started charging, and Finder recognized the device normally. Over the next few days, the behavior became inconsistent: Sometimes the phone would charge. Sometimes it would not charge at all. Connecting to the Mac worked most of the time, but occasionally even that failed. I also noticed another unusual behavior: If I unplugged the Lightning cable from the iPhone and plugged it back in, the charging symbol would briefly appear. However, if I left the cable connected to the iPhone and unplugged/replugged only the USB end from the power adapter, there would be no response whatsoever—no charging sound, no charging icon, nothing. I cleaned the charging port, cable connectors, and charger contacts, but the issue remained. At that point, I realized the problem started immediately after installing the iOS 27 beta. To verify whether it was software-related, I restored the device back to iOS 26.5. After downgrading, the charging issue completely disappeared, and the phone began charging normally again with the same charger and cable. Based on my testing, this appears to be a software-related issue introduced in the iOS 27 beta rather than a hardware problem. I am posting this in case other iPhone SE (2020) users are experiencing similar charging behavior after updating to the beta. Device: iPhone SE (2020) Issue: Intermittent charging failure after updating to iOS 27 beta Status: Resolved after restoring to iOS 26.5

I have a reproducible Bluetooth audio fault on my MacBook Pro M3 Max and have narrowed it down as far as I can from user space. I have filed it as FB25169767. I am posting the data here in case it helps others with the same log lines, and in case an Apple engineer can say what to capture next. I used AI tools for this investigation: Claude to run the tests and analyse the logs, and ChatGPT for web research. I did the listening tests myself, and the outside sources quoted below were checked against the originals. My setup MacBook Pro M3 Max (Mac15,9), macOS 15.6.1 (24G90) Bluetooth controller: Broadcom BCM4388, firmware 22.5.542.2788 Sink: Creative T100 desktop speaker, Bluetooth 5.0, A2DP, SBC only Negotiated: SBC 44.1 kHz joint stereo, bitpool 52, 322 kbps, 5 frames x 117 B per packet every 14.51 ms, L2CAP MTU 672 The speaker is about 25 cm from the Mac, with line of sight. Wi-Fi is on 5 GHz. A Magic Trackpad is connected. Symptom I have heard audible gaps from this speaker in every app for years. My AirPods and Sony WH-1000XM4 on the same Mac do not glitch. What bluetoothd reports for my speaker A2DP LinkQualityReport, one line a second while streaming: A2DP LinkQualityReport: Handle = 11 ReTx = 75.8% (135 / 178), NAK = 0, NoSync = 135, TxPwr = 7 dBm, RSSI = -46, {50,75,90}th Noise = {-102,-102,-101} for 29 ch, 2EDR pkts = 138, 3EDRTx pkts = 0, HDR4Tx pkts = 0, HDR8Tx pkts = 0, ... CoexDenial = 0, CoexRequest = 0, ... TxFlush pkts = 0, Tx2Flush pkts = 0, rate = 322 kbps Flow off = 0 Over 11,808 reports from my normal use (3.3 h of streaming, 12 to 13 October 2026): Speaker (SBC) AirPods (AAC), earlier capture ReTx median 56.6% (p10 50.5%, p90 63.0%) median 8.1% Retransmission cause all NoSync, NAK 0 mostly NoSync RSSI median -38 dBm about -47 dBm Noise about -100 dBm similar Packets on air about 195/s, all 2-EDR (about 2.8 attempts per 14.51 ms audio packet) about 38/s, mostly HDR TxPwr, AFH channels 7-8 dBm, about 44 8 dBm, about 45 "Link Adaptive Packet type support" 0 1 Packet drops 17.6 a minute (25.8 a minute on another day) 0 while streaming This is what the drops look like in my log: [Server.A2DP] A2DP packet flushed: L2CAP (chip) flush occured. Current sequence=28, timestamp=40557459 [Stack.L2CAP] Write in progress (status=65535) [Server.A2DP] A2DP packet flushed: Audio Queue full, remove oldest and insert sequence=29 (latest), timestamp=40557479 Every one of the 2,670 "Audio Queue full" drops in that period comes with an L2CAP "Write in progress (status=65535)" on the same thread in the same millisecond, just before it. The other 795 drops are "L2CAP (chip) flush occured". So most of the lost audio is discarded on the host when the previous write to the controller has not completed yet. Other details: The report's TxFlush pkts, Tx2Flush pkts and slot counters are 0 in every report for this link, also in seconds with a logged chip flush. Flow off is above 0 in only 19 of 2,835 seconds (one capture), so the controller's ACL buffers are not usually full. bluetoothd logs "Setting flush timeout, chipId:23" and "Dynamic Latency settting flush timeout to 200 ms" at AirPods events, never at this speaker's stream start. Audio Timesync for this link: "Audio Delivery Average Time" 9750 to 16750, "Pending Packets" 18 to 27, "Queue depth" up to 8. Second symptom: CoreAudio overloads With this speaker, bluetoothd logs Initiate Audio Delivery Speed Change (0.9x or 1.1x) about once a second. With AirPods it happens only at stream start. Each change shifts the HAL clock: safety_violation_time_gap median 7.9 ms, max 20.9 ms (1,645 reports). Any client with a 256-frame IO buffer (Chrome Web Audio uses 256 below 96 kHz) then logs HALS_OverloadMessage: Overload possibly due to safety violation 50 to 100 times a minute. I ran a silent test: a CoreAudio client playing digital zeros to the speaker, 40 s per buffer size. HAL buffer Overloads/min ReTx 256 frames 49.5 60.5% 512 frames 0 58.0% 1024 frames 0 58.0% A bigger buffer stops the overloads but not the packet drops. Control experiment: a non-Apple sender to the same speaker I plugged a USB Bluetooth 4.0 dongle (Broadcom BCM20702A0) into the same Mac. macOS attaches no Bluetooth driver to it, so I could drive it from user space with BTstack (port/libusb, a2dp_source_demo). Same desk, same distance, same SBC bitpool 52 at 14.51 ms intervals. 2 min 24 s of audio, and I listened to all of it: 9,892 of 9,892 media packets completed, no flush, no audible gap. Packets in flight: median 2, max 5. Send to Number Of Completed Packets: median 27 ms, p95 48 ms, under 70 ms in steady state. BTstack sets no automatic flush timeout and never discards late packets. So my speaker's receiver and my room are fine. The fault is in Apple's transmit path for this link: bluetoothd, the BCM4388 firmware, or the link policy between them. This test cannot say which. What I ruled out Nothing I changed moved ReTx from 50 to 60%, and it does not follow RSSI between -36 and -56 dBm. Bluetooth off/on (ReTx 57.8% before, 58.8% after), re-pairing (64% after) Trackpad traffic (0 reports/s, ReTx 56%), Wi-Fi coexistence (5 GHz, CoexDenial 0) Lid open, nearby LED lamps unplugged, monitor USB-C cable unplugged, Mac moved 2 m away Audio content: digital silence behaves the same as music I have not yet tried a fresh boot (the Mac had been up 116 days), macOS 15.8.1 or a PacketLogger capture. Related Asahi Linux found that Apple's Broadcom controllers (BCM4377/4378/4388) need vendor command 0xFC57 (ACL priority) for clean A2DP, and that the whole audio connection must stay high priority while it carries audio: one low-priority packet, such as a volume change, causes a dropout (netdev list, 15 April 2026, "[PATCH v2] Bluetooth: Add Broadcom channel priority commands"). An earlier capture showed macOS sending 0xFC57 plus vendor commands 0x1DD, 0x205 and 0x22D per connection at playback start. A similar write-up with the same three log lines, ReTx 51.4% at -36 dBm, but triggered by sleep/wake and cured by Bluetooth off/on (which does not help me): https://note.com/honest_kudu5817/n/n7e8a12aecb13 Questions Does macOS apply a different link policy to a non-Apple SBC sink than to AirPods (ACL priority, automatic flush timeout, packet types, Dynamic Latency)? Does "Link Adaptive Packet type support=0" mean this link is excluded from something? Is 0xFC57 held for the whole stream, or dropped around AVRCP traffic such as volume changes? What does NoSync count exactly, and why would it be more than half of all transmissions at -40 dBm? Is there anything I can capture beyond PacketLogger with the Bluetooth logging profile that would help the Bluetooth team? Has anyone else seen "Write in progress (status=65535)" paired with "Audio Queue full" on a steady link like this, and found anything that changes it? I am happy to run more tests or share more logs.

Hi there, I am working on a (Mac Catalyst) HomeKit my own private application, which observes different characteristics of different accessories. This works (also thanks to the advice here, thanks again to all who helped!) like a charm. Now I've found that one of my outlets which is connected through Matter supports power consumption (in Home.app), but there is no characteristic for that, all I can see is its power state. Self-evidently, access to the consumption would be something Matter-specific. At this moment, to save time, I'd rather not study the complete Matter kit in detail if it can be dodged for this particular very limited goal. Is it possible just as simply as possible to read in (if readable) and observe (if observable) those extra Matter characteristics (if any) for an HMAccessory, presumably through its matterNodeID somehow? I'd be grateful for a sample code, if some is available (preferably ObjC, but of course Swift better'n nothing). Thanks a lot!

My MacBook Pro M5 running MacOS Tahoe 26.3 beta fails to detect two identical ASUS ROG Swift OLED PG32UCDM monitors simultaneously. Only one display is recognized at a time. One potential root cause might be that both monitors report identical binary EDID serial numbers (0x01010101), and the MacBook Pro M5 appears to use this value exclusively for display identity rather than combining it with other more detailed information (e.g., port, or alphanumeric serial number). I've verified that the monitor EDID binary serial numbers are in fact identical -- however the alphanumerical serial numbers are not identical. NOTE: This behavior is specific to the MacBook Pro M5 — when connecting both monitors via usb-c to a Mac Mini M4 Pro running the same MacOS Tahoe 26.3 beta, the monitors work fine. The OS detects both and assigns different names to them (PG32UCDM (1) and PG32UCDM (2)). NOTE: I could be wrong about this root cause, I don't have a way to disprove it, though the fact the monitors work fine on a Mac Mini is suspicious. What I have tried: Connecting the two monitors using different monitor ports (one on DisplayPort, another on HDMI, etc.), and different MacBook ports (one on HDMI, another on USB-C, etc.) Bumping down the resolution on the monitors to "1920x1080 (low resolution)" and 30Hz to rule out bandwidth issues. Connecting one, or both, monitors to CalDigit TS5 Plus dock. Neither alternate configuration yields the device recognizing both screens. Using BetterDisplay to import a manually-edited EDID for the screen, with a different binary EDID value, manufacturer name, etc. I've also verified that if I plug in my Apple Studio Display as one of the monitors, then the MacBook recognizes both one of the PG32UCDM monitors and the Studio Display at the same time. The issue seems to occur only when both monitors plugged into it are the same PG32UCDM model. When I have both monitors plugged into my MacBook, each time I disconnect the cable to whichever monitor is currently recognized, it immediately recognizes the other monitor. Plugging the cable for the disconnected monitor back in has no effect. I'm at a loss. Has anyone run into this issue and found a successful workaround that is not one of the approaches I've described above?

I’m using an iPhone 15 Pro Max on iOS 27, with the Action Button assigned to the flashlight. The problem is that the Action Button only activates the flashlight when the front of the phone is unobstructed. If the phone is facing away from me, against clothing, partly covered, or otherwise detected as being in a pocket, iOS ignores the Action Button press. I understand why proximity/pocket detection exists to prevent accidental activation, but for the flashlight this behaviour is inconvenient. The flashlight is one of the functions where a physical button is especially useful because I often want to activate it without looking at or repositioning the phone. I also tried assigning a Shortcut that toggles the flashlight instead of using the native Flashlight Action Button option, but the same restriction still applies. Steps to reproduce: Assign Flashlight to the Action Button. Lock the iPhone. Hold the phone normally and cover the front/proximity sensor, or place the phone screen-down. Press and hold the Action Button. The flashlight does not activate. Uncover/turn the screen toward you and try again — it works. Expected behaviour: An intentional press-and-hold of the Action Button should be able to activate the flashlight regardless of phone orientation or proximity sensor state. At minimum, it would be useful to have an option such as: “Allow Action Button while proximity sensor is covered” or an exception specifically for the flashlight. The current behaviour makes the Action Button significantly less useful as a physical flashlight switch.

Hi, i am using mopai kt393 which is listed on apple mfi devices list in web. My phone is 14 pro(ios 27) and cannot be charged via mopai kt393. I tried to use another phones : 14 pro(ios 18), 13 basic(ios 26), they were charged normally. Is this a bug of ios27? or new rules on ios 27? or mopai kt393 is actually not a mfi device? Anyone has this issue too?

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.

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.

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?

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

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 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.

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.

一部の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.

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