Background / Objective We are currently developing a solution to centrally manage Apple OS updates (major and minor) across managed macOS devices. Before implementing at scale, we need Apple’s guidance on supported and future-proof update mechanisms under MDM. Questions / Ask (Apple Guidance Requested) Apple recommended method What is Apple’s recommended approach to perform: Minor updates (e.g., macOS X.Y → X.Z) Major upgrades (e.g., Ventura → Sonoma) in an enterprise fleet? Support boundary Is macOS update management only supported via MDM (including any newer declarative workflows), or are local mechanisms (installer + command-line tooling) also considered supported for enterprise automation? Use of startosinstall Can we leverage the existing utility: /Applications/Install macOS .app/Contents/Resources/startosinstall for automated upgrades in enterprise environments? If yes, are there recommended flags/workflows Apple endorses for unattended or minimally interactive upgrades? Long-term support / stability Does startosinstall have any form of long-term support / stability guarantees across future macOS releases? Are there any known deprecations planned (or guidance that customers should transition to MDM/DDM workflows)? MDM interaction / interference When using startosinstall, can MDM policies (software update deferrals/restrictions, update enforcement, etc.) interfere with or block the upgrade? If interference is expected, what is the correct supported way to coordinate: MDM software update settings local startosinstall execution to avoid failures and ensure compliance? What We Need From Apple (Desired Outcome) A clear statement of recommended and supported update workflow(s) for enterprise managed macOS: for minor updates for major upgrades Guidance on whether startosinstall is acceptable for long-term automation, or whether we should only use MDM/DDM-driven workflows. Any best practices or reference documentation Apple recommends for implementing this safely and reliably.

We are upgrading macOS (minor versions and potentially major versions) using a scripted approach: Install the InstallAssistant package via installer Trigger OS install via startosinstall On MDM-managed assets, OS update policies appear to prohibit or interfere with the update flow. The update often fails with startosinstall reporting “Helper tool crashed…” during the “Preparing” phase. Steps to Reproduce On an MDM-enrolled Mac with OS update restriction/deferral policies applied, run: sudo /usr/sbin/installer -pkg /Path/To/InstallAssistant.pkg -target / && echo 'MACOS_PASSWORD' | /Applications/Install\ macOS\ Sonoma.app/Contents/Resources/startosinstall --agreetolicense --forcequitapps --stdinpass --user MACOS_USER Actual Result Package installation reports success, but startosinstall fails during preparation with: Standard Output installer: Package name is macOS15.7_SoftwareUpdate installer: Upgrading at base path / installer: The upgrade was successful. By using the agreetolicense option, you are agreeing that you have run this tool with the license only option and have read and agreed to the terms. If you do not agree, press CTRL-C and cancel this process immediately. Preparing to run macOS Installer... Preparing: 0.0% Preparing: 0.1% ... Preparing: 24.9% Standard Error Helper tool crashed... notes.log Install.log is also attached. Questions for Apple / Ask: We suspect this crash is caused by MDM OS update restrictions/policies. We need Apple’s recommended method to perform macOS updates (minor + major) when MDM is present, especially in environments where update deferrals/restrictions may be configured.

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.

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?

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.

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 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 }

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.

Hello, I am working on a cross‑platform application that uses libiconv to convert strings to/from Unicode. I need to modify the existing code for compatibility with macOS. However, the call to iconv() fails with an unclear errno value (92) when using "WCHAR_T": std::wstring ConvertToWchar(const std::string& iconvCodeSet, const std::string_view str) { iconv_t conv = iconv_open("WCHAR_T//TRANSLIT", iconvCodeSet.c_str()); if (conv == (iconv_t)-1) { std::cerr << "iconv_open() failed" << std::endl; return {}; } std::wstring out(str.size(), L'\0'); auto inPtr = (char*)str.data(); size_t inSize = str.size(); auto outPtr = (char*)out.data(); size_t outSize = out.size() * sizeof(wchar_t); if (iconv(conv, &inPtr, &inSize, &outPtr, &outSize) == (size_t)-1) { std::cerr << "iconv() failed. errno = " << errno << std::endl; return {}; } if (iconv(conv, nullptr, &inSize, &outPtr, &outSize) == (size_t)-1) { std::cerr << "iconv() failed. errno = " << errno << std::endl; return {}; } iconv_close(conv); return out; } int main() { std::string str1((const char*)u8"ΟΔΥΣΣΕΥΣ"); std::wstring str2 = ConvertToWchar("UTF-8", str1); if (str2.empty()) return 1; std::cout << "converted" << std::endl; return 0; } Using "UTF-32" works fine, but "WCHAR_T//TRANSLIT" fails. What is the recommended way to convert wchar_t strings using libiconv? Why does the conversion fail with "WCHAR_T//TRANSLIT"? Thank you in advance!

The actual error: pkgbuild: error: Could not find appropriate signing identity for “Developer ID installer: My Name (DeveloperID)”. I'm trying to sign a program written with gfortran. The steps worked the last time (Mar 23) I built this code. The steps to error: a) xcrun notarytool store-credentials --apple-id "xxx" --team-id "yyy" Giving Profile Name zzz and App-specific password b) codesign --force --timestamp --options=runtime -s "Developer ID Application: My Name (yyy)" AppName c) pkgbuild --root ROOT --identifier org.aaa.bbb --version "1.1.1" --sign "Developer ID installer: My Name (yyy)" AppName.pkg ROOT contains the package contents At this point I get the error pkgbuild: error: Could not find appropriate signing identity for “Developer ID installer: My Name (yyy)” Are there steps that have changed. Any suggestions? Thanks, David

Hello, Back in January 2024, I filed a bug report regarding a cache being kept by the macOS Wallpaper Agent. This cache contains every image ever set as a users wallpaper, and at the time the issue was reported, it never cleared, leaving hundreds of gigabytes wasted on users disks in some cases. FB13536275 This issue was ultimately fixed in macOS 15.1 beta 6, and remained fixed for the duration of macOS 15. The fix was excellent - the cache was reduced to storing just 2-3 days worth of images. Sadly, we've discovered that this issue is back in macOS Tahoe. The cache has moved locations, and once again is not clearing. We have filed this bug again, less than a year after it was first fixed: FB20636593 We develop an app called 24 Hour Wallpaper that keeps the wallpaper in sync with the time of day. This necessitates that the app regularly changes the wallpaper, which sadly now results in an infinitely growing and useless cache of BMP files generated by the system. As we waited 10 months for this to get fixed the first time, we expect to wait at least that long to get it fixed again, and have no confidence that it will stay fixed because the last fix lasted less than a year. This leaves us in a bad position, as people can't use our app without the cache growing arbitrarily and ultimately completely filling their disk. We've already had customers call Apple to complain about this, and the good news is that the support agents understand that this is a problem with macOS, not with our app. What we've decided to do is add a feature to the app that monitors the size of this cache and periodically deletes it. We're required to get the users permission the first time to do this, but after that the permission is cached, so the app can keep the cache folder clean regardless of if macOS is doing it's job or not. We haven't seen any side effects or problems as a result of doing this. We've seen other apps like CleanMyMac do this without any problems. We're wondering if there is anything we should be aware of regarding this caches behavior before releasing this flushing feature. Thanks for your time, -josh