Dear Apple, It looks likes Apple like my new idea, and a lot. I know this as Apple always want their things to be easily understandable, and for MagSafe to be understandable it has to mimic macOS. I got an unreliable reply for the first post, just a person telling me I’m in the wrong place for this. The MagSafe is amazing, but everything needs to be upgraded in some way or the other, DTS engineers are saying that developer forums are for developing, not feedback. So here I am, developing the MagSafe wire, as I would by now rather get a third-party MagSafe wire if mine possibly breaks. $49. This is the price tag for an official MagSafe wire. If it can’t show anything but charging and charged, it’s something that must be reproduced. We have the hardware, we have the red and green diodes in the MagSafe, we just need to turn both of them on to make yellow. We have the hardware, and physics is helping us by saying: “Red + green light = yellow light.” This isn’t as complicated as π, so please implement it and let over 100 million users feel that MagSafe is finally worth the price. It is extremely simple, no new tests, no new safety certifications, just a new code you can forget about once released. To make things as easy as possible, here is the code, you can inspect it and test it, it should be OK. (THIS CODE IS TO SHOW THE BASE OF THE IDEA, PLEASE DONT COPY-PASTE, DOUBLE CHECK IT FIRST. Consider that I didn’t code this myself, I got help. Don’t expect any code from me to be mine) #include <stdbool.h> #include <stdint.h> typedef enum { MODEL_AIR, MODEL_PRO } MacModel; typedef enum { LED_OFF, LED_SOLID_AMBER, LED_SOLID_YELLOW, LED_SOLID_GREEN, LED_PULSING_AMBER, LED_PULSING_YELLOW } LEDState; uint32_t current_cycle_seconds = 0; MacModel get_mac_model(void); uint8_t get_battery_soc(void); uint8_t get_charge_limit(void); uint32_t get_charger_wattage(void); bool check_hardware_faults(void); void apply_led_hardware_state(LEDState state, bool pin_high); void update_magsafe_led(void) { MacModel model = get_mac_model(); uint8_t soc = get_battery_soc(); uint8_t limit = get_charge_limit(); uint32_t wattage = get_charger_wattage(); bool overcharge_fault = (soc > (limit + 2)); bool critical_error = check_hardware_faults() || overcharge_fault; bool slow_charger = false; if (model == MODEL_AIR && wattage < 30) { slow_charger = true; } else if (model == MODEL_PRO && wattage < 70) { slow_charger = true; } LEDState normal_state; if (soc >= 90 || soc >= limit) { normal_state = LED_SOLID_GREEN; } else if (soc >= 50) { normal_state = LED_SOLID_YELLOW; } else { normal_state = LED_SOLID_AMBER; } LEDState active_state = normal_state; bool should_pulse = false; if (current_cycle_seconds < 10) { if (critical_error) { active_state = LED_PULSING_AMBER; should_pulse = true; } else if (slow_charger) { active_state = LED_PULSING_YELLOW; should_pulse = true; } } bool led_pin_high = true; if (should_pulse) { if (current_cycle_seconds % 2 != 0) { led_pin_high = false; } } apply_led_hardware_state(active_state, led_pin_high); current_cycle_seconds++; if (current_cycle_seconds >= 20) { current_cycle_seconds = 0; } } (THIS CODE IS TO SHOW THE BASE OF THE IDEA, PLEASE DONT COPY-PASTE, DOUBLE CHECK IT FIRST. Consider that I didn’t code this myself, I got help. Don’t expect any code from me to be mine) This should show: Pulsing Amber for critical issues Pulsing yellow for slow chargers, under 30w for Macbook air and if under 70w for Macbook pro. Pulses for 10 seconds, and shows the light of the battery percentage for 10 seconds. Amber: 0-50% battery Yellow: 50-90% battery Green: 90%+ battery or reached charging limit. Please consider this code, I prefer a reply if possible to keep track of the new MagSafe update. macOS is amazing, but there are always final touches to be added, and if the hardware can be as similar as possible to the software, this is what brings understanding the battery alive, and apple has always wanted macOS to be as understandable as possible, why not the wire as well? If you need any extra information for the MagSafe, feel free to reply to me on the forum, I will try replying as soon as possible. Let the MagSafe glow. Let it show a yellow. It’s WWDC, and here I am right here. Let 2026 be the year where MagSafe is the most understandable yet, and let the yellow color come alive to MagSafe. Please consider it another chance to get a fresh, serious and realistic start to this. I am more than ready to mark the other post as answered if I get a realistic, understandable and useful reply to this. I apologize if my previous responses weren't very useful; I am not a formally trained engineer, but I wanted to show my idea the best way I could. May I please get a proper reply? Im extremely sorry for my previous replies that lost me reputation, but I promise I won’t reply to other posts from now on. May I please get a proper reply? May my idea get supported? May MagSafe feel as good as the magnetic “snap”? Please keep in mind that im in developer forums to develop the MagSafe wire, and as the DTS engineer stated in their reply: “ These forums are for questions about developing software and accessories for Apple platforms. If this is the case then feel free to provide more information,” In this thread here. There I am. Developing an accessory. MagSafe. I have been using macOS for about a year now, I noticed this flaw since a long time, and here I am, getting it out and loud to Apple in WWDC. Please do not count this as spam, or a repost of my original idea, I am conscious of what im currently doing, so please give this a good read and a caring, useful reply. I really hope you consider this and make MagSafe stand out, alongside the MacBook Neo. It was amazing. Unstoppable. But why not the MagSafe be as well? All the best, Alyaman

