After upgrading my M1 MacBook Pro from macOS 26 to macOS 27, my NuPhy Kick75 Bluetooth keyboard started randomly disconnecting during normal use. This issue did not occur on macOS 26 with exactly the same Mac, keyboard, physical location, and usage environment. The problem started immediately after upgrading to macOS 27. The keyboard disconnects approximately 2–3 times per hour. When the interruption occurs, the Bluetooth connection indicator on the keyboard also shows that the Bluetooth link has been lost. This is therefore an actual Bluetooth disconnection rather than only input lag or delayed keyboard events. The keyboard automatically reconnects shortly afterward. macOS bluetoothd logs captured at the exact time of an occurrence confirm that the Bluetooth LE HID link is being disconnected. Hardware Mac: MacBook Pro with Apple M1 Keyboard: NuPhy Kick75 Bluetooth device name: Kick75 IO-2 Connection type: Bluetooth LE HID Regression macOS 26: No Bluetooth disconnections observed during long-term normal use. macOS 27: Random Bluetooth disconnect/reconnect events occur approximately 2–3 times per hour. No keyboard, firmware, physical location, or other hardware/environmental changes were made when the issue started. The behavioral change occurred immediately after upgrading the Mac from macOS 26 to macOS 27. Steps to Reproduce Connect a NuPhy Kick75 keyboard to an M1 MacBook Pro using Bluetooth. Use the keyboard normally for typing. Continue normal use for approximately one hour. At seemingly random intervals, keyboard input suddenly stops. At the same time, the keyboard's Bluetooth connection indicator shows that the Bluetooth link has been lost. macOS automatically reconnects to the keyboard shortly afterward. The same event can be observed in bluetoothd logs as an LE HID link disconnection. Frequency Intermittent but frequent. Approximately 2–3 occurrences per hour after upgrading to macOS 27. Expected Result The Bluetooth LE HID connection should remain stable during normal use, as it did on macOS 26. Actual Result The Bluetooth LE HID connection is unexpectedly terminated. macOS subsequently reconnects to the keyboard automatically. Relevant bluetoothd Log The following was captured during an actual disconnection at: 2026-09-15 17:47:44 Disconnect OI_HCI_LM_HANDLE: 0x55 (85) wakeUp: No RSSI: -37 -37 -37 -37 ... _GATT_LE_DisconnectedCB ... reason STATUS 708 LE Link disconnected ... reason 708 LE ConnManager disconnection complete reason 708 localRole=Central encrypted:1 linkReady:1 disconnectDevice:0 localRole:0 reason:708 result:307 Device disconnected - { devicename: Kick75 IO-2, result: 307 } App disconnected - { bundle: com.apple.BTLEServer, reconnecting: Y } macLeDeviceDisconnected: LE Connection disconnected. Device is a LE HID. BLE Disconnected Unspecified reason 708 Setting LeDevice to Compatible HID from Compatible HID The RSSI values immediately before the disconnection remained consistently around -37 dBm, indicating a very strong Bluetooth signal at the time the link was lost. The following fields appear consistently relevant to this event: reason:708 result:307 disconnectDevice:0 reconnecting:Y macOS also classified the keyboard as a Compatible HID. Related Community Reports This may not be isolated to the Kick75. There is an independent community report involving a NuPhy Air75 V3 on macOS 27 that describes very similar Bluetooth LE HID disconnections. That report has several notable similarities: The Air75 V3 disconnects repeatedly on macOS 27. The same keyboard reportedly operates normally on Windows and iOS 27. Other Bluetooth devices connected to the affected Mac reportedly remain stable. The reporter's macOS Bluetooth logs contain: Incompatible LE HID HID latency issue detected LE Link disconnected (reason 708) Another user reported the same problem with a NuPhy Air65 V3. NuPhy Support responded that they had adjusted Bluetooth parameters and optimized the Bluetooth connection interval, and offered a test firmware for further investigation. The original reporter later tested the same Air75 V3 over Bluetooth on a Mac running macOS 26 at an Apple Store and reported that it did not disconnect. The reporter also observed that having certain Apple Bluetooth HID devices connected at the same time could affect the frequency of the NuPhy disconnections. The community report is titled: “Air75 V3 randomly disconnects on macOS 27 Developer Beta (works perfectly on Windows & iOS 27)” I am including the link to that report with this feedback as supporting information. Importantly, that report involves different NuPhy hardware and a different Mac, but its LE Link disconnected (reason 708) log message closely matches the reason 708 observed independently on my Kick75. This suggests the issue may affect more than one NuPhy Bluetooth LE HID keyboard model under macOS 27. Summary My own reproducible observations are: Same M1 MacBook Pro Same NuPhy Kick75 Same physical environment Stable Bluetooth operation on macOS 26 Frequent disconnections immediately after upgrading to macOS 27 Approximately 2–3 disconnections per hour Keyboard Bluetooth indicator confirms actual link loss bluetoothd confirms an LE HID disconnection RSSI was approximately -37 dBm immediately before the disconnection macOS records reason 708, result 307, and subsequently attempts to reconnect An independent NuPhy Air75 V3 report on macOS 27 also contains LE Link disconnected (reason 708) Taken together, these observations suggest a possible Bluetooth LE HID compatibility regression introduced in macOS 27. I can provide additional Bluetooth diagnostics, a sysdiagnose, and reproduce the issue with Apple's Bluetooth debug logging profile enabled if required.

