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

Using SwiftUI on macOS, how can I add a toolbar item on the right-most (trailing) edge of the window's toolbar when an Inspector is used? At the moment, the toolbar items are all left-of (leading) the split view tracking separator. I want the inspector toolbar item to be placed similar to where Xcode's Inspector toolbar item is placed: always as far right (trailing) as possible. NavigationSplitView { // ... snip } detail: { // ... snip } .inspector(isPresented: $isInspectorPresented) { InspectorContentView() } .toolbar { // What is the correct placement value here? ToolbarItem(placement: .primaryAction) { Button { isInspectorPresented.toggle() } label: { Label("Toggle Inspector", systemImage: "sidebar.trailing") } } } See the attached screenshot. When the InspectorView is toggled open, the toolbar item tracks leading the split view tracking separator, which is not consistent with how Xcode works.

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!

Ich habe Tahoe 26.2. installiert und bekomme nun keine Verbindungen zu externen Geräten (Keyboard, Synthesizer). KI gefragt und Antwort bekommen: Tahoe ist keine macOS-update und existiert nicht. Was ist die Wahrheit?

Hi, I have started facing an issue with Xcode since updating to macOS 26.1. The debugger is not stopping at breakpoints in Objective-C code, however breakpoints in Swift file are working fine. I am using Xcode 16.4. For breakpoints in Objective-C files I have started to get this message since the OS update - 'Xcode won't pause at this breakpoint because it has not been resolved.' I have already tried cleaning derived data and build folder. I do not want to upgrade to Xcode 26. Could someone help with the fix? Thanks

I am trying to set an image as the background in the window of a DMG. The image is: PNG file; 144x144 resolution; 1138x574 size. In macOS Tahoe, the image is added by: selecting the DMG window; opening the "Show View Options" dialog; clicking on "Picture"; dragging the image file to the small square box labelled "Drag image here"; closing "Show View Options" dialog. The DMG is then ejected. In Disk Utility, the image file is converted to "Read Only image (UDRO)". The converted image file is opened and the background image is visible. The image file is then copied to a MacBook running macOS 12 Monterey and opened. The background image is NOT shown. The image file is copied to a Mac mini running macOS 14 Sequoia and opened. The background image is NOT shown. Have read past online discussions in which it was explained that an image file called "background" should be inside a hidden folder called ".background". The above procedure did not do that. Is that old advice still correct for macOS Tahoe ? Has Tahoe somehow broken the method used for setting the background of a Window ? Is the method used in Tahoe different to past versions of macOS ? If so, is there a way of maintaining compatibility with old versions of macOS ? Is there any documentation on how to set the background image of a DMG window which might explain this behaviour ?? Thanks.

I'm trying to put a sub menu inside the context menu using the NSExtensionFileProviderActions in info.plist. Which should look like this image below I have been trying to use FPUIActionExtensionViewController for doing this task but I havent got any context menu like above. But still doing that does seem to complicate the task more. Is there a simpler way to do this task, like doing it within the info.plist so I dont have to complicate the task by creating a view controller. ?

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

In trying to convert some Objective-C to Swift, I have a subclass of NSWindowController and want to write a convenience initializer. The documentation says You can also implement an NSWindowController subclass to avoid requiring client code to get the corresponding nib’s filename and pass it to init(windowNibName:) or init(windowNibName:owner:) when instantiating the window controller. The best way to do this is to override windowNibName to return the nib’s filename and instantiate the window controller by passing nil to init(window:). My attempt to do that looks like this: class EdgeTab: NSWindowController { override var windowNibName: NSNib.Name? { "EdgeTab" } required init?(coder: NSCoder) { super.init(coder: coder) } convenience init() { self.init( window: nil ) } } But I'm getting an error message saying "Incorrect argument label in call (have 'window:', expected 'coder:')". Why the heck is the compiler trying to use init(coder:) instead of init(window:)?

On macOS 26.1 (25B78) I can't give Full Disk Access to sshd-keygen-wrapper. Now my Jenkins jobs do not work because they do not have the permission to execute the necessary scripts. Until macOS 26.1 everything worked fine. I restarted the machine several times and tried to give access from Settings -> Privacy & Security -> Full Disk Access but it just does not work. I tried logging with ssh on the machine and executing a script but again nothing happened.

Dear Apple, while implementing Declared Age Range API in my app, I've noticed a mistake in documentation: the isEligibleForAgeFeatures property is marked 26.0+ in documentation, but 26.2+ in Xcode, which ultimately leads to inability to use it with OS below 26.2. Moreover, I'm thoroughly confused by this quote from documentation: This flag returns true on iOS and iPadOS based on a person’s eligibility and always returns false on macOS. It leads me to two questions: Is it possible to use Declared Age Range API for macOS apps? Will it be possible to use it in future? Will there be any changes regarding this matter in a meantime (especially after Jan 1st)? If yes - when should we expect these changes? If no - why this API declares macOS 26+ support alongside iOS/iPadOS, if it simply doesn't work for macOS now? As of now, my iOS app works flawlessly with given API (on iOS 26.2) while macOS app returns isEligibleForAgeFeatures = false and requestAgeRange request always throws AgeRangeService.Error.notAvailable. Also, does it mean that one should not use isEligibleForAgeFeatures boolean while implementing Declared Age Range API for apps below iOS 26.2 (I mean 26.0+)? Or implementing given API for iOS 26.2+ is a sufficient way to go? So shouldn't the whole API be marked as 26.2+? The minimum iOS version in my app is 16.0 and minimum macOS version is 13.0 anyway, so the significant part of users is left out of these updates, but the main goal here is legal compliance.

In my impression, this issue has been around for years. In the Mac App Store, the app description is collapsed by default. After clicking "More" to expand it, the last few lines of the description are always cropped. It seems that the more content there is, the more content gets cropped. The following screenshots are from the same app, one with the system language set to Chinese and the other to English.

We recently upgraded OpenSSL from version 1.1.1 to 3.4.0. After this upgrade, we observed that PKCS#12 files generated using OpenSSL 3.4.0 fail to import into the macOS Keychain with the following error: Failed to import PKCS#12 data: -25264 (MAC verification failed during PKCS12 import (wrong password?)) This issue is reproducible on macOS 14.8.2. The same PKCS#12 files import successfully on other macOS versions, including 15.x and 26.x. Additionally, PKCS#12 files that fail to import on macOS 14.8 work correctly when copied and imported on other macOS versions without any errors. PKCS#12 Creation The PKCS#12 data is created using the following OpenSSL API: const char* platformPKCS12SecureKey = _platformSecureKey.has_value() ? _platformSecureKey.value().c_str() : NULL; PKCS12* p12 = PKCS12_create( platformPKCS12SecureKey, NULL, keys, _cert, NULL, 0, 0, 0, 0, 0 ); if (!p12) { throw std::runtime_error("Failed to create PKCS#12 container"); } PKCS#12 Import The generated PKCS#12 data is imported into the macOS Keychain using the following code: NSString *certPassKey = [NSString stringWithUTF8String:getCertPassKey()]; NSDictionary *options = @{ (__bridge id)kSecImportExportPassphrase: certPassKey, (__bridge id)kSecAttrAccessible: (__bridge id)kSecAttrAccessibleAfterFirstUnlockThisDeviceOnly, (__bridge id)kSecAttrIsExtractable: @YES, (__bridge id)kSecAttrIsPermanent: @YES, (__bridge id)kSecAttrAccessGroup: APP_GROUP }; CFArrayRef items = NULL; OSStatus status = SecPKCS12Import( (__bridge CFDataRef)pkcs12Data, (__bridge CFDictionaryRef)options, &items );

Hello, After upgrading to macOS 26.2, I’ve noticed a significant performance regression when calling evaluateJavaScript in an iOS App running on Mac (WKWebView, Swift project). Observed behavior On macOS 26.2, the callback of evaluateJavaScript takes around 3 seconds to return. This happens not only for: evaluateJavaScript("navigator.userAgent") but also for simple or even empty scripts, for example: evaluateJavaScript("") On previous macOS versions, the same calls typically returned in ~200 ms. Additional testing I created a new, empty Objective-C project with a WKWebView and tested the same evaluateJavaScript calls. In the Objective-C project, the callback still returns in ~200 ms, even on macOS 26.2. Question Is this a known issue or regression related to: iOS Apps on Mac, Swift + WKWebView, or behavioral changes in evaluateJavaScript on macOS 26.2? Any information about known issues, internal changes, or recommended workarounds would be greatly appreciated. Thank you. Test Code Swift class ViewController: UIViewController { private var tmpWebView: WKWebView? override func viewDidLoad() { super.viewDidLoad() // Do any additional setup after loading the view. setupUserAgent() } func setupUserAgent() { let t1 = CACurrentMediaTime() tmpWebView = WKWebView(frame: .zero) tmpWebView?.isInspectable = true tmpWebView?.evaluateJavaScript("navigator.userAgent") { [weak self] result, error in let t2 = CACurrentMediaTime() print("[getUserAgent] \(t2 - t1)s") self?.tmpWebView = nil } } } Test Code Objective-C - (void)scene:(UIScene *)scene willConnectToSession:(UISceneSession *)session options:(UISceneConnectionOptions *)connectionOptions { NSTimeInterval startTime = [[NSDate date] timeIntervalSince1970]; WKWebView *webView = [[WKWebView alloc] init]; dispatch_async(dispatch_get_main_queue(), ^{ [webView evaluateJavaScript:@"navigator.userAgent" completionHandler:^(id result, NSError *error) { NSTimeInterval endTime = [[NSDate date] timeIntervalSince1970]; NSLog(@"[getUserAgent]: %.2f s", (endTime - startTime)); }]; }); }

Since upgrading to Mac OS 10.5 Beta-2, daemons launched with launchctl are failing to open Desktop/Documents/Downloads files and folders even in read mode with an error "Operation not permitted".Does anyone facing this issue?

Hello, According to documentation, the App Store does not re-download the entire app when updating, but instead generates an update package containing only the changed content compared to the previous version. I’d like to clarify the following points: 1. Granularity of file changes If only part of a large file changes, does the update package include the entire file, or does it patch only the modified portions within that file? 2. Guideline on separating files The documentation recommends separating files that are likely to change from those that are not. How should this be interpreted in practice? 3. Verifying the diff result Is there a way for developers to check the actual diff result of the update package generated by the App Store without submitting the app? Is there a diff command tool or comparison method closer to the actual App Store update process? 4. Estimating update size during development For apps with large-scale resources, minimizing update size is critical. Are there any tools or best practices to estimate the size of the update package before submitting to the App Store? Any clarification or reference materials would be greatly appreciated. Thank you.

While preparing my app for Declared Age Range capability usage, I've noticed a weird behaviour: the same code works for iOS, but not for macOS. My project uses same target for both platforms, so the capability is enabled for both platforms. The business logic layer is also shared across between platforms. Both UI layers are writter in SwiftUI. The iCloud account used for testing on iOS and macOS devices is the same, so even the consent is shared across both devices. While requestAgeRange(ageGates:) seems to work just fine for iOS app, for macOS app it always throws Not available error (DeclaredAgeRange.AgeRangeService.Error.notAvailable) Am I missing something? Could the API be somehow unavailable for macOS? Should I use AgeRangeService.shared.requestAgeRange(ageGates:in:) for macOS instead of SwiftUI's @Environment-based approach? Also, after giving permission, is there a way to actually revoke it? In Age Range for Apps menu I can only view the list of apps that have my consent to share my age range, but not the ability to revoke it.

I'm currently observing a problem similar to this thread https://developer.apple.com/forums/thread/737334 The difference is that this is happening after updating a system extension. Basically same error, sysextd complains it can not check that the system extension is notarized: macOS Error 3 + Error code=-67050. I think macOS (Sequoia 15.3.2 or 15.7.2 if it matters) is wrong in this case for the following reasons: when using spctl assess -t install, the system extension is reported to be correctly notarized. when restarting the Mac, the updated system extension is correctly checked and staged. if I run spctl assess before sysextd tries to check the system extension, it works. I'm currently thinking of 2 reasons why the check does not work: sysextd is somehow trying to work with a cached assessment that has become invalid after the system extension was updated. macOS needs way more time between the update of the files and the request to update the staged extension. I tried adding a 5-second delay. This does not seem to work or at least reliably. I tried just touching the system extension, no positive result. Unfortunately, in macOS Sequoia, it is not possible anymore to reset-default using spctl and see if it solves the issue, at least the next time the update is performed. [Q] Is there some magic operation that would help macOS correctly check the notarization of an updated system extension?

[Submitted as FB20950954] Xcode Simulator causes crackling and distortion in audio playback across all apps (Apple Podcasts, Music, third-party). REPRO STEPS Open any audio app and start playback Note the audio quality Launch Xcode Simulator After a few seconds, note audio quality again Quit Xcode Simulator Audio returns to normal CURRENT Audio has crackling and distortion while Simulator is running. EXPECTED Clean audio playback regardless of whether Simulator is running. SYSTEM INFO macOS 26.1 (25B78) Xcode 26.1 (17B55) Simulator 26.0 (1058)

Hi everyone, I'm new to building apps on Swift and recently I've been wondering how does Apple get this blur effect behind the control center on Mac OS Tahoe. I think it would be nice to use in an app that I'm making but I can't seem to find it in the docs. Is it available through AppKit? I would appreciate some help on this