What supported behaviour, if any, may applications rely on for inherited RLIMIT_AS when launching a process on macOS on Apple silicon using posix_spawn and subsequent exec transitions? An older published XNU header defines RLIMIT_AS: XNU resource.h (immutable revision) I am looking for the documented support and virtual-address-space accounting scope, including exclusions. For a finite limit already set in the launching process, does any documented guarantee cover the new process from its first executable or dynamic-loader mapping and across later exec transitions, or does the limit take effect at a later stage? If the limit cannot be applied, does launch abort before any target user code executes, what failure is reported, and can mappings occur before that failure? An explicit statement that this guarantee is not provided would also be helpful. My question concerns virtual address space, rather than resident memory or a language runtime's heap. A successful setter or getrlimit readback by itself does not answer when the limit takes effect. If an answer relies on published XNU code, what public release/build record would be needed to relate an immutable source revision to a released macOS build on Apple silicon, and what limits apply to that correspondence? I am asking about the supported public interface and publicly available documentation/source, without requesting private implementation details. A link to an existing answer or the documented boundary would be appreciated.

My Mac App Store utility removes Mac metadata files (._* AppleDouble files and .DS_Store) from external drives formatted exFAT or FAT32. The app is sandboxed with com.apple.security.files.user-selected.read-write and com.apple.security.files.bookmarks.app-scope. The user grants access to the volume through NSOpenPanel. Deleting a ._ file works, except when its companion file carries com.apple.quarantine (for example, a file downloaded with Safari and copied to the drive with Finder). Then: let partner = volume + "/Nirvana.zip" // has com.apple.quarantine let appleDouble = volume + "/._Nirvana.zip" removexattr(partner, "com.apple.quarantine", XATTR_NOFOLLOW) // -1, errno 1 (EPERM) unlink(appleDouble) // -1, errno 1 (EPERM)The same unlink succeeds from Terminal (not sandboxed, without Full Disk Access). On exFAT the extended attributes live in the ._ file, so I assume the sandbox refuses because deleting it would remove the quarantine attribute. Tried, with no change: Full Disk Access granted to the app. Adding com.apple.security.files.user-selected.executable (verified in the built app with codesign -d --entitlements -). On a real drive (a music library), about 71% of the ._ files belong to quarantined files, so this is most of what users want removed. Is there a supported way for a sandboxed app to remove these files: an entitlement, an API, or an explicit user action? If not, can you confirm it's intended behavior, so I can explain it accurately to users? macOS 27.2, Xcode 27.2, Apple silicon. Focused sample project available (one source file). DTS case 23240704.

We would like to minimise the amount of code exposed in the product we have developed and an obvious option is to configure our build setting to use the All Symbols for Strip Style. Some investigation with an AI tool reports there are possible problems doing so. ContentFilter: non-global → all — risky. The NetworkExtension and XPC subsystems load your bundle and look up classes by name through the ObjC runtime, which uses __objc_classlist and friends (not the Mach-O symbol table), so in principle all works. In practice it occasionally breaks bundle loading in edge cases. If you try this, test specifically that systemextensionsctl activates the bundle and the filter actually traps packets. Is it safe to use All Symbols with a content filter or do we need to accept Non-Global symbols? Thanks, Dave

