macOS is the operating system for Mac.

Posts under macOS tag

200 Posts

Post

Replies

Boosts

Views

Activity

Separate CGBitmapContexts drawn concurrently produce wrong pixels when another thread fills translucent shapes (FB25211753)
Hi, my first post :-) feel free to say hi! I’ve filed this as FB25211753 and am posting in case others hit it. When several threads each draw into their own CGBitmapContext (separate buffers, separate contexts), one context’s output is corrupted if another thread is filling translucent shapes at the same time. QA1238 says drawing to separate Quartz objects on separate threads is supported. With only identical renders running concurrently, 0 of 64 differ from a serial reference. With another thread filling translucent ellipses into an unrelated context, 32 of 32 differ. On macOS 27.0.1, each corrupted render has about 0.3–4.6% of its bytes wrong, by up to 219 of 255 levels. On 26.5.1 it was smaller: 0.2–0.5%, up to 55. It’s triggered by translucent ellipses or paths. Opaque fills and translucent rectangles don’t trigger it, and per-thread colour spaces don’t help. Thread Sanitizer reports no race in the test code. Configuration: MacBook Pro (M4 Pro), macOS 26.5.1 and 27.0.1, Xcode 26.4 / Swift 6.3. Minimal reproduction (Core Graphics only). Run with swiftc -O repro.swift -o repro && ./repro: // Separate CGBitmapContexts drawn on separate threads give wrong pixels while another thread fills translucent // shapes. Seen on macOS 26.5.1 and 27.0.1 (Apple M4 Pro). Core Graphics only. // Run: swiftc -O repro.swift -o repro && ./repro // Minimal repro: separate CGBitmapContexts on separate threads, Core Graphics only. import CoreGraphics import Foundation let sRGB = CGColorSpace(name: CGColorSpace.sRGB)! /// A fixed drawing: black, a few large translucent ellipses and a stroked circle. func victim() -> [UInt8] { let w = 600, h = 400 let ctx = CGContext(data: nil, width: w, height: h, bitsPerComponent: 8, bytesPerRow: w * 4, space: sRGB, bitmapInfo: CGImageAlphaInfo.premultipliedLast.rawValue)! ctx.setFillColor(CGColor(srgbRed: 0, green: 0, blue: 0, alpha: 1)) ctx.fill(CGRect(x: 0, y: 0, width: w, height: h)) for i in 0..<6 { ctx.setFillColor(CGColor(srgbRed: 1, green: Double(i) / 6, blue: 0.3, alpha: 0.5)) ctx.fillEllipse(in: CGRect(x: 40 + i * 80, y: 100, width: 120, height: 120)) } ctx.setStrokeColor(CGColor(srgbRed: 1, green: 1, blue: 1, alpha: 0.3)) ctx.strokeEllipse(in: CGRect(x: 100, y: 50, width: 400, height: 300)) let p = ctx.data!.assumingMemoryBound(to: UInt8.self) return Array(UnsafeBufferPointer(start: p, count: w * h * 4)) // read the context's own memory: no image decoding } /// Unrelated work on another context: many tiny translucent ellipses. func aggressor() { let ctx = CGContext(data: nil, width: 800, height: 500, bitsPerComponent: 8, bytesPerRow: 0, space: sRGB, bitmapInfo: CGImageAlphaInfo.premultipliedLast.rawValue)! for k in 0..<1600 { ctx.setFillColor(CGColor(srgbRed: 1, green: 1, blue: 1, alpha: Double(k % 7) / 7)) ctx.fillEllipse(in: CGRect(x: k % 800, y: k % 500, width: 1, height: 1)) } } let reference = victim() for mode in ["victims only", "victims + aggressors"] { let lock = NSLock() nonisolated(unsafe) var bad = 0, compared = 0 DispatchQueue.concurrentPerform(iterations: 64) { i in if mode != "victims only", i % 2 == 1 { aggressor(); return } let same = victim() == reference lock.lock(); compared += 1; if !same { bad += 1 }; lock.unlock() } print("\(mode): \(bad) of \(compared) renders differ from the serial reference") } Has anyone else seen this, or found a workaround other than drawing on a single thread?
3
0
753
42m
Ventura: NWConnection returns server error in waiting state instead of failed state
In our macOS SystemExtension, we are using Network.framework for creating web socket connection to our remote WSS server. We provide authentication token in cookies of the connection and websocket server validates it before upgrading the connection from HTTP to WebSocket. If the cookie is invalid, server returns 403 HTTP status code and closes the connection. When server returns 403, in Big Sur and Monterey, we get state update of failed(let error) where error is NWError.posix(.ECONNABORTED). However, in Ventura, we are getting state waiting(let error) where error is NWError.posix(.ECONNABORTED). As per documentation, waiting state should be received if there is any network error in establishing the connection and connection goes into waiting for network path change. But in this case, TCP connection to server is established, HTTP headers are received and validated by server and then get rejected. So shouldn't this result into connection failed instead of waiting? This behaviour has only changed on Ventura. On Big Sur and Monterey we still get failed with error.
4
0
1.4k
8h
macOS: Reliable custody of a sandboxed worker if its controller dies during spawn
Hello, I'm investigating the supported macOS mechanisms for supervising a single unprivileged, sandboxed worker process. The target environment is macOS 15.6 (24G84), Apple Silicon (arm64). The worker is intended to operate under a separate Standard user identity, with tightly restricted capabilities and no requirement to create child processes. The main challenge is the startup failure window: A controller initiates worker creation, but exits unexpectedly before spawn returns or before the worker's identity and authenticated handshake can be independently recorded. In this situation, we need a supported approach to prevent the worker from becoming an unaccounted-for process, or to recover sufficiently trustworthy custody to determine its lifecycle and cleanup state. I have reviewed direct child-process supervision, POSIX process groups, launchd job behaviour, sandbox inheritance, resource limits and process identification mechanisms. I would appreciate guidance on the following: Is there a public, supported macOS API or system service that provides recoverable process custody from initial worker creation, including controller failure during startup? Could an application-associated XPC service or launchd mechanism provide the required lifecycle relationship without granting the worker independent ongoing execution authority? Is generation-safe, audit-token-based process signaling available through a supported public interface, and what are its privilege and acquisition requirements? Is setting a hard RLIMIT_NPROC limit before worker operations a supported way to prevent further fork/spawn activity by an unprivileged worker? What limitations or exceptions should be considered? What can macOS guarantee about process termination and cleanup after controller failure, and what must remain application-level verification? I'm particularly interested in documented guarantees and supported APIs rather than behaviour observed only in tests or private interfaces. Any recommendations or references to Apple documentation would be greatly appreciated. Thank you.
5
0
145
8h
Supported receiver-confinement guarantee for anonymous XPC connections on macOS 27.0.1
I’m assessing whether the public C XPC APIs provide the recipient guarantee needed for a local security boundary. The proposed path uses a dedicated anonymous listener, a transferred xpc_endpoint_t, and xpc_connection_create_from_endpoint. Before releasing protected data, I need to establish which process occurrence can receive it and whether that binding continues to hold through delivery. Here, “process occurrence” means one running instance, including protection against confusing it with a later instance that reuses its PID. The target reports macOS 27.0.1 (26A434), Darwin 27.0.0, arm64, and xnu-13432.1.9~1/RELEASE_ARM64_T6000. The selected Command Line Tools SDK reports macOS 27.0, SDK build 26A425. These are read-only inventory results; I have not run an XPC prototype for this question. Is there a supported public API contract that lets the sending application, or a separately authorized local verifier, establish before protected data becomes accessible that this connection’s actual receiver is the authenticated process occurrence and remains confined to it for that send? I specifically need to understand whether that guarantee covers endpoint copying or forwarding, repeated or concurrent connections created from one endpoint, process replacement, queued messages, and replies or access-capable attachments. I am asking about the selected C connection API; I do not assume equivalent behavior across the C and Swift session APIs. If a supported mechanism exists, which APIs, OS versions, privileges or entitlements are required, and where is the guarantee documented? If the public API does not expose this guarantee, a clear statement of that limit would help me choose an appropriate transport boundary. The distinction I need to resolve is between authenticating a peer at one point and ensuring that protected outgoing data reaches only that same process occurrence. I am seeking the supported security contract, without requesting access to private implementation details.
3
0
94
9h
macOS application renaming
Hello, We are developing a macOS application with many different components that are required for our business features. We distribute the product outside the App Store and sign it with our Developer ID certificate. Rebranding an app is a rare case, but sometimes it happens. My question is: Does Apple have any guide or recommendations on how to rebrand an app properly, other than distributing a completely new product? I am asking because our application has a complex structure: UI app (MyApp1, bundle ID = com.myApp1.osx.app) Helper tool (MyApp1HelperTool, bundle ID = com.myApp1.osx.HelperTool) Privileged daemon (MyApp1Daemon, bundle ID = com.myApp1d) System Extension, Transparent Proxy (MyApp1Proxy, bundle ID = com.myApp1.osx.proxy) As you can see, the brand name is used not only in the bundle and product names, but also in the bundle IDs. At some point, I need to change the product name from MyApp1 to MyApp2. Ideally, I would also like to change the bundle IDs to match the new brand. After rebranding, end users should not see MyApp1 anywhere in the system, only MyApp2. Also, components that are already installed and approved (System Extension, proxy configuration, helper tool, etc.) should stay approved. We would like to avoid showing the approval prompts again to all our end users. I did some research and found that bundle IDs technically cannot be changed. To solve this, I would need to release a new app and implement an in-app update mechanism that updates MyApp1 to MyApp2. However, even with a new app and an in-app update mechanism, I did not find a way to avoid user prompts for approving the new extension, the proxy, and possibly the privileged helper tool. For macOS, these will be new components that require explicit user approval. MDM is not a solution for us: some of our customers use MDM, but many of them do not. We want the update to be as smooth as possible. Thank you!
2
0
61
12h
URL Filter fails on macOS 27.2 beta: privacy-proxy failure on PIR status request
On macOS 27.2 beta 1/2 our URL filter never starts: the session loops starting -> stopping. The same build works on macOS 27.0 (26A428). Both our TestFlight and notarized standalone builds fail. Prefilter and PIR registration succeed. The PIR status request then fails: NWPath is satisfied, the connection is configured proxy fail closed, proxy strict fail closed, the proxy fails (event: proxy:children_failed), and the error is NSURLErrorDomain -1009 / POSIX 50 "Network is down" with _NSURLErrorPrivacyProxyFailureKey=true. NEMembershipCheckerErrorDomain Code=3 -> NEAgentURLFilterErrorDomain Code=3; the app sees serverSetupIncomplete. The privacy-proxy allow-list entry is identical on macOS 27.0 and 27.2 beta (com.adguard). Disabling the VPN, rebooting, and recreating the URL filter configuration do not help. Log excerpt: neagent: updatePrefilterWithCompletionHandler - result 1 neagent: <NEPIRChecker> - Register with PIR Server (group <com.adguard.safari.AdGuard> ... PrivacyProxyFailOpen <0> ...) -> completed registration ciphermld: [C3 ...] proxy fail closed, proxy strict fail closed ciphermld: [C3.1.1 ... failed proxy (satisfied (Path is satisfied), interface: en0[802.11], ipv4, dns, uses wifi, flow divert agg: 2, LQM: good)] event: proxy:children_failed ciphermld: queryStatus: NSURLErrorDomain -1009 / POSIX 50 "Network is down", _NSURLErrorPrivacyProxyFailureKey=true, NWPath=satisfied neagent: Failed to startFilter <Error Domain=NEMembershipCheckerErrorDomain Code=3 "(null)"> nesessionmanager: NEURLFilterPlugin(com.adguard.safari.AdGuard[url-filter][inactive]): setStatus:error: - err Error Domain=NEAgentURLFilterErrorDomain Code=3 Filed as FB24933164.
6
2
514
13h
Immersive Translate macOS 1.34.2: expedited review confirmed, still Waiting for Review
Hello App Review team, We would appreciate help checking a critical bug-fix update for our existing macOS app, Immersive Translate. App ID: 6447957425 Developer: Funstory.ai limited Platform: macOS Version / build: 1.34.2 (590) Submitted: October 18, 2026, at 14:55 China Standard Time (UTC+8) Current status: Waiting for Review Developer Support case: 103001150548 The currently published macOS version, 1.34.1, has a confirmed Safari extension initialization bug. Affected users cannot translate webpages, and the floating translation button disappears. Multiple users have reported this issue. Version 1.34.2 contains the fix. We requested expedited review, and Apple’s confirmation page stated: We’ll expedite review for Immersive Translate. However, at our latest check, the submission remained in “Waiting for Review,” more than 40 hours after submission. We have also contacted Developer Support under case 103001150548, but have only received an automatic acknowledgement so far. Could you please help: Verify that the expedited review request is correctly associated with macOS version 1.34.2, build 590. Check whether the submission is progressing normally or requires any additional information or action from us. Follow up on case 103001150548 with the appropriate team and advise on the next steps. Public user reports and our fix announcement: https://github.com/immersive-translate/immersive-translate/issues/4102 This update restores core functionality for affected existing users. We would appreciate your help making the fix available as soon as possible. Thank you.
1
0
107
19h
macOS test case - Could not launch app
Hi, Overview I am using Xcode Cloud for my multi platform app. The macOS test case fails, however the iOS test case runs and succeeds. I don't have any UI test cases written, the test case are simple and have nothing platform (macOS) specific. Questions What can I do to fix this? Is there any user privileges needed to launch the macOS app for testing? I ask because when I ran the UI tests locally it launched the app and asked for my macOS user password. Just wondering if that is the reason it didn't launch in Xcode Cloud. Error: <Appname> encountered an error (Failed to install or launch the test runner. If you believe this error represents a bug, please attach the result bundle at /Volumes/workspace/resultbundle.xcresult.(Underlying Error: Could not launch "AppnameTests. The LaunchServices launcher has returned an error. Please check the system logs for the underlying cause of the error. (Underlying Error: The operation couldn't be completed. Launch failed. (Underlying Error: Launch job spawn failed) ))) × Could not launch "<Appname>" × Could not launch "AppnameTests" × AppnameUITests.testExample() Failed to get launch progress for <XCUIApplicationImpl: 0x600000564630 <BundleID> at /Volumes/workspace/TestProducts/Debug-Dev/<Appname>.app>: Could not launch "app name". The LaunchServices launcher has returned an error. Please check the system logs for the underlying cause of the error. (Underlying Error: The operation couldn't be completed. Launch failed. (Underlying Error: Launch job spawn failed)) AppnameUITests.swift:28 * AppnameUITests.testLaunchPerformance) Failed to get launch progress for «XCUIApplicationimpl: 0x60000054630 <BundleID> at /Volumes/workspace/TestProducts/Debug-Dev/<Appname>.apps: Could not launch "<Appname>". The LaunchServices launcher has returned an error. Please check the system logs for the underlying cause of the error. (Underlying Error: The operation couldn't be completed. Launch failed. (Underlying Error: Launch job spawn failed)) AppnameUITests.swift:37 g * AppnameUITestsLaunchTests.testLaunch) Failed to get launch progress for «XCUIApplicationimpl: 0x60000054630 <BundleID> at /Volumes/workspace/Testroducts/Debug-Dev/<Appname>.apps: Could not launch "<Appname>". The LaunchServices launcher has returned an error. Please check the system logs for the underlying cause of the error. (Underlying Error: The operation couldn't be completed. Launch failed.
6
0
3.4k
1d
macOS app-specific container: documented initial creation behavior and storage restrictions
I am considering a dedicated macOS .app and am looking for public Apple documentation about the initial creation of its app-specific container by the operating system. The priority is to protect existing application data and settings. Running the proposed app and allowing application-managed storage remain on hold. This question concerns an individual app’s container, rather than an App Group shared container. The target macOS version, bundle identifier, signing configuration, and entitlements are not specified here. Please identify any conditions on which an answer depends. My primary question is: Is there public Apple documentation that identifies what the OS creates during initial container creation, which items are mandatory or conditional, and what triggers their creation? Where documented, I would like to understand their locations, contents, size bounds, and lifetime. For a later assessment, I also need to understand: How the container and its initial contents are associated with a particular .app, including any relevant signing or identity requirements. Whether a public, supported mechanism can permit OS-managed initial container creation while separately preventing subsequent application-managed writes inside that container. Please distinguish OS-managed initial creation from writes performed by application code or frameworks used by the application. Please also identify whether the behavior depends on App Sandbox, entitlements, or the macOS version. Links to documentation describing the supported guarantees and their limits would be especially helpful. If some details are implementation-dependent or undocumented, please distinguish those from documented guarantees. Thank you.
3
0
116
1d
Permanently disconnect/disable build-in display on iMac with M1
Hello, does anyone know how to permanently disable the built‑in display in macOS 15 on iMac M1 programmatically or via the terminal? I’m facing a problem — the display cable is broken. As a result, not only does it work poorly, but there’s also severe overheating in the upper right part of the iMac. The warranty has expired, and I don’t have the funds to replace the display right now. So I’m looking for ways to disable the built‑in screen and work only with an external display. At the moment, I’ve found a way to disable the display after logging in, but before logging in, the screen gets hot, and in this mode I won’t be able to upgrade to the new operating system. The process is lengthy, and the screen will become significantly hot. Ideally, the built‑in display should be disabled during reboot and when upgrading to a new version of macOS, and an external display should be used as the main display.
0
0
43
2d
Diagnosing pre-main latency in a short-lived macOS child process while preserving its parent
I’m looking for a supported way to investigate startup latency before main() in a short-lived native macOS child process, while preserving its original parent-child relationship. Environment macOS 26.6.2, build 25G83. Native arm64 executables. The on-disk /usr/lib/dyld contains the identifier dyld-1387; this is a static observation, not independent verification of all runtime shared-cache components. The diagnostic runs were started manually from normal macOS Terminal. All inputs and target processes are synthetic test fixtures. Execution structure Test supervisor → Watchdog → Observer → Query Observer launches Query using posix_spawn(). Query checks a synthetic target process’s identity using Security.framework and produces a fixed 28-byte result. Observer passes an explicit environment containing only LANG=C and LC_ALL=C. Consequently, exporting DYLD variables in the outer Terminal would not pass them to Query. Our existing test has a 1000 ms Query deadline and requires empty Query stderr. This is an application-defined acceptance requirement, not a claimed macOS timing guarantee. Observed results A historical full regression run timed out at approximately 1001 ms, with no Query result bytes received. That run did not have main-entry instrumentation, so we cannot determine where its time was spent. A later isolated, instrumented run measured: posix_spawn return to Query main entry: 832.687 ms main entry to return: 24.179 ms Observer-measured Query elapsed time: 864 ms Another isolated, instrumented run measured: posix_spawn call duration: 0.179 ms spawn return to main entry: 634.334 ms main entry to return: 6.757 ms Observer-measured Query elapsed time: 647 ms In the third run, getrusage(RUSAGE_SELF) at main entry reported cumulative CPU time of 3.014 ms user and 2.583 ms system. Before main returned, the cumulative total was 8.088 ms. Timeline measurements used CLOCK_MONOTONIC. Interpretation limits These successful diagnostic runs do not explain or resolve the historical timeout. Instrumentation changes the executable, and cache state and scheduling may differ. The CPU and wall-clock measurements cover different intervals. Subtracting them would not give an exact waiting-time measurement. We cannot currently attribute the delay to dyld, scheduling, security checks, IPC, or I/O. Diagnostic constraints We want to preserve the original parent-child relationship and avoid system-wide collection, disabling security protections, or silently changing permissions. We have not established that the Instruments App Launch configuration available to us can capture this child’s earliest startup phases while restricting collection to Query. The historical DYLD_PRINT_STATISTICS options are not documented in the installed dyld manual. Attaching a sampling tool after obtaining the PID may miss the relevant startup interval and may perturb this short-lived process. Questions What supported tool or API on this macOS version can distinguish startup phases before main() for this posix_spawn-created child? Can collection itself be restricted to Query, rather than collecting system-wide data and filtering the report afterward? What permissions are required, which early phases remain unobservable, and how much observer perturbation should we expect? If these constraints cannot all be met, what is the smallest necessary change to the diagnostic setup? What minimal sample project and evidence would be most useful for further investigation? I have preserved the original failure and subsequent diagnostic evidence, but do not yet have a standalone Xcode sample that reliably reproduces the historical timeout. I’m requesting guidance on an appropriate measurement method, not asserting that this is a confirmed macOS defect.
4
0
98
5d
MacBook Pro apps open unexpectedly after closing lid
This occurred after I had closed all apps before closing the lid. I received answer to this on apple regular support but was told that my post had been removed from the regular support service and the question had been moved here because it involved beta software. I do not recall agreeing to be a part of any beta software participation. I have been having issues with my computer doing weird things which I had communicated to the regular support group (icons for apps popping up on the desktop.... and some were banking related - not necessarily the app icon itself, but one of the files that if clicked would open the banking app) . Does anyone know what is going on and where this problem is coming from. What is going on? I do test software for 1 developer, but that developer has nothing to do with what is happening,.
1
0
49
6d
macOS XPC: Can incoming message size be bounded before payload allocation?
Hello, I'm designing a local macOS helper service (minimum deployment target: macOS 13) that performs one fixed syntax-validation operation. The submitted source is never executed. The security contract requires: A maximum incoming transport request size of 327,680 bytes. Immediate rejection when the 327,681st byte is encountered, without an allocation proportional to an unbounded sender-controlled payload. No application-level response for an oversized transport request, followed by termination of the affected connection. Complete application responses limited to 65,536 bytes, without treating truncated output as successful. I've reviewed the public XPC APIs, including xpc_data_get_length, xpc_connection_cancel, and xpc_connection_set_peer_code_signing_requirement. The remaining uncertainty is whether XPC can enforce a receiver-side message-size limit before materializing the incoming payload. My questions are: Does any public XPC API on macOS 13+ provide a documented maximum incoming message size that is enforced before payload materialization or proportional allocation? If not, is the entire incoming XPC message necessarily materialized before the application event handler receives it? Is there a supported XPC design for guaranteeing bounded receiver memory with untrusted input, or should this requirement use a different local transport, such as an AF_UNIX SOCK_STREAM socket? What guarantees does xpc_connection_cancel provide regarding connection termination, pending messages, and prevention of connection reuse after detecting malformed or oversized input? I'm specifically looking for documented platform guarantees rather than behavior that happens to work in testing. Thank you!
4
0
218
6d
Supported libSystem state after a LaunchDaemon permanently drops privileges
I am testing a fixed signed LaunchDaemon startup program that uses setgroups, setgid and setuid to establish a dedicated non-root identity before loading its service library or creating an application XPC listener. This follows the single-process, deferred-library direction discussed in DTS thread 844906. The remaining question is the supported treatment of system-runtime state initialized before the credential transition. Test environment: Apple silicon, macOS 27.0.1 / Darwin 27.0.0, hardened runtime, no special entitlements. The host links only libSystem and has no application constructors. This is a temporary diagnostic, not an installed product or a file-operation service. Our test verifies real, effective and saved UID/GID, the exact supplementary group vector and failed attempts to regain root. After the transition, a read-only own-task Mach inventory still sees a voucher even though successful task/current-thread voucher getters return null. It also sees one send+receive endpoint without an alias to any of the queried special/registered roles. Ordinary hardened launchd controls in both the login GUI and user domains also have a voucher and such an endpoint. Their recorded endpoint attributes match the post-drop test: empty queue, sequence 1, make-send count 1, send rights present, no send-once rights, port sets or notification requests. We do not treat this as proof that the objects or authority are equivalent. No messages are sent to the unidentified endpoint and no runtime-owned rights are destroyed. In a separate ordinary-user test, public voucher recipe extraction reports only a BANK attribute. Published libdispatch source describes a default task-bank voucher stored separately from the current thread's voucher slot. Published XNU source captures identity when bank context is initialized. We have not established the corresponding lifecycle or authority implications on this OS release, and do not claim that the observed voucher retains root authority. For this startup arrangement, what supported public contract should an application use to establish that libSystem's retained runtime context does not preserve usable pre-drop administrator authority before loading service code? Is there a supported sanitization step, or a specific documented OS trust assumption under which leaving that state intact is intended? If the combination of exact group reduction, deferred service loading and launchd Mach-service check-in cannot support that boundary, which public architecture should we use instead? We are seeking a documented arrangement or a clear limit on the guarantee, rather than a private reset API or an explanation of every internal endpoint. We have not used same-PID exec, a root supervisor, private APIs, or a broad port-type allowlist. Relevant documentation or a minimal public sample would help.
1
0
227
6d
Can a sandboxed Mac App Store app schedule power-on from shutdown and automatic shutdown?
Hello, I am developing a native macOS utility using SwiftUI and AppKit, and I am investigating whether its power scheduling features can be implemented in a sandboxed app distributed through the Mac App Store. The intended functionality is: Schedule power-on from a fully shut-down state, not just wake from sleep. Schedule wake from sleep and shutdown. Let the user select weekdays and times, and modify or cancel the schedule. Keep the schedule effective after the user quits the app. For example, the user could explicitly configure power-on at 08:00 and shutdown at 22:00, Monday through Friday. My local prototype uses pmset with administrator authorization. For a possible Mac App Store version, I am looking for a supported implementation that does not execute privileged shell commands or run an application helper as root. What I have checked The documentation for IOPMSchedulePowerEvent states that it must be called as root. Calling that API directly therefore does not appear to remove the privilege requirement. App Review Guideline 2.4.5 requires sandboxing and prohibits requesting escalation to root privileges. I also reviewed launchd scheduling and user-supplied scripts through NSUserAppleScriptTask, but neither appears to provide a self-contained solution for scheduling power-on from shutdown without privileged operations. Questions Is there a public API or system-mediated authorization mechanism that supports this functionality from a sandboxed third-party app? Is there a requestable entitlement specifically applicable to power-event scheduling? If the complete feature set is unsupported, which operations are available within App Sandbox: power-on from shutdown, wake from sleep, and scheduled shutdown? The current deployment target is macOS 13 or later, on Apple silicon and Intel. If a supported solution requires a newer macOS version or specific hardware, that information would also be helpful. I am asking about supported API capabilities and architecture, rather than advance App Review approval. A documentation reference—or confirmation that scheduled power-on from shutdown is unavailable under these constraints—would help me choose the appropriate distribution model. Thank you.
1
0
116
1w
Location Services stopped working across the system on macOS
MacBook Air (M4) Current build: macOS 27 Developer Beta (26A5368g) I have a system-wide Location Services failure affecting Apple Maps, Safari geolocation APIs, and any application requesting the current location. Symptoms: Apple Maps cannot determine current location. Safari and browser geolocation APIs fail. Websites report that location cannot be found. Location Services are enabled and permissions are granted. The issue has persisted across: macOS 26.5 beta macOS 26.6 beta macOS 26.6 beta 2 macOS 27 Developer Beta Troubleshooting already performed: Multiple Wi-Fi networks tested. iPhone hotspot tested. VPN enabled and disabled. Location Services reset. Permissions reset and reauthorized. New clean local user account created (no Apple ID, no third-party software). Issue reproduces identically in the clean account. Technical observations: locationd logs repeatedly show: knownCount = 0 AlsWifi = unknown while Wi-Fi scanning itself appears successful: queryMacAddresses.size = 57 The system sees dozens of nearby access points, but none appear to be recognized for Wi-Fi positioning. Additional findings: Wi-Fi hardware functions normally. Internet connectivity is normal. Bluetooth and Find My device presence work. GeoServices resources are present on disk. No successful location fix is ever produced. Has anyone seen similar CoreLocation / GeoServices behavior where Wi-Fi scans succeed but knownCount always remains 0 and no location fix is generated?
6
2
1.9k
1w
macOS 13+: Is LOCAL_PEERTOKEN a supported way to authenticate AF_UNIX peers?
Hello, I'm evaluating a local macOS helper service with a minimum deployment target of macOS 13. The service would communicate over an AF_UNIX SOCK_STREAM socket and must authenticate the signed code identity of the connecting process before accepting an operation. I'm investigating whether LOCAL_PEERTOKEN can provide a reliable audit token associated with the peer of an accepted socket. The public macOS SDK declares LOCAL_PEERTOKEN in sys/un.h, but I haven't found documentation establishing its precise security guarantees or availability across supported macOS versions. My questions are: Is LOCAL_PEERTOKEN a public, supported API on macOS 13 and later? Can it be used with getsockopt() on a file descriptor returned by accept() to retrieve an audit_token_t for the connected peer? At what point is the peer identity captured? Is the returned audit token securely bound to the original connecting process, even if that process exits and its PID is reused? Is the audit token obtained through LOCAL_PEERTOKEN officially supported as input to Security.framework APIs such as SecCodeCopyGuestWithAttributes (using kSecGuestAttributeAudit) or SecTaskCreateWithAuditToken? Does the identity remain trustworthy if the connected socket descriptor is inherited or passed to another process? Are there documented limitations concerning descriptor passing or time-of-check/time-of-use races? What is Apple's recommended public API sequence for verifying the signed code identity of an AF_UNIX peer on macOS 13+, including in an App Sandbox environment? I'm looking for documented security and availability guarantees rather than relying solely on observed behavior. Thank you!
1
0
80
1w
Separate CGBitmapContexts drawn concurrently produce wrong pixels when another thread fills translucent shapes (FB25211753)
Hi, my first post :-) feel free to say hi! I’ve filed this as FB25211753 and am posting in case others hit it. When several threads each draw into their own CGBitmapContext (separate buffers, separate contexts), one context’s output is corrupted if another thread is filling translucent shapes at the same time. QA1238 says drawing to separate Quartz objects on separate threads is supported. With only identical renders running concurrently, 0 of 64 differ from a serial reference. With another thread filling translucent ellipses into an unrelated context, 32 of 32 differ. On macOS 27.0.1, each corrupted render has about 0.3–4.6% of its bytes wrong, by up to 219 of 255 levels. On 26.5.1 it was smaller: 0.2–0.5%, up to 55. It’s triggered by translucent ellipses or paths. Opaque fills and translucent rectangles don’t trigger it, and per-thread colour spaces don’t help. Thread Sanitizer reports no race in the test code. Configuration: MacBook Pro (M4 Pro), macOS 26.5.1 and 27.0.1, Xcode 26.4 / Swift 6.3. Minimal reproduction (Core Graphics only). Run with swiftc -O repro.swift -o repro && ./repro: // Separate CGBitmapContexts drawn on separate threads give wrong pixels while another thread fills translucent // shapes. Seen on macOS 26.5.1 and 27.0.1 (Apple M4 Pro). Core Graphics only. // Run: swiftc -O repro.swift -o repro && ./repro // Minimal repro: separate CGBitmapContexts on separate threads, Core Graphics only. import CoreGraphics import Foundation let sRGB = CGColorSpace(name: CGColorSpace.sRGB)! /// A fixed drawing: black, a few large translucent ellipses and a stroked circle. func victim() -> [UInt8] { let w = 600, h = 400 let ctx = CGContext(data: nil, width: w, height: h, bitsPerComponent: 8, bytesPerRow: w * 4, space: sRGB, bitmapInfo: CGImageAlphaInfo.premultipliedLast.rawValue)! ctx.setFillColor(CGColor(srgbRed: 0, green: 0, blue: 0, alpha: 1)) ctx.fill(CGRect(x: 0, y: 0, width: w, height: h)) for i in 0..<6 { ctx.setFillColor(CGColor(srgbRed: 1, green: Double(i) / 6, blue: 0.3, alpha: 0.5)) ctx.fillEllipse(in: CGRect(x: 40 + i * 80, y: 100, width: 120, height: 120)) } ctx.setStrokeColor(CGColor(srgbRed: 1, green: 1, blue: 1, alpha: 0.3)) ctx.strokeEllipse(in: CGRect(x: 100, y: 50, width: 400, height: 300)) let p = ctx.data!.assumingMemoryBound(to: UInt8.self) return Array(UnsafeBufferPointer(start: p, count: w * h * 4)) // read the context's own memory: no image decoding } /// Unrelated work on another context: many tiny translucent ellipses. func aggressor() { let ctx = CGContext(data: nil, width: 800, height: 500, bitsPerComponent: 8, bytesPerRow: 0, space: sRGB, bitmapInfo: CGImageAlphaInfo.premultipliedLast.rawValue)! for k in 0..<1600 { ctx.setFillColor(CGColor(srgbRed: 1, green: 1, blue: 1, alpha: Double(k % 7) / 7)) ctx.fillEllipse(in: CGRect(x: k % 800, y: k % 500, width: 1, height: 1)) } } let reference = victim() for mode in ["victims only", "victims + aggressors"] { let lock = NSLock() nonisolated(unsafe) var bad = 0, compared = 0 DispatchQueue.concurrentPerform(iterations: 64) { i in if mode != "victims only", i % 2 == 1 { aggressor(); return } let same = victim() == reference lock.lock(); compared += 1; if !same { bad += 1 }; lock.unlock() } print("\(mode): \(bad) of \(compared) renders differ from the serial reference") } Has anyone else seen this, or found a workaround other than drawing on a single thread?
Replies
3
Boosts
0
Views
753
Activity
42m
Ventura: NWConnection returns server error in waiting state instead of failed state
In our macOS SystemExtension, we are using Network.framework for creating web socket connection to our remote WSS server. We provide authentication token in cookies of the connection and websocket server validates it before upgrading the connection from HTTP to WebSocket. If the cookie is invalid, server returns 403 HTTP status code and closes the connection. When server returns 403, in Big Sur and Monterey, we get state update of failed(let error) where error is NWError.posix(.ECONNABORTED). However, in Ventura, we are getting state waiting(let error) where error is NWError.posix(.ECONNABORTED). As per documentation, waiting state should be received if there is any network error in establishing the connection and connection goes into waiting for network path change. But in this case, TCP connection to server is established, HTTP headers are received and validated by server and then get rejected. So shouldn't this result into connection failed instead of waiting? This behaviour has only changed on Ventura. On Big Sur and Monterey we still get failed with error.
Replies
4
Boosts
0
Views
1.4k
Activity
8h
macOS: Reliable custody of a sandboxed worker if its controller dies during spawn
Hello, I'm investigating the supported macOS mechanisms for supervising a single unprivileged, sandboxed worker process. The target environment is macOS 15.6 (24G84), Apple Silicon (arm64). The worker is intended to operate under a separate Standard user identity, with tightly restricted capabilities and no requirement to create child processes. The main challenge is the startup failure window: A controller initiates worker creation, but exits unexpectedly before spawn returns or before the worker's identity and authenticated handshake can be independently recorded. In this situation, we need a supported approach to prevent the worker from becoming an unaccounted-for process, or to recover sufficiently trustworthy custody to determine its lifecycle and cleanup state. I have reviewed direct child-process supervision, POSIX process groups, launchd job behaviour, sandbox inheritance, resource limits and process identification mechanisms. I would appreciate guidance on the following: Is there a public, supported macOS API or system service that provides recoverable process custody from initial worker creation, including controller failure during startup? Could an application-associated XPC service or launchd mechanism provide the required lifecycle relationship without granting the worker independent ongoing execution authority? Is generation-safe, audit-token-based process signaling available through a supported public interface, and what are its privilege and acquisition requirements? Is setting a hard RLIMIT_NPROC limit before worker operations a supported way to prevent further fork/spawn activity by an unprivileged worker? What limitations or exceptions should be considered? What can macOS guarantee about process termination and cleanup after controller failure, and what must remain application-level verification? I'm particularly interested in documented guarantees and supported APIs rather than behaviour observed only in tests or private interfaces. Any recommendations or references to Apple documentation would be greatly appreciated. Thank you.
Replies
5
Boosts
0
Views
145
Activity
8h
Supported receiver-confinement guarantee for anonymous XPC connections on macOS 27.0.1
I’m assessing whether the public C XPC APIs provide the recipient guarantee needed for a local security boundary. The proposed path uses a dedicated anonymous listener, a transferred xpc_endpoint_t, and xpc_connection_create_from_endpoint. Before releasing protected data, I need to establish which process occurrence can receive it and whether that binding continues to hold through delivery. Here, “process occurrence” means one running instance, including protection against confusing it with a later instance that reuses its PID. The target reports macOS 27.0.1 (26A434), Darwin 27.0.0, arm64, and xnu-13432.1.9~1/RELEASE_ARM64_T6000. The selected Command Line Tools SDK reports macOS 27.0, SDK build 26A425. These are read-only inventory results; I have not run an XPC prototype for this question. Is there a supported public API contract that lets the sending application, or a separately authorized local verifier, establish before protected data becomes accessible that this connection’s actual receiver is the authenticated process occurrence and remains confined to it for that send? I specifically need to understand whether that guarantee covers endpoint copying or forwarding, repeated or concurrent connections created from one endpoint, process replacement, queued messages, and replies or access-capable attachments. I am asking about the selected C connection API; I do not assume equivalent behavior across the C and Swift session APIs. If a supported mechanism exists, which APIs, OS versions, privileges or entitlements are required, and where is the guarantee documented? If the public API does not expose this guarantee, a clear statement of that limit would help me choose an appropriate transport boundary. The distinction I need to resolve is between authenticating a peer at one point and ensuring that protected outgoing data reaches only that same process occurrence. I am seeking the supported security contract, without requesting access to private implementation details.
Replies
3
Boosts
0
Views
94
Activity
9h
macOS application renaming
Hello, We are developing a macOS application with many different components that are required for our business features. We distribute the product outside the App Store and sign it with our Developer ID certificate. Rebranding an app is a rare case, but sometimes it happens. My question is: Does Apple have any guide or recommendations on how to rebrand an app properly, other than distributing a completely new product? I am asking because our application has a complex structure: UI app (MyApp1, bundle ID = com.myApp1.osx.app) Helper tool (MyApp1HelperTool, bundle ID = com.myApp1.osx.HelperTool) Privileged daemon (MyApp1Daemon, bundle ID = com.myApp1d) System Extension, Transparent Proxy (MyApp1Proxy, bundle ID = com.myApp1.osx.proxy) As you can see, the brand name is used not only in the bundle and product names, but also in the bundle IDs. At some point, I need to change the product name from MyApp1 to MyApp2. Ideally, I would also like to change the bundle IDs to match the new brand. After rebranding, end users should not see MyApp1 anywhere in the system, only MyApp2. Also, components that are already installed and approved (System Extension, proxy configuration, helper tool, etc.) should stay approved. We would like to avoid showing the approval prompts again to all our end users. I did some research and found that bundle IDs technically cannot be changed. To solve this, I would need to release a new app and implement an in-app update mechanism that updates MyApp1 to MyApp2. However, even with a new app and an in-app update mechanism, I did not find a way to avoid user prompts for approving the new extension, the proxy, and possibly the privileged helper tool. For macOS, these will be new components that require explicit user approval. MDM is not a solution for us: some of our customers use MDM, but many of them do not. We want the update to be as smooth as possible. Thank you!
Replies
2
Boosts
0
Views
61
Activity
12h
URL Filter fails on macOS 27.2 beta: privacy-proxy failure on PIR status request
On macOS 27.2 beta 1/2 our URL filter never starts: the session loops starting -> stopping. The same build works on macOS 27.0 (26A428). Both our TestFlight and notarized standalone builds fail. Prefilter and PIR registration succeed. The PIR status request then fails: NWPath is satisfied, the connection is configured proxy fail closed, proxy strict fail closed, the proxy fails (event: proxy:children_failed), and the error is NSURLErrorDomain -1009 / POSIX 50 "Network is down" with _NSURLErrorPrivacyProxyFailureKey=true. NEMembershipCheckerErrorDomain Code=3 -> NEAgentURLFilterErrorDomain Code=3; the app sees serverSetupIncomplete. The privacy-proxy allow-list entry is identical on macOS 27.0 and 27.2 beta (com.adguard). Disabling the VPN, rebooting, and recreating the URL filter configuration do not help. Log excerpt: neagent: updatePrefilterWithCompletionHandler - result 1 neagent: <NEPIRChecker> - Register with PIR Server (group <com.adguard.safari.AdGuard> ... PrivacyProxyFailOpen <0> ...) -> completed registration ciphermld: [C3 ...] proxy fail closed, proxy strict fail closed ciphermld: [C3.1.1 ... failed proxy (satisfied (Path is satisfied), interface: en0[802.11], ipv4, dns, uses wifi, flow divert agg: 2, LQM: good)] event: proxy:children_failed ciphermld: queryStatus: NSURLErrorDomain -1009 / POSIX 50 "Network is down", _NSURLErrorPrivacyProxyFailureKey=true, NWPath=satisfied neagent: Failed to startFilter <Error Domain=NEMembershipCheckerErrorDomain Code=3 "(null)"> nesessionmanager: NEURLFilterPlugin(com.adguard.safari.AdGuard[url-filter][inactive]): setStatus:error: - err Error Domain=NEAgentURLFilterErrorDomain Code=3 Filed as FB24933164.
Replies
6
Boosts
2
Views
514
Activity
13h
Immersive Translate macOS 1.34.2: expedited review confirmed, still Waiting for Review
Hello App Review team, We would appreciate help checking a critical bug-fix update for our existing macOS app, Immersive Translate. App ID: 6447957425 Developer: Funstory.ai limited Platform: macOS Version / build: 1.34.2 (590) Submitted: October 18, 2026, at 14:55 China Standard Time (UTC+8) Current status: Waiting for Review Developer Support case: 103001150548 The currently published macOS version, 1.34.1, has a confirmed Safari extension initialization bug. Affected users cannot translate webpages, and the floating translation button disappears. Multiple users have reported this issue. Version 1.34.2 contains the fix. We requested expedited review, and Apple’s confirmation page stated: We’ll expedite review for Immersive Translate. However, at our latest check, the submission remained in “Waiting for Review,” more than 40 hours after submission. We have also contacted Developer Support under case 103001150548, but have only received an automatic acknowledgement so far. Could you please help: Verify that the expedited review request is correctly associated with macOS version 1.34.2, build 590. Check whether the submission is progressing normally or requires any additional information or action from us. Follow up on case 103001150548 with the appropriate team and advise on the next steps. Public user reports and our fix announcement: https://github.com/immersive-translate/immersive-translate/issues/4102 This update restores core functionality for affected existing users. We would appreciate your help making the fix available as soon as possible. Thank you.
Replies
1
Boosts
0
Views
107
Activity
19h
macOS test case - Could not launch app
Hi, Overview I am using Xcode Cloud for my multi platform app. The macOS test case fails, however the iOS test case runs and succeeds. I don't have any UI test cases written, the test case are simple and have nothing platform (macOS) specific. Questions What can I do to fix this? Is there any user privileges needed to launch the macOS app for testing? I ask because when I ran the UI tests locally it launched the app and asked for my macOS user password. Just wondering if that is the reason it didn't launch in Xcode Cloud. Error: <Appname> encountered an error (Failed to install or launch the test runner. If you believe this error represents a bug, please attach the result bundle at /Volumes/workspace/resultbundle.xcresult.(Underlying Error: Could not launch "AppnameTests. The LaunchServices launcher has returned an error. Please check the system logs for the underlying cause of the error. (Underlying Error: The operation couldn't be completed. Launch failed. (Underlying Error: Launch job spawn failed) ))) × Could not launch "<Appname>" × Could not launch "AppnameTests" × AppnameUITests.testExample() Failed to get launch progress for <XCUIApplicationImpl: 0x600000564630 <BundleID> at /Volumes/workspace/TestProducts/Debug-Dev/<Appname>.app>: Could not launch "app name". The LaunchServices launcher has returned an error. Please check the system logs for the underlying cause of the error. (Underlying Error: The operation couldn't be completed. Launch failed. (Underlying Error: Launch job spawn failed)) AppnameUITests.swift:28 * AppnameUITests.testLaunchPerformance) Failed to get launch progress for «XCUIApplicationimpl: 0x60000054630 <BundleID> at /Volumes/workspace/TestProducts/Debug-Dev/<Appname>.apps: Could not launch "<Appname>". The LaunchServices launcher has returned an error. Please check the system logs for the underlying cause of the error. (Underlying Error: The operation couldn't be completed. Launch failed. (Underlying Error: Launch job spawn failed)) AppnameUITests.swift:37 g * AppnameUITestsLaunchTests.testLaunch) Failed to get launch progress for «XCUIApplicationimpl: 0x60000054630 <BundleID> at /Volumes/workspace/Testroducts/Debug-Dev/<Appname>.apps: Could not launch "<Appname>". The LaunchServices launcher has returned an error. Please check the system logs for the underlying cause of the error. (Underlying Error: The operation couldn't be completed. Launch failed.
Replies
6
Boosts
0
Views
3.4k
Activity
1d
macOS app-specific container: documented initial creation behavior and storage restrictions
I am considering a dedicated macOS .app and am looking for public Apple documentation about the initial creation of its app-specific container by the operating system. The priority is to protect existing application data and settings. Running the proposed app and allowing application-managed storage remain on hold. This question concerns an individual app’s container, rather than an App Group shared container. The target macOS version, bundle identifier, signing configuration, and entitlements are not specified here. Please identify any conditions on which an answer depends. My primary question is: Is there public Apple documentation that identifies what the OS creates during initial container creation, which items are mandatory or conditional, and what triggers their creation? Where documented, I would like to understand their locations, contents, size bounds, and lifetime. For a later assessment, I also need to understand: How the container and its initial contents are associated with a particular .app, including any relevant signing or identity requirements. Whether a public, supported mechanism can permit OS-managed initial container creation while separately preventing subsequent application-managed writes inside that container. Please distinguish OS-managed initial creation from writes performed by application code or frameworks used by the application. Please also identify whether the behavior depends on App Sandbox, entitlements, or the macOS version. Links to documentation describing the supported guarantees and their limits would be especially helpful. If some details are implementation-dependent or undocumented, please distinguish those from documented guarantees. Thank you.
Replies
3
Boosts
0
Views
116
Activity
1d
Stuck Waiting for Review
Hi, I'm curious if others have spent a long time stuck waiting for review. I submitted a week ago, and have a growing audience exited to play my new game and continuing to not have it available is hurting my growth. Should I submit a form for expedited review? Apple ID : 6816716633 Name: Atlas of Crowns Submission ID: 08837345-2546-48a8-a330-930d68dad2e0
Replies
0
Boosts
0
Views
52
Activity
2d
Permanently disconnect/disable build-in display on iMac with M1
Hello, does anyone know how to permanently disable the built‑in display in macOS 15 on iMac M1 programmatically or via the terminal? I’m facing a problem — the display cable is broken. As a result, not only does it work poorly, but there’s also severe overheating in the upper right part of the iMac. The warranty has expired, and I don’t have the funds to replace the display right now. So I’m looking for ways to disable the built‑in screen and work only with an external display. At the moment, I’ve found a way to disable the display after logging in, but before logging in, the screen gets hot, and in this mode I won’t be able to upgrade to the new operating system. The process is lengthy, and the screen will become significantly hot. Ideally, the built‑in display should be disabled during reboot and when upgrading to a new version of macOS, and an external display should be used as the main display.
Replies
0
Boosts
0
Views
43
Activity
2d
Diagnosing pre-main latency in a short-lived macOS child process while preserving its parent
I’m looking for a supported way to investigate startup latency before main() in a short-lived native macOS child process, while preserving its original parent-child relationship. Environment macOS 26.6.2, build 25G83. Native arm64 executables. The on-disk /usr/lib/dyld contains the identifier dyld-1387; this is a static observation, not independent verification of all runtime shared-cache components. The diagnostic runs were started manually from normal macOS Terminal. All inputs and target processes are synthetic test fixtures. Execution structure Test supervisor → Watchdog → Observer → Query Observer launches Query using posix_spawn(). Query checks a synthetic target process’s identity using Security.framework and produces a fixed 28-byte result. Observer passes an explicit environment containing only LANG=C and LC_ALL=C. Consequently, exporting DYLD variables in the outer Terminal would not pass them to Query. Our existing test has a 1000 ms Query deadline and requires empty Query stderr. This is an application-defined acceptance requirement, not a claimed macOS timing guarantee. Observed results A historical full regression run timed out at approximately 1001 ms, with no Query result bytes received. That run did not have main-entry instrumentation, so we cannot determine where its time was spent. A later isolated, instrumented run measured: posix_spawn return to Query main entry: 832.687 ms main entry to return: 24.179 ms Observer-measured Query elapsed time: 864 ms Another isolated, instrumented run measured: posix_spawn call duration: 0.179 ms spawn return to main entry: 634.334 ms main entry to return: 6.757 ms Observer-measured Query elapsed time: 647 ms In the third run, getrusage(RUSAGE_SELF) at main entry reported cumulative CPU time of 3.014 ms user and 2.583 ms system. Before main returned, the cumulative total was 8.088 ms. Timeline measurements used CLOCK_MONOTONIC. Interpretation limits These successful diagnostic runs do not explain or resolve the historical timeout. Instrumentation changes the executable, and cache state and scheduling may differ. The CPU and wall-clock measurements cover different intervals. Subtracting them would not give an exact waiting-time measurement. We cannot currently attribute the delay to dyld, scheduling, security checks, IPC, or I/O. Diagnostic constraints We want to preserve the original parent-child relationship and avoid system-wide collection, disabling security protections, or silently changing permissions. We have not established that the Instruments App Launch configuration available to us can capture this child’s earliest startup phases while restricting collection to Query. The historical DYLD_PRINT_STATISTICS options are not documented in the installed dyld manual. Attaching a sampling tool after obtaining the PID may miss the relevant startup interval and may perturb this short-lived process. Questions What supported tool or API on this macOS version can distinguish startup phases before main() for this posix_spawn-created child? Can collection itself be restricted to Query, rather than collecting system-wide data and filtering the report afterward? What permissions are required, which early phases remain unobservable, and how much observer perturbation should we expect? If these constraints cannot all be met, what is the smallest necessary change to the diagnostic setup? What minimal sample project and evidence would be most useful for further investigation? I have preserved the original failure and subsequent diagnostic evidence, but do not yet have a standalone Xcode sample that reliably reproduces the historical timeout. I’m requesting guidance on an appropriate measurement method, not asserting that this is a confirmed macOS defect.
Replies
4
Boosts
0
Views
98
Activity
5d
MacBook Pro apps open unexpectedly after closing lid
This occurred after I had closed all apps before closing the lid. I received answer to this on apple regular support but was told that my post had been removed from the regular support service and the question had been moved here because it involved beta software. I do not recall agreeing to be a part of any beta software participation. I have been having issues with my computer doing weird things which I had communicated to the regular support group (icons for apps popping up on the desktop.... and some were banking related - not necessarily the app icon itself, but one of the files that if clicked would open the banking app) . Does anyone know what is going on and where this problem is coming from. What is going on? I do test software for 1 developer, but that developer has nothing to do with what is happening,.
Replies
1
Boosts
0
Views
49
Activity
6d
macOS XPC: Can incoming message size be bounded before payload allocation?
Hello, I'm designing a local macOS helper service (minimum deployment target: macOS 13) that performs one fixed syntax-validation operation. The submitted source is never executed. The security contract requires: A maximum incoming transport request size of 327,680 bytes. Immediate rejection when the 327,681st byte is encountered, without an allocation proportional to an unbounded sender-controlled payload. No application-level response for an oversized transport request, followed by termination of the affected connection. Complete application responses limited to 65,536 bytes, without treating truncated output as successful. I've reviewed the public XPC APIs, including xpc_data_get_length, xpc_connection_cancel, and xpc_connection_set_peer_code_signing_requirement. The remaining uncertainty is whether XPC can enforce a receiver-side message-size limit before materializing the incoming payload. My questions are: Does any public XPC API on macOS 13+ provide a documented maximum incoming message size that is enforced before payload materialization or proportional allocation? If not, is the entire incoming XPC message necessarily materialized before the application event handler receives it? Is there a supported XPC design for guaranteeing bounded receiver memory with untrusted input, or should this requirement use a different local transport, such as an AF_UNIX SOCK_STREAM socket? What guarantees does xpc_connection_cancel provide regarding connection termination, pending messages, and prevention of connection reuse after detecting malformed or oversized input? I'm specifically looking for documented platform guarantees rather than behavior that happens to work in testing. Thank you!
Replies
4
Boosts
0
Views
218
Activity
6d
Supported libSystem state after a LaunchDaemon permanently drops privileges
I am testing a fixed signed LaunchDaemon startup program that uses setgroups, setgid and setuid to establish a dedicated non-root identity before loading its service library or creating an application XPC listener. This follows the single-process, deferred-library direction discussed in DTS thread 844906. The remaining question is the supported treatment of system-runtime state initialized before the credential transition. Test environment: Apple silicon, macOS 27.0.1 / Darwin 27.0.0, hardened runtime, no special entitlements. The host links only libSystem and has no application constructors. This is a temporary diagnostic, not an installed product or a file-operation service. Our test verifies real, effective and saved UID/GID, the exact supplementary group vector and failed attempts to regain root. After the transition, a read-only own-task Mach inventory still sees a voucher even though successful task/current-thread voucher getters return null. It also sees one send+receive endpoint without an alias to any of the queried special/registered roles. Ordinary hardened launchd controls in both the login GUI and user domains also have a voucher and such an endpoint. Their recorded endpoint attributes match the post-drop test: empty queue, sequence 1, make-send count 1, send rights present, no send-once rights, port sets or notification requests. We do not treat this as proof that the objects or authority are equivalent. No messages are sent to the unidentified endpoint and no runtime-owned rights are destroyed. In a separate ordinary-user test, public voucher recipe extraction reports only a BANK attribute. Published libdispatch source describes a default task-bank voucher stored separately from the current thread's voucher slot. Published XNU source captures identity when bank context is initialized. We have not established the corresponding lifecycle or authority implications on this OS release, and do not claim that the observed voucher retains root authority. For this startup arrangement, what supported public contract should an application use to establish that libSystem's retained runtime context does not preserve usable pre-drop administrator authority before loading service code? Is there a supported sanitization step, or a specific documented OS trust assumption under which leaving that state intact is intended? If the combination of exact group reduction, deferred service loading and launchd Mach-service check-in cannot support that boundary, which public architecture should we use instead? We are seeking a documented arrangement or a clear limit on the guarantee, rather than a private reset API or an explanation of every internal endpoint. We have not used same-PID exec, a root supervisor, private APIs, or a broad port-type allowlist. Relevant documentation or a minimal public sample would help.
Replies
1
Boosts
0
Views
227
Activity
6d
Can a sandboxed Mac App Store app schedule power-on from shutdown and automatic shutdown?
Hello, I am developing a native macOS utility using SwiftUI and AppKit, and I am investigating whether its power scheduling features can be implemented in a sandboxed app distributed through the Mac App Store. The intended functionality is: Schedule power-on from a fully shut-down state, not just wake from sleep. Schedule wake from sleep and shutdown. Let the user select weekdays and times, and modify or cancel the schedule. Keep the schedule effective after the user quits the app. For example, the user could explicitly configure power-on at 08:00 and shutdown at 22:00, Monday through Friday. My local prototype uses pmset with administrator authorization. For a possible Mac App Store version, I am looking for a supported implementation that does not execute privileged shell commands or run an application helper as root. What I have checked The documentation for IOPMSchedulePowerEvent states that it must be called as root. Calling that API directly therefore does not appear to remove the privilege requirement. App Review Guideline 2.4.5 requires sandboxing and prohibits requesting escalation to root privileges. I also reviewed launchd scheduling and user-supplied scripts through NSUserAppleScriptTask, but neither appears to provide a self-contained solution for scheduling power-on from shutdown without privileged operations. Questions Is there a public API or system-mediated authorization mechanism that supports this functionality from a sandboxed third-party app? Is there a requestable entitlement specifically applicable to power-event scheduling? If the complete feature set is unsupported, which operations are available within App Sandbox: power-on from shutdown, wake from sleep, and scheduled shutdown? The current deployment target is macOS 13 or later, on Apple silicon and Intel. If a supported solution requires a newer macOS version or specific hardware, that information would also be helpful. I am asking about supported API capabilities and architecture, rather than advance App Review approval. A documentation reference—or confirmation that scheduled power-on from shutdown is unavailable under these constraints—would help me choose the appropriate distribution model. Thank you.
Replies
1
Boosts
0
Views
116
Activity
1w
Location Services stopped working across the system on macOS
MacBook Air (M4) Current build: macOS 27 Developer Beta (26A5368g) I have a system-wide Location Services failure affecting Apple Maps, Safari geolocation APIs, and any application requesting the current location. Symptoms: Apple Maps cannot determine current location. Safari and browser geolocation APIs fail. Websites report that location cannot be found. Location Services are enabled and permissions are granted. The issue has persisted across: macOS 26.5 beta macOS 26.6 beta macOS 26.6 beta 2 macOS 27 Developer Beta Troubleshooting already performed: Multiple Wi-Fi networks tested. iPhone hotspot tested. VPN enabled and disabled. Location Services reset. Permissions reset and reauthorized. New clean local user account created (no Apple ID, no third-party software). Issue reproduces identically in the clean account. Technical observations: locationd logs repeatedly show: knownCount = 0 AlsWifi = unknown while Wi-Fi scanning itself appears successful: queryMacAddresses.size = 57 The system sees dozens of nearby access points, but none appear to be recognized for Wi-Fi positioning. Additional findings: Wi-Fi hardware functions normally. Internet connectivity is normal. Bluetooth and Find My device presence work. GeoServices resources are present on disk. No successful location fix is ever produced. Has anyone seen similar CoreLocation / GeoServices behavior where Wi-Fi scans succeed but knownCount always remains 0 and no location fix is generated?
Replies
6
Boosts
2
Views
1.9k
Activity
1w
macOS 13+: Is LOCAL_PEERTOKEN a supported way to authenticate AF_UNIX peers?
Hello, I'm evaluating a local macOS helper service with a minimum deployment target of macOS 13. The service would communicate over an AF_UNIX SOCK_STREAM socket and must authenticate the signed code identity of the connecting process before accepting an operation. I'm investigating whether LOCAL_PEERTOKEN can provide a reliable audit token associated with the peer of an accepted socket. The public macOS SDK declares LOCAL_PEERTOKEN in sys/un.h, but I haven't found documentation establishing its precise security guarantees or availability across supported macOS versions. My questions are: Is LOCAL_PEERTOKEN a public, supported API on macOS 13 and later? Can it be used with getsockopt() on a file descriptor returned by accept() to retrieve an audit_token_t for the connected peer? At what point is the peer identity captured? Is the returned audit token securely bound to the original connecting process, even if that process exits and its PID is reused? Is the audit token obtained through LOCAL_PEERTOKEN officially supported as input to Security.framework APIs such as SecCodeCopyGuestWithAttributes (using kSecGuestAttributeAudit) or SecTaskCreateWithAuditToken? Does the identity remain trustworthy if the connected socket descriptor is inherited or passed to another process? Are there documented limitations concerning descriptor passing or time-of-check/time-of-use races? What is Apple's recommended public API sequence for verifying the signed code identity of an AF_UNIX peer on macOS 13+, including in an App Sandbox environment? I'm looking for documented security and availability guarantees rather than relying solely on observed behavior. Thank you!
Replies
1
Boosts
0
Views
80
Activity
1w