I'm trying to install Mac OS 27 on my Mac Book Pro m1 pro and I'm getting this error: I have tried from the terminal, clearing the cache, and I've tried a couple of different days and the issue still occurs. Internet connection if fine, no VPNs and nothing that should block it.

On earlier iOS versions Live Activity displays correctly according to mode set.  Can't find an opened issue for that version: iOS 26 device: iPhone 16

Hi everyone, My TestFlight build has been stuck in 'Waiting for Review' for over 32 hours and I'm hoping someone can help or share their experience. The situation: I have an External Testing group with a Public Link set up. The build was submitted for Beta App Review on March 19th but it's been over 32 hours with no update. I have 25+ testers waiting to install the app. What I've tried: Waited patiently Checked App Store Connect multiple times No rejection emails received No issues flagged by Apple Questions: Is anyone else experiencing unusually long review times for TestFlight external builds right now? Is there anything I can do to speed up the process or check if something is wrong? Has anyone successfully resolved this by contacting Apple Developer Support directly? Any advice would be greatly appreciated. Thank you! Apple Support Case ID: 102846633409

I am seeing serious issues with iPhone Mirroring on macOS 27 Developer Beta 1. Environment Mac: MacBook Pro, Apple M4 Pro Model: Mac16,7 RAM: 24 GB macOS: macOS 27.0 Developer Beta 1 Build: 26A5353q SIP: Enabled Developer Mode: Enabled iPhone: iPhone 15 Pro Max Previously tested on: iOS 27 Beta 1 Currently restored to: iOS 26.5 Issue 1: iPhone Mirroring does not connect on iOS 27 Beta 1 and can leave the iPhone unusable When my iPhone 15 Pro Max was running iOS 27 Beta 1, iPhone Mirroring on macOS 27 Developer Beta 1 did not connect properly. I tried connecting multiple times. The iPhone appeared to think that the mirroring session had started successfully, because the iPhone screen turned off as expected for iPhone Mirroring. However, the Mac never actually completed the connection and never displayed the mirrored iPhone session. After this happened, the iPhone became completely stuck and unresponsive. The phone did not respond normally, and even force restart attempts were not working. The device remained unusable until the battery fully drained, which took about two days. After the battery was fully depleted, I was able to put the iPhone into DFU mode and restore it back to iOS 26.5. This suggests that something may be broken in the iPhone Mirroring / Continuity connection state between macOS 27 Developer Beta 1 and iOS 27 Beta 1. The iPhone seems to enter a state where it believes it is connected for mirroring, while the Mac never actually establishes the session. Issue 2: iPhone Mirroring crashes on macOS 27 Developer Beta 1 when used with iOS 26.5 After restoring the iPhone 15 Pro Max back to iOS 26.5, I was able to get a crash report from the Mac side. The iPhone Mirroring app crashed on macOS 27 Developer Beta 1 with the following details: Process: iPhone Mirroring Identifier: com.apple.ScreenContinuity Version: 2.0 Build Version: 114.38.15.1 OS Version: macOS 27.0 (26A5353q) Hardware Model: Mac16,7 Exception Type: EXC_BREAKPOINT (SIGTRAP) Termination Reason: Namespace SIGNAL, Code 5, Trace/BPT trap: 5 Triggered by Thread: 2 Dispatch Queue: com.apple.root.user-initiated-qos.cooperative The crashed thread shows a Swift assertion failure inside ScreenSharingKit.framework: Thread 2 Crashed: 0 libswiftCore.dylib assertionFailure(:_:file:line:flags:) + 216 1 ScreenSharingKit 0x29fbb60e0 2 libswiftCore.dylib _swift_release_dealloc + 64 3 libswiftCore.dylib RefCounts::doDecrementSlow 4 ScreenSharingKit 0x29fa894c0 5 ScreenSharingKit 0x29fb484d8 6 ScreenSharingKit 0x29fb48614 ... 15 libswift_Concurrency.dylib completeTaskWithClosure Relevant binary image: /System/Library/PrivateFrameworks/ScreenSharingKit.framework/Versions/A/ScreenSharingKit CFBundleIdentifier: com.apple.screensharing.ScreenSharingKit CFBundleVersion: 114.38.15.1 Crash interpretation The crash appears to be a first-party Apple framework crash inside ScreenSharingKit, caused by a Swift assertion failure. It does not appear to be caused by memory pressure, Rosetta, or third-party code injection. Relevant crash report details: External Modification Summary: task_for_pid: 0 thread_create: 0 thread_set_state: 0 System Integrity Protection: enabled Memory usage also does not look excessive: Writable regions: Total=251.0M MALLOC: 128.4M Expected behavior iPhone Mirroring should either connect successfully or fail gracefully. It should not: Leave the iPhone in a stuck/unresponsive state. Put the iPhone screen into mirroring mode while the Mac never completes the connection. Require the iPhone battery to fully drain before DFU restore is possible. Crash on macOS with an internal ScreenSharingKit Swift assertion failure. Actual behavior On iOS 27 Beta 1: iPhone Mirroring never completed the connection on the Mac. The iPhone behaved as if the session started. The iPhone screen turned off. The iPhone became completely unresponsive. Force restart did not work. Device only became recoverable after battery fully drained. I then restored the iPhone to iOS 26.5 via DFU. On iOS 26.5: iPhone Mirroring was able to run, but the Mac-side app later crashed. The crash occurred inside Apple’s ScreenSharingKit.framework. The crash type was EXC_BREAKPOINT (SIGTRAP) from Swift _assertionFailure. Reproducibility Partially reproducible. iOS 27 Beta 1 + macOS 27 Developer Beta 1: connection repeatedly failed and eventually left the iPhone stuck. iOS 26.5 + macOS 27 Developer Beta 1: iPhone Mirroring can connect, but the Mac app crashed with the attached report. Crash identifiers Incident Identifier: B6D4D86D-03C4-4466-B9D6-4CF70DF0B46F Crash Reporter Key: 8BD85D40-8AC8-E771-2D80-153D7C4C5366 Process: iPhone Mirroring [11429] Bundle ID: com.apple.ScreenContinuity The crash report points to ScreenSharingKit.framework, so this looks like a possible beta regression in the iPhone Mirroring / Continuity stack.