Hi all, This has been bothering me for quite a while. Basically my new iMac (bought for a few months only) started to crash randomly. I went to the genius bar and they couldn't do anything to identify the issue, I tried reinstalling the OS and even reinstalling an older version of Mac OS as well, but still seeing this issue. Today it happened twice and below are the details: Mac specs: Model Name: iMac  Model Identifier: iMac20,1  Processor Name: 10-Core Intel Core i9  Processor Speed: 3.6 GHz  Number of Processors: 1  Total Number of Cores: 10  L2 Cache (per Core): 256 KB  L3 Cache: 20 MB  Hyper-Threading Technology: Enabled  Memory: 16 GB  Boot ROM Version: 1554.100.64.0.0 (iBridge: 18.16.14556.0.0,0)  Serial Number (system): xxx  Hardware UUID: xxx  Activation Lock Status: Enabled The DiagnosticReports around the time it crashed has a lot of files with .gpuRestart, e.g.: Kernel_2021-04-27-213412_Zhuzengs-iMac.gpuRestart and file WindowServer_2021-04-27-213319_Zhuzengs-iMac.userspace_watchdog_timeout.spin in between. The details of the the first gpuRestart file Tue Apr 27 21:32:13 2021 Event: GPU Reset Date/Time: Tue Apr 27 21:32:13 2021 Application: Path: Tailspin: /Library/Logs/DiagnosticReports/gpuRestart2021-04-27-213213.tailspin GPUSubmission Trace ID: 0 OS Version: Mac OS X Version 10.15.7 (Build 19H1030) Graphics Hardware: AMD Radeon Pro 5300 Signature: 2 Report Data: GPU Log Version: 1 Restart Channel: 18 VMPT --THE STATE OF THE DRIVER AMDRadeonX6000_AMDNavi14GraphicsAccelerator state: ENABLED PCIe Device: [3:0:0], DID=0x7340, RID=0x47, SSID=0x219 TotalVideoRAMBytes: 0x00000000ff000000 (4278190080) Uptime 21:50:05.077572 [00] Channel: GFX, last reset at 0:00:00.000000 CompletedTS = 0x005be078, SubmittedTS = 0x005be079 SentTS = 0x005be078, sent at 21:49:00.896511, ScheduledTS = 0x005be079, submitted at 21:50:03.672539 Wait for Channel 18, TS 0xef924 PendingEvent: YES NumberOfPendingCB = 1, FirstPendingTS = 0x005be079, LastPendingTS = 0x005be079 FirstPendingCB: ProcessID = 225, ProcessName = WindowServer, SubmitContext = Unknown (0) GPUAddress = 0x0000000431cef000, Size = 0x000001d3, VMID = 2 ContentValidation = PASS Buffer range 0x0 .. 0x100:c0012800 80000000 80000000 c0026900 00000081 80000000 40004000 c0026900 By searching online this seems to be happening to others as well but I failed to find a common fix for this. Any help would be hugely appreciated!!!

