I am seeing a repeatable interaction between audio activity or audio-device discovery and a Bluetooth LE HID mouse on a Mac mini M2 Pro. Opening the detailed Sound panel in Control Center, or changing the HDMI audio output, makes the pointer stutter. Opening Apple’s Music.app has also caused a temporary complete loss of the mouse. In the worst cases, the mouse becomes completely unavailable and does not recover without Bluetooth troubleshooting or re-pairing. Configuration Mac mini Mac14,12, Apple M2 Pro, 32 GB RAM macOS Tahoe 26.7 (25G229) Also reproduced on macOS Tahoe 26.1 (25B78) Logitech MX Anywhere 3 Mac over Bluetooth LE VID 0x046D, PID 0xB025 Firmware MPM24.01_0015 Logitech MX Keys M Mac over Bluetooth LE PL4071UH display and audio output over HDMI Logi Options+ installed Trigger Connect the MX Anywhere 3 Mac and MX Keys over Bluetooth. Open Control Center from the menu bar. Open the detailed Sound panel, or change the HDMI audio output. Move the Bluetooth mouse continuously while audio-output discovery is taking place. The issue is intermittent, but it has been reproduced several times on both macOS 26.1 and 26.7. Pointer stuttering can continue after the Sound panel is closed. A later incident occurred when I opened Apple’s Music.app. The Bluetooth mouse became unavailable again, but this time it recovered automatically after approximately ten seconds. The Sony WH-1000XM6 headset was connected over Bluetooth, while the 512 GB USB flash drive was not connected. This shows that the USB drive is not required for a temporary mouse loss and makes concurrent Bluetooth audio activity a more relevant condition to investigate. The additional trigger suggests that the problem may not be limited to the Control Center interface itself and may also be associated with audio-subsystem initialization or audio-device activity. This is an observation, not yet a confirmed causal link. Additional condition in the permanent-loss cases In every incident where the mouse did not recover on its own and became effectively unusable, the following two devices were also present: a Sony WH-1000XM6 wireless headset connected over Bluetooth; a 512 GB SanDisk USB flash drive connected to the Mac. I am reporting this as a correlation, not as a confirmed cause. The headset adds simultaneous Bluetooth audio activity. The USB drive may or may not be relevant depending on its USB mode, activity, shielding, physical location, and possible 2.4 GHz interference. The 512 GB capacity is included only to identify the device. Less severe cursor stuttering has also been observed around Sound-panel discovery; the two devices above are specifically the common condition I recorded during the permanent mouse-loss incidents. Observed result The pointer starts stuttering and raw mouse HID reports develop multi-second gaps. In severe incidents, the Bluetooth mouse stops working entirely. Opening Music.app has also caused a temporary complete loss of the mouse; during that incident the Sony WH-1000XM6 was connected over Bluetooth, the USB flash drive was not connected, and the mouse recovered automatically after approximately ten seconds. Logi Options+ then displays the mouse as inactive. The mouse disappears from the IOHID tree, while the Bluetooth keyboard can remain present. A wired USB mouse remains responsive, so the Mac and pointer rendering are not completely frozen. The failure can persist after the Sound panel is closed. Relevant logs On macOS 26.7, bluetoothd repeatedly recorded the following sequence for the MX Anywhere 3 Mac: MX Anywhere 3 Mac needs low latency current connection parameters: interval 30.00 ms, latency 0 connection changed to: interval 7.50 ms, latency 44 Device "MX Anywhere 3 Mac" is Incompatible LE HID Device "MX Anywhere 3 Mac" does not have _HID_SERVICE_ Connection timed out disconnect result: 307 BLEPaired HIDBadBehavior Central The sequence repeated during automatic reconnection attempts. The mouse later recovered on some occasions, but other incidents required turning Bluetooth off for about 15 seconds, turning it back on, forgetting the mouse, and pairing it again. Instrumented reproduction During a monitored reproduction on macOS 26.1: detailed audio discovery started at +21.333 s; a 2.400 s gap in raw HID reports from the mouse occurred 0.899 s before that event; bluetoothd then reported a HID lag issue for VID 0x046D, PID 0xB025 at +1.897 s; no display-frame gaps were detected; there was no sustained CPU saturation. This indicates that the interruption is already present in the raw HID input stream. It does not appear to be only a cursor animation or WindowServer rendering delay. Expected result Discovering or switching audio outputs should not alter a separate BLE HID mouse connection, cause multi-second HID report gaps, remove _HID_SERVICE_, or disconnect the mouse. Technical points for investigation Could this be a macOS Bluetooth/HID connection-parameter or service-discovery problem triggered by concurrent audio discovery? In particular, why does macOS change the mouse from 30 ms / latency 0 to 7.5 ms / latency 44, then classify it as Incompatible LE HID, lose _HID_SERVICE_, and eventually disconnect it with result 307? Has anyone reproduced the same sequence with a Logitech BLE mouse, a Bluetooth audio headset, or a USB 3 storage device connected? The issue was also submitted through Apple’s public macOS feedback form on 24 September 2026. That form confirmed receipt but did not provide an FB case number. Possibly related report Another Developer Forums report describes a different BLE HID device with Incompatible LE HID and disconnect result 307 on macOS 27. The hardware and trigger are different, but the Bluetooth/HID failure signature may be related: https://developer.apple.com/forums/thread/845857

We occasionally observe es_mute_process_events() called on an es_client_t while an AUTH event delivered by the same client is still outstanding. In the problematic state, es_mute_process_events() stops returning inside IOConnectCallStructMethod. Subsequent calls to es_respond_flags_result() and a fallback es_respond_auth_result() on the same es_client_t also block in IOConnectCallStructMethod, eventually causing the AUTH deadline to be missed. We would like to clarify the concurrency semantics of these APIs: Is it supported to call es_mute_process_events() before responding to an outstanding AUTH event delivered by the same es_client_t? Can es_mute_process_events() wait for in-flight/outstanding AUTH processing? Are mute operations and es_respond_*() calls serialized internally for a single es_client_t? Can an in-progress mute operation prevent a concurrent es_respond_*() call from completing? Is the recommended pattern to respond to the AUTH message first and update mute state asynchronously afterward?

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?