Hello Apple Developer Support, After updating my iPad to iPadOS Beta 27, the Notes+ app has started crashing frequently. This issue did not happen before the system update. The app often crashes when I open notes, edit content, or try to use files inside Notes+. Another serious issue is that I cannot properly download or import files from iCloud Drive into Notes+. When I try to select a file from iCloud Drive and add it to Notes+, the process may fail, freeze, or cause Notes+ to crash. This has made Notes+ very difficult to use on iPadOS Beta 27. I rely on Notes+ for study notes, file organization, and daily productivity, so this problem has a big impact on my normal use. Steps to reproduce: 1.Use an iPad running iPadOS Beta 27. Open the Notes+ app. 2.Open or edit an existing note. 3.Try to import or attach a file from iCloud Drive. 4.Notes+ may freeze, fail to import the file, or crash. Expected result: Notes+ should run normally, and files from iCloud Drive should be imported into Notes+ successfully. Actual result: Notes+ crashes frequently, and iCloud Drive files cannot be imported reliably. This issue started after updating to iPadOS Beta 27. Please check the compatibility between iPadOS Beta 27, Notes+, and iCloud Drive file importing. Thank you.

Retrained Siri multiple times, turned off and on, hard reboots, cannot clear the badge on Settings icon asking to reset Siri. Siri working, new Siri on waitlist. How to clear? IOS 27 beta 1, iPhone 17 Pro.

