I built a couple of app intents for macOS, which generally work great. However, I'm struggling with configuring an app intent that takes a parameter, so that it doesn't require the app to launch before presenting people with the list of options. If the app is running and I run the intent in Spotlight, I can see the message defined by the intent's parameterSummary and I can select a parameter from the list of entities. If the app is not running, it is launched first and only then the intent message fully populates in Spotlight and allows parameter selection. What I've tried: Support background or deferred mode in the intent. Conformed the entities to IndexedEntity. Conformed the entity query to EnumerableEntityQuery, implementing suggestedEntities and allEntities. Conformed the entity query to EntityStringQuery. Donated the intent to Spotlight on app launch. Donated the entities to Spotlight on app launch, both using indexSearchableItems and indexAppEntities. Not sure if both are required or if the latter is just a more convenient version of the former. Do I have to conform to or implement something else? Do I need to work with an app intent extension? If so, would I put all app intent code into the extension instead of the main app? Is this a system bug I should file?

I'm writing a read-only filesystem extension. I see that the documentation for loadResource(resource:options:replyHandler:) claims that the --rdonly option is supported, which suggests that this should be possible. However, I have never seen this option provided to my filesystem extension, even if I return usableButLimited as a probe result (where it doesn't mount at all - FB19241327) or pass the -r or -o rdonly options to the mount(8) command. Instead I see those options on the volume's activate call. But other than saving that "readonly" state (which, in my case, is always the case) and then throwing on all write-related calls I'm not sure how to actually mark the filesystem as "read-only." Without such an indicator, the user is still offered the option to do things like trash items in Finder (although of course those operations do not succeed since I throw an EROFS error in the relevant calls). It also seems like the FSKit extensions that come with the system handle read-only strangely as well. For example, for a FAT32 filesystem, if I mount it like mount -r -F -t msdos /dev/disk15s1 /tmp/mnt Then it acts... weirdly. For example, Finder doesn't know that the volume is read-only, and lets me do some operations like making new folders, although they never actually get written to disk. Writing may or may not lead to errors and/or the change just disappearing immediately (or later), which is pretty much what I'm seeing in my own filesystem extension. If I remove the -F option (thus using the kernel extension version of msdos), this doesn't happen. Are read-only filesystems currently supported by FSKit? The fact that extensions like Apple's own msdos also seem to act weirdly makes me think this is just a current FSKit limitation, although maybe I'm missing something. It's not necessarily a hard blocker given that I can prevent writes from happening in my FSKit module code (or, in my case, just not implement such features at all), but it does make for a strange experience. (I reported this as FB21068845, although I'm mostly asking here because I'm not 100% sure this is not just me missing something.)

