I’m having an issue installing my TestFlight build on a Mac. The build (v1.0 build 1) uploads successfully and shows as “Complete” in App Store Connect. I can also open the build details page, and my Apple ID / tester access / group setup looks correct. However, on TestFlight (macOS), when I tap Install/Load, I get this error: Unable to install. The requested app isn’t available or can’t be found. Notes: The app is an iOS app (iPhone + iPad), and I enabled availability for Mac (Designed for iPad) in App Store Connect. The Mac is Apple Silicon, running macOS Tahoe 26.1. Could you help me understand why TestFlight shows this message on Mac, and what I should change in Xcode/App Store Connect to make the build compatible?

I'm working on a command line tool, and trying to make it as fast as possible. I ran it under instruments' processor trace (really cool tool by the way, thanks for that) and found that the majority of the time it is taking to run, is actually spent in dyld, specifically dyld4::prepare(dyld4::APIs&, mach_o::Header const*). Out of a total run time of 1.27ms my code only takes 34.17μs or about 2.7%, that's a LOT of overhead! I re-ran my binary with the dyld activity instrument added to the mix, and it showed that the biggest known chunk of time that dyld spends during process startup is in "Run static initializer" from libSystem, though the majority of the time spent by dyld is unaccounted for and left labelled generically as "Launch Executable". Obviously I can't modify libSystem on my users' systems so is there anything I can do to reduce this overhead? Maybe some way to promise that I won't use the Obj-C runtime so that doesn't need setting-up or something?

Since the introduction of the siblings / and /System/Volumes/Data architecture, some very basic, critical commands seems to have a broken behaviour ( cp, rsync, tar, cpio…). As an example, ditto which was introduced more than 10 years ago to integrate correctly all the peculiarity of HFS Apple filesystem as compared to the UFS Unix filesystem is not behaving correctly. For example, from man ditto: --rsrc Preserve resource forks and HFS meta-data. ditto will store this data in Carbon-compatible ._ AppleDouble files on filesystems that do not natively support resource forks. As of Mac OS X 10.4, --rsrc is default behavior. [...] --extattr Preserve extended attributes (requires --rsrc). As of Mac OS X 10.5, --extattr is the default. and nonetheless: # ls -@delO /private/var/db/ConfigurationProfiles/Store drwx------@ 5 root wheel datavault 160 Jan 20 2024 /private/var/db/ConfigurationProfiles/Store                            ********* com.apple.rootless 28 *************************** # mkdir tmp # ditto /private/var/db/ConfigurationProfiles tmp ditto: /Users/alice/Security/Admin/Apple/APFS/tmp/Settings: Operation not permitted ditto: /Users/alice/Security/Admin/Apple/APFS/tmp/Store: Operation not permitted # ls -@delO tmp/Store drwx------ 5 root wheel - 160 Aug 8 13:55 tmp/Store                            * # The extended attribute on copied directory Store is empty, the file flags are missing, not preserved as documented and as usual behaviour of ditto was since a long time ( macOS 10.5 ). cp, rsync, tar, cpio exhibit the same misbehaviour. But I was using ditto to be sure to avoid any incompatibility with the Apple FS propriaitary modifications. As a consequence, all backup scripts and applications are failing more or less silently, and provide corrupted copies of files or directories. ( I was here investigating why one of my security backup shell script was making corrupted backups, and only on macOS ). How to recover the standard behaviour --extattr working on modern macOS?

Environment macOS Tahoe 26.2 (Build 25C56) Also tested with macOS 26.3 Developer Beta - same issue Windows Server 2022 DFS namespace Connection via Tailscale VPN (but also tested with direct network connection) Problem Description When connecting to a Windows Server 2022 DFS namespace from macOS Tahoe, the root namespace connects successfully, but all subfolders appear empty and return either: "No route to host" "Authentication error" (alternates inconsistently) Steps to Reproduce Set up a Windows Server 2022 DFS namespace (e.g., \\domain.com\fs) Add DFS folder targets pointing to file servers (e.g., \\fs02\share, \\fs03\share) From macOS Tahoe, connect via Finder: smb://domain.com/fs Root namespace mounts successfully Issue: Subfolders show as empty or return "No route to host" when accessed What Works Direct SMB connections to individual file servers work perfectly: smb://10.118.0.26/sharename ✓ smb://fs02.domain.com/sharename ✓ Same DFS namespace works from Windows clients Same DFS namespace worked from macOS Sonoma 14.4+ What Doesn't Work DFS referrals from macOS Tahoe 26.x to any DFS folder target The issue persists regardless of: Kerberos vs NTLM authentication SMB signing enabled/disabled on servers Various /etc/nsmb.conf configurations DNS resolution (tested with IPs and FQDNs) Historical Context A similar DFS referral bug existed in macOS Sonoma 14.0 and was fixed in 14.1. This appears to be a regression in macOS Tahoe 26. Request Please investigate the DFS referral handling in macOS Tahoe. The fact that direct SMB connections work while DFS referrals fail suggests an issue specifically in the DFS referral processing code. Feedback Assistant report will be filed separately.