Hello everyone, I am the developer of a macOS window management app called NeoTiler. I am currently optimizing it entirely for Apple Silicon using Swift. I am using the Accessibility API (AXUIElementSetAttributeValue) to resize windows. While it works flawlessly on Safari and native apps, I've noticed a slight animation stutter when resizing Electron-based apps like VS Code or Discord. Has anyone experienced this specific stutter with AX APIs on M-series chips? Are there any workaround flags I should pass? Thanks!

I can not activate AX88179 anymore after I have updated my mac to version 11.5 although On 11.4 Big Sur, everything was still be ok. I also check extensionsctl list on command prompt and it shows as follows: mabook@mabooks-MBP ~ % systemextensionsctl list 2 extension(s) --- com.apple.system_extension.driver_extension enabled active teamID bundleID (version) name [state] 5RHFAZ9D4P com.asix.dext.usbdevice (1.2.0/1.2.0) com.asix.dext.usbdevice [terminating for uninstall but still running] 5RHFAZ9D4P com.asix.dext.usbdevice (1.2.0/1.2.0) com.asix.dext.usbdevice [activated waiting to upgrade on reboot] How should I deal with this problem to connect to Ethernet

At first, the MacBook Air M2 gives an "failed to personalize" error when updating, the detailed error message shown by softwareupdate shows that something related a recovery partition is wrong. The exact error message is not available now. (To solve this issue) I tried to revive the Mac, but it failed the first time and multiple tries also failed after that. The Mac is unable to boot into macOS and the Recovery. The MacUpdater.log shows the following: [12:13:52.3728] find_filesystem_partitions: recovery os container= volume= [12:13:52.3728] entering fsck_recovery_os_filesystems [12:13:52.3728] ramrod_display_set_granular_progress_forced: 29.000000 [12:13:52.3728] fsck_recovery_os_filesystems: No dev node for 'Recovery' partition [12:13:52.3728] leaving fsck_recovery_os_filesystems, returning 26 [12:13:52.3728] [04:13:49.0882-GMT]{3>6} CHECKPOINT FAILURE:(FAILURE:26) MOUNTED:[0x1605] fsck_recovery_volume [0]D(failed to fsck recovery OS filesystems) Since there are many important data on the Mac, I cannot do a restore on it. How should I restore the data?

We develop a third-party endpoint security agent (DLP / device control). It needs kTCCServiceBluetoothAlways to enumerate paired Bluetooth devices and disconnect them selectively based on policy — without user interaction, since this runs unattended on managed fleets. Until recently we granted this silently via a com.apple.TCC.configuration-profile-policy (PPPC) profile pushed by MDM, or by writing directly to the TCC database — the latter no longer possible starting with macOS 27 (Golden Gate). As of macOS 27, tccd also ignores the PPPC profile approach: Override: skipping kTCCServiceBluetoothAlways ... as it is defined in deprecated PPPC profile As a result, end users now hit the standard Bluetooth access consent popup, which we have no way to suppress or pre-answer with Allow. ** Questions: ** Is there any currently supported MDM mechanism — profile-based, DDM, or otherwise — to pre-approve kTCCServiceBluetoothAlways for a specific managed app, so the popup never appears? If direct pre-approval is gone for good, is there any supported way to auto-answer the popup on the user’s behalf via policy (as exists for some other TCC services)? Is this now permanently interactive by design, or is a replacement mechanism planned for MDM-managed Bluetooth access?

while resizing screen on mac, start getting this weird error [API] cannot add handler to 3 from 3 - dropping All lazyVgrids fail to show afterwards then app crashes if you keep resizing. This error started with macOS Ventura. Any help much appreciated.

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?

To invite external testers for my Mac application with TestFlight I fellow the instructions from Apple Store Connect web page. https://developer.apple.com/help/app-store-connect/test-a-beta-version/invite-external-testers#invite-testers-using-a-public-link Test a beta version Invite external testers Invite external testers using a public link or email 9. After adding all your criteria, click Confirm. Then, copy the link and share it on social media, messaging apps, email, or any other channel. I found one reference about it: Share the link anywhere on social media, Slack, Discord, or email campaigns. I was not able to find anywhere in Discord to invite testers... Can you let me know how to work in Discord or "on social media, messaging apps, email, or any other channel" Please give me some link... Thank you.