Hi everyone, I need help stopping the maintenance wakes due to "CalendarDate". All apparently related UI settings are off (Calendar: manual refresh, no notifications, time to travel OFF, Settings > Time & Date > Automatic time & date OFF) Two days ago, I got hourly dark wakes, but then I turned "Automatic time & date" off, and now I only got 5 wakes instead of 10, but I think this still shouldn't happen with all these settings off. I would appreciate any help. System: macOS 26.1 MacBook Pro 2019 pmset -g VACTDisabled 0 Currently in use: lidwake 1 lowpowermode 0 standbydelayhigh 0 proximitywake 0 standby 0 standbydelaylow 0 ttyskeepawake 0 hibernatemode 3 powernap 0 gpuswitch 2 hibernatefile /var/vm/sleepimage highstandbythreshold 50 displaysleep 10 womp 0 networkoversleep 0 sleep 0 (sleep prevented by bluetoothd, mds_stores) tcpkeepalive 0 halfdim 0 acwake 0 disksleep 10 pmset -g log | grep "due to" 2025-11-16 00:26:38 +0100 DarkWake DarkWake from Deep Idle [CDN] : due to EC.RTC/Maintenance Using AC (Charge:100%) 45 secs 2025-11-16 00:27:23 +0100 Sleep Entering Sleep state due to 'Maintenance Sleep':TCPKeepAlive=disabled Using AC (Charge:100%) 13728 secs 2025-11-16 04:16:11 +0100 DarkWake DarkWake from Deep Idle [CDN] : due to EC.RTC/Maintenance Using AC (Charge:100%) 45 secs 2025-11-16 04:16:56 +0100 Sleep Entering Sleep state due to 'Maintenance Sleep':TCPKeepAlive=disabled Using AC (Charge:100%) 7216 secs 2025-11-16 06:17:12 +0100 DarkWake DarkWake from Deep Idle [CDN] : due to EC.RTC/Maintenance Using AC (Charge:100%) 45 secs 2025-11-16 06:17:57 +0100 Sleep Entering Sleep state due to 'Maintenance Sleep':TCPKeepAlive=disabled Using AC (Charge:100%) 3616 secs 2025-11-16 07:18:13 +0100 DarkWake DarkWake from Deep Idle [CDN] : due to EC.RTC/Maintenance Using AC (Charge:100%) 45 secs 2025-11-16 07:18:58 +0100 Sleep Entering Sleep state due to 'Maintenance Sleep':TCPKeepAlive=disabled Using AC (Charge:100%) 3616 secs 2025-11-16 08:19:14 +0100 DarkWake DarkWake from Deep Idle [CDN] : due to EC.RTC/Maintenance Using AC (Charge:100%) 45 secs 2025-11-16 08:19:59 +0100 Sleep Entering Sleep state due to 'Maintenance Sleep':TCPKeepAlive=disabled Using AC (Charge:100%) 1457 secs log show --predicate '"SMCRTC"' --start "2025-11-16 00:00:00" --end "2025-11-16 08:00:00" --info --debug (showing only the sequence from the first dark wake) 2025-11-16 00:26:29.315541+0100 0x125b50 Default 0x0 0 0 kernel: (AppleSMCRTC) SMCRTC: setPowerState 1 2025-11-16 00:26:29.322608+0100 0x125a3e Default 0x0 0 0 kernel: (AppleSMCRTC) SMCRTC: [PowerByCalendarDate] 0/0/0 0:0:0 (0) 2025-11-16 00:26:29.322625+0100 0x125a3e Default 0x0 0 0 kernel: (AppleSMCRTC) SMCRTC: [PowerByCalendarDate] 0/0/0 0:0:0 (0) 2025-11-16 00:26:38.242885+0100 0x125c15 Default 0x0 0 0 kernel: (AppleSMCRTC) SMCRTC: [PowerByCalendarDate] 0/0/0 0:0:0 (0) 2025-11-16 00:26:38.242889+0100 0x125c15 Default 0x0 0 0 kernel: (AppleSMCRTC) SMCRTC: [PowerByCalendarDate] 0/0/0 0:0:0 (0) 2025-11-16 00:27:40.807018+0100 0x126175 Default 0x0 0 0 kernel: (AppleSMCRTC) SMCRTC: [MaintenanceWakeCalendarDate] 2025/11/16 3:16:0 (0) 2025-11-16 00:27:40.807038+0100 0x126175 Default 0x0 0 0 kernel: (AppleSMCRTC) SMCRTC: [MaintenanceWakeCalendarDate] 2025/11/16 3:16:0 (0) 2025-11-16 00:27:42.262812+0100 0x126290 Default 0x0 0 0 kernel: (AppleSMCRTC) SMCRTC: setPowerState 0 2025-11-16 00:27:42.262823+0100 0x126290 Default 0x0 0 0 kernel: (AppleSMCRTC) SMCRTC: setPowerState 0 2025-11-16 00:27:43.836823+0100 0x1262b2 Default 0x0 0 0 kernel: [143883.997279]: SMCRTC: setAlarmEnable 0xe0000280 2025-11-16 00:27:43.836830+0100 0x1262b2 Default 0x0 0 0 kernel: [143883.999744]: SMCRTC: enabled wake alarm (MaintenanceWakeCalendarDate) in 13697 seconds 2025-11-16 00:27:43.836836+0100 0x1262b2 Default 0x0 0 0 kernel: [143883.999845]: SMCRTC: setAlarmEnable 0xe0000300 2025-11-16 00:27:44.385470+0100 0x126209 Default 0x0 0 0 kernel: IOPlatformWakeAction -> AppleSMCRTC 2025-11-16 00:27:44.385474+0100 0x126209 Default 0x0 0 0 kernel: (AppleSMCRTC) SMCRTC: updated wake type to Maintenance 2025-11-16 00:27:44.385477+0100 0x126209 Default 0x0 0 0 kernel: (AppleSMCRTC) SMCRTC: updated wake type to Maintenance 2025-11-16 00:27:44.385481+0100 0x126209 Default 0x0 0 0 kernel: (AppleSMCRTC) SMCRTC: Maintenance 2025/11/16 03:16:00 2025-11-16 00:27:44.385485+0100 0x126209 Default 0x0 0 0 kernel: (AppleSMCRTC) SMCRTC: Maintenance 2025/11/16 03:16:00

