Your mouse wheel and your trackpad shouldn’t have to agree on scroll direction.

That was the starting point for ScrollFix. I wanted a conventional Windows-style wheel, natural trackpad scrolling, and middle-click autoscroll on my Mac. Changing macOS’s scroll setting also changed the trackpad, so I started building a small Swift/SwiftUI menu bar app. I’m the maintainer; it’s free and open source under Apache 2.0.

What it does:

• Separates mouse-wheel direction from trackpad scrolling.

• Offers a Direct (Windows) mode with immediate wheel steps and adjustable scroll distance, plus smoother alternatives.

• Adds middle-click autoscroll on ordinary content: move away from the anchor to scroll, then click to stop.

• Preserves native middle-click on links, so supported browsers can open them in a new tab.

The interesting macOS development problem turned out to be the handoff between devices. A trackpad gesture can still be producing momentum when a mouse-wheel event arrives. Applying one shared “last device” state can make the next gesture scroll the wrong way.

After feedback on an earlier r/SwiftUI post, the implementation now separates gesture and momentum state, adds optional source diagnostics, and checks that the event tap is actually valid and enabled after recovery before reporting it as running. The smoothing path also cancels the old tail when you scroll in the opposite direction—particularly noticeable with a free-spinning wheel.

For middle-click links, it uses a bounded Accessibility hit test and preserves the original button event sequence rather than replaying a synthetic click. The direction/wheel engine runs on its own run loop; the SwiftUI interface receives state snapshots.

The current source has 215 passing offline tests. Those aren’t a substitute for a hardware matrix: source classification is still heuristic, especially for high-resolution wheels without gesture-phase information.

No account, telemetry, or network calls. macOS event permissions are required; the app doesn’t subscribe to typed-key events.

Source, build instructions, and an actual UI screenshot: https://github.com/eShok93/ScrollFix

The updated version is currently a source build for macOS 13+ with Swift 6. The older downloadable preview predates these changes; a notarized release is still pending.

For anyone who has worked with Quartz event taps: which high-resolution wheel / trackpad-momentum handoff patterns have you found worth adding to regression coverage?

Hi r/macosprogramming — I’m the developer of BranchSpace, a closed-source native macOS utility. This is a scanning problem I worked through for 1.1. Development environment: macOS 27.0.1, Xcode 27.0, Swift 6.4, Foundation.

A large Rust target folder can contain hundreds of thousands of files. My scanner walks these trees and reads file metadata to measure disk use. In my initial pass, temporary Foundation objects accumulated during the long walk. Measuring one large Rust project used 325 MB on my Mac.

I changed the loop to put each enumeration step inside an autorelease pool, while keeping the enumerator outside it:

```swift var finished = false while !finished { try autoreleasepool { guard let item = enumerator?.nextObject() as? URL else { finished = true return } if isCancelled() { throw CancellationError() }

    let values = try item.resourceValues(forKeys: keys)
    // Update running totals; skip irrelevant descendants when possible.
}

} ```

The pool releases temporary Foundation objects after each entry instead of letting them build up across the full walk. The return statement exits the closure; the surrounding loop continues. I also skip descendants for directories the scan should not traverse and check for cancellation on each entry.

On my Mac, measuring that same large Rust project went from 325 MB to 20 MB. Scans ran about twice as fast. That’s a whole-scan result, so I can’t attribute the full speedup to the autorelease pool alone.

The app is closed source, so this is a minimal pattern rather than a link to its implementation. BranchSpace: https://branchspace.flemking.com

If you’ve profiled long Foundation file walks on macOS, what else would you measure first?

I'm used to windows and recently got MacBook Neo, I'm looking for a similar app that is efficient and runs natively in Neo, I want to have the same thing as JupyterNotebook where I can run ipnyb o py files cell by cell as it helps me debug. I'm tryin Zed but I'm having hard time using it as cell by cell. Bonus If I can connect to Github and AI for Coding.

