Hey guys, can everyone share how long an estimated time range it took to get the new siri AI

Hello, I am developing a cross-platform mobile app that communicates with an external accessory over a serial (UART) link. HARDWARE : The accessory is an optical reading probe that connects to the phone via USB. Inside the cable there is a standard FTDI USB-to-serial chip (similar to common FTDI/CP210x USB-serial adapters). WHAT WORKS On Android, our app: Detects the USB device Opens the serial port Reads and writes raw bytes successfully This wired FTDI path is fully implemented and working. WHAT DOES NOT WORK On iPhone, using the same wired FTDI USB accessory: We connect via Lightning or USB-C adapter The app never sees the FTDI device We cannot find a public iOS API to open a generic USB-serial port MY QUESTION : Is there any supported way for a third-party iOS app to communicate with a generic FTDI USB-serial device over a wired USB connection? Specifically, am I missing: A public Apple framework for USB serial? An Info.plist key or entitlement? A system driver on iOS similar to macOS AppleUSBFTDI (TN2315)? Or is wired USB-serial on iPhone only possible with MFi-certified accessories (External Accessory framework) or another transport such as Bluetooth LE? WHAT I HAVE ALREADY CHECKED External Accessory: seems to require MFi hardware and a registered protocol string. Our FTDI probe is not MFi. TN2315 (AppleUSBFTDI): appears to be macOS only, not iOS. Physical USB connection: cable fits, but no serial API is exposed to the app. ENVIRONMENT Platform: iOS (iPhone) Language: C# / .NET-iOS Need: transparent byte-level serial read/write SUMMARY: Android USB-serial works with our FTDI wired accessory. iOS does not. Am I missing something on iOS, or is generic FTDI USB-serial simply not supported for third-party iPhone apps? Thank you for any guidance.

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

Is there any UIRequiredDeviceCapabilities string that can be used to restrict an app to Apple TV 4K (2nd generation) or later hardware? I can’t find one. I’m working on a tvOS app that uses Continuity Camera. That feature only works on Apple TV 4K (2nd gen) and Apple TV 4K (3rd gen) hardware. There seems be no way to warn App Store customers that the app will not work on Apple TV 4K (1st gen). In the App Store or TestFlight, a user with a 1st gen device incorrectly sees a compatibility note that the app “Works on this Apple TV”. Setting a minimum OS version is not currently a helpful path for me — even tvOS 26.5 is compatible with 1st generation hardware. I can’t think of a good way to prevent users with an incompatible Apple TV 4K from installing an app that won’t work on their 1st generation devices. Any ideas? Am I missing something?

I’m seeing a Bluetooth call audio routing issue on a new iPhone 17 Pro running iOS 26.5.1, build 23F81. Bluetooth media audio works normally. Music and video audio stay on Bluetooth headphones without issues. The problem appears only when the device switches into call audio / HFP mode. Tested with multiple earbuds: Samsung, OPPO, Huawei and CMF Buds Pro 2. The behavior is similar with all of them. There are no other Bluetooth devices connected. Call Audio Routing is already set to Bluetooth Headset in Accessibility settings. The issue affects cellular calls, FaceTime Audio, Telegram and Signal. In some cases the earbuds seem to switch into call mode, but the call audio route falls back to the iPhone receiver or speaker instead of staying on the Bluetooth headset. After the call ends, Bluetooth media audio returns normally. I captured a sysdiagnose right after reproducing the issue. Relevant observations from the logs: Device: iPhone18,2 iOS: 26.5.1 Build: 23F81 Sysdiagnose time: 2026-06-03 11:22:03 +0300 In Bluetooth/CoreCapture/bluetooth_status.txt, Bluetooth was ON 3 paired devices were present 1 device was connected Connected device at the time: CMF Buds Pro 2 So the headset was not simply disconnected from the phone. In the powerlog, before the call the audio route was HeadphonesBT for media playback. Around the FaceTime Audio test, HeadsetBT / PhoneCall appeared, but then the route moved to ReceiverAndMicrophone / Speaker instead of staying on HeadsetBT. During a later cellular call, the active PhoneCall route was also ReceiverAndMicrophone rather than HeadsetBT. After the call ended, the route returned to HeadphonesBT for media playback. This looks like the Bluetooth connection remains alive, but call audio / HFP routing fails. The same sysdiagnose also contains CentauriFirmwareEvent entries under crashes_and_spins from the previous day. They show: subsystem = BT host-reason = firmware crash BTMAIN panic faulting_task = link_manager_thread LMAC_5G watchdog expired SCAN watchdog expired These firmware crash events do not happen at the exact same timestamp as the call test, so I’m not claiming that every call directly crashes Bluetooth firmware. But the sysdiagnose shows both incorrect Bluetooth call audio routing and separate BT firmware crash events. Has anyone seen similar behavior on iPhone 17 / iOS 26 with Bluetooth HFP call audio? Could this be a known iOS 26 / Apple N1 / Bluetooth firmware issue, or does it look more like a hardware defect of this particular device?