As part of the OpenJDK testing we run several regression tests, including for Java SE networking APIs. These APIs ultimately end up calling BSD socket functions. On macos, starting macos 26, including on recent 26.2 version, we have started seeing some unexplained but consistent exception from one of these BSD socket APIs. We receive a "ENOBUFS" errno (No buffer space available) when trying to construct a socket(). These exact same tests continue to pass on many other older versions of macos (including 15.7.x). After looking into this more, we have been able to narrow this down to a very trivial C code which is as follows (also attached): #include <stdio.h> #include <sys/socket.h> #include <string.h> #include <unistd.h> #include <sys/errno.h> static int create_socket(const int attempt_number) { const int fd = socket(AF_INET6, SOCK_STREAM, 0); if (fd < 0) { fprintf(stderr, "socket creation failed on attempt %d," " due to: %s\n", attempt_number, strerror(errno)); return fd; } return fd; } int main() { const unsigned int num_times = 250000; for (unsigned int i = 1; i <= num_times; i++) { const int fd = create_socket(i); if (fd < 0) { return -1; } close(fd); } fprintf(stderr, "successfully created and closed %d sockets\n", num_times); } The code very trivially creates a socket() and close()s it. It does this repeatedly in a loop for a certain number of iterations. Compiling this as: clang sockbufspaceerr.c -o sockbufspaceerr.o and running it as: ./sockbufspaceerr.o consistently generates an error as follows on macos 26.x: socket creation failed on attempt 160995, due to: No buffer space available The iteration number on which the socket() creation fails varies, but the issue does reproduce. Running the same on older versions of macos doesn't reproduce the issue and the program terminates normally after those many iterations. Looking at the xnu source that is made available for each macos release here https://opensource.apple.com/releases/, I see that for macos 26.x there have been changes in this kernel code and there appears to be some kind of memory accountability code introduced in this code path. However, looking at the reproducer/application code in question, I believe it uses the right set of functions to both create as well as release the resources, so I can't see why this should cause the above error in macos 26.x. Does this look like some issue that needs attention in the macos kernel and should I report it through feedback assitant tool?

SMBClient-593 introduces a crtitical bug. When reading and writing data at high volume, the SMBClient no longer properly receives and handle responses from the server. In some cases, the client mishandles the response packet and the following errors are seen in the logs: 2025-12-02 21:36:04.774772-0700 localhost kernel[0]: (smbfs) smb2_smb_parse_write_one: Bad struct size: 0 2025-12-02 21:36:04.774776-0700 localhost kernel[0]: (smbfs) smb2_smb_write: smb2_smb_read_write_async failed with an error 72 2025-12-02 21:36:04.774777-0700 localhost kernel[0]: (smbfs) smbfs_do_strategy: file.txt: WRITE failed with an error of 72 In other cases, the client mishandles the response packet and becomes completely unresponsive, unable to send or receive additional messages, and a forced shutdown of the computer is required to recover. This bug is only present on macos 26. We believe the operative change is in the latest commit, SMBClient-593 beginning at line now 3011 in smb_iod.c. The issue seems to be a race, and occurs much more frequently once throughput exceeds around 10Gbps, and again more frequently above 20Gbps.