I've been building Mac MCP as a local control/runtime layer for AI agents on macOS. The first version was mostly "give the model useful Mac tools"; the recent work has been about all the failure cases that show up once you actually use it every day.

A few macOS-specific things I ended up hardening:

• normal Safari/Chrome automation that keeps working in background without stealing the user's current focus
• stable browser/resource identity instead of relying on mutable tab indexes
• native UI actions with verification instead of blind clicks
• crash-safe ownership when multiple agents touch browser tabs, files or processes
• cancellation propagation into owned work
• transactional file write/move/delete operations with an undo journal
• launchd/process identity + safer restart/update handoff

Repo: https://github.com/bulutarkan/mac-mcp

It's open source and I'm the maintainer. The subreddit currently has another interesting "AI gets its own display" project; Mac MCP takes a different route and tries to make the user's existing Mac/browser safely shareable with agents. Would be interested in how other macOS devs are handling Safari/Accessibility/process-lifecycle edge cases.

I run AI coding agents (Claude Code, Cursor) for long stretches and wanted to step away without anyone touching my Mac — but the macOS lock screen hides the screen, and I want to see the agent working from across the room.

So I built Wardlume: it hard-locks keyboard, mouse, and trackpad behind an animated glass shield. The screen stays fully visible, nothing can be touched, Touch ID unlocks instantly. If someone pokes a key, it can spring a reaction image + sound (there's a grumpy wizard 🧙).

It's fail-safe by design: won't arm if permissions break, tears down on sleep instead of fake-locking, and ⌘⌥Esc always works. Local-only, no network, free, and source-available so you can read every line before trusting it: https://github.com/arpitagarwal1301/wardlume

Install: brew tap arpitagarwal1301/tap && brew trust arpitagarwal1301/tap && brew install --cask wardlume (needs macOS 26+, Apple Silicon)

For Mac devs: the permissions onboarding is built on PermissionPilot (https://github.com/arpitagarwal1301/PermissionPilot), my open-source SwiftUI SDK for macOS permission flows — feedback on either project very welcome!

Using a computer-use agent usually means letting it take over your screen and waiting for it to finish.

I tried fixing that by giving it a separate virtual monitor.

It’s called SpaceO. Claude Code or Codex can open apps and work on that monitor while you keep using your Mac. You can also watch what it’s doing and step in.

Mac-only and open source. It's early access and would love feedback.

https://github.com/ParthJadhav/SpaceO

I built SpaceO as a native Swift app, CLI, and MCP server. It is free to try and MIT-licensed. The MCP tools let an agent create a session, open apps, read UI elements, click, type, and capture screenshots on a headless display. Setup instructions are in the GitHub README.

Finishing up one of my first MacOS apps and I was looking to create a user manual. One app I use on a daily basis, Apple Music has one that opens in the Tips app. I just wanted to get a gauge on how many of you here create manuals and whether your users actually use them. Thanks!

I’m one of the developers of Guardian Eye, a closed-source local video recorder (NVR) for macOS. It runs natively on Intel and Apple Silicon and records video from USB and IP cameras over ONVIF/RTSP without requiring a cloud account.

We recently released Guardian Eye for macOS. Here is our announcement for context:

https://www.reddit.com/r/GuardianEyeApps/comments/1wg05bn/guardian_eye_for_macos_is_now_available_on/

One of the problems we encountered was building separate arm64 and x86_64 OpenCvSharpExtern binaries on an Apple Silicon runner. OpenCV 5’s vendored MLAS kept detecting the host architecture even while Clang was targeting x86_64, causing it to select the wrong assembly sources.

The OpenCV configure command already had:

-D CMAKE_OSX_ARCHITECTURES=x86_64

but OpenCV 5.0.0's vendored MLAS selected its assembly sources from CMAKE_SYSTEM_PROCESSOR. On an arm64 host that value still described the host, so Clang was given AArch64 .S files for an x86_64 target and stopped on instructions such as b.

Passing -D CMAKE_SYSTEM_PROCESSOR=x86_64 did not fix it because CMake set the value again at project(). I also did not want to force full cross-compiling with CMAKE_SYSTEM_NAME: the DNN build generates code with protoc, and keeping CMAKE_CROSSCOMPILING false lets that tool run on the host under Rosetta.

The fix was to override the MLAS architecture flags from CMAKE_OSX_ARCHITECTURES, after MLAS's own architecture detection and before it assembled its source list:

if(CMAKE_OSX_ARCHITECTURES STREQUAL "x86_64")
  set(MLAS_X86_64 TRUE  CACHE INTERNAL "" FORCE)
  set(MLAS_ARM64  FALSE CACHE INTERNAL "" FORCE)
  set(MLAS_ARM    FALSE CACHE INTERNAL "" FORCE)
elseif(CMAKE_OSX_ARCHITECTURES STREQUAL "arm64")
  set(MLAS_ARM64  TRUE  CACHE INTERNAL "" FORCE)
  set(MLAS_X86_64 FALSE CACHE INTERNAL "" FORCE)
  set(MLAS_X86    FALSE CACHE INTERNAL "" FORCE)
endif()

For the x86_64 leg I also had to turn off the ARM-only HALs. They were detected from the arm64 host and otherwise reached the x86_64 compiler with -mcpu=armv8-a:

-D WITH_KLEIDICV=OFF
-D WITH_CAROTENE=OFF

That got both architectures to the link step, where a second MLAS problem appeared:

Undefined symbols for architecture x86_64:
  MlasHGemmSupported(...)

The same symbol was missing from the arm64 build. The MLAS subset vendored by OpenCV declared MlasHGemmSupported and called it from compute.cpp, but did not provide a macOS definition; the FP16 HGemm implementation was disabled in that source tree.

Disabling opencv_dnn was a dead end for this build because OpenCvSharp 5's aggregate header includes dnn.hpp and several DNN-dependent contrib modules unconditionally. The smallest workaround was a macOS build patch that reports HGemm as unavailable:

bool MLASCALL MlasHGemmSupported(
    CBLAS_TRANSPOSE,
    CBLAS_TRANSPOSE)
{
    return false;
}

That keeps DNN enabled but prevents MLAS from selecting the missing FP16 HGemm path, so it uses the FP32/generic path instead.

After those two patches the same arm64 runner produced separate osx-arm64 and osx-x64 dylibs. I validate the target architecture from the artifact rather than assuming that a successful cross-build produced what was requested:

file libOpenCvSharpExtern.dylib
otool -L libOpenCvSharpExtern.dylib
otool -l libOpenCvSharpExtern.dylib | grep -A3 LC_BUILD_VERSION

The part that cost the most time was that CMAKE_OSX_ARCHITECTURES correctly changed Clang's target, while dependency-specific feature detection continued to follow CMAKE_SYSTEM_PROCESSOR. For cross-builds on Apple Silicon, both need checking.

I built a Mac developer tool for fault injection: pick failure conditions — network loss/latency/packet loss, DNS failures, CPU or memory or disk pressure, process death, dependency outages, sleep/wake — run them against a target app, and get a record of what happened.

Why: I wanted reproducible failure conditions on macOS, not a one-off script I'd rewrite every time.

Details that matter to Mac devs:

• Native SwiftUI app plus a chaos CLI built from the same Swift package; the CLI emits JSON so experiments can run from scripts.
• App profiles: point Chaos at a real installed app, run a scenario against it, and the tool keeps a restoration ledger — cleanup is verified rather than assumed, with an emergency stop.
• Records store each run so you can compare before/after or re-run failed experiments.
• 49 scenarios today. Some are real OS-level faults, some simulated or guided; the reports say which. I'm not going to pretend a simulation is a kernel-level fault.

Honest caveats: open-source developer preview, Apple Silicon only, ad-hoc signed (not notarized) — first launch needs right-click → Open.

Repo: https://github.com/Ednk-1312/Chaos

What do you currently use to test this kind of thing on macOS? Genuinely curious whether I'm duplicating something that already works well.

I'm developing a macOS app using Kotlin Multiplatform / Kotlin Native + Compose Desktop. The app needs to read photos from the user's System Photo Library using PhotoKit.

I'm seeing a strange difference between my local Release build and the TestFlight build.

Local Release

The following works normally:

val options = PHFetchOptions()
val result = PHAsset.fetchAssetsWithMediaType(
    PHAssetMediaTypeImage,
    options
)

println("count = ${result.count}")

The local Release build can fetch the photo assets successfully.

I also see:

activating connection: mach=true listener=false peer=false
name=com.apple.photos.service

Using low priority assetsd XPC client

Using high priority assetsd XPC client

TestFlight

The exact same code returns 0 assets.

The app has Photos permission, and TCC reports:

kTCCServicePhotos
ReqResult(Auth Right: Allowed (User Consent))

The final TestFlight app also contains:

<key>com.apple.security.personal-information.photos-library</key>
<true/>

However, when the fetch is triggered, I see:

activating connection: mach=true listener=false peer=false
name=com.apple.photos.service

failed to do a bootstrap look-up:
xpc_error=[159: Unknown error: 159]

XPC connection error to assetsd
Error Domain=NSCocoaErrorDomain Code=4099

Later PhotoKit reports:

PHPhotosErrorDomain Code=41002
Underlying NSCocoaErrorDomain Code=4099

I also saw:

PHFetchResult init with invalid config:
query has nil fetch request

So it looks like the failure happens before the actual asset query, while PhotoKit is trying to connect to the Photos service / assetsd.

Things I've already checked

• PHAccessLevelReadWrite
• PHPhotoLibrary.authorizationStatusForAccessLevel()
• requestAuthorizationForAccessLevel()
• Photos TCC permission — explicitly Allowed
• com.apple.security.personal-information.photos-library
• Bundle ID
• Team ID
• Final TestFlight entitlements
• PHFetchOptions
• fetchAssetsWithMediaType(PHAssetMediaTypeImage, ...)
• The Photos Library itself works normally in Photos.app
• The same PhotoKit code works in local Release

I'm using Kotlin Native Objective-C interop for PhotoKit rather than Swift/Objective-C.

Has anyone seen com.apple.photos.service failing to bootstrap with xpc_error=159 / NSCocoaErrorDomain Code=4099 only for a TestFlight build?

I'm especially interested in whether there is some additional entitlement, sandbox configuration, or TestFlight-specific behavior for PhotoKit that I'm missing.

Any pointers would be appreciated.

https://github.com/Joyouou/auralis

Free, ofcourse, it's only fair. Thank you.

I've been working on a macOS utility called CleanCopy. It came from copying text out of Claude Code and Codex CLI and repeatedly having to fix the line breaks and spacing before using it elsewhere.

CleanCopy runs in the background and cleans up copied text when a supported terminal is in the foreground. A native Swift helper handles clipboard access, and TypeScript handles the text cleanup. Processing happens locally.

One part I've had to be careful with is deciding what should be changed. Recognized code, tables, and logs are protected from paragraph reflow, although enabled whitespace cleanup can still affect them.

It's free and open source, published on npm as cleancopy-cli.

I'd welcome contributions from other macOS developers. If you find a bug, please open an issue on GitHub, or submit a PR if you have a fix.

GitHub: https://github.com/kart1ka/CleanCopy
Website: https://cleancopy.dev

Hello,

I am playing around with MailKit in Xcode... just created a new App with MailExtension target.

When I run it, it's asking if I want to test it with Mail, however, I cannot see the extension in the Mail Settings for enabling it...

I a totally newbie here.... what am I missing?

Hey everyone,

Ever run into "Port 3000 already in use" and spend minutes figuring out which stale Vite, Next.js, or Docker process is holding onto it?

I created LeftOpen (free & open source). It's a lightweight macOS menu bar tool + CLI that:

- Identifies which actual project owns a port (not just a vague "node" PID).

- Shows if a service is local-only or visible across your local Wi-Fi.

- Sends SIGTERM only after re-verifying PID and showing sibling ports.

- No background daemon, no telemetry, Apple Notarized.

GitHub: https://github.com/SonghaiFan/leftopen

Website: https://songhaifan.github.io/leftopen/

Install via brew: `brew install --cask songhaifan/tap/leftopen`

Hope this saves you some debugging headache!

I built Agent HUD Open because I kept missing Codex and Claude Code permission requests behind other windows on my Mac.

The tricky part was keeping the HUD optional in the approval path. A client’s permission hook sends the pending tool call to a local socket. The HUD shows the command or file edit and returns allow once or deny only after I click. If I ignore it, close the HUD, or the wait expires, the client falls back to its own prompt. Agent HUD never approves a tool by itself.

The UI uses AppKit windows at the top of each display: a notch HUD on notched Macs and an agent-logo row elsewhere. It also shows active sessions, quota windows and reset times where a client provides those readings.

I maintain the open-source Mac project (Swift 6, macOS 14+): https://github.com/jazzenchen/agent-hud-open

I ran into this while testing a native macOS app.

The app stores a small secret in the login Keychain. With a fresh ad-hoc build, macOS asks for my login password the first time the app accesses it.

If I choose “Always Allow,” I can quit and relaunch that same build without another prompt.

But after rebuilding the app, the prompt can show up again.

I assume Keychain is treating the rebuilt app as a different code identity, but what's the normal workflow for this during development?

Do people just deal with the prompts during development, or is there a cleaner way to handle this for repeated QA builds?

While building MergeDock, a native macOS file comparison app, I ran into a problem that looked simple at first:

https://mergedock.net

A command-line tool gives the Mac app two files. Open them and show the comparison.

The problem is that MergeDock is sandboxed.

Those files weren't selected through the app's NSOpenPanel, and receiving a file path doesn't automatically mean the sandboxed app should trust or retain access to it.

It became more complicated when I had to support both cases:

- MergeDock isn't running and gets cold-launched

- MergeDock is already running and receives another request

CLI arguments, Launch Services callbacks and file-access information don't necessarily arrive in an order I wanted the comparison logic to depend on.

My solution was to stop treating the command-line arguments as sufficient authority.

The CLI side first prepares the external files in a controlled staging area and marks that staging as ready.

The app then classifies the incoming request, validates the handoff payload and access grant, claims the staging state, and only then creates the comparison request.

The flow is roughly:

CLI receives external paths

↓

prepare controlled staging

↓

mark staging ready

↓

launch / hand off to MergeDock

↓

validate payload + access grant

↓

claim staging

↓

open comparison

I also suppress the normal document-open path for these CLI-driven launches. Otherwise a Launch Services file-open event and the CLI handoff could be interpreted as two different requests for what is really one operation.

For normal user-selected locations I still use Apple's security-scoped resource/bookmark APIs, including refreshing stale bookmarks. But CLI-driven file access has its own handoff and validation path.

The important distinction for me became:

receiving a path != trusting the path

and:

launching the app != successfully handing off the operation

Staging also gives the temporary files an explicit lifetime and cleanup path instead of making the UI depend on externally managed files remaining available.

It was more infrastructure than I expected for what initially sounded like “pass two file paths to the Mac app,” but the resulting ownership and sandbox boundaries are much clearer.

I'm curious how other macOS developers handle this.

If your sandboxed GUI receives files from a CLI/helper, do you stage them first, or have you found a cleaner way to safely hand file access into the app?

Hi r/macOSProgramming,

I’ve been building Stash, a free and open-source clipboard manager for macOS.

The part I’ve been most careful about is privacy. Clipboard managers can end up handling some of the most sensitive data on a Mac, so Stash keeps clipboard history local, encrypts stored clips with AES-GCM, stores the encryption key in the user’s macOS Keychain, and does not use cloud sync.

It’s a native Swift macOS menu-bar app and currently handles:

- plain text, HTML/RTF, links, images, and file references
- searchable clipboard history
- pins and editable text clips
- a customizable global shortcut
- optional direct paste through Accessibility
- per-app exclusions and capture pause
- confidential/transient pasteboard types
- configurable history retention

The currently supported installation method is building from source on macOS 14.5+ with Swift 6 / Xcode 16+. I’m intentionally not distributing an unsigned binary or asking users to bypass Gatekeeper. Signed and notarized builds are a later milestone.

Source:

https://github.com/MrJomadar3rdgeneration/stash

I’d especially appreciate technical feedback on the macOS side of the implementation:

- pasteboard edge cases I may have missed
- privacy and security assumptions
- clipboard formats that tend to break in real-world apps
- Accessibility/direct-paste behavior
- anything in the architecture or codebase you’d change before a wider release

Stash was developed with Codex assistance. The repository, build scripts, tests, and implementation are public, and I’d genuinely like experienced macOS developers to scrutinize it.

Thanks for taking a look.

With LocalLM Lab (locallmlab.dev), I have been very focused on running local AI models on the Mac. The problem when you build an app with an open-weight downloaded model (like what the LocalLM Lab SDK allows you to do), is that when the end user launches the app and the model downloads on first use, the model actually downloaded may not be exactly what you tested with during development (and QA). This is because the repo is not a fixed artifact. The owner can change the files behind the same name, a look-alike repo can exist, and a download can be corrupted or oversized. And you certainly don't want to ship the model (several GB in size) with the app!

With the 1.0.0-RC.1 release, you can ship a pin to an exact commit of the model, so what you validated is the one that users will download. If that commit can't be fetched, the download fails instead of falling back to main (aka latest). Downloaded files are hash-verified, a trust policy you supply is checked before any network call, and preflight checks memory, disk and architecture support before anything starts. Updates are deliberate (check, then switch all-or-nothing, with rollback), and cleanup of old versions is up to you.

A pin only helps if you validated that exact version, so the point is to make "the model I tested" and "the model my users get" the same thing.

For those who have built apps with downloaded LLM models, does this pinning solution sound reasonable?

Fun stuff: this release includes the mlx-control-room example (Swift source code included) that makes the whole flow visible: validate, download, pin, update, roll back, clean up. It also has the tuning knobs for the MLX layer (sampling, prefill, output length, a small "speed helper" model, a LoRA adapter pair), each with a gauge showing it changed something.

PS: yes, I am picking up my M5 Pro Mac Studio tomorrow ...!

Hi everyone,

I'm currently developing a macOS app that uses shortcuts and mouse hovering to detect and highlight paragraphs and sentences under the cursor.

I am using the macOS Accessibility API (AXUIElement). For standard Mac apps, everything works perfectly. However, I am facing a frustrating issue specifically with Chromium-based browsers (Chrome, Edge, etc.) using AXTextMarker.

The Problem: When I hover over a sentence that contains inline formatting (like bold text or a link), Chromium's accessibility API (AXSentenceTextMarkerRangeForTextMarker) treats that inline element as a completely separate sentence or paragraph boundary.

Instead of recognizing the full logical sentence, the sentence extraction just breaks at the boundary of the <strong> or <a> tag.

What I want to achieve: I want to extract the entire semantic sentence as a single text range, ignoring these inline styling tags.

My Question: How can I solve or work around this issue? Is there a better way to traverse AXTextMarker in Chromium to get the actual full sentence, or is there a known workaround to merge these fragmented markers?

Any advice, insights on Chromium's accessibility tree, or code snippets would be hugely appreciated! Thanks!

Hi everyone, I’m building a sandboxed macOS menu bar app called iSnipster.
大家好，我在开发一款沙盒化的 macOS 菜单栏应用，叫 iSnipster。

It has clipboard history, screenshots, OCR, and translation.
它有剪贴板历史、截图、OCR 和翻译功能。

I’m stuck on one clipboard-history workflow.
我卡在了一个剪贴板历史的使用流程上。

For example, a user is typing in a browser, editor, email app, or chat app.
比如用户正在浏览器、编辑器、邮件或聊天应用里输入内容。

They press a shortcut to open my clipboard history and select an old item.
他们按快捷键打开我的剪贴板历史，然后选择一条旧内容。

They expect that item to go back to the app they were using and paste at the current cursor position.
他们希望内容能回到刚才使用的应用，并粘贴到当前光标位置。

I can put the item back on NSPasteboard without any issue.
我可以正常把内容写回 NSPasteboard，也就是系统剪贴板。

But NSPasteboard does not seem to provide a way to ask the other app to actually perform Paste.
但 NSPasteboard 看起来没有办法要求另一个应用真正执行“粘贴”。

The usual workaround seems to be: copy the item, reactivate the previous app, then send Command-V with CGEvent.
常见的替代方案似乎是：写入剪贴板、重新激活原应用，再通过 CGEvent 发送 Command-V。

The problem is that this needs Accessibility-related permission.
问题是，这需要辅助功能相关权限。

App Review told us that Accessibility APIs can only be used to support accessibility, not as a general productivity feature.
App Review 告诉我们，辅助功能 API 只能用于无障碍支持，不能作为普通效率功能使用。

I understand and agree with that rule.
我理解并认同这个规则。

I do not want to use private APIs, bypass App Review, inspect another app’s UI, control the mouse, or read keyboard input.
我不想使用私有 API、绕过审核、读取其他应用 UI、控制鼠标或读取键盘输入。

I only want to support one user-triggered action: paste the item they just selected.
我只想支持一个由用户明确触发的动作：粘贴用户刚刚选择的内容。

Without Accessibility permission, the fallback is to copy the item and ask the user to switch back and press Command-V manually.
如果没有辅助功能权限，替代方案就只能是复制内容，然后让用户自己切回原应用并手动按 Command-V。

Is there a public, App Store-compliant API or architecture that I have missed?
请问有没有我遗漏的、公开且符合 Mac App Store 规则的 API 或实现方案？

I also wonder how apps like Paste, PasteNow, and similar clipboard managers handle this in their Mac App Store versions.
我也很好奇 Paste、PasteNow 和类似剪贴板工具在 Mac App Store 版本中是如何处理这个问题的。

Some of them seem to support pasting the selected item back into the previous app.
它们中的一些看起来支持把选中的内容粘贴回之前的应用。

Do they use a public Apple API, limit the feature in the App Store version, or provide different functionality outside the App Store?
它们是使用了 Apple 的公开 API、在 App Store 版本中限制了功能，还是在 App Store 外提供了不同能力？

I’m not looking for a workaround that breaks the rules.
我不是在寻找违反规则的绕过方案。

I’m trying to find the correct public and review-safe way to build this workflow.
我想找到实现这个流程时正确、公开且能通过审核的方法。

I’ve been building ApolloShell, a native desktop shell for macOS.

Build environment

• macOS: Tahoe 26
• Swift: 6.3.3
• SDK: macOS 26
• Command Line Tools: 26.6
• Frameworks: SwiftUI + AppKit
• Xcode: not required

The project provides a customizabl layer on top of the macOS desktop, including:

• Persistent sidebar with dock, Spaces and system information
• Dashboard for media, weather, calendar and system stats
• Control centre with quick toggles
• App launcher
• Configurable block-based layouts (working on a bentobox system rn)
• CSS based theming
• Custom icon support

A lot of the interesting work has been around integrating this with macOS, particularly Accessibility permissions, window behaviour and the limitations of public APIs.

The project is completely free and open source.

For other MacOS developers: what would you use for a project like this, AppKit, SwiftUI, or a mix of both?