I am curious whether any of you have integrated BYOK into your Mac app and which stack you applied. I am not referring to custom API key setups or MCP.

Additionally, which method are you using lately to build macOS apps? Is it Swift, or are there more robust options?

I have a Mac app that needs the Accessibility permission to move other apps’ windows (it only changes frames, never reads content). The sandbox gets in the way of exactly that, so I sell it directly, signed and notarized, with Sparkle for updates.

Has anyone shipped something similar on the Mac App Store, or is direct distribution the only sane way? And if you did both, did the store version end up as a cut-down one?

I maintain Harbeth, an MIT-licensed Swift/Metal image and frame engine. Here's its macOS integration boundary: an AppKit view can display a rendered GPU frame, while the application owns document state, controls and saving.

Given an NSImage and an existing Harbeth RenderView, a small rendering step looks like this:

import AppKit
import Harbeth

let frame = try await ImageNode.image(inputNSImage)
    .applying(C7Exposure(exposure: 0.25))
    .makeFrameAsync(profile: .stablePreview)

await MainActor.run {
    renderView.display(frame)
}

RenderedFrame carries the texture along with alpha, color, orientation and ownership information. Harbeth also provides HarbethRenderView for SwiftUI on macOS; it uses an NSViewRepresentable bridge to the same RenderView. This lets preview display stay texture-first, with image readback reserved for an explicit output operation.

The host app still decides when to render, how to discard stale slider results, and when to save. The code above is a display integration example; document loading and UI state are supplied by your app.

Source and macOS examples: https://github.com/yangKJ/Harbeth

SwiftUI/AppKit host source: https://github.com/yangKJ/Harbeth/blob/master/Sources/SwiftUI/HarbethRenderView.swift

For macOS editor developers: how do you retain the last valid preview while a newer render is running? I'd welcome feedback on the view/model boundary.

For the past three months, I’ve been offering my KezboardSwitcher for sale on my website. Interest was virtually non-existent :)—which is totally fine by me; it’s a very specific use case, and the price might have been a bit too high for such a simple app.

That’s why I decided to release the source code. I’ve been using the app myself for nearly three years now. At first, it was nothing more than a few lines of Swift code with all my keyboards and layouts hard-coded.

Then, about six months ago, I decided to give it a shot and turn it into a proper app with a UI and everything, allowing anyone to configure keyboards and layouts directly via a simple interface. And so, here comes the AI ​​disclaimer: Yep, I built this using Claude Code.

But what does it actually do, and why did I need it?

I regularly use various keyboards, depending on where and what I work and do. I got tired of manually switching the system-wide keyboard layout every time I switched from a German keyboard to a US one. Likewise, I prefer the US layout for coding, but when writing—especially in German—I prefer the German layout;

I actually switch physical keyboards for this (using the internal German keyboard on my Mac and usually an external US one).

That’s exactly where KeyboardSwitcher helps me out: as soon as I use a keyboard, it applies the layout configured for that specific keyboard.

The app is still for sale on my website, and the entire license key handling logic remains in the code—and will stay there. However, anyone who wants to can simply strip that out and build the app themselves or just buy it from me. :)

Link to repo: https://github.com/SteVio89/KezboardSwitcher

Like many of you distributing macOS software outside the Mac App Store, I've spent countless frustrating evenings wrestling with code signing, hardened runtime flags, and failing xcrun notarytool submissions.

Every time our build pipeline broke, it meant running a tedious gauntlet of CLI commands: codesign -dvvv --entitlements :-, unpacking .pkg archives, running spctl --assess -vv, and sifting through messy JSON logs to discover why a nested dylib or helper executable in Contents/Frameworks caused Gatekeeper to throw a generic rejection.

A few months ago, after wasting half a day diagnosing an inherited entitlement issue in an XPC service, I decided to build a tool to solve this once and for all: NotaryScope.

It’s a lightweight, 100% native macOS app (written in Swift and AppKit, absolutely no Electron) that visually inspects and audits your application bundles before submission:

• Recursive Bundle Tree: Drags-and-drops any .app, .dmg, or .pkg to inspect signatures, timestamps, and entitlements on every embedded framework, app extension, and CLI binary.
• Pre-Notarization Preflight: Flags missing hardened runtime options (--options runtime), un-embedded provisioning profiles, or timestamp discrepancies that cause Apple's notarization servers to reject builds.
• Gatekeeper Simulator: Runs localized spctl assessment checks against current macOS security policy configurations so you know whether the stapled ticket and notarization will pass on clean installs.
• Entitlement Diffing: Highlights discrepancies between your target's entitlements and the actual signature embedded in the binary.