On Apple Watch (reported several times, but also on a powerful Ultra3), the CMAltimeter occasionally stops delivering updates for a while (a couple of minutes) then resumes. This makes for a terrible user experience. What could cause this? Is there a way to (best case) prevent this, or (workaround) detect it? This is production critical, any help would be greatly appreciated. Thanks a lot!

Our App has a feature that needs to determine if the phone was stationary during the last 10 seconds. For the past several years, we have been using CMMotionActivityManager for this feature and it has worked very reliably. We query motion activity for the past 10 seconds (using queryActivityStarting(from:to:to:) method) and check for any events where the stationary property is false. However, the behavior of CMMotionActivityManager has changed in iOS 16.4 Beta: CMMotionActivityManager no longer reports motion as it did on iOS 16.3 and earlier versions. With iOS 16.4 Beta, CMMotionActivityManager will falsely return events where the stationary property is true (or return no events) even though the phone was in motion during the query interval. There are times when it does return motion events correctly, but that only happens if the phone is in constant motion for a sustained period of time. This behavior is drastically different from previous iOS versions where even the slightest bit of movement would generate motion events. i'm really hoping this is an issue in the beta and will be sorted out soon. Feedback Filed: FB12005598

So for last two years ive been dealing with unwanted unauthorized access to my data having zero clue what was the reasoning it. I need help to fix this please. I deal with random people "linking" up to my "whatever syncing or streamin" I never signed up for anything this and lost everything in my life over this. I finally found out the root (which is this program apple offers) and it's being used maliciously 100%. please help