MacOS Music App No Longer Accepts "Play Next" and "Add to Up Next" from iTunes Remote app. Connect to your library through the iTunes Remote App. Navigate to a song within the iOS iTunes Remote App and press and hold on the song and when the action sheet comes up select "Play Next" or "Add to Up Next". View the MacOS Music App's Playing Next queue to discover that the additions were not made. Thanks for any help you can provide on this. I'd really love to see this working again. I captured network traffic (tcpdump) between the iTunes Remote iOS app and Music.app on macOS 26 (Tahoe). When tapping "Play Next" on a track, the Remote app sends: GET /ctrl-int/1/playqueue-edit?command=add&query='dmap.itemid:27387'&sort=album&mode=3 Music.app responds with HTTP 404 Not Found. "Add to Up Next" sends the same endpoint with mode=0 and also receives 404 Not Found. Other Remote app functions work correctly over the same connection (play/pause, skip), browsing the library, and viewing the queue all return successful responses. Only the queue-add operation returns 404.

Hello, On Mac OS monterey, OSSystemExtensionRequest.deactivationRequest is failing with deactivation request for com.xxxxxx.networkextensionapp.netextension failed authorization check, error: Error Domain=OSSystemExtensionErrorDomain Code=13 "(null)" Even after providing the correct credentials for authorisation when prompted for.

I've got a single-window app whose main ContentView is a table of records. It has some menu commands, defined in my App file, that allow record-level operations (add, delete, process, etc). It also uses some framework-provided editing views (i.e. TextFieldView) for individual fields on each record. I'm having a lot of trouble implementing undo/redo. The menu commands don't have access to the Environment to obtain the undoManager there. The undoManager is nil during onAppear of the ContentView, so I can't set it into my view model before running some user-initiated action on the view itself. If I wire up custom Undo/Redo menu items with my own UndoManager, the TextFieldView undo no longer works. I even tried getting at the underlying NSWindowDelegate to provide my own UndoManager in windowWillReturnUndoManager, but that never gets called. What's the correct pattern to use here?

