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.

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

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

Hello, We are testing Wallet passes with iBeacons in iOS 26 Beta. In earlier iOS releases, when a device was in proximity to a registered beacon, the corresponding pass would surface automatically. In iOS 26 Beta, this behavior no longer occurs, even if the pass is already present in Wallet. I have not found documentation of this change in the iOS 26 release notes. Could you please confirm whether this is expected in iOS 26, or if it may be a Beta-specific issue? Any pointers to updated documentation would be appreciated. Thank you.

I’m investigating whether a consumer iPhone app can control AirPods Pro environmental listening settings using public APIs, while keeping all live audio processing inside the earbuds. On a real iPhone running iOS 26.6.1, with AirPods reporting model A3064 and firmware 8B41 in Settings: CoreBluetooth connects and successfully reads the manufacturer, model and firmware characteristics. Explicit discovery of service 7798082B-B7B7-45A6-9933-563492EFE04E returns no matching service. Unfiltered discovery completes without errors but also excludes that service. A system PacketLogger capture contains metadata mapping that service to handles 0x12–0x2B, and characteristic D5621CC1-F7AB-45DB-9403-9EAF744D5390 to value handle 0x18. System ATT reads of that handle receive responses. Our app performs no setting writes. We understand that system trace metadata does not establish third-party access. Is this service intentionally unavailable to third-party CoreBluetooth clients? Alternatively, is there a documented public connection, authorization or entitlement requirement that could explain its absence? If this service is unavailable, is there any supported API for controlling AirPods environmental amplification or frequency balance? A minimal Swift project and diagnostic report are available.

I'm trying to work out why Channel Sounding won't start on my device, and I'd be grateful for any pointers on what condition I haven't satisfied. What I see On an iPhone 17 Pro Max running iOS 27.0 beta (24A5390f), queried after the central manager reaches .poweredOn as the documentation requires: if #available(iOS 27.0, *) { print(CBCentralManager.supports(.channelSounding)) // false print(NISession.deviceCapabilities.supportsBluetoothChannelSounding) // true } No accessory or connection is involved — both are local queries. Because supports(.channelSounding) is false, the Core Bluetooth path fails with CBError code 13 ("Channel Sounding is not supported by the local or remote device"). I also tried calling startChannelSoundingSession(:) anyway, past my own capability check, against a connected peer; the same code 13 comes back from peripheral(:didCompleteChannelSoundingSession:), so it isn't merely an advisory check. The Nearby Interaction path gets further — its capability check passes, so session.run(_:) is called with NINearbyAccessoryConfiguration(bluetoothChannelSoundingIdentifier:previousBluetoothIdentifier:) against a paired, connected reflector — and then invalidates with NIErrorCodeSessionFailed (-5887). Same result with isCameraAssistanceEnabled set to both true and false. Apple's own "Measuring Distance Between Devices Using Channel Sounding" sample behaves identically on this device, so it isn't my code. What I've ruled out Querying before .poweredOn — the value is read in centralManagerDidUpdateState when the state is .poweredOn. Hardware — this is an iPhone 17 Pro Max, and Nearby Interaction's own capability check reports the hardware as capable. The Language & Region setting — changing it makes no difference. Beta staleness — updated across two betas, no change. The reflector — it implements the Ranging Service GATT server and the reflector role, and ranges successfully against another unit of its own model. What I'm unsure about The header comment for CBCentralManagerFeatureChannelSounding reads: The hardware and region supports channel sounding That's the only mention of "region" I can find in any Channel Sounding documentation — WWDC26 session 369 lists the N1 chip and the accessory-side requirements, but nothing about region, and there's no API to query that condition. My device is a South Korea market unit operating in South Korea, so I'm wondering whether that's what I'm hitting, but I have no way to confirm it. I'd also be glad to be told I'm simply wrong about something more mundane. Questions What conditions cause supports(.channelSounding) to return false on a device that has the N1 chip? Is region genuinely one of them, and if so, is it determined by the market the device was sold in, its current location, or something else? Should NISession.deviceCapabilities.supportsBluetoothChannelSounding be expected to agree with the Core Bluetooth check, or does it intentionally report hardware capability only? If the latter, is there a supported way to check Channel Sounding availability before running a session? For anyone with Channel Sounding working: which path are you using — Core Bluetooth's startChannelSoundingSession(_:), or NISession with NINearbyAccessoryConfiguration? And does supports(.channelSounding) return true for you? Question 3 is mostly to help me tell whether this is specific to my device. Thanks — happy to share more logs or a minimal reproducer if it's useful.

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?

