According the video "Build an AppKit app with the new design" (https://developer.apple.com/videos/play/wwdc2025/310/), it is now possible to add a badge on a NSToolbarItem object. However, in don't see a badge in the NSToolbar API. The code example in the video includes for example "NSItemBadge.count(4)", but the only Google result for this is the video mentioned above. Is this still work in progress or I'm overlooking something?

The following repro case results in a previews crash on Xcode 26 beta 3 (report attached). FB18762054 import SwiftUI final class MyItem: Identifiable, Labelled { var label: String init(_ label: String) { self.label = label } } protocol Labelled { var label: String { get } } struct HelloView: View { let label: String var body: some View { Text(label) } } struct ListView<Element: Labelled & Identifiable>: View { @Binding var elements: [Element] var body: some View { List { ForEach($elements, id: \.id) { $element in HelloView(label: element.label) // crash // Replacing the above with a predefined view works correctly // Text(element.label) } } } } struct ForEachBindingRepro: View { @State var elements: [MyItem] = [ MyItem("hello"), MyItem("world"), ] var body: some View { ListView(elements: $elements) } } #Preview("ForEachBindingRepro") { ForEachBindingRepro() } foreachbindingrepro-2025-07-12-020628.ips

Hi, I work on a financial app in Brazil and since Beta 1 we're getting several crashes. We already opened a code level support and a few feedback issues, but haven't got any updates on that yet. We were able to resolve some crashes changing some of our implementation but we aren't able to understand what might be happening with this last one. This is the log we got on console: erro 11:55:41.805875-0300 MyApp CoreData: error: Failed to load NSManagedObjectModel with URL 'file:///private/var/containers/Bundle/Application/0B9F47D9-9B83-4CFF-8202-3718097C92AE/MyApp.app/ServerDrivenModel.momd/' We double checked and the momd is inside the bundle. The same app works on any other iOS version and if we build using Xcode directly (without archiving and installing on an iOS26 device) it works as expected. Have anyone else faced a similar error? Any tips or advice on how we can try to solve that?

With the new multi-windowing design in iPadOS 26, the behavior of openWindow() has changed. In iPadOS 18, if I called openWindow(), I would go from a full-screen window to two side-by-side windows. That allowed my app to meet the goal of the user; keep some information on the screen while being able to navigate through the app in the other window. In iPadOS 26 (beta 3), this no longer works. Instead, a new Window opens ON top of the current window. I am looking for some mechanism to help the user see that two windows are now present and then easily move them on the screen (tiled, side-by-side) or whatever else they would prefer.

During the Camera lab session at WWDC25, support for DICOM was mentioned. I'm trying to work with the new AVFileType dcm to help with handling DICOM scans. Can anyone provide some assistance?

My iphone 11 pro max in ios 26 is not a liquid glass like other

I'm trying to update one of my apps to the new Liquid Glass effects using Xcode 26. Came across a weird issue in that I reproduced in an empty project on its own with a storyboard with a single segmented control on the initial viewController I have a UISegmentedControl with 3 options. If I click index 2, while index 0 is selected, everything works as normal However if I select index 1, and then index 2, it jumps back to index 0 instead of selecting 2. All the events fire as though I tapped index 0

I Got The Developer Beta For iOS AND iPadOS 26. On my main devices because im poor and cant buy another one. so.. should i be worried of it being unstable? Also i didnt backup because iCloud Is Full and im not paying for a better subscription thats more expensiv.

I'm building and running from Xcode 26 to macOS 15.5. On launch, app crashes on start dynamic runtime linking with failure to find _LocationEssentials framework.

I'm trying to apply a glass effect on a circle stroke but all it does is apply it to the circle itself and not the stroke: import SwiftUI let kCarouselCircleSize: CGFloat = 150 let kCarouselOpacity: Double = 0.3 let kCarouselStrokeWidth: CGFloat = 60 struct ContentView: View { @State var showing = false var body: some View { VStack(spacing: 60) { Text("ultraThinMaterial:") .font(.title) CarouseCircle(drawProgress: 0.7, isActive: false) Text("glassEffect()") .font(.title) CarouseCircle(useGlassEffect: true, drawProgress: 0.7, isActive: false) } .background(content: { Image(.background2) }) .padding() } } struct CarouseCircle: View { var size: CGFloat = kCarouselCircleSize var strokeWidth: CGFloat = kCarouselStrokeWidth var useGlassEffect: Bool = false var drawProgress: CGFloat var isActive: Bool var body: some View { if useGlassEffect { Circle() .trim(from: 0, to: drawProgress) .fill(.clear) .stroke(.blue, style: StrokeStyle(lineWidth: strokeWidth, lineCap: .round)) .frame(width: size, height: size) .glassEffect() .shadow(color: .black.opacity(kCarouselOpacity), radius: isActive ? 4 : 1, x: 0, y: 0) .rotationEffect(.degrees(-90)) // Start drawing at button 1's position } else { Circle() .trim(from: 0, to: drawProgress) .fill(.clear) .stroke(.ultraThinMaterial, style: StrokeStyle(lineWidth: strokeWidth, lineCap: .round)) .frame(width: size, height: size) .shadow(color: .black.opacity(kCarouselOpacity), radius: isActive ? 4 : 1, x: 0, y: 0) .rotationEffect(.degrees(-90)) // Start drawing at button 1's position } } } Here's the result: Is this supported, a bug or something I'm doing wrong?

We are experiencing a crash in our application that only occurs on devices running iOS beta 26. It looks like a Beta problem. The crash appears to be caused by an excessive number of open File Descriptors. We identified this after noticing a series of crashes in different parts of the code each time the app was launched. Sometimes it would crash right at the beginning, when trying to load the Firebase plist file. That’s when we noticed a log message saying “too many open files,” and upon further investigation, we found that an excessive number of File Descriptors were open in our app, right after the didFinishLaunching method of the AppDelegate. We used the native Darwin library to log information about the FDs and collected the following: func logFDs() { var rlim = rlimit() if getrlimit(RLIMIT_NOFILE, &rlim) == 0 { print("FD LIMIT: soft: \(rlim.rlim_cur), hard: \(rlim.rlim_max)") } // Count open FDs before Firebase let openFDsBefore = countOpenFileDescriptors() print("Open file descriptors BEFORE Firebase.configure(): \(openFDsBefore)") } private func countOpenFileDescriptors() -> Int { var count = 0 let maxFD = getdtablesize() for fd in 0..<maxFD { if fcntl(fd, F_GETFD) != -1 { count += 1 } } return count } With this code, we obtained the following data: On a device with iOS 26 Beta 1, 2, or 3: FD LIMIT: soft: 256, hard: 9223372036854775807 Open file descriptors BEFORE Firebase.configure(): 256 On a device with iOS 18: FD LIMIT: soft: 256, hard: 9223372036854775807 Open file descriptors BEFORE Firebase.configure(): 57 In the case of the device running iOS 26 beta, the app crashes when executing Firebase.configure() because it cannot open the plist file, even though it can be found at the correct path — meaning the OS locates it. To confirm this was indeed the issue, we used the following code to close FDs before proceeding with Firebase configuration. By placing a breakpoint just before Firebase.configure() and running the following LLDB command: expr -l c -- for (int fd = 180; fd < 256; fd++) { (int)close(fd); } This released the FDs, allowing Firebase to proceed with its configuration as expected. However, the app would later crash again after hitting the soft limit of file descriptors once more. Digging deeper, we used this code to try to identify which FDs were being opened and causing the soft limit to be exceeded: func checkFDPath() { var r = rlimit() if getrlimit(RLIMIT_NOFILE, &r) == 0 { print("FD LIMIT: soft: \(r.rlim_cur), hard: \(r.rlim_max)") for fd in 0..<Int32(r.rlim_cur) { var path = [CChar](repeating: 0, count: Int(PATH_MAX)) if fcntl(fd, F_GETPATH, &path) != -1 { print(String(cString: path)) } } } } We ran this command at the very beginning of the didFinishLaunching method in the AppDelegate. On iOS 26, the log repeatedly showed Cryptexes creating a massive number of FDs, such as: /dev/null /dev/ttys000 /dev/ttys000 /private/var/mobile/Containers/Data/Application/AEE414F2-7D6F-44DF-A6D9-92EDD1D2B014/Library/Application Support/DTX_8.191.1.1003.sqlite /private/var/mobile/Containers/Data/Application/AEE414F2-7D6F-44DF-A6D9-92EDD1D2B014/Library/Caches/KSCrash/MyAppScheme/Data/ConsoleLog.txt /private/var/mobile/Containers/Data/Application/AEE414F2-7D6F-44DF-A6D9-92EDD1D2B014/Library/HTTPStorages/mybundleId/httpstorages.sqlite /private/var/mobile/Containers/Data/Application/AEE414F2-7D6F-44DF-A6D9-92EDD1D2B014/Library/HTTPStorages/mybundleId/httpstorages.sqlite-wal /private/var/mobile/Containers/Data/Application/AEE414F2-7D6F-44DF-A6D9-92EDD1D2B014/Library/HTTPStorages/mybundleId/httpstorages.sqlite-shm /private/preboot/Cryptexes/OS/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64e /private/preboot/Cryptexes/OS/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64e.01 /private/preboot/Cryptexes/OS/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64e.11 /private/preboot/Cryptexes/OS/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64e.12 /private/preboot/Cryptexes/OS/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64e.13 /private/preboot/Cryptexes/OS/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64e.14 /private/preboot/Cryptexes/OS/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64e.15 /private/preboot/Cryptexes/OS/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64e.16 /private/preboot/Cryptexes/OS/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64e.17 /private/preboot/Cryptexes/OS/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64e.18 /private/preboot/Cryptexes/OS/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64e.19 /private/preboot/Cryptexes/OS/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64e.20 /private/preboot/Cryptexes/OS/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64e.21 /private/preboot/Cryptexes/OS/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64e.22 /private/preboot/Cryptexes/OS/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64e.23 /private/preboot/Cryptexes/OS/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64e.24 /private/preboot/Cryptexes/OS/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64e.25 /private/preboot/Cryptexes/OS/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64e.26 /private/preboot/Cryptexes/OS/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64e.29 /private/preboot/Cryptexes/OS/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64e.30 /private/preboot/Cryptexes/OS/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64e.31 /private/preboot/Cryptexes/OS/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64e.32 /private/preboot/Cryptexes/OS/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64e.36 /private/preboot/Cryptexes/OS/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64e.37 /private/preboot/Cryptexes/OS/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64e.38 /private/preboot/Cryptexes/OS/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64e.39 /private/preboot/Cryptexes/OS/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64e.40 /private/preboot/Cryptexes/OS/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64e … This repeats itself a lot of times. … /private/preboot/Cryptexes/OS/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64e.36 /private/preboot/Cryptexes/OS/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64e.37 /private/preboot/Cryptexes/OS/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64e.38 /private/preboot/Cryptexes/OS/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64e.39 /private/preboot/Cryptexes/OS/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64e.40

I just installed macOS Tahoe beta on a mac mini. It says I am not connected to the internet, and attempts to use file sharing fail. Network status says that Ethernet and WiFi are working. Any suggestions?

The objective C code using the kernel API ‘sysctlbyname’ for ‘kern.osproductversion’ returns 16.0 instead of 26.0 on macOS Tahoe. sysctlbyname("kern.osproductversion", version, &size, NULL, 0) The command ‘sysctl kern.osproductversion’ returns ‘kern.osproductversion: 26.0’ on same macOS Tahoe. Note: The objective C code was built using Xcode 16.3.

Hello, I am testing an existing app on iOS 26. It hast an UITableViewController that shows a custom context menu preview using previewForHighlightingContextMenuWithConfiguration and providing an UITargetedPreview. Something along the lines like this (shortened): public override func tableView(_ tableView: UITableView, previewForHighlightingContextMenuWithConfiguration configuration: UIContextMenuConfiguration) -> UITargetedPreview? { guard let indexPath = configuration.identifier as? NSIndexPath else { return nil } let previewTableViewCell = self.getCell(for: indexPath) var cellHeight = self.getCellHeight(for: indexPath, with: maxTextWidth) // Use the contentView of the UITableViewCell as a preview view let previewMessageView = previewTableViewCell.contentView previewMessageView.frame = CGRect(x: 0, y: 0, width: maxPreviewWidth, height: cellHeight) previewMessageView.layer.masksToBounds = true let accessoryView = ... let totalAccessoryFrameHeight = accessoryView.frame.maxY - cellHeight var containerView = UIView(frame: .init(x: 0, y: 0, width: Int(maxPreviewWidth), height: Int(cellHeight + totalAccessoryFrameHeight))) containerView.backgroundColor = .clear containerView.addSubview(previewMessageView) containerView.addSubview(accessoryView) // Create a preview target which allows us to have a transparent background let previewTarget = UIPreviewTarget(container: tableView, center: ...) let previewParameter = UIPreviewParameters() // Remove the background and the drop shadow from our custom preview view previewParameter.backgroundColor = .clear previewParameter.shadowPath = UIBezierPath() return UITargetedPreview(view: containerView, parameters: previewParameter, target: previewTarget) } On iOS 18 and below this works fine and buttons that are included in the accessoryView are tapable by the user. Now on iOS 26 the preview is shown correct (although it has a bit weird shadow animation), but tapping a button of the accessoryView now closes the context menu, without triggering the touchUpInside event anymore. For me it feels like an unintended change in behavior, but maybe I am missing something? Filed FB18644353

Macbook pro M4 - will not accept any power adapter after beta update iPhone 16 pro - same exact problem Devices are dead Tried multiple chargers - Watch and IPad appear to be taking a charge for now..

Immediately after installing iOS 26 on my iPhone 14 Pro, my phone display stopped working. It's not responding to touch, but I can see it charging. It also wakes the screen whenever I pick it up, but it's not touching at all. What do I do, or do I have to downgrade?

Hi, In my apps, the recent iOS 16.0 beta 7 (20A5356a) broke the .timer DateStyle property of the Text view, in a SwiftUI widget. In previous OS and beta, Text(Date(), style: .timer) was correctly displaying an increasing counter. In iOS 6.0 beta 7, Text(Date(), style: .timer) does not update anymore, (and is offset to the left). The other DateStyle (like .offset, .relative, ...) seems to update correctly. Anyone noticed that (very specific) problem ?

Has anyone had success using the HKWorkoutRouteBuilder in conjunction with the new iOS support for HKLiveWorkoutBuilder? I was running my watchOS code that worked now brought over to iOS and when I call insertRouteData the function never returns. This happens for both the legacy and closure based block patterns. private var workoutSession: HKWorkoutSession? private var workoutBuilder: HKLiveWorkoutBuilder? private var serviceSession: CLServiceSession? private var workoutRouteBuilder: HKWorkoutRouteBuilder? private func startRouteBuilder() { Task { @MainActor in self.serviceSession = CLServiceSession(authorization: .whenInUse) self.workoutRouteBuilder = self.workoutBuilder?.seriesBuilder(for: .workoutRoute()) as? HKWorkoutRouteBuilder self.locationUpdateTask = Task { do { for try await update in CLLocationUpdate.liveUpdates(.fitness) { if let location = update.location { self.logger.notice(#function, metadata: [ "location": .stringConvertible(location) ]) try await self.workoutRouteBuilder?.insertRouteData([location]) self.logger.notice("Added location") } } } catch { self.logger.error(#function, metadata: [ "error": .stringConvertible(error.localizedDescription) ]) } } } } I did also try CLLocationManager API with delegate which is what my current watch code uses (a bit old). Same issue. Here is what I've found so far: If the workout session is not running, and if the builder hasn't started collection yet, inserting route data works just fine I've tried different swift language modes, flipped from main actor to non isolated project settings (Xcode 26) Modified Apple's sample code and added location route building to that and reproduced the error, modified sample attached to feedback This issue was identified against Xcode 26 beta 2 and iPhone 16 Pro simulator. Works as expected on my iPhone 13 Pro beta 2. FB18603581 - HealthKit: HKWorkoutRouteBuilder insert call within CLLocationUpdate task never returns

Since first beta of iOS 26 I've created a workflow where I can deploy to TestFlight the builds compiled using the iOS 26 SDK, and it has worked fine until yesterday when I started receiving this error: Unsupported SDK or Xcode version. Your app was built with an SDK or version of Xcode that isn’t supported. Although you can use beta versions of SDKs and Xcode to build and upload apps to App Store Connect, you need to use the latest Release Candidates (RC) for SDKs and Xcode to submit the app. For details on currently supported SDKs and versions of Xcode, visit: https://developer.apple.com/news/releases. I haven't changed anything in the workflow so I suspect it's a bug on Apple side? Or am I missing something? It is set to use "Latest Beta or Release" for both Xcode and macOS, archive and deploy to TestFlight Internal Testing. Thank you!

Does anyone know where I can get to the API diffs for iOS 18 -> iOS 26?