Hi everyone, My MBP keeps waking from sleep every night to perform Calendar maintenance, although all UI settings that seem related are turned off (Calendar: manual refresh, time to travel = OFF, Clock: automatic time & date = OFF, Automatic Time Machine backup = OFF) Does anyone know how to stop this? Thank you! Here's a log entry sequence filtered by "SMCRTC", which is what's setting the wake alarms. 2025-11-16 06:17:03.314744+0100 0x126a4c Default 0x0 0 0 kernel: (AppleSMCRTC) SMCRTC: setPowerState 1 2025-11-16 06:17:03.321001+0100 0x126a25 Default 0x0 0 0 kernel: (AppleSMCRTC) SMCRTC: [PowerByCalendarDate] 0/0/0 0:0:0 (0) 2025-11-16 06:17:03.321006+0100 0x126a25 Default 0x0 0 0 kernel: (AppleSMCRTC) SMCRTC: [PowerByCalendarDate] 0/0/0 0:0:0 (0) 2025-11-16 06:17:12.237732+0100 0x126ab8 Default 0x0 0 0 kernel: (AppleSMCRTC) SMCRTC: [PowerByCalendarDate] 0/0/0 0:0:0 (0) 2025-11-16 06:17:12.237755+0100 0x126ab8 Default 0x0 0 0 kernel: (AppleSMCRTC) SMCRTC: [PowerByCalendarDate] 0/0/0 0:0:0 (0) 2025-11-16 06:18:15.297172+0100 0x127051 Default 0x0 0 0 kernel: (AppleSMCRTC) SMCRTC: [MaintenanceWakeCalendarDate] 2025/11/16 6:18:3 (0) 2025-11-16 06:18:15.297191+0100 0x127051 Default 0x0 0 0 kernel: (AppleSMCRTC) SMCRTC: [MaintenanceWakeCalendarDate] 2025/11/16 6:18:3 (0) 2025-11-16 06:18:16.747652+0100 0x127119 Default 0x0 0 0 kernel: (AppleSMCRTC) SMCRTC: setPowerState 0 2025-11-16 06:18:16.747678+0100 0x127119 Default 0x0 0 0 kernel: (AppleSMCRTC) SMCRTC: setPowerState 0 2025-11-16 06:18:18.320761+0100 0x78 Default 0x0 0 0 kernel: [164918.482167]: SMCRTC: setAlarmEnable 0xe0000280 2025-11-16 06:18:18.320767+0100 0x78 Default 0x0 0 0 kernel: [164918.484702]: SMCRTC: enabled wake alarm (MaintenanceWakeCalendarDate) in 3585 seconds 2025-11-16 06:18:18.320773+0100 0x78 Default 0x0 0 0 kernel: [164918.484802]: SMCRTC: setAlarmEnable 0xe0000300 2025-11-16 06:18:18.873247+0100 0x1271c6 Default 0x0 0 0 kernel: IOPlatformWakeAction -> AppleSMCRTC 2025-11-16 06:18:18.873252+0100 0x1271c6 Default 0x0 0 0 kernel: (AppleSMCRTC) SMCRTC: updated wake type to Maintenance 2025-11-16 06:18:18.873254+0100 0x1271c6 Default 0x0 0 0 kernel: (AppleSMCRTC) SMCRTC: updated wake type to Maintenance 2025-11-16 06:18:18.873259+0100 0x1271c6 Default 0x0 0 0 kernel: (AppleSMCRTC) SMCRTC: Maintenance 2025/11/16 06:18:03 2025-11-16 06:18:18.873262+0100 0x1271c6 Default 0x0 0 0 kernel: (AppleSMCRTC) SMCRTC: Maintenance 2025/11/16 06:18:03