Hi, I'm testing DL-TDoA with Qorvo QM35 anchors and an iPhone 16 Pro running iOS 27 (24A5430a). A separate DWM3001C receiver successfully receives the QM35 anchor frames, with CRC, STS and MAC integrity checks passing. The app uses NIDLTDOAConfiguration with BLE discovery, as described in Apple’s DL-TDoA ranging guide . supportsDLTDOAMeasurement returns true, Location permission is granted, and the app stays foregrounded. Apple’s logs show our BLE discovery configuration being reassembled and parsed, followed by RangingStarted. Approximately 150 ms later, we see FatalChipError and a session suspension for ErrorHandling. The phone’s firmware report contains: ASSERTION FAILED: hmd.c:5723: nchains_enabled >= 2, 0, 0 The app receives no DL-TDoA measurements. We’ve reproduced the same assertion after rebooting the phone and with both QM35 UWB sessions stopped, leaving only BLE discovery active. Incoming anchor transmissions therefore aren’t required to trigger this failure. Has anyone encountered this assertion during DL-TDoA startup? Is there a discovery configuration requirement worth checking, or a known issue with this iOS build? Happy to share the exact discovery payload and diagnostic logs. Thanks! efad25a2-0aaf-49c9-85ee-74d4f384b3ab.rtf

hi folks, hobbyist here working on developing with DL-TDoA on ios. i was trying to find the DL-TDoA interoperability spec online at https://developer.apple.com/nearby-interaction/. but its missing from the latest one for iOS 27 preview. (R6) when do we expect to have access to an interoperability spec? thanks.

I am using an 11-inch M4 iPad Pro. I first noticed severe battery drain while the iPad was idle. After checking the device, I found that several unrelated functions had stopped working at the same time: Front and rear cameras show a black screen Face ID does not work LiDAR does not work Flashlight does not work Apple Pencil is not detected, paired, or charged through the magnetic charging area Apple Diagnostics at the Genius Bar also reported failures involving the front camera, rear camera, Face ID, and LiDAR. I was told at the Genius Bar that, because the device is outside the standard warranty period, it would be treated as an out-of-warranty hardware failure and would not qualify for free repair. There has been no drop or liquid damage. I have already performed multiple force restarts, updated iPadOS, and factory-reset the device several times, but the symptoms remain unchanged. What seems unusual is that several functionally separate systems became unavailable at nearly the same time, together with severe standby battery drain. Because of that, I am wondering whether this could be related to embedded software, firmware, power management, or low-level hardware control rather than several independent hardware components coincidentally failing at once. Has anyone seen a similar issue on an M4 iPad Pro, or is there any known firmware or system-level failure that could cause this pattern?