Hello, We're developing endpoint security software using the Endpoint Security framework, and we've encountered challenges with the behavior change in macOS 15 regarding provisioning UDIDs in cloned VMs. The Change Prior to macOS 15, cloning a VM preserved its UDID (format: 0000FE00-9C4ED9F68BBDC72D). Starting with macOS 15, cloned VMs receive a new UDID generated from the host's Secure Enclave (format: b043d27202c7ac37ca3c6b82673302225485cae9), making each clone effectively a new device. Our Workflow We maintain a clean base VM image and clone it for each test run. We add the base VM's UDID to our provisioning profile once, then create clones which (previously) retained that same UDID, allowing us to start new testing cycles without re-registering devices. This is essential because our product involves low-level system integration through the Endpoint Security framework, and if something goes wrong during development, it has the potential to affect system stability. To prevent any cascading issues between test runs or different product versions, we need each test to start from a known clean state rather than reusing the same VM. The Challenge With each VM clone generating a new UDID, we're hitting Apple's device registration limits quickly. This particularly impacts: New team members who spin up VMs for the first time and can't run signed builds Our CI/CD pipeline where multiple test environments need provisioning profiles Developers testing different branches who need separate clean environments Current Workaround We've found that VMs created on macOS 14 and upgraded to macOS 15+ retain their original UDID format. However, we're concerned this workaround may stop working in future macOS versions, which would leave us without a viable path forward. If the workaround stops working, our fallback would be signing each CI build with a Developer ID signature to allow running on any device. However, we'd prefer to avoid this as it would significantly increase load on Apple's signing infrastructure for what are essentially internal test builds. We completely understand the security reasoning behind tying UDIDs to the host's Secure Enclave for Apple Account support. However, for development workflows that don't require Apple Account features in VMs but do require clean, isolated test environments, the previous behavior was quite valuable. Question Is there a recommended approach for teams in our situation? We're happy to explore alternative workflows if there's a pattern we're missing, or we'd be glad to provide more context if this is a use case Apple is considering for future updates. Thanks for any guidance you can provide! Feedback case: FB21389730

Is there any way I can know that another app has gone full screen? Please note that this is not what NSWindowDidEnterFullScreenNotification does, that only works for my own windows. As for why I need to know: Say you're playing a YouTube video full screen. The video fills up the main display, and if there's a second display, it goes black. Well, mostly. I have a utility app with small status windows that remain on top. I'd like to be polite and hide them in this scenario.

I have an orphaned asset folder taking up 9.13GB located at: /System/Library/AssetsV2/com_apple_MobileAsset_iOSSimulatorRuntime/c0d3fd05106683ba0b3680d4d1afec65f098d700.asset It contains SimulatorRuntimeAsset version 18.5 (Build 22F77). Active Version: My current Xcode setup is using version 26.2 (Build 23C54). I checked the plist files in the directory and found what seems to be the cause of the issue: The "Never Collected" Flag: The Info.plist inside the orphaned asset folder explicitly sets the garbage collection behavior to "NeverCollected": <key>__AssetDefaultGarbageCollectionBehavior</key> <string>NeverCollected</string> The Catalog Mismatch: The master catalog file (com_apple_MobileAsset_iOSSimulatorRuntime.xml) in the parent directory only lists the new version (26.2). Because the old version (18.5) is missing from this XML, Xcode and mobileassetd seem to have lost track of it entirely. What I Have Tried (All Failed) Xcode Components: The version 18.5 does not appear in Settings -> Components, so I cannot delete it via the GUI. Simctl: xcrun simctl list runtimes does not list this version. Running xcrun simctl runtime delete 22F77 fails with: "No runtime disk images or bundles found matching '22F77'." Manual Deletion: sudo rm -rf [path] fails with "Operation not permitted", presumably because /System/Library/AssetsV2 is SIP-protected. Third-party Tools: Apps like DevCleaner do not detect this runtime (likely because they only scan ~/Library or /Library, not /System/Library). Has anyone found a way to force the system (perhaps via mobileassetd or a specific xcrun flag) to re-evaluate this folder and respect a deletion request? I am trying to avoid booting into Recovery Mode just to delete a cache file. Any insights on how AssetsV2 handles these "orphaned" files would be appreciated.

I want to print the content of a WKWebView. I've done some searching, and many people have struggled with this over the years. Some claimed success, but their solutions don't work for me. One person created images for each pages and printed that, but then if you were to print to PDF, you'd get a PDF containing images rather than text. If I just call the printView(_:)) method of the view, I get blank pages. With the following more elaborate code, I get a partial printout, 11 out of what should be about 13 pages. let info = NSPrintInfo.shared info.topMargin = 72.0; info.bottomMargin = 72.0; info.leftMargin = 72.0; info.rightMargin = 72.0; info.isVerticallyCentered = false; info.isHorizontallyCentered = false; info.horizontalPagination = .fit; info.verticalPagination = .automatic; let printOp = webView!.printOperation( with: info ) printOp.canSpawnSeparateThread = true printOp.view?.frame = NSMakeRect( 0, 0, info.paperSize.width, info.paperSize.height ) printOp.runModal(for: webView.window!, delegate: self, didRun: nil, contextInfo: nil ) When I run the above under the debugger, I see console messages saying CGContextClipToRect: invalid context 0x0. Once the print dialog appears, if I touch (but not change) the selected printer, then the page count changes to the correct value.