I have an app for macOS that is built using Mac Catalyst. I need to perform some background processing. I'm using BGProcessingTaskRequest to schedule the request. I have also integrated CKSyncEngine so I need that to be able to perform its normal background processing. On iOS, when the user leaves the app, I can see a log message that the request was scheduled and a bit later I see log messages coming from the actual background task code. On macOS I ran the app from Xcode. I then quit the app (Cmd-q). I can see the log message that the request was scheduled. But the actual task is never run. In my test, I ran my app on a MacBook Pro running macOS 26.0. When I quit the app, I checked the log file in the app sandbox and saw the message that the task was scheduled. About 20 minutes later I closed the lid on the MacBook Pro for the night. I did not power down, it just went to sleep. Roughly 10 hours later I opened the lid on the MacBook Pro, logged in, and checked the log file. It had not been updated since quitting the app. I should also mention that the laptop was not plugged in at all during this period. My question is, does a Mac Catalyst app support background processing after the user quits the app? If so, how is it enabled? The documentation for BGProcessingTaskRequest and BGProcessingTask show they are supported under Mac Catalyst, but I couldn't find any documentation in the Background Tasks section that mentioned anything specific to setup for Mac Catalyst. Running the Settings app and going to General -> Login Items & Extension, I do not see my app under the App Background Activity section. Does it need to be listed there? If so, what steps are needed to get it there? If this is all documented somewhere, I'd appreciate a link since I was not able to find anything specific to making this work under Mac Catalyst.

Our background monitoring application uses a Unix executable that requests Screen Recording permission via CGRequestScreenCaptureAccess(). This worked correctly in macOS Tahoe 26.0.1, but broke in 26.1. Issue: After calling CGRequestScreenCaptureAccess() in macOS Tahoe 26.1: System dialog appears and opens System Settings Our executable does NOT appear in the Screen Recording list Manually adding via "+" button grants permission internally, but the executable still doesn't show in the UI Users cannot verify or revoke permissions Background: Unix executable runs as a background process (not from Terminal) Uses Accessibility APIs to retrieve window titles Same issue occurs with Full Disk Access permissions Environment: macOS Tahoe 26.1 (worked in 26.0.1) Background process (not launched from Terminal) Questions: Is this a bug or intentional design change in 26.1? What's the recommended approach for background executables to properly register with TCC? Are there specific requirements (Info.plist, etc.) needed? This significantly impacts user experience as they cannot manage permissions through the UI. Any guidance would be greatly appreciated. Thank you