I have an app for iOS already on the AppStore and I'm trying to add a macOS version of it. The AppID prefix for this app is different than my Team ID. This mismatch was always fine for submitting my iOS app. However for some reason, the macOS version gets rejected when I upload it. It tells me the AppID prefix must match my Team ID. I do not control my TeamID and I do not control my AppID prefix, they are both given to me by Apple. Yet the error message tells me they must match. How do I get past this? Here is the error message: Validation failed Invalid code signing entitlements. Your application bundle's signature contains code signing entitlements that aren't supported on macOS. Specifically, the "APPID_PREFIX.MY_BUNDLE_ID" value for the com.apple.application-identifier key in "MY_PACKAGE" isn't supported. This value should be a string that starts with your Team ID, followed by a dot ('"), followed by the bundle ID. (ID: 930b77ae-099f-4798-a14a-2803f2a9be9e) Thanks in advance for any pointer.

Hi, We are looking for guidance on synchronizing a user’s login keychain passphrase after changing that user’s local account password, when the user is not currently logged in. Context We have an MDM product for macOS, and we sometimes need to change a local account password while that user is not logged in. Updating the account password itself from our privileged daemon is fine. The hard part is keeping their login keychain in sync — that only seems to work when we run as that user, in their own session. So we perform the keychain update from a per-user LaunchAgent, not from root. What works (user is logged in) From the user’s LaunchAgent we run: # 1) Change account password (if not already changed) dscl . -passwd "/Users/<username>" "<currentPassword>" "<newPassword>" # 2) Sync login keychain passphrase security set-keychain-password -o "<currentPassword>" -p "<newPassword>" login.keychain-db With correct current/new secrets, this succeeds when the helper is running as that user while they are logged in. What fails (user is not logged in) Starting the same LaunchAgent for that user fails with: Bootstrap failed: 125: Domain does not support specified action So we cannot get user-context execution for the keychain update while the user is not logged in. Approaches we already tried Post-login LaunchAgent — We stage the current/new passwords and install a LaunchAgent that runs after the user logs in to migrate the keychain. By the time the user is logged in and the agent runs, macOS has already created a new login keychain and renamed the previous one (e.g. login.keychain-db-renamed-N). At that point we can no longer reliably migrate/restore the original keychain. sudo -u <username> security set-keychain-password … from a root daemon — Led to Keychain Access / keychain state corruption in our testing; we do not consider this a production path. Delete the login keychain — Works as a reset, but discards saved credentials. Acceptable for some admin reset flows; not acceptable for a password change where we know both secrets and want to preserve the keychain. Ask Is there a supported way to update login.keychain-db for a user who is not logged in, given known current and new passphrases, without deleting the keychain? If so, what is that way? If not is there a way to merge the old login keychain as we have the old password too? Also please confirm whether updating another user’s login keychain from root / sudo -u is unsupported, so we can exclude it from product design. Happy to provide sanitized logs (error 125, security failures, renamed keychain timelines) if useful. Thanks.

See crash details here:- https://pastebin.com/i9u5PE4X There's a comprehensive thread here, folks! https://discussions.apple.com/thread/255651156?sortBy=oldest_first Thanks for any thoughts.

Hello, I am currently developing a printed data security feature for a cross-platform DLP system. On other platforms, this functionality relies on a cross-platform third-party library. On macOS, this library depends on the Core Graphics and AppKit frameworks. So, such dependency makes it impossible to use the code within a launch daemon, which is where this mechanism needs to run. As an alternative approach, I am considering implementing the necessary functionality inside a CUPS filter. However, I have some doubts regarding the execution context of the CUPS filter process. Is it safe to use AppKit within a CUPS filter? Thank you in advance.

Filed FB24179855 for this. Posting here so others hitting similar limitations can track and/or reference it (Apple's triage reportedly weighs duplicate count). Issue <stdbit.h>, the C23 standard header for bit-manipulation utilities (stdc_leading_zeros, stdc_count_ones, stdc_bit_width, etc.) from C23 §7.18, is not present in the macOS SDK libSystem. Worth noting this is a libc/SDK gap, not a compiler gap. Apple Clang accepts -std=c23 fine, and <stdckdint.h> (also C23, also library-level, e.g. ckd_add) is already present and working correctly. So C23 library headers are clearly being landed in libSystem incrementally. stdbit.h just hasn't made it in yet. If anyone's found a workaround (other than falling back to __builtin_clz/__builtin_popcount etc.) or has visibility into whether this is scheduled, would be good to hear. Repro #include <stdbit.h> int main(void) { return stdc_leading_zeros((unsigned)0); } $ /usr/bin/cc -std=c23 repro.c repro.c:1:10: fatal error: 'stdbit.h' file not found 1 | #include <stdbit.h> | ^~~~~~~~~~ 1 error generated. Environment Apple clang version 21.0.0 (clang-2100.1.1.101) Target: arm64-apple-darwin25.6.0

That is not exactly a development issue, but more a Mac configuration (which may hide other problems ?). I use a new MacBookAir with MacOS 26. When I Airdrop from another Mac (15.7.8) the MacBookAir does not show any icon but a blank area, whilst other devices show their icons: That seems an old issue with MacBookAir: https://www.reddit.com/r/macbookair/comments/1benu4o/blank_airdrop_icon/ Beside this, Airdrop works OK. Just as if the MacBookAir icon was missing in some system file ? Has anyone a solution ? I filed a bug report FB24034384

In the below code, I create two windows, and use a window delegate to make sure that whenever the first is fullscreened, its menubar and dock are hidden properly. However, when I fullscreen the first window and go back to the desktop to see my second window, the second window's minimize button is grayed out and using miniaturize on it will not work either. I've tried various things; it seems like if I fullscreen the second window and the unfullscreen it, it then becomes minimizable without additional side effects. Is there any reason why this is happening? This seems like a bug in AppKit... so how do I work around it programmatically? #import <Cocoa/Cocoa.h> @interface AppDelegate : NSObject <NSApplicationDelegate, NSWindowDelegate> @property (strong) NSWindow *mainWindow; @property (strong) NSWindow *secondaryWindow; @end @implementation AppDelegate - (void)applicationDidFinishLaunching:(NSNotification *)aNotification { NSRect mainRect = NSMakeRect(100, 300, 400, 300); self.mainWindow = [[NSWindow alloc] initWithContentRect:mainRect styleMask:(NSWindowStyleMaskTitled | NSWindowStyleMaskClosable | NSWindowStyleMaskMiniaturizable | NSWindowStyleMaskResizable) backing:NSBackingStoreBuffered defer:NO]; [self.mainWindow setTitle:@"Main Window (Go Fullscreen Here)"]; [self.mainWindow setDelegate:self]; NSTextField *mainLabel = [NSTextField labelWithString:@"1. Click the green zoom/fullscreen button on THIS window.\n\n2. Look at the other window's yellow minimize button."]; [mainLabel setFrame:NSMakeRect(20, 100, 360, 100)]; [[self.mainWindow contentView] addSubview:mainLabel]; [self.mainWindow makeKeyAndOrderFront:nil]; NSRect secondaryRect = NSMakeRect(550, 300, 400, 300); self.secondaryWindow = [[NSWindow alloc] initWithContentRect:secondaryRect styleMask:(NSWindowStyleMaskTitled | NSWindowStyleMaskClosable | NSWindowStyleMaskMiniaturizable | NSWindowStyleMaskResizable) backing:NSBackingStoreBuffered defer:NO]; [self.secondaryWindow setTitle:@"Secondary Window (The Victim)"]; NSButton *testButton = [NSButton buttonWithTitle:@"Try code [window miniaturize:]" target:self action:@selector(attemptProgrammaticMinimize:)]; [testButton setFrame:NSMakeRect(80, 130, 240, 40)]; [[self.secondaryWindow contentView] addSubview:testButton]; [self.secondaryWindow makeKeyAndOrderFront:nil]; } - (NSApplicationPresentationOptions)window:(NSWindow *)window willUseFullScreenPresentationOptions:(NSApplicationPresentationOptions)proposedOptions { return NSApplicationPresentationFullScreen | NSApplicationPresentationHideMenuBar | NSApplicationPresentationHideDock; } - (void)attemptProgrammaticMinimize:(id)sender { [self.secondaryWindow miniaturize:nil]; NSLog(@"[Repro] Minimize attempted"); } - (BOOL)applicationShouldTerminateAfterLastWindowClosed:(NSApplication *)sender { return YES; } @end int main(int argc, const char * argv[]) { @autoreleasepool { NSApplication *app = [NSApplication sharedApplication]; [app setActivationPolicy:NSApplicationActivationPolicyRegular]; AppDelegate *delegate = [[AppDelegate alloc] init]; [app setDelegate:delegate]; [app activateIgnoringOtherApps:YES]; [app run]; } return 0; }

Hello, We are experiencing an issue where our recent notarization submissions are stuck indefinitely in the "In Progress" status, and no notarization logs are available to inspect. Here are the details for our impacted submissions: Team ID: 34AC638RKM Submission ID 1: 18020127-4742-4d5f-8f56-9742e1aab766 (Submitted: 2026-07-31 13:22 UTC) Submission ID 2: f00b0f39-8b6e-4b80-aaad-dd1690cc7d85 (Submitted: 2026-07-31 21:23 UTC) Prior submissions in June were accepted without issue using the same build pipeline and signing configuration. Is there a known backend delay with the notary service, or can an Apple engineer assist in checking the status of these submission tickets? Thank you!

We're investigating an edge case around push/local notification handling on macOS when multiple instances of the same app are running simultaneously, launched via open -n /path/to/App.app. We're aware this isn't the standard/expected usage pattern for macOS apps, which are singleton by default, but we need to understand and correctly handle this case, so any clarity here would help. Setup: macOS app, AppKit, using NSApplicationDelegate and UNUserNotificationCenterDelegate. Two separate processes of the same app launched via open -n, each independently calling UNUserNotificationCenter.current().delegate = self and registerForRemoteNotifications() on launch. Questions: Device token : is the device token unique per device and app installation, or could two separately-running processes of the same installed app each be issued a different token? Our understanding from Apple's documentation is that the token identifies the app and device combination, not a specific process. Can you confirm this holds even in a multi-instance scenario? Notification tap routing : when a notification, local or remote, is tapped and both process instances have independently registered a UNUserNotificationCenterDelegate, which instance's delegate receives userNotificationCenter didReceive withCompletionHandler? Is this deterministic, for example the most recently registered instance, or the one most recently connected to usernoted? Is it arbitrary or undefined? Or does the system only allow one instance's delegate connection to be active at a time, silently disconnecting the other? Is there any documented or recommended way for an app to detect it's running as a secondary instance launched via open -n, and adjust its notification handling behavior accordingly, if relevant? We understand this falls outside the normal supported usage pattern for macOS apps, but since the behavior isn't documented for this scenario, any insight, even confirming this is undefined behavior, would be genuinely useful for us to plan around.

Filed as FB24092251. On macOS 27.0 beta (26A5388g), clicking into any text input inside a WKWebView in a Mac Catalyst app makes focus oscillate forever and typing does nothing. CPU pegs at 100% while the editor is focused. The same binary works fine on macOS 26. The DOM element never actually loses focus. Only the window does: window focus -> activeElement=TEXTAREA.inputarea JS focus -> activeElement=TEXTAREA.inputarea window blur -> activeElement=TEXTAREA.inputarea <- window loses key status JS blur -> activeElement=TEXTAREA.inputarea <- element did not ...repeats indefinitely... Pausing during the loop shows why. Focusing the element sends WebKit into UIKit's software-keyboard machinery, on a platform that has no software keyboard: -[UIKeyboardSceneDelegate containerWindowForViewService:] -[UIKeyboardSceneDelegate _setKeyWindowSceneInputViews:animationStyle:] -[UIKeyboardSceneDelegate _reloadInputViewsForResponder:force:fromBecomeFirstResponder:] -[UIResponder(UIResponderInputViewAdditions) reloadInputViews] -[WKContentView(WKInteraction) _continueElementDidFocus:...] -[WKContentView(WKInteraction) _elementDidFocus:...] WebKit::WebPageProxy::elementDidFocus(...) Building that container steals key status from the web view. First responder ends up on the enclosing _UIHostingView, so key presses are delivered there and immediately cancelled: pressesBegan: [...], focusedItem: monacoEditor firstResponder at keypress: _UIHostingView<...> pressesCancelled: [...] The catch: -becomeFirstResponder cannot be used to recover, because it is the trigger. Calling it re-enters _elementDidFocus and re-arms the loop permanently. So there is no app-side way back — the only API that reclaims the keyboard is the one that breaks it. Minimal repro is just a WKWebView in a UIViewRepresentable inside a SwiftUI hierarchy, with any focusable . No Monaco needed. Partial mitigation, if you hit this: do not echo focus/blur commands back at the web view in response to its own focus events, and treat a blur where document.hasFocus() is false but activeElement is unchanged as a window-level blur rather than an editing-ended event. That stops the runaway loop and keeps your focus state correct — but it does not restore typing. Has anyone found a way to get first responder back to the web view without calling -becomeFirstResponder? Or a way to stop the keyboard scene delegate engaging on Catalyst in the first place? If you can reproduce on 27 beta, please file a duplicate referencing FB24092251.

MacBook Air (M4) Current build: macOS 27 Developer Beta (26A5368g) I have a system-wide Location Services failure affecting Apple Maps, Safari geolocation APIs, and any application requesting the current location. Symptoms: Apple Maps cannot determine current location. Safari and browser geolocation APIs fail. Websites report that location cannot be found. Location Services are enabled and permissions are granted. The issue has persisted across: macOS 26.5 beta macOS 26.6 beta macOS 26.6 beta 2 macOS 27 Developer Beta Troubleshooting already performed: Multiple Wi-Fi networks tested. iPhone hotspot tested. VPN enabled and disabled. Location Services reset. Permissions reset and reauthorized. New clean local user account created (no Apple ID, no third-party software). Issue reproduces identically in the clean account. Technical observations: locationd logs repeatedly show: knownCount = 0 AlsWifi = unknown while Wi-Fi scanning itself appears successful: queryMacAddresses.size = 57 The system sees dozens of nearby access points, but none appear to be recognized for Wi-Fi positioning. Additional findings: Wi-Fi hardware functions normally. Internet connectivity is normal. Bluetooth and Find My device presence work. GeoServices resources are present on disk. No successful location fix is ever produced. Has anyone seen similar CoreLocation / GeoServices behavior where Wi-Fi scans succeed but knownCount always remains 0 and no location fix is generated?

From the currently available information, it seems like the only way to get the new-in-Tahoe sidebar inspector effect is to use a NSSplitView in conjunction with NSSplitviewController & inspectorWithViewController:. I'm currently trying to get the same inspector effect - which also affects the looks of controls inside the inspector, like text fields, which switch to a gray-ish background - in a totally custom splitter-like view hierarchy that is way more complex than NSSplitView and thus cannot inherit or take advantage of it. Is there a way to integrate this effect in a custom view? Maybe using NSVisualEffectView or NSGlassEffectView?

In the past I was always able to install every major macOS version on an external drive so that I can test my apps. But now I'm unable to install macOS Tahoe 26 on an external drive. Actually, as far as I'm aware, there are not even official links to macOS 26 installers, but only instructions on how to update to macOS 26 from an existing macOS installation. So I thought I'd install macOS 15 on a separate drive and then update to macOS 26, but whenever I run the macOS 15 installer, tell it to install on the external drive, and reboot after the setup process completes, my MacBook just boots into my main macOS partition as if nothing happened. 3 months ago I somehow managed to install macOS Tahoe beta 1 on an external drive, I don't remember how (but I don't think it was anything crazy); booting into that beta 1 partition and trying to update doesn't work either, as my MacBook again boots into my main macOS partition. I already asked help about the update problem one month ago here, but nobody replied. Could someone at Apple please provide instructions on how one is supposed to install macOS 26 on an external drive (if possible before it becomes available to the public)? Are we supposed to buy a separate Mac for every macOS version that we want to test our apps on?

On macOS 27 Beta 2, a simple NavigationSplitView example exhibits bizarre behaviour when the window is resized. The sidebar seemingly expands and collapses at random as the window is resized. The symptoms can be exacerbated with toolbar items. The sidebar appears to behave correctly when an inspector view is not present. Copy paste the code below into a new Xcode 27 project and run on macOS 27 and then resize the window: File -> New -> Project... -> App import SwiftUI @main struct MyApp: App { var body: some Scene { WindowGroup { ContentView() } } } struct ContentView: View { var body: some View { NavigationSplitView { Text("Sidebar") } detail: { Text("Content") } .inspector(isPresented: .constant(true)) { Text("Inspector") } } } Adding .frame or .inspectorColumnWidth to any of the Text views does not appear to fix the issues. macOS: 27.0 Beta (26A5368g) Xcode: 27.0 beta 2 (27A5209h)

Device Details: MBP M2 Pro AND MBP M3 Pro macOS 26.3 (25D125) Xcode Version 26.3, 26.2, 26.1 (I reinstalled all 3 of these after the macOS update) BUG: Xcode hangs indefinitely when performing Source Control operations (Pull or Push) on a Git repository that uses SSH authentication. The same repository works correctly when performing the equivalent Git operations from the Terminal using the Git CLI. The issue appears to be specific to Xcode’s internal Source Control integration. When the operation is triggered from Xcode, the UI shows a spinning progress indicator and never completes. Terminal Git commands (git fetch, git pull, git push) complete normally using the same SSH key and repository. A hang sample taken during the issue shows the Xcode main thread blocked in Source Control authentication and fingerprint handling code paths, including: IDESourceControlUIHandler IDESourceControlFingerprintManager handleAuthenticationFailure showFingerprintAlertOnWindow This suggests Xcode may be waiting on a Source Control authentication or host fingerprint UI flow that never resolves. SSH connectivity itself is functioning correctly: ssh -T git@bitbucket.org and ssh -T git@github.com both authenticate successfully. git ls-remote, git fetch, git pull, and git push all work correctly from Terminal. No Source Control accounts are configured in Xcode Preferences. Authentication relies entirely on SSH keys. Steps to Reproduce Configure an SSH key for Git access (e.g., Bitbucket or GitHub) and confirm it works via Terminal. Clone or open an existing Git repository that uses SSH (git@host:repo.git). Open the project/workspace in Xcode. In Xcode, attempt a Source Control operation such as: Source Control → Pull Source Control → Push Observe that Xcode displays a spinning progress indicator and does not complete the operation. Logs available on this Feedback Assist ID: FB22146913

We have been having unexplained failures with the codesign tool recently on macosx aarch64 and x64 hosts. Every once in a while when signing an app locally using the following command: /usr/bin/codesign -s - -vvvv --force /home/me/FooBarCalculator.app results in the following error: /home/me/FooBarCalculator.app: timestamps differ by 185 seconds - check your system clock The number of seconds reported in the error message keeps varying (but usually in that range). We have checked the system clock but there isn't anything wrong (from what we can see) with the host. In fact, we have been seeing this error on several hosts now, so it isn't specific to one host. While looking into this issue, we even printed the details of an already signed binary using the following command: codesign -dvvv HelloWorld.app and that prints among other things, similar warning message: ... Timestamp=12 May 2026 at 5:36:0 AM HelloWorld.app: timestamp mismatch: internal time 12 May 2026 at 5:32:59 AM (184 seconds apart) I'm looking for inputs on how we go about debugging this issue and where/how the codesign tool sources these timestamps from (any specific API?) and what value is it comparing against to notice a difference. These affected hosts have different operating system versions some 15.x and some 26.x.