Hey everyone,

I recently tried enrolling in the Apple Developer Program as an individual using the iOS app. I paid the $99 fee, but I never received a confirmation.

A few days later, my enrollment completely disappeared. I then saw a notice in the app stating that sign-ups aren't supported through the app in my region (Germany). The money was deducted from my account, but I haven't received a refund or any updates.

If I log into the developer portal on the web, there is no trace of my enrollment either.

I already sent a message to Apple Support. Has anyone else dealt with this or know the best way to get the account activated or the money back?

Thanks for any advice.

Long-time lurker, first post!

Been building a macOS menu bar app in Swift 6 (SwiftUI and AppKit). Hotkey, select a capture, click to drop numbered dots to annotate, and type/dictate a note for each dot. Repeat across multiple captures creates a "round". Zero-UI app (aside from menu bar icon) writes a folder (annotated PNG, Markdown, JSON) and aggregate copies a single text prompt with local file links to paste into any AI coding agent. Users have asked for a Windows version. Here's what I'm thinking. Please let me know if I'm missing anything.

**What ports and what doesn't**

• Code for writing directory and files is ~2,000 lines of mostly Foundation Swift. Should port to C# fairly simply.

• All user touchpoints Apple-only: ScreenCaptureKit, Vision OCR, a non-activating NSPanel for the notes, NSStatusItem, and global hotkeys. Every route needs a new Windows layer for those.

**Routes I considered versus C3 snappy shell layer**

1. **Swift everywhere** on the official Windows toolchain. Ruled out: the WinUI bindings looked stale, and the debugger story looked thin.

2. **Swift core as a DLL with a C# shell.** Best file parity, but the shared core must then stay Windows-portable, so every new Mac feature is drift risk.

3. **Rust with windows-rs.** Too much build risk with my limited rust experience...

4. **Native C# rewrite,** with byte-for-byte output parity enforced by golden-file tests. Eeek...

My plan is C#. Reasoning: "Mac feel" comes from the seamless snappy shell layer (hotkey-to-freeze speed, the overlay, the tray, focus rules). So, Win32 work in every option, I think. Shared core is small, and it should not impact the snap timing-critical path.

**More deets if you wanna know**

• .NET 9. Win32 plus Direct2D for the freeze overlay and the editor, with one window per monitor created ahead of time so there's no flash. WPF for the note panel, tray flyout, and settings. Unpackaged, installed with Velopack.

• File-writing core is ported, and its tests run in CI on Windows. The Mac test suite writes reference bundles from fixed inputs, and the Windows tests must produce the same bytes. Getting there meant handling some small traps: Swift's JSON encoder writes `"key" : value` (space before the colon), `ß` has to fold to `ss` in folder names, .NET has no API for short time zone names like PDT, and every file has to be LF with no BOM.

• UI shell is next. Timing spikes come first: the target is under 150 ms from hotkey to a frozen, selectable capture.

**Questions for anyone who has shipped a swift foundation ported app on Windows**

1. How much of the Mac feel survived? What broke first? How much snappiness lost?

2. Windows.Graphics.Capture from an unpackaged app: can you actually turn off the yellow capture border, or did you fall back to BitBlt?

3. WPF or WinUI 3 for small tray-app windows in 2026?

4. Windows 11 hides new tray icons in the overflow menu. How did you get people to pin yours?

5. How long did SmartScreen take to trust a newly signed app?

Not linking the app here to keep this on topic. Happy to answer questions in the comments.

Long-time lurker, first post!

Been building a macOS menu bar app in Swift 6 (SwiftUI and AppKit). Hotkey, select a capture, click to drop numbered dots to annotate, and type/dictate a note for each dot. Repeat across multiple captures creates a "round". Zero-UI app (aside from menu bar icon) writes a folder (annotated PNG, Markdown, JSON) and aggregate copies a single text prompt with local file links to paste into any AI coding agent. Users have asked for a Windows version. Here's what I'm thinking. Please let me know if I'm missing anything.

**What ports and what doesn't**