Hello, Users are reporting that widgets in my iOS app running on Mac OS are starting to crash after updating to MacOS 26.1. Everything works fine on iOS 26.1 and MacOS 15.6. The same bugs I found in iOS 26 beta 4, but then Apple fixed them in iOS 26RC and now they're back in macOS. Any suggestions? Crash report: Process: WidgetWebWidgetExt [23580] Path: /Volumes/VOLUME/*/WidgetWeb.app/PlugIns/WidgetWebWidgetExt.appex/WidgetWebWidgetExt Identifier: app.vitalek.widgetapp.web.WidgetWebExt Version: 7.5 (5796) AppVariant: 1:MacFamily20,1:18 Code Type: ARM-64 (Native) Role: unknown Parent Process: launchd [1] Coalition: app.vitalek.widgetapp.web.WidgetWebExt [28539] User ID: 501 Date/Time: 2025-11-04 11:47:19.0746 -0500 Launch Time: 2025-11-04 11:47:18.8035 -0500 Hardware Model: Mac14,6 OS Version: macOS 26.1 (25B78) Release Type: User Crash Reporter Key: 39D39455-7F69-746C-2A1D-7A6086F25541 Incident Identifier: 7AC31574-73A4-4320-B17A-C2819252EEDA Sleep/Wake UUID: 1535756C-44D8-497F-A288-07E53CD9B9E4 Time Awake Since Boot: 18000 seconds Time Since Wake: 7417 seconds System Integrity Protection: enabled Triggered by Thread: 0, Dispatch Queue: com.apple.main-thread Exception Type: EXC_CRASH (SIGABRT) Exception Codes: 0x0000000000000000, 0x0000000000000000 Termination Reason: Namespace SIGNAL, Code 6, Abort trap: 6 Terminating Process: WidgetWebWidgetExt [23580] Application Specific Information: abort() called Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 libsystem_kernel.dylib 0x1926e75b0 __pthread_kill + 8 1 libsystem_pthread.dylib 0x192721888 pthread_kill + 296 2 libsystem_c.dylib 0x192626850 abort + 124 3 libc++abi.dylib 0x1926d5858 __abort_message + 132 4 libc++abi.dylib 0x1926c44d4 demangling_terminate_handler() + 304 5 libobjc.A.dylib 0x1922f0414 _objc_terminate() + 156 6 libc++abi.dylib 0x1926d4c2c std::__terminate(void (*)()) + 16 7 libc++abi.dylib 0x1926d8394 __cxxabiv1::failed_throw(__cxxabiv1::__cxa_exception*) + 88 8 libc++abi.dylib 0x1926d833c __cxa_throw + 92 9 libobjc.A.dylib 0x1922e6580 objc_exception_throw + 448 10 Foundation 0x19495122c -[NSAssertionHandler handleFailureInMethod:object:file:lineNumber:description:] + 288 11 UIKitMacHelper 0x1b0240c80 -[UINSApplicationDelegate init] + 1348 12 UIKitMacHelper 0x1b02406d8 __41+[UINSApplicationDelegate sharedDelegate]_block_invoke + 48 13 libdispatch.dylib 0x19257eac4 _dispatch_client_callout + 16 14 libdispatch.dylib 0x192567a60 _dispatch_once_callout + 32 15 UIKitMacHelper 0x1b02405dc +[UINSApplicationDelegate sharedDelegate] + 324 16 UIKitCore 0x1ca488518 -[UIScene setTitle:] + 188 17 UIKitCore 0x1ca487e90 -[UIScene initWithSession:connectionOptions:] + 1084 18 UIKitCore 0x1cb2a6a54 -[UIWindowScene initWithSession:connectionOptions:] + 92 19 UIKitCore 0x1ca66b44c -[_UIScreenBasedWindowScene initWithScreen:session:lookupKey:] + 292 20 UIKitCore 0x1ca66aff4 +[_UIScreenBasedWindowScene _unassociatedWindowSceneForScreen:create:] + 408 21 UIKitCore 0x1cb09171c -[UIWindow _uiWindowSceneFromFBSScene:] + 704 22 UIKitCore 0x1cb0918cc -[UIWindow _initWithFrame:debugName:scene:attached:] + 92 23 UIKitCore 0x1cb091e68 -[UIWindow _initWithOrientation:] + 56 24 UIKitCore 0x1cb091ebc -[UIWindow init] + 72 25 WidgetWebWidgetExt 0x1027eb250 0x102718000 + 864848 26 WidgetWebWidgetExt 0x1027ea418 0x102718000 + 861208 27 WidgetWebWidgetExt 0x1027f5bc8 0x102718000 + 908232 28 WidgetWebWidgetExt 0x1027f4bfc 0x102718000 + 904188 29 WidgetWebWidgetExt 0x1027cf9f4 0x102718000 + 752116 30 WidgetWebWidgetExt 0x102807c20 0x102718000 + 982048 31 libdispatch.dylib 0x19257eac4 _dispatch_client_callout + 16 32 libdispatch.dylib 0x1925696e4 _dispatch_continuation_pop + 596 33 libdispatch.dylib 0x19257c800 _dispatch_source_latch_and_call + 396 34 libdispatch.dylib 0x19257b4d4 _dispatch_source_invoke + 844 35 libdispatch.dylib 0x19259c008 _dispatch_main_queue_drain.cold.5 + 592 36 libdispatch.dylib 0x192573f48 _dispatch_main_queue_drain + 180 37 libdispatch.dylib 0x192573e84 _dispatch_main_queue_callback_4CF + 44 38 CoreFoundation 0x1927ea980 __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ + 16 39 CoreFoundation 0x1927bf7dc __CFRunLoopRun + 1944 40 CoreFoundation 0x19287935c _CFRunLoopRunSpecificWithOptions + 532 41 Foundation 0x194a06890 -[NSRunLoop(NSRunLoop) runMode:beforeDate:] + 212 42 Foundation 0x194005a50 -[NSRunLoop(NSRunLoop) run] + 64 43 libxpc.dylib 0x19240ce14 _xpc_objc_main + 668 44 libxpc.dylib 0x19241ecf8 _xpc_main + 40 45 libxpc.dylib 0x19241ecd0 xpc_bs_main + 16 46 BoardServices 0x1ac51179c +[BSServicesConfiguration activateXPCService] + 72 47 ExtensionFoundation 0x237a92710 _EXRunningExtension.resume() + 1592 48 ExtensionFoundation 0x237a911a8 _EXRunningExtension.start(withArguments:count:) + 124 49 ExtensionFoundation 0x237a88f24 EXExtensionMain(_:_:) + 668 50 Foundation 0x1940065ec NSExtensionMain + 200 51 dyld 0x192359d54 start + 7184