The documented template for @AppEntity(schema: .messages.message) at Integrating your messaging app with Apple Intelligence and on the MessagesEntity.message reference page shows: var reaction: <#ReadReaction#>? with <#ReadReaction#> rendered as a placeholder (the Xcode placeholder syntax). A natural reading is "fill in your own type that you want to use here". I tried several: Tapback? where Tapback is @AppEnum(schema: .messages.customReaction) MessageReaction? (same, renamed) MessageReaction? with manual AppEnum conformance (no schema decoration) AttributedString? AttributedString (non-optional) field omitted entirely Each variant produced one of: error: Property 'reaction' type does not match required AppSchemaEntity property type 'ReadReactionCases:(Schema<Tapback> | AttributedString)' error: Required AppSchemaEntity property 'reaction' must be optional error: Missing required property 'reaction' from AppSchemaEntity 'messages.message' The phrase ReadReactionCases:(Schema<Tapback> | AttributedString) is opaque — ReadReactionCases isn't a public type, Schema<Tapback> isn't constructable from outside, and the documentation doesn't mention @UnionValue in this context. The actual working pattern, which I only found by downloading the UnicornChat sample and reading MessageEntity.swift, is: @UnionValue enum MessageReaction: Sendable { case customReaction(CustomReaction) } @AppEnum(schema: .messages.customReaction) enum CustomReaction: String, AppEnum { case sticker static let caseDisplayRepresentations: [Self: DisplayRepresentation] = [ .sticker: "Sticker" ] } Two suggestions: Update the schema-template comment in the docs to either name MessageReaction explicitly with a @UnionValue annotation, or include a one-line note: "The reaction field is a @UnionValue enum wrapping the customReaction schema enum — see UnicornChat sample." The current placeholder <#ReadReaction#> plus the prose suggesting "you can generate the properties... with the @AppEntity(.messages.message) Swift macro" reads as if the developer just supplies any AppEnum-conformer. Improve the diagnostic. Property type does not match required AppSchemaEntity property type 'ReadReactionCases:(Schema<Tapback> | AttributedString)' is unhelpful because ReadReactionCases doesn't appear in any reachable type. Either rename to something developer-facing, or include a fix-it that suggests @UnionValue. iOS 27.0 beta, Xcode 27 beta, macOS Tahoe 26.4.

There are two beta restore files for A16, both are for ipad15,8. Please post one for ipad15,7

Ever since I updated my Mac mini M4 to macOS 27 (Golden Gate), the Applications icon in my Dock has stopped working completely. Clicking it does nothing. Is this a known bug, or is there something wrong with my system? Has anyone else experienced the same issue after updating? If there's a fix or workaround, I'd really appreciate the help. Thanks!

Can anyone help me with this error message? Beta contract is missing for the app. Error IDs: 3976de05-9ac1-41e1-9294-a8827535015e 96bfccea-8fe8-450a-8cff-fbc55b696b29 I have tried looking at agreements, there is nothing to sign or that I have not accepted. I cannot find any agreement related to this. I have tried sending my app for TestFlight review from web browser or TestFlight app in my iPhone but no help at all I get the same error message. I have tried sending request to Apple support to call me but that also ends up with error. Is there anything wrong going with Apple. How can we contact Apple? They are not replying to my emails either.

I'd like to use Xcode 27 Beta, for its Coding Intelligence features, on existing iOS 17 thru 26 production code. As long as I don't allow iOS 27 as a target, will I be able to use Xcode 26 to submit the Xcode 27 project files now to the App Store for distribution? I can imagine situations where Xcode 27 makes use of a new backward-compatible API feature that Xcode 26 balks at. Perhaps I'll have to watch out for that, unless there's a way to tell Xcode 27 to avoid it automatically?

