Supported sandbox approach for cross-app window positioning and resizing

App & System Services Core OS
yuv1982 OP
Created
Replies 2
Boosts 0
Views 92
Participants 2

I am developing a macOS window-management utility for a new Mac App Store submission, targeting macOS 13+ on Apple silicon and supported Intel Macs. Its core function is to move and resize windows belonging to other, unmodified applications, in response to explicit menu commands, registered keyboard shortcuts, or optional edge-drag snapping.

The current unsandboxed engineering implementation uses public Accessibility APIs: AXUIElementCreateApplication, AXUIElementCopyAttributeValue / AXUIElementCopyMultipleAttributeValues for window geometry, AXUIElementCopyElementAtPosition for drag targeting, and AXUIElementSetAttributeValue for AXPosition and AXSize. It requires explicit Accessibility consent. Window information is processed locally; the app does not transmit it.

I understand that App Review Guideline 2.4.5(i) requires App Sandbox and that “Protecting user data with App Sandbox” lists assistive Accessibility API use as incompatible. The DTS answer in thread 789663 also explains that sandboxed apps cannot use Accessibility APIs, while noting that some use cases have alternatives.

For this specific cross-application positioning/resizing use case:

  1. Is there a currently supported public API or documented, requestable entitlement that permits it in a newly submitted sandboxed Mac App Store app?
  2. If a supported alternative exists, what API/architecture and minimum OS requirements apply, including any approval process?
  3. If there is no supported route, can you confirm that this functionality cannot currently be delivered within the described sandboxed Mac App Store constraints?

I am seeking a supported architecture for controlling other apps’ windows. The unsandboxed tests establish functionality only; they do not establish sandbox compatibility or App Review eligibility.

References:

  • https://developer.apple.com/app-store/review/guidelines/#hardware-compatibility
  • https://developer.apple.com/documentation/security/protecting-user-data-with-app-sandbox
  • https://developer.apple.com/forums/thread/789663
Answered by DTS Engineer in 914242022

Things haven’t changed since… ah… um… yesterday, when I replied on this thread.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Replies  2
Boosts 0
Views  92
Participants  2
DTS Engineer OP
Apple
Recommended

Things haven’t changed since… ah… um… yesterday, when I replied on this thread.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"
yuv1982 OP

Thank you for the referral to thread 854711. I understand that its answer covers both public APIs/entitlements and a supported Store architecture for the described foreign-window operations.

I have one narrower question about a published standard access group not discussed there. On macOS 27.0.1 (26A434), the signed System Events dictionary declares com.apple.systemevents.window.position with read access on window collections and read/write access on window position and size.

A disposable universal sandboxed client targeting macOS 13 used:

<key>com.apple.security.app-sandbox</key><true/>
<key>com.apple.security.scripting-targets</key>
<dict>
  <key>com.apple.systemevents</key>
  <array><string>com.apple.systemevents.window.position</string></array>
</dict>

It also carried the separate Hardened Runtime Apple Events entitlement and usage description. It used no temporary exception, private API or direct AX geometry fallback. It was an ad-hoc engineering probe, not a Store-provisioned product.

After explicit Automation consent, no-prompt authorization queries for get and set returned 0. This read returned -10004, “A privilege violation occurred”:

on readGeometry()
    with timeout of 5 seconds
        tell application id "com.apple.systemevents"
            set w to window 1 of process "NativeTarget"
            return (position of w) & (size of w)
        end tell
    end timeout
end readGeometry

The target was a disposable single-window AppKit app. The same frozen client failed identically both before and after its Accessibility trust became true. No geometry setter ran. Its temporary Accessibility access is now revoked.

Does this standard access group support such foreign-window property access from a sandboxed app? If so, does the expression above request something outside the group, and which documented property/object-specifier form, OS availability and signing/provisioning conditions apply? Separate property-only position and size reads have not yet been tested.

The actual product, now named Tilra, additionally needs exact focused/dragged-window selection and stable same-window Restore, alongside menu commands, hotkeys, all layouts and optional edge snapping. Windows remain independent. If the group supports only narrow geometry access, does your earlier negative answer still apply to that full contract? We retain macOS 13+, Intel and Apple silicon and mandatory Mac App Store distribution.

I am seeking technical clarification of this named group, separately from App Review policy. I am not treating its dictionary declaration, a potential successful read, or user consent as proof of full supported functionality or Store eligibility.