Filing this for engineering visibility and to ask whether the observed behavior matches expected M5 Pro DCP architecture. FB22701284 contains full sysdiagnose and supporting data. Hardware Configuration MacBook Pro 16-inch (Mac17,8) M5 Pro chip, 18-core CPU 64GB unified memory (highest M5 Pro memory tier) 1TB SSD macOS Tahoe 26.4.1 (build 25E253) AppleDCP-1041.100.97~429-t605xdcp.RELEASE Display Configuration Two identical LG UltraGear 27GM950B monitors: 27" Mini LED panels, native 5120x2880 DisplayPort 2.1 UHBR20 (80 Gbps capable) 165Hz native refresh, HDR-capable Connection topology (all third-party display software removed for clean test): Mac TB5 port 1 → Silkland DP80 USB-C cable (VESA-certified) → Monitor #1 USB-C input Mac TB5 port 2 → Silkland DP80 USB-C cable (VESA-certified) → Monitor #2 USB-C input DisplayLink Manager fully uninstalled No dock, no MST hub, no signal converters Apple Specification Context Per the MacBook Pro user guide, M5 Pro supports dual displays at 5K@120Hz (support.apple.com/guide/macbook-pro/apd8cdd74f57/mac), with the documented instruction to "connect the display with the highest resolution first." Observed Behavior Solo connection (either monitor) Either monitor in isolation: 5120x2880 @ 144Hz, Maximum Source Bandwidth 27,400 Mbps, 10-bit, HDR enabled. Dual connection (BetterDisplay 4.3.3 diagnostic) Monitor on dispext0@B0000000: 5120x2880 @ 144Hz, Maximum Source Bandwidth: 27,400 Mbps, HDR enabled Monitor on dispext1@90000000: Degraded from native 5K, Maximum Source Bandwidth: 13,700 Mbps, HDR disabled The 27,400/13,700 split is deterministic and follows connection order. Hardware substitution (cables, ports, monitor positions) confirmed the allocation follows position in connection order, not specific hardware. Each monitor achieves full 27,400 Mbps when solo. Per-pipe budget structure exposed in BetterDisplay 4.3.3 Recent BetterDisplay versions expose allocation limits in display reports: Allocation limits - horizontal: 3360, 3840 pixels HiDPI (6720, 7680 pixels LoDPI) Allocation limits - vertical: 2304 pixels HiDPI (4608 pixels LoDPI) This matches the per-sub-pipe budget structure documented in third-party M5 Max DCP firmware analysis, where M5 Max shows MaxSrcRectWidthForPipe = (6720, 7680, 7680, 7680). M5 Pro appears to expose only two values (6720, 7680). WindowServer assertion failure WindowServer crash on 2026-05-16 with assertion failure in the function calculating per-pipe maximum source rectangle widths: Thread 16 Crashed: com.apple.coreanimation.render-server CA::WindowServer::AppleDisplay::max_src_rect_width_by_pipes(unsigned char) const + 92 CA::WindowServer::AppleDisplay::max_src_rect_pixels() const + 60 CA::WindowServer::Server::get_display_info() + 1812 Exception: EXC_CRASH (SIGABRT), Abort trap 6. This is the same function third-party DCP firmware analysis identifies as governing the per-sub-pipe budget calculation. Reference to Existing Thread Apple CoreOS DTS Engineer Kevin Elliott in thread 814201 (https://developer.apple.com/forums/thread/814201) described M5 MacBook Pro display architecture: "Driving the display at 240Hz require both of the two display 'pipes' and the system ends up allocating both pipes to the first monitor it discovers. That prevents it from lighting up the second monitor, as there isn't currently any way for software to shift allocations of display pipes between machines." That thread addressed a single-display 4K@240Hz scenario where the second display failed to initialize. The underlying allocation mechanism (first-come-first-served pipe assignment, no dynamic reallocation) appears consistent with the dual-display configuration I'm observing, with the manifestation differing (both displays initialize but the second is bandwidth-constrained rather than absent). Specific Technical Questions Is the 27,400/13,700 Mbps asymmetric allocation observed on dual 5K configurations the expected manifestation of the two-pipe architecture described in thread 814201, or a distinct allocation policy specific to dual-display scenarios? The advertised dual 5K@120Hz capability requires approximately 28 Gbps per stream. The observed allocation appears insufficient to drive both displays at this specification simultaneously. Is there a configuration approach that allows both displays to receive adequate bandwidth allocation? Multiple sources document that M5 Max has more display engine output channels than M5 Pro. Is the architectural difference between M5 Pro and M5 Max sub-pipe count (per the BetterDisplay allocation limits and third-party firmware analysis) the underlying explanation for the differential dual-display capability? The WindowServer assertion failure in max_src_rect_width_by_pipes() — is this a known edge case for dual high-bandwidth display configurations on M5 Pro, or should this be filed as a separate issue from the bandwidth allocation behavior? Supporting Data Available BetterDisplay 4.3.3 diagnostic reports for both monitors WindowServer crash report (2026-05-16) ioreg output showing DCP unit assignments sysdiagnose attached to FB22701284 Happy to provide additional FB tickets with focused diagnostic captures if specific data would help engineering investigation.

Hi, we have developed an application that streams data from two BLE peripherals at a rate of 14.5kbps per peripheral. Until now, our devices streamed in near real time with no lag on all Apple devices with Bluetooth 5.0 or greater. Since the release of the iPhone 17 series and the iPad A16, we have reports from users of the data being streamed at significantly lower rates than expected. Any help here would be greatly appreciated as our customers are being affected by this change.

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?

Watch is no longer capturing biometric data. No sleep, HR, or SPO2, steps and activity after downloading 26.5 watchOS beta. Reset watch and was not able to resolve the issue.

Hi everyone, I am seeking clarification regarding the communication capabilities between an ESP32 microcontroller and Apple's latest devices, specifically the iPhone 16 Pro Max and iPad Pro, both equipped with USB-C ports. Background: MFi Certification: Historically, establishing communication between external devices and iOS devices required MFi (Made for iPhone/iPad) certification. But I remember this being necessary in the Lightning Cable to USB era. With the introduction of USB-C ports in recent iPhone and iPad models, there is an indication that MFi certification may no longer be necessary for certain peripherals. Perhaps I'm not confident on the terminology here: https://mfi.apple.com/en/who-should-join Project Requirements: I am working on a sensor research project that necessitates the collection of low-latency time-series data from an ESP32 microcontroller, which features a USB-C port. The data needs to be transmitted to an iPhone 16 Pro Max or iPad Pro. Bluetooth communication has proven insufficient due to its limited data transfer rates (~1.2 Mbps with L2CAP). While NEHotspot could be an alternative, it restricts the iPad's internet connectivity. Therefore, establishing a direct USB-C connection between the ESP32 and the iOS device appears to be the most viable solution. Questions: MFi Certification Necessity: Is MFi certification still required for an ESP32 microcontroller to communicate with iPhone 16 Pro Max or iPad Pro via USB-C? USB-C Communication Support: Do the iPhone 16 Pro Max and iPad Pro natively support serial communication over USB-C with microcontrollers like the ESP32? If not, are there recommended protocols or interfaces to facilitate this communication? App Development Considerations: Would developing a custom iOS application be necessary to handle data transmission from the ESP32 over USB-C? If so, are there specific APIs or frameworks provided by Apple to support this functionality? Data Transfer Rates: Considering the need for high-speed data transfer, are there any limitations or considerations regarding the data transfer rates achievable through a USB-C connection between the ESP32 and iOS devices? Thank you!