Hi fellow devs, I have a quick question is it possible to have virtual controllers on Mac. For instance can my app exclusively manage the controller and output it into the Game Controller framework? And create a virtual controller to allow for features such as controller emulation, haptic control, and others.

Consider this code: import SwiftUI struct ContentView: View { var body: some View { NavigationView { EmptyView() } } } Which looks like this: How can I prevent the sidebar from being resized by a mouse and from being hidden? P.S. Can consider using AppKit if it can help.

I failed to resize the icon image from instances of NSRunningApplication. I can only get 32×32 while I'm expecting 16×16. I felt it unintuitive in first minutes… Then I figured out that macOS menu seems not allowing many UI customizations (for stability?), especially in SwiftUI. What would be my best solution in SwiftUI? Must I write some boilerplate SwiftUI-AppKit bridging?

I have an existing iOS app with MapKit. It always shows the current user location with UserAnnotation. But the same isn't true for macOS. I have this sample macOS application in SwiftUI. In the following, the current user location with a large blue dot appears only occasionally. It won't, 19 of 20 times. Why is that? I do have a location privacy key in Info.plist. And the Location checkbox is on under Signing & Capabilities. import SwiftUI import MapKit struct ContentView: View { @State private var markerItems: [MarkerItem] = [ MarkerItem(name: "Farmers Market 1", lat: 35.681, lon: 139.691), MarkerItem(name: "Farmers Market 2", lat: 35.685, lon: 139.695), MarkerItem(name: "Farmers Market 3", lat: 35.689, lon: 139.699) ] @State private var position: MapCameraPosition = .automatic var body: some View { Map(position: $position) { UserAnnotation() ForEach(markerItems, id: \.self) { item in Marker(item.name, coordinate: CLLocationCoordinate2D(latitude: item.lat, longitude: item.lon)) } } .mapControlVisibility(.hidden) .mapStyle(.standard(elevation: .realistic)) .ignoresSafeArea() } } #Preview { ContentView() } struct MarkerItem: Hashable { let name: String let lat: Double let lon: Double }

We create custom VPN tunnel by overriding PacketTunnelProvider on MacOS. Normal VPN connection works seamlessly. But if we enable onDemand rules on VPN manager, intemittently during tunnel creation via OnDemand, internet goes away on machine leading to a connection stuck state. Why does internet goes away during tunnel creation?

Currently, we are developing an all-in-one DualSense utility for macOS. We are exploring how to integrate shortcuts into our app. Our vision is to have the user use the native Shortcuts app to choose the controller buttons that should trigger the shortcut action, such as opening Steam, turning on audio haptics, and more. As we explore this approach, we want to see whether we need to build the UI in our app to set the triggers or can we do this inside of Shortcuts? Can button presses recorded by our app trigger shortcuts? Can those button inputs be customized inside of Shortcuts or should we develop it into our app? And if we have it in our app, can our app see, select, and trigger shortcuts?

We're updating a FileProvider-based app which was written for Big Sur to recent macOS. The system requires that the extension be manually enabled by the user in System Preferences -- either under Extensions > Added Extensions, Privacy & Security > Extensions > Added Extensions, or in newer versions General > Login Items & Extensions. Is there a programmatic (preferably Swift) or installer-based way to enable this checkbox-- or at least to detect if it has been enabled for a particular app, and if not bring up the appropriate pane of Preferences? (For which I'd need a complete OS-version-specific list of which pane to bring up.) (I can detect whether our particular NSFileProviderDomain has its userEnabled flag set after it's defined during the mounting process, but I'd rather be able to detect / set it during initial setup.)