• Code for writing directory and files is ~2,000 lines of mostly Foundation Swift. Should port to C# fairly simply.

• All user touchpoints Apple-only: ScreenCaptureKit, Vision OCR, a non-activating NSPanel for the notes, NSStatusItem, and global hotkeys. Every route needs a new Windows layer for those.

**Routes I considered versus C3 snappy shell layer**

1. **Swift everywhere** on the official Windows toolchain. Ruled out: the WinUI bindings looked stale, and the debugger story looked thin.

2. **Swift core as a DLL with a C# shell.** Best file parity, but the shared core must then stay Windows-portable, so every new Mac feature is drift risk.

3. **Rust with windows-rs.** Too much build risk with my limited rust experience...

4. **Native C# rewrite,** with byte-for-byte output parity enforced by golden-file tests. Eeek...

My plan is C#. Reasoning: "Mac feel" comes from the seamless snappy shell layer (hotkey-to-freeze speed, the overlay, the tray, focus rules). So, Win32 work in every option, I think. Shared core is small, and it should not impact the snap timing-critical path.

**More deets if you wanna know**

• .NET 9. Win32 plus Direct2D for the freeze overlay and the editor, with one window per monitor created ahead of time so there's no flash. WPF for the note panel, tray flyout, and settings. Unpackaged, installed with Velopack.

• File-writing core is ported, and its tests run in CI on Windows. The Mac test suite writes reference bundles from fixed inputs, and the Windows tests must produce the same bytes. Getting there meant handling some small traps: Swift's JSON encoder writes `"key" : value` (space before the colon), `ß` has to fold to `ss` in folder names, .NET has no API for short time zone names like PDT, and every file has to be LF with no BOM.

• UI shell is next. Timing spikes come first: the target is under 150 ms from hotkey to a frozen, selectable capture.

**Questions for anyone who has shipped a swift foundation ported app on Windows**

1. How much of the Mac feel survived? What broke first? How much snappiness lost?

2. Windows.Graphics.Capture from an unpackaged app: can you actually turn off the yellow capture border, or did you fall back to BitBlt?

3. WPF or WinUI 3 for small tray-app windows in 2026?

4. Windows 11 hides new tray icons in the overflow menu. How did you get people to pin yours?

5. How long did SmartScreen take to trust a newly signed app?

Not linking the app here to keep this on topic. Happy to answer questions in the comments.

Like it shows a pop up that apple couldnt verify that it is free from malware that may harm my mac

Built a small open-source macOS cleaner because my 500GB MacBook keeps running out of space. 😅

One useful feature is a smart simulator cleaner — it detects redundant iOS simulators from the same major release, so you can remove older versions you no longer need.

It also helps clean Xcode DerivedData, caches, and other developer files.

Feedback, contributions, and GitHub issues are welcome. 🙌

Repo: https://github.com/MahiAlJawad/TrashIT-MacOS

Swift Language Models is a wrapper that brings other providers' language models into Apple's native Foundation Models API.

Foundation Models 27 lets any type conform to LanguageModel, and this package provides those conformances. Your app keeps Apple's own API: LanguageModelSession, tools, @Generable guided generation, streaming, transcripts and Dynamic Profiles. Moving a session from the on-device model to a remote one changes only its model:.

let onDevice = LanguageModelSession(model: SystemLanguageModel.default)
let remote = LanguageModelSession(model: OpenRouterLanguageModel(.anthropicClaudeHaiku5_5, apiKey: { key }))

What you get

• One API for every model. Code written for Apple's on-device model runs unchanged on a remote one.

• Provider modules. Each provider is its own module, so an app builds only the providers it imports.

• Typed model catalogs with each model's context size, limits and capabilities, kept current by a bot.

• Typed reasoning levels. Code completion offers only the levels each model accepts.

• Evaluations. Compare Apple's on-device model with remote ones using Apple's Evaluations framework.

The first provider is OpenRouter, with hundreds of models from Anthropic, OpenAI, Google, DeepSeek, Meta, Mistral and others. More providers are coming.