Simply opening Simulator app (26.0) causes high CPU usage on macOS Tahoe (26.1). ReportCrash process usage is very high throughout and causes the system to heat up pretty soon. Looking into Console app for the logs found MercuryPosterExtension process is keep on crashing. (Check under Crash Reports) simctl Diagnose https://download.developer.apple.com/OS_X/OS_X_Logs/simctl_Diagnose_Logging_Instructions.pdf Share the Simulator Diagnose report while reporting, Thanks. I have raised a ticket/feedback with Apple. I request all of you to raise one too so this gets fixed soon. Apple Feedback Assistant - FB20985249

Platform SSO not working on macos devices for zscaler application other app like safari / chrome working well. Need help from apple expert on the same. Environment : IDP : Entra ID MDM : Omnissa Workspace one UEM platform : macOS

I'm looking for clarification on a SwiftUI performance point mentioned in the recent Optimize your app's speed and efficiency | Meet with Apple video. (YouTube link not allowed, but the video is available on the Apple Developer channel.) At the 1:48:50 mark, the presenter says: Writing a value to the Environment doesn't only affect the views that read the key you're updating. It updates any view that reads from any Environment key. [abbreviated quote] That statement seems like a big deal if your app relies heavily on Environment values. Context I'm building a macOS application with a traditional three-panel layout. At any given time, there are many views on screen, plus others that exist in the hierarchy but are currently hidden (for example, views inside tab views or collapsed splitters). Nearly every major view reads something from the environment—often an @Observable object that acts as a service or provider. However, there are a few relatively small values that are written to the environment frequently, such as: The selected tab index The currently selected object on a canvas The Question Based on the presenter's statement, I’m wondering: Does writing any value to the environment really cause all views in the entire SwiftUI view hierarchy that read any environment key to have their body re-evaluated? Do environment writes only affect child views, or do they propagate through the entire SwiftUI hierarchy? Example: View A └─ View B ├─ View C └─ View D If View B updates an environment value, does that affect only C and D, or does it also trigger updates in A and B (assuming each view has at least one @Environment property)? Possible Alternative If all views are indeed invalidated by environment writes, would it be more efficient to “wrap” frequently-changing values inside an @Observable object instead of updating the environment directly? // Pseudocode @Observable final class SelectedTab { var index: Int } ContentView() .environment(\.selectedTab, selectedTab) struct TabView: View { @Environment(\.selectedTab) private var selectedTab var body: some View { Button("Action") { // Would this avoid invalidating all views using the environment? selectedTab.index = 1 } } } Summary From what I understand, it sounds like the environment should primarily be used for stable, long-lived objects—not for rapidly changing values—since writes might cause far more view invalidations than most developers realize. Is that an accurate interpretation? Follow-Up In Xcode 26 / Instruments, is there a way to monitor writes to @Environment?

[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)

Recently, we have adapted the passkey function on the Mac, but we always encounter the error message "Unable to verify the web credentials association of xxx with domain aaa. Please try again in a few seconds." We can confirm that https://aaa/.well-known/apple-app-site-association has been configured and is accessible over the public network. Additionally, the entitlements in the app have also been set with webcredentials:aaa. This feature has been experiencing inconsistent performance. When I restart my computer or reinstall the pkg, this feature may work or it may still not work. I believe this is a system issue. Here is feed back ID: FB20876945 In the feedback, I provided the relevant logs. If you have any suggestions or assistance, please contact me. I would be extremely grateful!