Since the iOS 18 and Xcode 16, I've been getting some really strange SwiftData errors when passing @Model classes around. The error I'm seeing is the following: SwiftData/BackingData.swift:409: Fatal error: This model instance was destroyed by calling ModelContext.reset and is no longer usable. PersistentIdentifier(id: SwiftData.PersistentIdentifier.ID(url: x-coredata://34EE9059-A7B5-4484-96A0-D10786AC9FB0/TestApp/p2), implementation: SwiftData.PersistentIdentifierImplementation) The same issue also happens when I try to retrieve a model from the ModelContext using its PersistentIdentifier and try to do anything with it. I have no idea what could be causing this. I'm guessing this is just a bug in the iOS 18 Beta, since I couldn't find a single discussion about this on Google, I figured I'd mention it. if someone has a workaround or something, that would be much appreciated.

Anyone unable to configure their widgets on iOS 27? I can edit a widget’s configuration but that doesn’t have any effect on the widget. I’m seeing this in the simulator and I have some users seeing it on-device. Is this a known issue or are there workarounds?

All of these issues appear when the search controller is set on the view controller's navigationItem and the search controller's searchBar has its scopeButtonTitles set. So far the following issues are affecting my app on iOS/iPadOS 26 as of beta 7: When the scopeBarActivation of UISearchController is set to .onSearchActivation, the preferredSearchBarPlacement of the navigationItem is set to .integratedButton, and the searchBarPlacementAllowsToolbarIntegration is set to false (forcing the search icon to appear in the nav bar), on both iPhones and iPads, the scope buttons never appear. They don't appear when the search is activated. They don't appear when any text is entered into the search bar. FB19771313 I attempted to work around that issue by setting the scopeBarActivation to .manual. I then show the scope bar in the didPresentSearchController delegate method and hide the scope bar in the willDismissSearchController. On an iPhone this works though the display is a bit clunky. On an iPad, the scope bar does appear via the code in didPresentSearchController, but when any scope bar button is tapped, the search controller is dismissed. This happens when the app is horizontally regular. When the app on the iPad is horizontally compact, the buttons work but the search bar's text is not correctly aligned within the search bar. Quite the mess really. I still need to post a bug report for this issue. But if issue 1 above is fixed then I don't need this workaround. When the scopeBarActivation of UISearchController is set to .onSearchActivation, the preferredSearchBarPlacement of the navigationItem is set to .stacked, and the hidesSearchBarWhenScrolling property of the navigationItem is set to false (always show the search bar), and this is all used in a UITableViewController, then upon initial display of the view controller on an iPhone or iPad, you are unable to tap on the first row of the table view except on the very bottom of the row. The currently hidden scope bar is stealing the touches. If you activate and then cancel the search (making the scope bar appear and then disappear) then you are able to tap on the first row as expected. The initially hidden scope bar also bleeds through the first row of the table. It's faint but you can tell it's not quite right. Again, this is resolved by activating and then canceling the search once. FB17888632 When the scopeBarActivation of UISearchController is set to .onSearchActivation, the preferredSearchBarPlacement of the navigationItem is set to integrated or .integratedButton, and the toolbar is shown, then on iPhones (where the search bar/icon appears in the toolbar) the scope buttons appear (at the top of the screen) the first time the search is activated. But if you cancel the search and then activate it again, the search bar never appears a second (or later) time. On an iPad the search bar/icon appears in the nav bar and you end up with the same issue as #1 above. FB17890125 Issues 3 and 4 were reported against beta 1 and still haven't been fixed. But if issue 1 is resolved on iPhone, iPad, and Mac (via Mac Catalyst), then I personally won't be affected by issues 2, 3, or 4 any more (but of course all 4 issues need to be fixed). And by resolved, I mean that the scope bar appears and disappears when it is supposed to each and every time the search is activated and cancelled (not just the first time). The scope bar doesn't interfere with touch events upon initial display of the view controller. And there are no visual glitches no matter what the horizontal size class is on an iPad. I really hope the UIKit team can get these resolved before iOS/iPadOS 26 GM.

ubject: Walkie-Talkie App Not Working After Updating to iOS 27 Developer Version Dear Support Team, I am experiencing an issue with the Walkie-Talkie app after updating my device to the iOS 27 Developer Version. Since the update, the app is not functioning properly, and I am unable to connect or communicate with my contacts using Walkie-Talkie. I have already tried several troubleshooting steps, including restarting the device, checking my network connection, and verifying that both FaceTime and Walkie-Talkie are enabled. However, the issue still persists. Could you please help identify the cause of this problem and advise on any available solutions or known issues related to the iOS 27 Developer Version? Device Model: [IPHONE 17] iOS Version: iOS 27 Developer Version Issue Started: Immediately after updating to iOS 27 Developer Version Thank you for your assistance. I look forward to your response.

I installed the new MacOS Beta 1 on Monday, June 8 and Siri was requested. It is now Thursday, June 11 and I am still on the wait list. The conference is almost over with any interactive sessions. I am concerned that my configuration may be causing a bug. The AppleID I am logged in on the Mac (M4, 24GBs RAM, 512GB storage-130GB free) is not the same as my paid Developer AppleID used to download Xcode, etc. (it is however a Developer ID). This has never been a problem before. Could this be causing an issue? Related question, since I have not gotten the "New Siri" will this actually change the Foundation Models?

Summary While parallel testing Core Location on the new iOS 26.1 beta (23B5044i), I observed what I believe to be a regression of the issue described here: https://developer.apple.com/forums/thread/779192 Specifically, user positioning underground subway stations is noticeably inaccurate on the beta, whereas the same scenarios remain accurate on the unupgraded device below. I work with the MTA (New York City) and work with the OP of that thread. Happy to provide additional testing or details if helpful. Please let me know what else you need. Test Info Riding NYCT from Wall St to 34th St Penn Station on the 2 train carrying two iphones Recording: https://limewire.com/d/dpTWi#pDC3GRYIdE Expected: Consistent underground positioning comparable to prior releases. Actual: Degraded/inaccurate underground positioning on iOS 26.1 beta. Test Devices Left Screen: iPhone 15 Pro Max - iOS 26.1 beta (23B5044i) Right Screen: iPhone 11 - iOS 18.6.2 (22G100) Blue dots show location set by CoreLocation. Red dot on iphone 11 shows the actual location of both devices as I was able to manually place while travelling through a station. Placement through tunnels is not easy to verify and not usually indicated. Timestamps Comparison of when train was actually observed in a station vs when 26.1 and 18.6.2 CoreLocation updated to the station Fulton St 1:48 iOS 26.1 correctly updates (correctly) 2:16 iOS 18.6.2 updates (28sec late) Park Place 4:12 train arrives 4:15 iOS 18.6.2 updates to ~near Park Place 5:04 iOS 18.6.2 updates to Park Place (correctly) 6:07 iOS 26.1 update to ~near Park Place (over 2 mins late) Chambers St 6:02 train arrives / iOS 18.6.2 updates (correctly) 6:14 iOS 26.1 updates to ~near Chambers 6:18 iOS 26.1 update to Chambers (correctly) Franklin St 6:52 train arrives 6:55 iOS 18.6.2 updates (correctly) x:xx iOS 26.1 does not update Canal St: 7:16 train arrives 7:18 iOS 18.6.2 updates (correctly) x:xx iOS 26.1 does not update Houston St 7:54 train arrives 8:00 iOS 18.6.2 updates (correctly) x:xx iOS 26.1 does not update Christopher St 8:37 iOS 26.1 presumably between Houston St and Christopher St 8:40 train arrives / iOS 18.6.2 updates (correctly) x:xx iOS 26.1 does not update 14 St 9:22 train arrives 9:28 iOS 18.6.2 updates (correctly) 11:01 as train departs station iOS 26.1 updates (1.5 mins late)

It has been 3 days on the waitlist. Is there something wrong with the apple servers?

I just noticed something on macOS 27 beta 1 and I'm not sure if it's a bug or just how the new feature works. After quitting an app with Cmd+Q, the Dock keeps showing the gray dot with the "Running in Background" message. So I checked — ps aux shows nothing running for the app at all. The only trace is its auto-updater job in launchctl list (com.anthropic.claudefordesktop.ShipIt), which is registered but has no PID, so it's not actually executing anything. Out of curiosity I tried Discord and got the exact same thing (com.discord.discord.ShipIt), so this probably happens with any Electron app that uses the Squirrel updater. Is this intended behavior? Trying to understand if the indicator reflects registered background items (and not just live processes) so I know what to expect for Electron-based apps.

I got macOS Golden Gate developer beta, so Xcode stopped working. Then, I got Xcode 27 Beta because I was super excited about it, but then after adding my build, App Store Connect says that I can't add builds made with Xcode beta for review, and since I have macOS Golden Gate, I can't use non-beta Xcode. How do I either archive as non-beta or downgrade in some way (since I can't go back to macOS Tahoe)? I would like to add my app for review soon.