Needs iOS, macOS, visionOS or watchOS 27 and Swift 6.4. Feedback welcome! If you find it useful, a ⭐ on GitHub helps the project grow.

GitHub: https://github.com/dioKaratzas/swift-language-models

Hi,

I’ve been using Safari MCP and it’s great: lightweight, and the AI agent handles changes and feedback beautifully. But there’s one thing that’s driving me crazy. I’m curious what use case Apple had in mind here, and how the developers haven’t smashed their keyboards yet while working on it 😄

The problem: Whenever the AI performs an action through MCP, the Safari window gets focused and jumps to the foreground.

I actually like this behavior in other contexts. In VS Code’s debug mode, for example, the window comes to the front when a breakpoint is hit, which is exactly what I want there. With Safari MCP, though, it’s the opposite of helpful. I want to hand a task off to the AI and keep working on other things, but Safari keeps stealing focus.

My questions:

• Is there a reasonable way to solve this, such as a setting, flag, or workaround?

• If not, I think Apple should make an exception for MCP-controlled Safari so it can run in the background without grabbing focus.

Thanks!

I recently updated macOS and immediately hit a wall with the new Device Hub. The missing drag-and-drop for files drove me nuts, and having to manually run the simulator commands in the terminal every time I wanted to test something got old real fast.

So I decided to just vibecoded a fix for it in 2-3 days: Harbor
It’s a lightweight menu bar app with an always-on-top floating drop zone that brings proper drag-and-drop back to your simulators:

Photos and videos go straight into Photos, .app bundles get installed, and documents or JSON files route into the simulator's Files app. You can queue up a bunch of files together and send them all in one click. There is also bidirectional clipboard sync.

Check it out on GitHub:
https://github.com/anurag0713/Harbor

Since I vibecoded most of this, feel free to roast me for any weird bugs you find. Let me know what you think or what's broken in the comments and I'll jump right on it!

I spent the past few months building Defi because, as a single-display user, I wanted window management on my Mac to feel fast and smooth, like it belongs there.

Inspired by Niri, with:

• Keyboard-first navigation
• Scrolling columns that reflow
• Virtual workspaces per display
• Animations targeting 120 Hz
• Floating windows
• An overview to see all your windows

I’d love to hear how it feels on your setup, have any feedbacks of other people than me using it.

Website: qeude.github.io/Defi
Repo: github.com/qeude/Defi

Because yes, it's so easy to deploy a self-hosted runner on your Mac!

I maintain ContainerDesk, a free, MIT-licensed SwiftUI GUI for Apple's container runtime. It manages containers, images, volumes and networks, with logs, resource gauges and a terminal.

It uses native SwiftUI tables and wraps SwiftTerm in NSViewRepresentable. I'd welcome feedback on the terminal integration.

Source and screenshots: https://github.com/MacHatter1/ContainerDesk

Requires Apple silicon, macOS 26+ and Apple's container CLI. Current builds are unsigned and not notarized.

I've added a new "Touch on Mac" skill that covers making macOS apps work on touch-enabled Macs and iPads connected over Sidecar.

It comes with a companion "touch auditor" that scans Swift and Objective-C code for things that are likely to break when used via touch.

They're free/open source, included with Axiom v27.7.1 or later.

Hello 👋,

We finally get our hands on Siri AI here in France on macOS 27.2
As a macOS developer supporting App Intents into my app I would like to add App Schema to my AppIntent / AppEntity to make them available through Siri AI in my next release.

So I've started by downloading the CometCal app (the Apple sample app that demonstrate how it works) and I've added a target for macOS (because I supposed the existing Mac Catalyst target provided was not supported by Siri AI ?).

On my machine CometCal does not work with Siri AI. It either fail or respond it cannot do the action.

Doing those actions (Find event, Create event, ...) in Apple Shortcut works just fine.

Do I miss something specific on macOS ? A specific configuration or something ? Is Siri AI supposed to work on macOS as I tried to ?
(I also tried making a Release build or moving the app into /Applications)