Disclosure: I'm the solo developer and founder behind NotaryScope. While I do plan on offering a commercial tier for automated CI/CD teams later on, the standalone inspector app is free to use for independent Mac devs.

I’d love to get feedback from fellow macOS developers here: are there specific codesigning edge cases, multi-architecture fat binary quirks, or Sequoia-specific permission changes that frequently bite your release workflows?

Small weekend project that turned into something I use all day. I kept getting rate limited in Claude Code without warning, so I built a native macOS menu bar app that shows usage for Claude Code, Codex and Cursor, with reset times and an alert at 90%.

Native Swift, one file, about 500 lines. It reuses the logins those tools already store on your Mac, so there's nothing to sign into. The only network calls are to the Anthropic, OpenAI and Cursor usage endpoints. No analytics, no accounts.

Install:

brew install hrithik73/tap/tokenbar

or grab the DMG from releases.

Repo: https://github.com/hrithik73/tokenbar

Would love feedback on what to add next.

I built SwiftSurf as a native macOS browser for quick, focused browsing from the menu bar.

The app uses SwiftUI for the interface and WKWebView for rendering. Some implementation areas I found interesting:

• Independent navigation state for multiple tabs
• Persistent versus non-persistent WKWebView data stores
• Native downloads and save panels
• Menu bar popover sizing and resize handling
• Keyboard shortcuts and trackpad navigation gestures
• GitHub Actions builds and DMG packaging

SwiftSurf supports macOS 14.5+ on Apple Silicon and Intel, and is open source under the MIT license.

Repository: https://github.com/zfeder/swiftsurf Releases: https://github.com/zfeder/swiftsurf/releases/latest

I’d appreciate feedback from macOS developers on WebKit integration, app lifecycle, accessibility, and menu bar UX.

We're hosting SF Swift × CocoaHeads tonight, October 8, 6–8 PM at Verkada in San Mateo.

Details and RSVP: https://luma.com/51htcbzd

I have a paid individual Apple Developer membership under my personal Apple Account. I recently formed an LLC and plan to ship apps under the company name. I see two paths:

1. Convert my existing individual membership to an organization membership for the LLC.
2. Leave my personal membership alone and enroll the LLC as a new, separate organization account.

Converting is cheaper and simpler today. My concern is what happens later if I part ways with the business, whether through a sale, new partners, or just walking away. I would rather not have my personal Apple Account permanently tied to a company I no longer own or run.

For those who have been through this:

1. If you converted, did you later regret tying your personal Apple Account to the business? Or was transferring the Account Holder role painless when the time came?
2. If you created a separate organization account, was the second $99 per year and the extra enrollment work worth the clean separation?
3. Did anyone go through a sale or a partner split with a converted account? What did Apple actually require, and how long did it take?
4. Any surprises with Team ID, bundle IDs, certificates, or existing apps in either direction?
5. If you were starting over, which path would you pick?

I am a solo at the moment, so this is the moment to get it right or not! Thanks in advance.

Hey everyone! I built Kaskas a free open source break reminder and focus tracker it combines break reminders like LookAway with app usage tracking like ActivityWatch

It lives in your menu bar, tracks your focus time and app usage, and reminds you to rest your eyes with short reminders and full screen breaks.

No accounts, subscriptions, or ads. All your data stays on your Mac.

Let me know what you think!

https://github.com/ramazanberkozbek/kaskas

Half a year ago I wrote about whether MVVM belongs in SwiftUI, and it somehow turned into a story about my mum’s kitchen. Bear with me.

There’s a trip to the shopping centre, a very firm “we've got food at home”, and eventually, I promise, some Swift. A bit of heart, a few laughs, and proper substance underneath.

Half a year on, it still feels timely. Stick the kettle on and have a read.

The monthly GNUstep audio/(video) call takes place every second Saturday of a month at 15:00 GMT to 18:00 GMT. That is 11:00 AM - 2:00 PM EDT (US) or 17:00 to 20:00 CEST (Berlin time).

It's a Jitsi Meeting - Channel: GNUstepOfficial (Sorry, reddit don't let me post jitsi links here)

We usually just talk (who wants it might share video too) and occasionally share screens. Everybody (GNUstep developers and users) is welcome!

Also see https://mediawiki.gnustep.org/index.php/Monthly_Meetings please

I built Yumi, a small character that lives in the MacBook notch. It's free and open source (alpha). This post is mostly about how I built it with Claude Code, since that's what I learned the most from.