FaceTime’s screen-share audio balance is insanely absurd right now. Whenever I share media, the system audio that gets sent through FaceTime is a tiny whisper even at full volume (or even when connected to my speaker or headphones). The moment anyone on the call makes any noise at all, the shared audio ducks so hard it disappears, while the voice (or rustling or air conditioning noise) spikes to painful levels. It’s impossible to watch or listen to anything together. Also, the feature where FaceTime would shrink to a square during screen-sharing has been completely removed. That was a good feature and I'm really confused why it's gone. Now, the FaceTime window stays as a long rectangle that covers part of the content I'm trying to share (unless I do full screen tile, but then I can't pull up any other windows during the call) and can't be made smaller than about a third of the screen. You can't resize the window or adjust its dimensions, so it ends up blocking the actual media you're trying to watch. Here are some feature requests/fixes that would greatly improve the FaceTime screen-share experience: Option to adjust the shared media volume independently of call audio. Disable/toggle the extreme automatic audio docking while screen-sharing Reintroduce the minimized “floating square” mode or allow full manual resizing and repositioning of the FaceTime window during screen-share sessions. Overall, this setup makes FaceTime screen-sharing basically unusable. The audio balance is so inconsistent that it’s easier to switch to Zoom or Google Meet, which both handle shared sound correctly and let you move the call window out of the way. Until these issues are fixed, there’s no practical reason to use FaceTime for shared viewing at all.

On macOS, I get a system popup when running UI tests in GitHub saying: “bash” is requesting to bypass the system private window picker and directly access your screen and audio. How can I prevent these login and screen access popups from appearing during automated UI tests? Is there an official setup or configuration for running IntelliJ UI tests in CI environments (macOS, Linux, Windows) to avoid such dialogs? My builds run in GitHub Actions VMs, so I can’t manually grant these permissions, and they block the tests.

NSVisualEffectView in AppKit has two main properties: material and blendingMode. Material is well supported in SwiftUI, but I can't seem to find an equivalent for blendingMode. What is the SwiftUI equivalent to NSVisualEffect.BlendingMode?

Hello, I would like to change the system timezone in macOS, given a timezone identifier in the IANA timezone database. is 'systemsetup -settimezone' the only available tool or API that can be used to change the timezone? I have observed that TimeZone(identifier:) can initialize a TimeZone from any identifier in the tz database, but many identifiers are missing from the list accepted by systemsetup. For example, if the user has set the timezone to "Mumbai - India" in system settings, the timezone identifier returned by 'systemsetup -gettimezone' is Asia/Kolkata, which is not in the list printed by 'systemsetup -listtimezones'. What is the recommended way to map a IANA timezone name (or a TimeZone object) to one of the timezone names accepted by 'systemsetup'?

I have Mac apps that embed “Helper Apps” inside their main bundle. The helper apps do work on behalf of the main application. The helper app doesn’t show a dock icon, it does show minimal UI like an open panel in certain situations (part of NSService implementation). And it does make use of the NSApplication lifecycle and auto quits after it completes all work. Currently the helper app is inside the main app bundle at: /Contents/Applications/HelperApp.app Prior to Tahoe these were never displayed to user in LaunchPad but now the Spotlight based AppLauncher displays them. What’s the recommended way to get these out of the Spotlight App list on macOS Tahoe? Thanks in advance.

Hi, We use Flat package installers (.pkg based installers) to install our applications on macOS. In macOS 26.1, installation is failing with the error Unable to use PK session due to incompatible packages. Terminating. 2025-11-03 14:22:36+05:30 Admin-3 installer[1160]: Install failed: The Installer could not install the software because there was no software found to install. Same installer package is working on macOS 26. Any help is greatly appreciated.

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.

I am using an NSOutlineView via NSViewRepresentable in a SwiftUI application running on macOS. Everything has been working fine. Up until lately, I've been returning a custom NSView for each item using the standard: func outlineView(_ outlineView: NSOutlineView, viewFor tableColumn: NSTableColumn?, item: Any) -> NSView? { // View recycling omitted. return MyItemView(item) } Now I want to explore using a little bit more SwiftUI and returning an NSHostingView from this delegate method. func outlineView(_ outlineView: NSOutlineView, viewFor tableColumn: NSTableColumn?, item: Any) -> NSView? { // View recycling omitted. let rootView = MySwiftUIView(item) let hostingView = NSHostingView(rootView: rootView) return hostingView } For the most part, this appears to be working fine. NSOutlineView is even correctly applying highlight styling, so that's great. But there's one small glitch. The outline view's disclosure triangles do not align with the hosting view's content. The disclosure triangles appear to just be pinned to the top. Perhaps they can't find a baseline constraint or something? Is there any SwiftUI modifier or AppKit/SwiftUI technique I can apply here to get the disclosure button to appear in the right place? Here is what the SwiftUI + NSHostingView version looks like: Note the offset disclosure indicators. (Image spacing is a bit off as well using Label, but fixable. Here is what an NSView with NSTextFields looks like: Disclosure indicators are correctly aligned, as you would expect.