Hello! I am wondering if anyone else is experiencing a significant CPU drain from Spotlight (specifically corespotlightd) in macOS 11.2.2. Since updating to macOS 11.2.2 any time that I access spotlight using Command + Space Bar I immediately experience a system wide lag. Viewing this in Activity Monitor I see a %CPU spike of corespotlightd in the realm of 200-400%. that last for anywhere from 5 to 15 seconds. I have sent this in through Feedback Assistant, but no other reports seem to have been linked to the radar. I have attempted a few different fixes as well: Terminal killall corespotlightd resolves the issue momentarily, but does not fix long term Restarting computer does nothing to solve Re-indexing spotlight does not solve I have also disabled more advanced search functions (Bookmarks and History, Contacts, Events and Reminders, Fonts, Mail &amp;amp; Messages, Music, Siri Suggestions, and Movies are all disabled) - This did not fix the issue. I have also disabled search for external hard drives which also did not solve the issue. Open to any other suggestions for fixes, or if anyone else has a similar issue. Mac mini, 2018 (2020 release), 3.2 GHz 6-Core Intel Core i7, 32 GB 2667 MHz DDR4. External GPU Radeon RX 570 4 GB.

I'm encountering a bug developing a (Thunderbolt) PCIDriverKit dext. The system runs well for a while, and then the hardware instance is shut down by the OS (Sonoma 14.7.6) for some unknown reason, but the dext is not, so hardware reads return 0xFFFFFFFF (device disconnected). There is no crash report, or diagnostic report. I don't see anything related in a sysdiagnose capture. The only hint I can find is the kernel logs indicate: 2026-07-01 16:18:15.929 Df kernel[0:139] (AppleT8122PCIeC) apciec[pcic1-bridge]::handleCompletionTimeoutInterrupt Completion timeout detected at address 0xe00510020 2026-07-01 16:18:15.929 Df kernel[0:139] (AppleT8122PCIeC) apciec[pcic1-bridge]::handleCompleterAbortInterrupt Completer Abort received (pri_status = 0x00100407, sec_status = 0x200000f0): 2026-07-01 16:18:15.929 Df kernel[0:139] (AppleT8122PCIeC) apciec[pcic1-bridge]::handleCompleterAbortInterrupt * Received Master Abort on a link side of the Root Complex That address (0xe00510020) looks like it's our PCI device (at a BAR0, offset 0x0020) read. What does this error explicitly mean? Did the device take too long to respond to the read request? After the event, every device on that Thunderbolt bus is disconnected, and a reboot seems to be required. Hardware is a 14" 2023 MacBook Pro M3.

I updated my OS to Tahoe 26.5 several days ago. Now, I'm developing a new macOS application under it. What I notice about it is that it can take the application at several seconds to select a file or a folder with NSSavePanel, NSOpenPanel and .fileImporter. First, I thought it's just my application. But it's not. Preview acts the same. First, a progress wheel keeps rolling several seconds. Then it will disappear, and you won't be able to select a folder for another several seconds. Why do they make it more difficult to use every time they release a new OS version? Why don't Reviewers notice when they test it? Wait for 10 seconds or more just to select a file or a folder? It's disappointing. I wish I could go back to macOS 15.7.

would like to enable Apple touschscreens to measure a set of bio parameteres through NDR (negative differential resistance) at the finger tip, whereas the proprietary measurement therapeutically channels out current out of the finger