Hello, I'm developing Verde, a Matter irrigation system (soil moisture sensors, a hub, and a multi-valve irrigation controller). My question is about Matter device type support in Apple Home, not about hardware or commissioning. The failure: when an endpoint declares certain device type IDs, Home refuses to create the accessory and reports that the device is not supported. Change nothing but the device type ID, and the same accessory is created and works. So this is Home rejecting a device type, not a pairing, discovery or hardware problem. Water Valve — 0x0042 Device type 0x0042 Water Valve (Matter 1.3) Cluster 0x0081 Valve Configuration and Control Result in Apple Home Not supported — accessory is not created Result on other Matter controllers Created and controllable Substitute we now ship: device type 0x010A On/Off Plug-in Unit with cluster 0x0006 On/Off. Accepted by Home immediately, and toggling the endpoint operates the valve. The substitution works but is a misrepresentation: the user sees a row of "plugs" for a device that controls irrigation valves. There are no valve semantics, no open/close vocabulary, and nothing tells Home — or an automation the user writes — that switching this on releases water. Soil Sensor — Matter 1.5 Device type Soil Sensor / soil measurement, introduced in Matter 1.5 Result in Apple Home Not available Substitute we now ship: 0x0307 Humidity Sensor with cluster 0x0405 Relative Humidity Measurement, because that is what Home renders. Soil moisture therefore appears in Home as air humidity — conceptually wrong, wrong icon, and it contaminates any humidity-based automation the user has set up. The CSA positioned the 1.5 soil types explicitly for irrigation use with Matter water valves, so the two gaps above are the same gap for us. Multi-endpoint valve controller — composition Our controller is a single accessory exposing seven independently controlled valve endpoints (endpoint IDs 1–7). Endpoints exist only for valves the installer has enabled, so the composition can legitimately change after a configuration change. Two questions on this: Changed composition isn't picked up. When an endpoint is removed, Home keeps showing it until the accessory is deleted and re-added. Is there a supported way to make Home re-read a device's composition in place? Preferred shape. For seven valves, does Apple prefer one accessory with seven endpoints, or a Bridge (0x000E) exposing seven separate accessories? 4. What we're asking Is Water Valve 0x0042 planned for Apple Home, and is there a timeframe we can plan to? Is the Matter 1.5 Soil Sensor device type planned? Until then, is substituting On/Off Plug-in Unit for a valve, and Humidity Sensor for soil moisture, acceptable to Apple? We'd rather follow your guidance than ship a misrepresentation we later have to undo — and than have a valve presented to users and automations as a plug. For a multi-endpoint valve controller: guidance on composition, and on refreshing a changed endpoint list in Home. Is there an authoritative, current list of the Matter device type IDs Apple Home accepts, more specific than the general support article? Designing against it is far cheaper than building an accessory and discovering Home will not create it.

I have an app that uses CMHeadphoneMotionManager on macOS without playing any sound. I have noticed that when I start playing audio with Spatial Audio set to either Head Tracked or Fixed, the yaw appears to recenter as soon as I press play, which I’ve confirmed by logging the motion data returned. This has a knock-on effect on my app because the orientation that I previously considered the center is no longer the center. Is this intentional behavior? Is AirPods head-motion data designed so that the application currently using Spatial Audio takes precedence over other applications using the CMHeadphoneMotionManager or should multiple applications be able to use the motion data independently without affecting each other’s orientation reference?

Hello Apple Home / Matter Engineering Team, We are developing a Matter-enabled indoor air quality monitoring device that includes radon measurement. The device can be successfully commissioned into Apple Home, and Apple Home correctly recognizes and displays the overall Air Quality information. However, the actual Radon concentration measurement is not displayed in the Apple Home app. We would like to clarify whether this is expected behavior in the current Apple Home implementation. Specifically: Does Apple Home currently support displaying the Matter Radon Concentration Measurement separately from the overall Air Quality value? If supported, which Matter cluster/attributes and device configuration does Apple Home expect? If our device correctly exposes the applicable Matter Radon Concentration Measurement cluster, should Apple Home display the measured value in the accessory UI? If Apple Home currently does not expose the Radon concentration in its UI, is there a recommended implementation for Matter accessory manufacturers? Commissioning and other Matter functionality are working correctly. We are specifically trying to determine whether this behavior is an Apple Home UI/support limitation or whether our Matter implementation needs to be modified. We can provide our Matter specification version, device type, endpoint/cluster configuration, screenshots, logs, and certification information if needed. Thank you, JS