The Problem When a user toggles radio buttons or checkboxes in a PDF using Preview, the widgets disappear following subsequent interactions after the file is saved and reopened. This renders the form fields unusable. Steps to Reproduce the Problem Open a PDF with radio buttons or checkboxes in Preview. Toggle a radio button or checkbox. Save and close the file. Re-open the PDF in Preview. Toggle the same button again. The button (and any others with the same field name) will disappear. Expected Results Toggling a radio button or checkbox should update the field value without causing the button (or related buttons) to disappear. This behavior is consistent with previous versions of PDFKit. What is Happening In Preview, interacting with radio buttons and checkboxes correctly updates their appearance as expected. Saving the PDF, however, causes the appearance dictionary to reference a new N entry that is a single appearance stream unassociated with any state. The annotation's AS entry is not updated. The original N entry remains but is no longer referenced. Subsequent interactions fail to update the visual presentation because the appearance stream is missing. Impact on User Experience Radio buttons and checkboxes may disappear and become unusable when toggled. PDF documents become irreparably altered after a button is toggled and the file is saved. PDF file size significantly increases when the file is saved. Users may believe they have successfully completed a form, only for the data to become inaccessible or invisible to recipients. Forms may need to be completely restarted or recreated from scratch if the original becomes unusable. The corrupted PDF structure might cause the file to render incorrectly or crash in third-party PDF viewers. Affected Apps/OSs Tested with Preview 11.0 (1147), as well as other apps that use PDFKit, on macOS Golden Gate 27.0 (26A428). This problem also affects PDFKit on iOS 27.0 and iPadOS 27.0. Feedback/bug report: FB24866826 Related Sample Output Original PDF File Checkbox widget annotation (6 0 obj), its appearance dictionary (17 0 obj), and normal appearance dictionary (18 0 obj). Button is not checked. 6 0 obj << /Border [ 0 0 0 ] /Rect [ 90 390 110 410 ] /T (button1) /F 4 /Subtype /Widget /DA (/.AppleSystemUIFont 13 Tf 0 g) /MK 16 0 R /C [ 0 ] /AP 17 0 R /V /Off /M (D:20260919225320Z00'00') /AS /Off /FT /Btn /Type /Annot /Ff 0 >> endobj 17 0 obj << /N 18 0 R >> endobj 18 0 obj << /Yes 20 0 R /Off 22 0 R >> endobj PDF File after Save Checkbox widget annotation object (6 0 obj), its new appearance dictionary object (8 0 obj), a new normal appearance stream object (20 0 obj), and the original appearance stream dictionary (now 21 0 obj). File saved after user checked button. 6 0 obj << /Ff 0 /Type /Annot /AS /Off /AP 8 0 R /MK 9 0 R /C [ 0 ] /FT /Btn /M (D:20260919225320Z00'00') /DA (/.AppleSystemUIFont 13 Tf 0 g) /Subtype /Widget /F 4 /Border [ 0 0 0 ] /Rect [ 90 390 110 410 ] /T (button1) /V (Yes) >> endobj 8 0 obj << /N 20 0 R >> endobj 20 0 obj << /Filter /FlateDecode /Resources << /ColorSpace << /CS1 [ /ICCBased 29 0 R ] /CS2 [ /ICCBased 30 0 R ] >> >> /BBox [ 0 0 20 20 ] /Type /XObject /Subtype /Form /Length 123 >> stream x UéA ¬0 Ô}≈|†≈nà¢úÛÇ* —SA =}Ïr(»ñµ≤w◊€YËà’|ÙÎŒç'óRï∂#SäÏÌü∞¢S‰Ì§ôRÌX }–É•åY Éçˆ BŒ H " *â´8™ˆZø6z⁄ÿ ”ú6ɀ੠"∫t˘‹;'¬ endstream endobj 21 0 obj << /Off 22 0 R /Yes 23 0 R >> endobj Note: No object references 21 0 obj in the PDF.

The Problem On opening a PDF document in the Preview app, PDF widget annotations appear pixelated/rasterized. This problem exists with button, text, and choice widget subtypes. The pixelation becomes more apparent when zoomed in. Expected Results PDF widgets should appear sharp and smooth, without pixelation. In previous versions of the Preview app, widgets appear vector-based as expected. Impact on User Experience PDF widgets appear pixelated and inconsistent with text content in the same PDF document. Widgets do not look like elements of an interactive form but, instead, resemble low-quality embedded images. Affected Apps/OSs: Preview 11.0 (1147), as well as other apps that use PDFKit, on macOS Golden Gate 27.0 (26A428). A similar problem appears to affect PDFKit on iOS 27.0 and iPadOS 27.0 as well. Feedback/bug report: FB24843022