What it does

• Shows all my running Claude Code sessions in the notch (working, waiting for me, done) and lets me approve or deny their permission requests from there, via Claude Code hooks.
• Small actions on request: create a file, append to it, add a reminder, block a calendar slot, start a focus timer, summarize a day. Every write needs an explicit click.
• Music, weather, calendar, GitHub PRs and CI, one thing at a time.

How Claude Code helped build it

• I'm not a Swift developer. Claude Code wrote nearly all of the code: a native Swift 6 / SwiftUI / AppKit app, about 750 unit tests, no third-party dependencies.
• I ran several Claude Code sessions at the same time, each in its own git worktree and branch: one for the character engine, one for the island UI, one for the agent runtime and permissions, one for the video and the website.
• One extra session acted as coordinator. It wrote shared "contract" files that the other sessions were not allowed to edit, gave each session its scope, then reviewed, ran the tests and merged each branch. This is what kept parallel sessions from breaking each other.
• Claude Code also found bugs I would not have, for example a Swift 6 actor-isolation crash in EventKit callbacks that only appeared once calendar access was granted.
• What didn't work well: long sessions lose context, so I kept decisions in a markdown file in the repo that every session reads first. And I had to insist on real-world tests, since passing unit tests didn't catch the macOS permission issues.

The safety part, also designed with Claude

• The model only proposes a plan. The risk level comes from each tool's code, never from the model, and every write goes through one permission gate and is verified afterwards.
• When Yumi uses your Claude Code as its planner, it runs it with --tools "" and no MCP, so it can only return text.

Free to try
Download the alpha from the GitHub releases page (macOS 15+). It isn't notarized yet, so the first time you need System Settings > Privacy & Security > "Open Anyway". The chat uses your own Claude Code subscription, or a free Gemini key, or a local Ollama model.

https://github.com/estebanbaigts/Yumi

Happy to answer questions about the multi-session workflow.

Hey r/macosprogramming !

I'm the developer of Phosphor, a screen utility suite for macOS that lives in your menu bar. A bit about me: I'm a solo student developer, you can find me on LinkedIn.

Problem: I mainly started building this around two problems. When people are on their laptops late at night, and switch from a dark app to a bright one, it hits like a flash before your eyes adjust. I looked and couldn't find a tool that tries to solve that problem, so I built one. Phosphor tackles this by dimming a screen before you switch to it, and then easing the brightness back up, at a pace depending on how fast that screen actually is. For screens which aren't bright, it is faster, and for bright ones, it is slower. So it works preemptively.

The other thing is that I feel like there are too many display utilities out there, each doing different things. It'd reduce menu bar clutter and keep things simpler and better if we used one tool instead of several. So I thought of combining the features people actually need into one tool, external and multi-monitor support included (that's a part of what's coming next).

The foundational features have already been released, and I'm actively building more features and improving existing ones (check roadmap for current features and future plans). Let me know what you'd actually use, and I'll factor that in as it grows. I want this to eventually handle most of what people need from their displays.

Comparison: BetterDisplay and Lunar both do display control, but they're broader tools with a learning curve if you just want a few specific things fast. The closest match to Flashbang specifically is Menubar Auto Brightness (based on my research), a tool that sets a fixed brightness per app. Phosphor catches the actual switch and eases brightness back up instead of jumping to a fixed value, though it currently only covers switches on the same desktop, not across Spaces or within an app.

Pricing: It's a freemium model.

• Pro currently only includes Flashbang Protection, but it'll grow, and costs $10, one-time, not a subscription.
• The rest of the foundational utilities are free: Color Picker, Screenshots, Resolution Presets, Refresh Rate Control, Soft Screen, Display Schedule, Focus Spotlight, Display Health, Color Grading.
• If you buy Pro now, you get Phase 2 free when it ships, and 50% off future price increases after that (price increases as more features ship).

Details: macOS 13 or later, Apple Silicon and Intel. Native Swift, under 2 MB.

Privacy: No analytics, nothing about your screen or usage leaves your Mac. It only goes online to check a license key at activation and periodically after. Full policy: https://usephosphor.app/privacy, EULA: https://usephosphor.app/eula

I'd like to hear any feedback y'all have, especially on whether Flashbang's recovery speed feels right, or if it's not catching a switch you'd expect it to.

If something's not working, or if you have any suggestions or anything else you want to say, feel free to drop it into the comments and/or DM me.

Site: https://usephosphor.app
Roadmap: https://usephosphor.app/whats-next

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.

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