We were using a BLE mouse with HID command in iOS device, mainly iPhone device and we can use the mouse pointer using the assistive touch . But when we updated the iOS version to iOS 26.4.2 , the mouse pointer become very slow and jumpy. So something changed in the latest version that hurt the BLE mouse pointer Please update your feedback or similar issues

I recently noticed a UX inconsistency while using the battery charge limit feature on my MacBook with a MagSafe charger. With the optimized charging feature, users can set a custom maximum charging limit (for example, 95%) to improve battery health. However, the MagSafe LED indicator continues to show the charging state (amber) even after the device reaches this user-defined limit. Previously, the LED would turn green when charging reached 100%, clearly indicating a “fully charged” state. But now, when charging stops at a user-defined limit, there is no clear visual feedback that charging has effectively completed based on the user’s preference. This creates confusion, as the LED suggests that charging is still ongoing even though the system has stopped charging at the configured limit. A possible approach to improve this could be to treat the user-defined limit as an effective “fully charged” state during charging. For example: if is_charging: if battery_percentage < user_defined_limit: LED = AMBER else: LED = GREEN This would align the physical LED indicator with the system’s charging behavior and improve clarity for users without requiring hardware changes. Has anyone else observed this behavior, or is there any existing workaround?

The app crashes when using EAAccessoryManager.showBluetoothAccessoryPicker(withNameFilter:) to connect to a Bluetooth accessory in a multi-accessory scenario. The crash occurs immediately after selecting an accessory from the picker UI. Steps to Reproduce: Ensure a Bluetooth accessory (Accessory A) is already connected to the iPhone/iPad and is visible in Bluetooth settings. Launch the app. Initiate a connection flow that presents the Bluetooth accessory picker using EAAccessoryManager.showBluetoothAccessoryPicker(withNameFilter:). Ensure another compatible accessory (Accessory B) is available and visible in the picker. Select Accessory B from the picker to connect. After connection, simulate a disconnect of Accessory B (e.g., power cycle or remove battery). Attempt to reconnect Accessory B by triggering the same picker flow again. Select Accessory B from the picker. Result: The accessory connects successfully at the system level. The app crashes immediately after selecting the accessory from the picker (during dismissal). Reproducibility: Occurs consistently under the described multi-accessory scenario. Not observed when only a single accessory is present.

Is there any information available on how developers can implement the "Firmware Update Readiness" and/or "Firmware Update Status" characteristics in HomeKit? Many consumer devices support this (showing an "update available" icon), however, there appears to be nothing in the documentation about this characteristic, and it is not listed as an option in the HomeKit Accessory Simulator. Thanks in advance!

Hi, I am trying to build a very simple iOS app in Xcode that starts an NFCNDEFReaderSession when I press a button. My goal right now is only to verify that the NFC reading process starts correctly on a real iPhone. I am not trying to publish the app on the App Store. When I try to start the session, I get this error in the console: -[NFCHardwareManager areFeaturesSupported:outError:]:435 XPC Error: Error Domain=NSCocoaErrorDomain Code=4099 "The connection to service named com.apple.nfcd.service.corenfc was invalidated: Connection init failed at lookup with error 159 - Sandbox restriction." UserInfo={NSDebugDescription=The connection to service named com.apple.nfcd.service.corenfc was invalidated: Connection init failed at lookup with error 159 - Sandbox restriction.} and then my app reports that NFC is not available on this device. Important details: I added Near Field Communication Tag Reading in Signing & Capabilities. I added the NFC privacy usage description in the target settings. I am using automatic signing. I am not using an Apple Developer Program paid account. I am using a Personal Team / free account. I should also mention that I am not experienced with Swift/iOS development, so I may be missing something basic in the setup. My question is: Is this expected when using a Personal Team / free account, or is there some configuration issue I should still check? I am happy to provide any additional information needed

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.

DJI's DNG files display abnormally in the Apple Photos app on iOS devices, with dark areas showing as very black, but the same files appear normal in Photoshop. I'm curious about what causes this issue.