Dear Apple Support, I would like to raise a concern regarding the behavior of the “Desktop & Documents Folders” feature in iCloud Drive. From a business and development standpoint, the fact that folders may be automatically moved or created without clear and explicit user awareness is quite concerning. File system behavior is something users generally expect to remain predictable and fully under their control. In particular, when working in development environments, even small and unintended changes to folder structures can lead to issues such as broken file paths, build errors, or inconsistencies in project setups. The possibility that such changes may occur automatically introduces an element of uncertainty that is difficult to manage in professional workflows. Additionally, there are security considerations. For example, if sensitive files such as configuration data or API keys are temporarily stored on the Desktop, the possibility that they could be unintentionally synced to the cloud raises valid concerns. Even if safeguards exist, the lack of clear visibility and explicit confirmation makes it difficult to confidently assess and manage risk. Overall, the current behavior gives the impression that folder operations may occur without sufficient transparency. From a business perspective, this impacts trust, predictability, and operational reliability. I would appreciate consideration of the following improvements: Clear and explicit communication before any folder movement or creation occurs A strictly opt-in model with unambiguous user consent Greater visibility into when and how synchronization affects local files Options to ensure fully local control over specific directories Thank you for your attention to this matter. I hope this feedback will contribute to improving the reliability and transparency of the feature. Sincerely,

In macOS Tahoe 26.2 an RDMA capability was added for Thunderbolt-5 interfaces. This has been demonstrated to significantly decrease the latency and maintain bandwidth for "clustered" Apple Silicon devices with TB5. What is the ideal and the maximum RDMA burst width for transfers over RDMA-enabled Thunderbolt-5 interfaces?

My phone's charging port is fried. It only charges wirelessly. Fixing it costs the same as the phone. I currently am having a lot of issues enrolling for apple developer program as well, so I can't use test flight right now. I want to enable developer mode on my phone, but it's never been connected to xcode before, so the option is not available. How do I enable developer mode without being able to connect it to a pc? I have a mac, and both my mac and iphone are on the same apple id. thank you

I'm relatively new to Swift development (and native iOS development for that matter) I've got an iOS app that uses the iPhone / iPad built in cameras, and am looking to make this more compatible with macOS. Using the normal AVCaptureDevice.DiscoverySession I seem to get the iPhone Continuity Camera and the in-built MacBook Pro camera but I don't see other input devices that I see in QuickTime Player (for example) such as connected external cameras or Virtual Inputs provided by NDI Virtual Input and OBS. Is there a way to see access these without a specific Mac build (as the rest of the functionality works great, and I'd rather not diverge the codebase too much as it's easier to update one app than two!

I need to use Xcode version 16 for a college project. However, I cannot install it on my mac. M2Pro - ios Tahoe 26.2. Is there any workaround for this? Is my best option to downgrade to Sequoia? I'm a little apprehensive about this but willing to give it a try. Can anyone recommend a good, reliable video for this?

Summary On Mac Studio systems (no built-in camera), macOS does not initialize camera services after a normal reboot if no physical camera is present. As a result, Continuity Camera does not appear anywhere in the system. Observed behavior System Information → Camera reports “No video capture devices were found.” Continuity Camera (iPhone) is completely absent from camera lists. Plugging in any USB UVC webcam immediately initializes camera services and causes both the USB camera and the iPhone (Continuity Camera) to appear. The USB camera can then be unplugged and Continuity Camera continues working until the next reboot. Reproduction steps Use a Mac Studio (no built-in camera) on recent macOS. Ensure no USB webcam or external camera is connected. Reboot the Mac normally. After login, open System Information → Camera. Expected Camera services should initialize even when no physical camera is present, allowing Continuity Camera to be available as the primary camera. Actual No camera devices are present unless a physical USB camera is connected at least once after boot. This reproduces 100% of the time on Mac Studio and appears to be a camera service bootstrap issue where Continuity Camera cannot be the first camera device. Issue has been filed via Feedback Assistant.

Previously discussed in beta:https://forums.developer.apple.com/message/330295This process stops responding every day it seems, I'm running 10.14.3 (18D109)When the process hangs, its Open Files and Ports include the following:txt /Library/Preferences/Logging/.plist-cache.ZP6RP0OT txt /private/var/db/timezone/tz/2018i.1.0/icutz/icutz44l.dat txt /usr/share/icu/icudt62l.dat txt /private/var/folders/35/dgpwsg457w17gs77hssnrbnw0000gn/0/com.apple.LaunchServices-231-v2.csstoreThose are not open when the service is running (before it hangs)Would like to know how frequently this hangs for everyone else and get steps to troubleshoot if possible.