Issue After upgrading to Tahoe 26.2, print queues monitored by PaperCut no longer work. The print queue gets paused, and the jobs fail to print. This issue was discovered during our internal testing prior to the Tahoe 26.2 public release, and a growing number of our mutual customers have also reported it since then. Root cause This appears to be due to changes in the behavior of CUPS Sandbox restrictions, which prevent the backend (and filter) from reading/writing to the PaperCut install folder. Error messages From syslog. 2025-12-22 16:41:59.283761+1100 0x1daf61 Error 0x0 0 0 kernel: (Sandbox) Sandbox: papercut(5783) deny(1) file-write-data /Library/Printers/PaperCut/Print Provider/print-provider.log When trying to create a TCP socket from the PaperCut filter. 2025-12-15 19:50:08,403 ERROR: os_tcp_socket_create: getaddrinfo failed: nodename nor servname provided, or not known Technical details PaperCut implements print queue monitoring using a CUPS backend (and filter). CUPS backends and filters run in a security 'sandbox' which limits what they can do (such as file/folder access, create network sockets, and execute sub-processes, etc.). The PaperCut backend (and filter) relies on some of these operations, so to function correctly, our code updates /etc/cups/cups-files.conf with "Sandboxing relaxed". Until 26.2, this relaxed mode allowed us to read/write to PaperCut folders, create TCP sockets to communicate with the local PaperCut Application Server, and execute/kill sub-processes. As an alternative to the relaxed mode, we also tried "Sandboxing off", but that doesn't help either (from CUPS scheduler/conf.h). typedef enum { CUPSD_SANDBOXING_OFF, /* No sandboxing */ CUPSD_SANDBOXING_RELAXED, /* Relaxed sandboxing */ CUPSD_SANDBOXING_STRICT /* Strict sandboxing */ } cupsd_sandboxing_t; Test code We can provide a simplified version of our backend that demonstrates the issue if required Questions Has the CUPS sandbox relaxing changed? According to the CUPS man pages (cups-files.conf(5)), "Sandboxing relaxed" should still work as before. If this is the new intended behavior, what are the other options/directives we can use to relax the limitations on CUPS backends and filters?

Hi there. I am trying to figure out how to make a macOS Tahoe app in SwiftUI with a sidebar. The problem I’m having is that the icons are the wrong size. If you visually compare the resulting sidebar with any built-in macOS app (Finder, Notes, Mail, Music, etc.) the built-in apps all have larger icons and the spacing is different from my SwiftUI app, which has too small icons and (I think) wrong spacing. I am trying to figure out what SwiftUI code I need to write to get a sidebar that looks the same as the other built-in macOS Tahoe apps. It’s also important to note that Tahoe sidebars have larger icons at the top level, and in cases where the items have a disclosure triangle with additional items nested within, the nested icons have smaller icons. I have not figured out how to properly replicate this effect either. I have spent quite a lot of time on trial-and-error with various combinations of .frame() and .font() modifiers. However, none of the results look quite right to me, and besides that, I think it is fundamentally the wrong approach; the UI or OS should be handling the sizing and spacing automatically, I shouldn’t have to specify it manually, as this is likely to break in past and future OS versions (and it never really looks exactly right in the first place). I am hoping there is some missing modifier that I am unaware of, which would solve this; or perhaps, some fundamental aspect of making lists in sidebars that I have missed. I would very much appreciate any advice. If you drop my code below into a new Xcode project, and compare it to a Finder window, you should be able to easily see the problem. import SwiftUI struct ContentView: View { var body: some View { splitView } @ViewBuilder var splitView: some View { NavigationSplitView { sidebar } detail: { helloWorld } } @ViewBuilder var sidebar: some View { List { NavigationLink { helloWorld } label: { Label("Test", systemImage: "book") } NavigationLink { helloWorld } label: { Label("Test 2", systemImage: "folder") } NavigationLink { helloWorld } label: { Label("Test 3", systemImage: "house") } DisclosureGroup( content: { NavigationLink { helloWorld } label: { Label("Test", systemImage: "book") } NavigationLink { helloWorld } label: { Label("Test 2", systemImage: "folder") } NavigationLink { helloWorld } label: { Label("Test 3", systemImage: "house") } }, label: { Label("Test 4", systemImage: "document") } ) } } @ViewBuilder var helloWorld: some View { VStack { Image(systemName: "globe") .imageScale(.large) .foregroundStyle(.tint) Text("Hello, world!") } .padding() } } #Preview { ContentView() }

When trying to open an encrypted CoreML model file on a system with SIP disabled, the error message is Failed to generate key request for <...> with error: -42187 This should state that SIP is disabled and needs to be enabled.