Circling back on the LocalLM Lab arc. With v0.7, we've moved from prompt experimentation into real app development on Apple's Foundation Models local AI. The LocalLM Lab SDK lets you build that same on-device model and MCP client this thread has covered directly into your own app, with real tool and data access (Slack, Todoist, GitHub, Notion, Linear, plus Calendar, Reminders, Contacts and Location). And you can ship your app including through the Mac App Store. This is a big improvement over version 0.6, where the localai-cli toolkit needed LocalLM Lab installed and running. On the other hand, the SDK (LocalLMLabSDKCore) doesn't relay through anything; it links FoundationModels and a real MCP client directly into your own binary and is totally self-contained. The example included in the SDK, Plate Today, has actually been built into a sandboxed test app and verified working, with a signed path to a Mac App Store .pkg (Apple Distribution signing + provisioning profile pipeline). That's "verified signable and sandbox-compatible," to be precise. Entitlements (from personal experience: always a complicated topic): com.apple.security.app-sandbox + com.apple.security.network.client for the app itself, plus the standard personal-information entitlements per connector used (com.apple.security.personal-information.calendars, .addressbook, .location) and matching NS*UsageDescription strings in Info.plist. The one worth flagging specifically: the network entitlement is easy to miss and fails silently rather than throwing. Without it, MCP connections and Weather calls just hang with no error surfaced. OAuth handling requires the app delegate callback (application(_:open:)), not SwiftUI's .onOpenURL. Worth knowing before wiring it up if you're SwiftUI-only. Full entitlements list + SDK guide: https://github.com/ancientcomputing/locallm/blob/main/docs/sdk-guide.md Feature page: thisbrain.ai/locallm/sdk.html I hope the availability of the SDK (free, Apache 2.0 license) will give folks further incentive to explore local AI-enabled applications on the Mac. What else would you want to do that the SDK doesn't currently support? File picker? Calendar/Reminders/Contacts edits & writes?

After updating my MacBook Pro (M4) to macOS 27.3 Beta (26C5035r), application windows flicker or flash while I drag them. They also unexpectedly jump to random positions and change size. This did not happen before the update. I have isolated the behavior to the "Show Menu Bar Background" setting ("Menü çubuğu arka planını göster" in Turkish). With this setting enabled, the problem occurs. Disabling it completely eliminates the problem on the same Mac. Steps to reproduce: Enable "Show Menu Bar Background" in System Settings. Open an application window and drag it by its title bar around the desktop. Observe the flickering/flashing and unexpected changes in position and size. Disable "Show Menu Bar Background" and repeat the dragging action. The problem disappears. Expected behavior: Windows should move smoothly with the pointer and keep their size unless intentionally resized. Actual behavior: Dragged windows flicker, jump, and resize unexpectedly when the menu bar background is enabled. Workaround: Leave "Show Menu Bar Background" disabled. Has anyone else encountered this after the same update? Is there another workaround that allows the menu bar background to remain enabled?

Traverse is a sandboxed macOS file manager with user-selected read/write access. For an input already carrying the complete raw com.apple.quarantine value 0086;timestamp;agent;event, a fresh private copy may receive 0082 with the remaining fields equal. This asks about the input state, without claiming a verified creation recipe for the retained test file. Our security requirement is equality of the entire original raw value before and throughout the interval when the destination name is reachable, including interruption immediately after publication. Is there a documented, supported App Sandbox API or operation that guarantees this for (a) a same-volume, same-inode move from private staging to an absent user-selected name, (b) a new file or extracted ZIP member, and (c) native Trash followed by restoration? If so, what OS/volume/entitlement scope and exact guarantee apply, and can the raw flags and event field be preserved without removing or replacing an OS-assigned quarantine mark? If no such public contract exists, please confirm that raw byte equality cannot be claimed from quarantineProperties, FileManager.trashItem, NSWorkspace.recycle, NSFileCoordinator, rename, clone/copy, or post-operation readback alone. We are not requesting a bypass of quarantine or a weaker substitute for 0086.