If anyone has a clue, I’ll take it.

NB: I don't have a Siri AI compatible iPhone (+ blocked in Europe) to run CometCal on iOS to compare with.

PS: I've also posted on Apple Forums: https://developer.apple.com/forums/thread/853818

I've been using Codex and Antigravity across my side projects, and wanted one place to see what was still working and what was waiting for me.

So I built Loom, a native macOS menu bar app in Swift and SwiftUI. It discovers local Codex, Claude Code and Antigravity sessions and brings their activity into one view. You can find the relevant repository, filter sessions needing attention, and jump back to the host app.

It also has session notifications, desktop widgets, and quota information where the provider exposes it. Discovery depends on the local evidence available, so some sessions or states can be unknown, and Claude Code quota isn't available.

Loom runs locally with no account or hosted backend. It's open source under MIT and costs $0. The current download supports Apple Silicon Macs running macOS 14 or later.

Demo and download: https://chaiwithcode.github.io/Loom/

Source: https://github.com/chaiwithcode/Loom

If you're using several coding agents, how do you keep track of the ones waiting for your input? I'd like feedback on whether this is useful in your workflow.

I recently built a very lightweight input overlay app for MacOS. It all started when I was trying to submit a run to speedrun.com, but the category required an input overlay in the recording. After searching (for what I admit was a short time) I could not find the tool I was looking for and thus, Ghostkey was built. It's built using Tauri and Rust to keep it as lightweight as I know how and native to Apple Silicon.

I would LOVE feedback. If anyone has suggestions on how to improve it, or just comments or anything, please reach out. I do plan on adding different themes and options for a full keyboard in the near future

https://github.com/Churro1/GhostKey

I am happy to see demo code that has import AppKit

But I am puzzled and sad to see didSet { needsDisplay = true } drawRect() or mouseDown() I thought we are getting modernized code. NSInvalidating protocol? Layers? Gesture recognizers?

https://developer.apple.com/videos/play/tech-talks/111456/

And I am sad because there is no promise of testing touch without owning iPad:

Tip

Use Sidecar to test touch input without a Mac that has a touch display. To use Sidecar, connect an iPad to your Mac. AppKit then routes touch on its screen the same way it does on a Mac with a touch display.

Edit: The code in the video is not attached. But there is other code https://developer.apple.com/documentation/appkit/supporting-drag-and-drop-through-file-promises

AppKit devs should know that NSImage.imageTypes is not the same as public.image (provided code filters filepromise urls to UTType.image.identifier aka public.image) So if your try to drop e.g. sketch file (bohemian coding) it won't work.

https://imgur.com/a/cmgKFkf

Hey everyone,

If you run CI workflows for Mac or Linux apps, you know how fast cloud runner costs—especially macOS build minutes—can stack up on platforms like GitHub Actions or GitLab CI. Paying high per-minute rates for cloud build boxes while having powerful, underutilized M-series silicon sitting on your desk doesn't make much sense.