Our app crashes when compiled with the iOS 27 beta 3 SDK and run as an iOS app on Mac, on both macOS 26 and macOS 27, as soon as a UISearchBar receives focus. The crash is due to this exception: *** Assertion failure in BOOL _screenBasedFocusUnsupported(void)(), UIScreen.m:3.725 Accessing the focus system through UIScreen is no longer supported. ( 0 CoreFoundation 0x000000018bea31c0 __exceptionPreprocess + 176 1 libobjc.A.dylib 0x000000018b91e91c objc_exception_throw + 88 2 Foundation 0x000000018e092644 -[NSMutableDictionary(NSMutableDictionary) initWithContentsOfFile:] + 0 3 UIKitCore 0x00000001c5dae8ec _screenBasedFocusUnsupported + 272 4 UIKitCore 0x00000001c5dae960 -[UIScreen _preferredFocusedWindow] + 24 5 UIKitCore 0x00000001c4ea3a60 -[UIScreen _mainSceneReferenceBounds] + 200 6 UIKitCore 0x00000001c4ea3914 -[UIScreen _mainSceneBoundsForInterfaceOrientation:] + 40 7 UIKitCore 0x00000001c5708134 +[UINavigationBar defaultSizeForOrientation:] + 76 8 UIKitCore 0x00000001c6222c88 -[_UISearchPresentationController _layoutPresentationWithSize:transitionCoordinator:] + 704 9 UIKitCore 0x00000001c622296c -[_UISearchPresentationController containerViewWillLayoutSubviews] + 84 10 UIKitCore 0x00000001c549304c block_destroy_helper.13 + 25112 11 UIKitCore 0x00000001c549344c block_destroy_helper.13 + 26136 12 UIKitCore 0x00000001c4ea26a8 -[UIView(CALayerDelegate) layoutSublayersOfLayer:] + 1648 13 QuartzCore 0x0000000196103dbc _ZN2CA5Layer15perform_update_EPS0_P7CALayerjNS_17LayerUpdateReasonEPNS_11TransactionE + 460 14 QuartzCore 0x000000019610390c _ZN2CA5Layer17update_if_needed_EPNS_11TransactionENS_17LayerUpdateReasonE + 692 15 QuartzCore 0x0000000196035d2c _ZN2CA7Context18commit_transactionEPNS_11TransactionEdPd + 608 16 QuartzCore 0x0000000195e69520 _ZN2CA11Transaction6commitEv + 652 17 AppKit 0x0000000190fe116c __37+[NSDisplayCycle currentDisplayCycle]_block_invoke.7 + 44 18 CoreFoundation 0x000000018be34ad0 __CFRUNLOOP_IS_CALLING_OUT_TO_A_BLOCK__ + 28 19 CoreFoundation 0x000000018be34a10 __CFRunLoopDoBlocks + 396 20 CoreFoundation 0x000000018be33e54 __CFRunLoopRun + 2356 21 CoreFoundation 0x000000018bf06234 _CFRunLoopRunSpecificWithOptions + 532 22 HIToolbox 0x0000000198c1f560 RunCurrentEventLoopInMode + 320 23 HIToolbox 0x0000000198c228bc ReceiveNextEventCommon + 488 24 HIToolbox 0x0000000198dac14c _BlockUntilNextEventMatchingListInMode + 48 25 AppKit 0x00000001909163d0 _DPSBlockUntilNextEventMatchingListInMode + 228 26 AppKit 0x000000019026a084 _DPSNextEvent + 576 27 AppKit 0x0000000190dff96c -[NSApplication(NSEventRouting) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 688 28 AppKit 0x0000000190dff678 -[NSApplication(NSEventRouting) nextEventMatchingMask:untilDate:inMode:dequeue:] + 72 29 AppKit 0x000000019025d13c -[NSApplication run] + 368 30 AppKit 0x00000001902357b0 NSApplicationMain + 880 31 AppKit 0x000000019047c958 +[NSWindow _savedFrameFromString:] + 0 32 UIKitMacHelper 0x00000001aa2651bc UINSApplicationMain + 972 33 UIKitCore 0x00000001c4e1aed4 UIApplicationMain + 144 34 UIKitCore 0x00000001c548bda0 block_destroy_helper.31 + 8880 35 DigitalConcertHall.debug.dylib 0x0000000106e41bd8 $sSo21UIApplicationDelegateP5UIKitE4mainyyFZ + 128 36 DigitalConcertHall.debug.dylib 0x0000000106e41b4c $s18DigitalConcertHall11AppDelegateC5$mainyyFZ + 32 37 DigitalConcertHall.debug.dylib 0x0000000106e4afc0 __debug_main_executable_dylib_entry_point + 28 38 dyld 0x000000018b9ac4e4 start + 6992 ) I could not test with the iOS 27 beta 4 SDK due to this blocking issue: https://developer.apple.com/forums/thread/839012 However, when I tried to set up a simple sample project, I could not reproduce the issue. Does anybody know what might be causing this? I filed feedback FB24201508

That is not exactly a development issue, but more a Mac configuration (which may hide other problems ?). I use a new MacBookAir with MacOS 26. When I Airdrop from another Mac (15.7.8) the MacBookAir does not show any icon but a blank area, whilst other devices show their icons: That seems an old issue with MacBookAir: https://www.reddit.com/r/macbookair/comments/1benu4o/blank_airdrop_icon/ Beside this, Airdrop works OK. Just as if the MacBookAir icon was missing in some system file ? Has anyone a solution ? I filed a bug report FB24034384

I was hoping with an OLED display that the new MBP might support true Adaptive Sync aka VRR. Alas, it only gets ProMotion, with the same huge gap between supported refresh rates at the top end (60hz and 120hz). Hooking up an HDMI VRR display such as any LG TV results in a display that works much better with variable framerates than the built-in display, since you can deliver frames at any interval between the min and max. VRR greatly improves games and already works great in macOS with an external display, so I humbly request that Apple consider another option next to ProMotion, for Adaptive Sync/VRR.

I’m developing GranaDash, a personal finance app for iPhone and Mac, and I’m looking especially for Brazilian Portuguese-speaking testers. The app helps organize household bills, everyday expenses and money lent to others, with syncing between devices. Its planned App Store category is Finance. I’d appreciate feedback on usability and cross-device updates: are the bill and payment flows clear, and do changes sync correctly between iPhone and Mac? Please report bugs and confusing steps through TestFlight. This is a 0.x beta. Join here: GranaDash on TestFlight

I'm positioning a tooltip-style panel relative to the mouse pointer and need to avoid overlapping the pointer glyph itself. This works fine at the default pointer size, but breaks once the user sets System Settings → Accessibility → Pointer → Pointer size to something larger than Normal — the pointer is visibly bigger on screen, but my offset doesn't grow to match, so the tooltip overlaps it. The only cursor-size-related value I've found any API expose is the ratio behind that same setting, read via: /usr/bin/defaults read com.apple.universalaccess mouseDriverCursorSizeThis returns a scale factor (1.0 = Normal, larger toward Large), not a size in points. I'm using it to scale a fixed offset, but that only approximates the real on-screen footprint of the pointer glyph — it doesn't tell me the glyph's actual rendered bounding box, so the tooltip still clips the pointer at larger sizes. Question: Is there a supported API — AppKit, Accessibility, or otherwise — that returns the system pointer's actual rendered size (bounding box, in points) reflecting the user's Pointer size setting? Or is there a different recommended approach for positioning UI relative to the live pointer without overlapping it, that doesn't depend on knowing that size directly? Minimal repro (AppKit, Swift Package Manager, no storyboard/xib — ~150 lines): enum CursorPrefs { static func readPointerScale() -> Double { let process = Process() process.executableURL = URL(fileURLWithPath: "/usr/bin/defaults") process.arguments = ["read", "com.apple.universalaccess", "mouseDriverCursorSize"] let outputPipe = Pipe() process.standardOutput = outputPipe process.standardError = Pipe() try? process.run() process.waitUntilExit() let data = outputPipe.fileHandleForReading.readDataToEndOfFile() let output = String(data: data, encoding: .utf8)?.trimmingCharacters(in: .whitespacesAndNewlines) ?? "" guard let scale = Double(output), scale >= 1.0 else { return 1.0 } return scale } } // A tracking-area view shows a tooltip-style NSPanel near NSEvent.mouseLocation, // offset by a fixed amount scaled by the value above. At Pointer size = Large, // the tooltip still overlaps the (visibly bigger) pointer glyph, because the // value is a ratio, not the glyph's rendered size in points.Steps to reproduce: Run the demo app (swift run, or open Package.swift in Xcode and Run). Open System Settings → Accessibility → Pointer → Pointer size and set it to Large. Quit and relaunch the demo (it reads the setting once at launch). Move the mouse over the gray box in the window. The floating tooltip tracks the pointer but still overlaps the now-larger pointer glyph. Environment: macOS 14.7.8 (23H730, Xcode 16.2 (16C5032a), Swift 5.9, arm64 (Apple Silicon). Happy to attach the full repro project as a zip if useful — it's a single main.swift plus an SPM manifest, no external dependencies.

Title: Supported launch code requirement with direct posix_spawn and exclusive child reaping on macOS I'm designing a security-sensitive process-lifecycle controller on Apple silicon macOS. The controller directly launches a signed foreground executable and must satisfy two requirements: Before any child executable code runs, macOS must enforce a launcher-supplied requirement binding the child to approved code, preferably using LaunchCodeRequirement and CodeDirectoryHash. The original parent must retain exclusive ownership of the child's terminal status through waitpid(), with signalling and reaping serialised by one designated execution context. I understand that Foundation Process.launchRequirement supports launch-time executable constraints, whereas the established lifecycle currently uses direct posix_spawn(). Could Apple DTS clarify: 1. Is there a supported public API for supplying an equivalent launcher-owned code requirement through direct posix_spawn() or its attributes? 2. If Foundation Process is the supported route, can its caller exclusively consume the direct child's terminal status with waitpid() without competing automatic reaping or status consumption by Foundation? Or must callers use Foundation's own termination reporting? 3. If those requirements cannot be combined through one supported interface, is there a recommended public API or launch topology providing both pre-execution code-requirement enforcement and an attributable terminal-status oracle? I'm seeking supported contractual behaviour, not private implementation details. This question concerns executable identity and child lifecycle ownership only. It does not assume that process termination establishes containment of descendants, delegated work or pending external operations. Thank you.

Password prompt are not working with PSSO enabled in MAC OS 27 while the same working in MAC OS 26. Issue is observed after updating to OS 27. Is there a known issue reported with OS version 27 and any fix expected in upcoming versions.

On macOS 26.5.2 (build 25F84), which documented API and return conditions, if any, establish that a regular file on APFS has no extended access control list (ACL), using an already-open file descriptor? We tested three disposable regular files on an APFS volume reporting ACL support. For each file, we opened a read-only file descriptor and called: acl_get_fd_np(fd, ACL_TYPE_EXTENDED) fgetattrlist() requesting ATTR_CMN_RETURNED_ATTRS | ATTR_CMN_EXTENDED_SECURITY Before and after inspection, fstat() confirmed stable device, inode, mode, and change timestamp. Observed results: 1. Newly created file, no ACL explicitly assigned acl_get_fd_np() returned NULL with errno == ENOENT. fgetattrlist() succeeded but omitted ATTR_CMN_EXTENDED_SECURITY from the returned attribute mask. FSOPT_PACK_INVAL_ATTRS also left that bit clear. 2. File with an explicitly assigned empty ACL acl_get_fd_np() returned NULL with errno == ENOENT. fgetattrlist() returned the extended-security attribute with an ACL entry count of zero. 3. File with one explicit ACL entry acl_get_fd_np() returned a non-null ACL. fgetattrlist() returned the extended-security attribute with an ACL entry count of one. Apple's published XNU attribute-packing implementation appears to use the same omission branch when ACL metadata is unsupported or when the ACL pointer is null. My question: Is there a supported descriptor-based API sequence that reliably distinguishes: Genuine absence of an extended ACL Unavailable or unsupported per-file ACL metadata An ACL retrieval failure If so, which API, capability checks, return values, attribute bits, or error conditions should a caller rely on? Are there relevant APFS or macOS version limitations? If the public API cannot establish ACL absence unambiguously in this situation, confirmation of that limitation would also be helpful. Thank you for your guidance.

On macOS I am creating a public/private key pair (ECDSA 256), will be secure enclave in the long run, just trying to baseline some functionality right now using file store (currently running in a system daemon). I can sign data using the private key with no problem, and export the public key. However, after generating a cert chain via CSR externally, I’m trying to figure out the proper incantation to import that cert/chain and have it recognized as matching the existing private key, but so far I can’t figure out the correct attributes to get it to pair up. Do you have any sample code that might have the right SecAddItem (or such) calls that would make this work as expected?

On macOS 27.x (Apple silicon) I've been measuring how launchd stops a job, and two behaviors don't match the documentation. Method: a throwaway job whose script traps SIGTERM and logs it, bootstrapped with different ExitTimeOut values, then stopped with launchctl bootout while timing when the process dies. Observed (LaunchAgent in the gui domain; the same results in the system domain with a LaunchDaemon): ExitTimeOut 45 -> `launchctl print` reports 45; SIGTERM, then SIGKILL at 45 s ExitTimeOut 61 -> reports 60; SIGTERM, then SIGKILL at 60 s ExitTimeOut 90 -> reports 60; SIGTERM, then SIGKILL at 60 s ExitTimeOut 120 -> reports 60; SIGTERM, then SIGKILL at 60 s ExitTimeOut 0 -> reports 0; SIGKILL after ~0.1 s, SIGTERM never deliveredman launchd.plist says of ExitTimeOut: "The amount of time launchd waits between sending the SIGTERM signal and before sending a SIGKILL signal when the job is to be stopped. The default value is system-defined. The value zero is interpreted as infinity and should not be used, as it can stall system shutdown forever." So: is there a 60-second ceiling on ExitTimeOut? It isn't documented that I can find, and it applies in both domains. And is zero meant to be "infinity" as documented, or an immediate SIGKILL as observed? Finally, is there a supported way for a service to be given more than 60 seconds to exit when launchd stops it — or is 60 seconds simply the maximum? Happy to file a Feedback with a minimal repro if that's useful.

On macOS 27 the File Provider extension of our app (Secure ShellFish, an SSH client) can't connect to any host on the local network, while the containing app connects to the same host on the same Mac without problems. Local Network is enabled for the app in System Settings, but every connection from the extension fails with "Local network prohibited". It did not happen on macOS 26 and still happens on macOS 27.2 (26B123). This is hitting end users of Secure ShellFish, not just my test setup, and it has been my number one support issue since macOS 27 was released. I filed this as FB24999927 with a sysdiagnose. I'm posting here to find out whether others with File Provider (or other) extensions see the same, and whether there is anything on our side that should make it work. Steps Install the app on a clean macOS 27 system and launch it. Choose Allow at the Local Network prompt. Add an SSH server on the local network (another Mac in my test) and open a terminal to it. This works. Open the same server in Finder (the File Provider domain under ~/Library/CloudStorage). The directory listing fails. What happens TN3179 says "In general, app extensions share the Local Network privilege state of their container app", so I expected the listing to load. Instead every connection from the extension to the LAN host is blocked, and the error depends on the networking API: CFStream: ENETDOWN (50) "Network is down" BSD socket connect(): EHOSTUNREACH (65) "No route to host" Network.framework (NWConnection, multipath TCP): waits with path unsatisfied (Local network prohibited) until our connect timeout, ETIMEDOUT (60) No Local Network prompt appears. Toggling the permission, rebooting, killing the extension process and reinstalling the app don't help. What I ruled out A stale extension process: freshly launched extension processes are blocked on their very first connection. A missing UUID cache: after installing a new build, nehelper populates the cache for the app with 14 UUIDs, including both slices of the extension's executable. The extension was blocked 23 seconds later. Shared executable UUIDs: the app and the extension have distinct Mach-O UUIDs. The sandbox: the extension has com.apple.security.network.client. A missing usage string: adding NSLocalNetworkUsageDescription to the extension's Info.plist changed nothing, with no prompt and no separate entry in System Settings. Networking in general: the extension reaches internet hosts and the Mac itself by its local name. Only other hosts on the local network are blocked. Log The blocked notification arrives with bundle_id: (null). UserEventAgent then maps the extension to the app by its UUID, nehelper answers that local network is allowed by preference, and the handler is called with the newly allowed state. Later connections from the same process are still blocked, so that state never takes effect for the extension. 09:19:37.575 UserEventAgent Got local network blocked notification: pid: 4297, uuid: 183484C2-8052-36AD-A81E-B02F15F875B3, bundle_id: (null) 09:19:37.575 UserEventAgent LocalNetwork: found bundle id com.appliedphasor.secure-shellfish.mac-provider by PID 09:19:37.575 ShellFish-Finder [C1.1.1 IPv6#dace0833.22 failed path (unsatisfied (Local network prohibited), interface: en0[802.11], ipv4, ipv6, uses wifi)] 09:19:37.576 UserEventAgent LocalNetwork: found bundle id com.appliedphasor.secure-shellfish by UUID 183484C2-8052-36AD-A81E-B02F15F875B3 09:19:37.597 nehelper UUID cache hit for com.appliedphasor.secure-shellfish 09:19:37.597 nehelper Local network allowed by preference for ShellFish (com.appliedphasor.secure-shellfish) 09:19:37.597 UserEventAgent App got response: 1 09:19:37.597 UserEventAgent Calling handler with newly allowed state: 1 09:19:44.795 fileproviderd populate-directory error: FP -1004 "Unable to list p5.local: Unable To Connect To P5.Local: Network Is Down."Questions Is this a known change in macOS 27? FB24035385 (helper and child processes no longer inherit Local Network access on macOS 27) sounds related, and other File Provider apps report the same, for example nextcloud/desktop#10885: https://github.com/nextcloud/desktop/issues/10885 Does an extension need anything on macOS 27 to share its container's Local Network privilege, such as an entitlement, an Info.plist key, or something the app must do first? If not, is there a supported workaround? The only one we see is to relay the extension's traffic through the main app over loopback, which only works while the app is running. For these users Finder integration is completely broken, because servers on the local network (Raspberry Pi, NAS, home servers) are the most common setup among them. Any pointers are much appreciated.

Our (sandboxed, distributed through the Mac App Store) app can optionally run as a CLI tool, to allow users to use it in scripts and other automation contexts. One of the usecases involves being a wrapper for the ssh command, but the ssh binary is not able to enable raw mode for stdin due to a sandbox violation (bug report). As a reduced example, I've created https://github.com/mihaip/sandboxed-cli-test, which has a minimal C program that uses tcsetattr to set attributes on stdin. That fails, and sandboxd logs to the console Sandbox: SandboxedCLI(30110) deny(1) file-ioctl /dev/ttys012. If I disable sandboxing on the binary then it works as expected. Looking through the sandbox profiles on /System/Library/Sandbox/Profiles, I'm not seeing cases where file-ioctl is enabled on /dev/tty. Are we out of luck, or is there a workaround?