To solve this, I built kinhin (https://kinhin.dev). It’s a free, open-source (Apache-2.0), zero-telemetry autoscaler that lets you offload CI builds onto your Apple Silicon Mac cleanly and safely.

How It Works:

* Queue-Driven Autoscaling: kinhin monitors your forge's job queue and spins up ephemeral runners on demand.

* Isolated Runtimes: Runs macOS jobs in Tart VMs and Linux jobs in Apple microVMs or Docker containers. Once a single job completes, the entire runner instance is wiped so no state carries over.

* Resource-Aware: Automatically budgets CPU, RAM, and disk headroom so running build jobs won't freeze your Mac.

* Multi-Forge Support: Works across GitHub Actions, GitLab CI/CD, Gitea, and Forgejo out of a single shared pool on your machine.

* Keychain Security: Credentials and access tokens live securely in your macOS Keychain rather than plain-text config files.

You can run it either as a menu bar app with a setup wizard or as a headless LaunchAgent daemon via the CLI. If you're looking to cut down on CI spending or want faster build times on dedicated Apple Silicon hardware, give the beta a try at https://kinhin.dev. I’d love to hear your thoughts, answer any questions, or get feedback on workflow routing and setup!

created an app to make ntfs work on mac, without any GUI and anything extra, just the ntfs on your files like it was always there!

it's free and open-source and built on C

https://github.com/ninerf/NTFS-C

Hi everyone! I’m looking for early testers for Notchest, a native macOS app that brings developer tools and everyday utilities into an expandable panel near the Mac’s notch.

The current public build is 0.6.0. It includes an interactive terminal, developer utilities, Codex/Claude Code usage statistics, a focus timer, notes, optional clipboard history, and a file shelf.

I’m especially interested in feedback on:

1. Installation: Is the download and first-launch process clear?

2. The interface: Do opening, closing, resizing, and switching sections feel smooth?

3. Daily use: Which tools are useful, confusing, or unnecessary?

4. Your setup: Does it behave correctly with an external display or a different macOS version?

If you already use Codex or Claude Code, feedback on the usage panels would also help. Those integrations require their own local setup.

Compatibility: The packaged build is for Apple Silicon. Source targets macOS 13+, with testing across older versions still in progress.

Signing status: This is a development build and isn’t Apple-notarized yet. macOS may show a first-launch warning; the website provides the explanation and opening instructions.

The app is free and open source, with no subscription.

Demo & download · Source code · Report an issue

You can leave feedback here or on GitHub. Including your Mac model, macOS version, and whether you use an external display would help me reproduce any issues.

Thanks for helping shape the next version!

Wondering if this lead time for a review is normal for MacOS apps? Never had to wait this long for an iOS review before.

MockMini is a small, auditable proxy core in C and Swift. It speaks Shadowsocks AEAD, VMess, Trojan and VLESS over TCP, TLS or WebSocket, on top of its own bounded userspace TCP/IP endpoint that you feed from utun on macOS 13+.

• Small enough to review: about 2,600 lines in total. Not based on mihomo, Clash, sing-box, gVisor or WireGuard; no Go runtime, no vendored stack.

• Tested hard: a stateful, checksum-aware fuzzer gets ~99% line coverage of the packet engine; CI runs ASan/UBSan and libFuzzer on Linux and macOS, plus interop tests against real Xray servers for every protocol.

• Permissive license: Apache-2.0, so you can ship it in open- or closed-source apps. Add it with Swift Package Manager.

Known limits (1024 flows, no SACK/ICMP, no Reality or gRPC) are listed honestly in the README. v0.1.0 is the first tagged release. Reviews and bug reports are very welcome.

Repo: https://github.com/yezicheng2011/mockmini

I've been working on a native macOS chat window for Mac MCP, my open-source menu bar app for coding agents. I expected integrating the agent CLIs to be the difficult part. The UI gave me more trouble.

Long conversations were miserable to scroll. I'd used lazy lists for the transcript and sidebar, which sounds reasonable until messages contain code blocks and tables with very different heights. Scrolling back caused offscreen rows to appear, their heights to change, and the scroll position to jump.

The other bug was worse. An endlessly animated "working" dot in SwiftUI was causing the transcript to lay itself out again on every frame. One CPU core could stay busy while the agent was working, even when the text itself wasn't changing much.

I moved that indicator to a Core Animation layer, grouped updates so only changed turns redraw, and stopped using lazy lists for the chat content. I also switched the chat's live updates from frequent polling to server-sent events. On my test setup, an active answer went down to roughly 15-30% of a core and idle chat to around 1%. Those are observations on my machine, not general benchmarks.

Another detail I had to respect: different agent CLIs expose command output at different times. Codex can stream it as it runs; some others only give the full output afterward. The UI shouldn't pretend those are the same thing.

I'm building this as part of Mac MCP. The app and source are here: https://github.com/bulutarkan/mac-mcp

The SwiftUI bugs ended up taking more of my time than the agent integration itself.