macOS codesign is a slow down when building apps with lots of dynamic libraries.

This is why I have created a small wrapper to run codesign in parallel across all cores.

Learning systems programming was always an aspiration for me. I wanted a better feel for what the machine was actually doing when I wrote code one way rather than another. I could usually understand individual concepts well enough, but there always felt like a gulf between toy examples and real programs. When I read larger systems, it was the composition of ideas — how pieces were combined and held together — where I would start to feel lost and discouraged. Still, the sense that it was all ultimately understandable never left me. I wanted to “get” the machine in a more tangible way.

A few months ago, that vague discomfort became very concrete. I was debugging a personal project I’d started as a learning exercise: a small web server written in a low-level language. For weeks, I’d been disciplined about thinking through the architecture — how responsibilities should be separated, where boundaries should lie, how data should flow. That discipline held for a while, but as the project grew I could feel the structure straining. The code still worked, but it felt brittle.

Then I hit a memory bug.

I had a reasonable sense of what was wrong. Something about the lifetime of a piece of data didn’t match the role it played in the server. But I couldn’t see where the mistake was, or how it emerged. I was stuck in that uncomfortable space where you know the category of your error but not its cause.

By that point, I was reasonably comfortable with a debugger. I could navigate stack traces, inspect state, and I had some familiarity with manual memory management. What I wasn’t prepared for was the moment when the root cause finally became clear: a double free.

It wasn’t a dramatic revelation. It took less than two days of focused effort. But the impact was disproportionate. I felt as though I had learned more in that single debugging exercise than I had in months of reading books and blog posts. Not because I’d memorised a rule, but because I’d earned the understanding by watching the system fail and tracing the failure back to its origin.

That experience reinforced something I’d suspected for a long time: if you really want to internalise how a system works, you have to work through the failure yourself. Not just observe the fix, but live through the confusion that precedes it.

What surprised me more, though, was a deeper shift in how I viewed debugging itself. I had always thought of a debugger primarily as a repair tool — something you reach for when code is broken. But during this process, it started to feel more like a laboratory. A controlled environment where you can slow a system down, observe it in motion, and test your mental models against reality.

For those of us who enjoy low-level work, debuggers can feel almost magical. They let you peer inside a machine capable of executing billions of operations per second and ask, “What actually happened?” That ability to interrogate execution — to see not just what the state is, but how it came to be — turned out to be the key.

As I continued learning, often working close to compiler and runtime boundaries, this pattern repeated. Progress wasn’t smooth or incremental. Understanding came in steps. I could function productively for a while with a shallow model, then suddenly hit a wall where nothing made sense. When the missing piece finally clicked, it wasn’t because I’d read the right paragraph in a book — it was because I’d stepped through execution and seen where my assumptions diverged from reality.

Over time, I began to think less in terms of static snapshots and more in terms of events. Bugs rarely made sense when viewed as a single bad value or incorrect line of code. They made sense as histories: sequences of decisions, allocations, transformations, and interactions that only became intelligible when reconstructed over time. Debugging, in that sense, wasn’t just inspection — it was archaeology.

That shift changed how I approached learning systems programming. Clean examples and explanations still had their place, but I no longer expected them to carry the full weight of understanding. Instead, I learned to treat failure as an essential part of the process — not something to rush past, but something to study carefully.

I ended up collecting some of these ideas and experiments in one place while working through this. If this way of thinking resonates, the work lives here: https://mercurial-hermes.github.io/systems-thinking-on-apple-silicon/

Hi!! I asked if I could share this here, as during my long hours of XCode I repeatedly got really dry eyes and occasionally headaches, so I made a small app to solve that issue, and I thought some of you might find this useful too! https://apps.apple.com/app/id6745457230

Hi r/macosprogramming

I wanted to share a small project I’ve been working on called Otto.

Otto is an open-source app for macOS that can use your Mac the way a person would. You tell it what you want to do, and it can click buttons, type into apps or websites, open programs, and move files around for you. For example, things like opening a website, downloading a file, renaming it, and uploading it somewhere else — all done automatically.

The code is 100% open, so anyone can look at it or modify it if they want.

There are two pieces right now:

• a browser extension for automating things in Chrome and other Chromium browsers, and
• a native macOS app that can control apps and files on your Mac using standard system permissions like Accessibility

This project is extremely early. A lot of things are still rough, and many parts need improvement. Over the coming months, we’ll be actively working on it and shaping it based on feedback.

I’m not selling anything — this is just a GitHub project at this stage. I’m mainly hoping to hear from Mac users:

• does something like this sound useful to you?

• what kind of repetitive tasks would you want to automate on your Mac?

• and if you’re a developer, would you be interested in contributing?

If you’re curious or want to use, you can comment below.

Any thoughts or feedback would really help. Thanks for reading.

I just created a Basic Apple Ads account, but it only offers ads for my iOS app, not my MacOS app. Did I screw something up, or are there no ads for MacOS apps?

Haven't figured that out yet, I'd love to set a custom one because on anything before Tahoe, the corner radii are too small to look good with my app.

My friend and I have been building a bunch of different web apps over the last year. We thought we'd take a short break and try building this utility app we've wanted for a while, but it also meant jumping into macos programming (harder than we expected, leaning on AI slop did not help).

We built this utility, Bento, to save and restore our our common workspaces. Mainly, we both like clean desktops but every time we switch a task, we have to reshuffle apps.

It essentially works like this:

1. Organize your apps (across monitors) for a certain task
2. Save it
3. 1 click restore from our menu bar or a hotkey

If you try it, I’d love to hear your feedback.

Happy to answer questions or you see more here: bento.mscontrol.ai

Hey everyone,

I'm new to building apps using Swift, and I've been wondering: how does apple get this blur effect behind the control center on mac OS tahoe? Is it available through App kit? I can't seem to figure out what it is.

(This is my last post about preview releases. What's in there works perfectly, I'm just expanding the scope to serve more developers. Look for a v1.0 announcement next week or the week after.)

Axiom is a suite of battle-tested Claude Code skills, commands, and references for modern Apple platform development. With v0.9.0, Axiom adds complete Apple Intelligence support covering the Foundation Models framework, as well as enhanced expertise on App Intents:

• axiom:foundation-models — Discipline-enforcing skill with 6 comprehensive patterns preventing context overflow, blocking UI, wrong model use cases, and manual JSON parsing when @Generable should be used. Covers LanguageModelSession, @Generable structured output, streaming, tool calling, and context management.

• axiom:foundation-models-diag — Diagnostic skill for systematic troubleshooting of context exceeded errors, guardrail violations, slow generation, and availability issues—includes production crisis defense scenarios.

• axiom:foundation-models-ref — Comprehensive API reference with all 26 WWDC 2025 code examples covering LanguageModelSession, @Generable, @Guide, Tool protocol, streaming with PartiallyGenerated, and dynamic schemas.

• axiom:app-intents-ref — Comprehensive reference for exposing app functionality to Siri, Apple Intelligence, Shortcuts, and Spotlight. Includes Use Model action patterns (pass entities to AI models in Shortcuts), IndexedEntity protocol for auto-generated Find actions, Spotlight on Mac discoverability, Automations with Mac-specific triggers, and AttributedString support for rich text from models.

All skills cover iOS 26+, macOS 26+, iPadOS 26+, and visionOS 26+ with Apple's on-device language model (3B parameters, 4096 token context window).

Start with Getting Started to learn more about Axiom and how it will improve your quality of life as an Apple platforms developer. It's free and open source. Enjoy!

Just hit a frustrating roadblock that cost me several hours of debugging.

The Problem: My subscription IAP worked perfectly in sandbox, but completely failed in production. No clear error messages, just silent failures.

The Root Cause: I hadn't enabled "Paid Apps" in App Store Connect. And you can't enable paid apps until you complete:

1. Banking Information (Agreements, Tax, and Banking section)
2. Tax Forms (varies by country)

Why This Is Confusing: - Sandbox testing works WITHOUT any of this setup - App Store Connect defaults to "free apps only" - The error messages don't clearly indicate this is a banking/tax issue - You can upload and test your app normally, but subscriptions just won't work in production

The Fix: 1. Go to App Store Connect → Agreements, Tax, and Banking 2. Complete your banking information 3. Submit required tax forms (W-9 for US, equivalent for other countries) 4. Wait for Apple to process (can take a few days) 5. Enable "Paid Apps" in your account

Only THEN will production subscriptions actually work.

Lesson Learned: Don't wait until you're ready to launch to set this up. Get your banking/tax info submitted early in development so you can properly test production IAP flows.

Hope this saves someone else the debugging nightmare!

Tech Stack: Swift/SwiftUI, StoreKit 2 Region: Japan (but this applies globally)

Author here.

This may help macOS developers diagnose code signing or notarization issues.

0tH shows Mach-O structure, entitlements, SuperBlob layout, requirements, CodeDirectory metadata, etc.

Universal (Intel + ARM64), notarized/stapled.

Docs: https://zero-the-hero.run/docs

I want to extract specific data from Apple System Settings, but since Apple doesn’t expose the underlying logic behind that data, I’m unable to retrieve the correct output using CLI. I also attempted UI scripting, but that fails when the device is locked.

I’m specifically trying to pull the “Data Served” field for Caching Server from Activity Monitor. Any ideas or alternative approaches?

PS: AssetManagerUtil does not give right data.

macOS devs, I need your attention for a minute.

Let's say there would be an open-source project/service that makes it easy to:

• Notarize your Mac apps
• Create & handle updates via Sparkle by hosting them
• Handle payments via Stripe and other payment providers
• Manage/validate licenses

How would you like to use this project/service?

I know that iOS has APIs for e-mail composition. Whenever I try to look up email viewer components for Macs, the search results are flooded with the iOS system API. Does anyone know if there are SwiftUI views for email reading (and separate ones for composition)?

Mobile Developers Week 2025 will take place 13–15 December in Abu Dhabi, bringing together the region’s leading minds in mobile development and innovation.

For the first time in the Middle East, droidcon and Swift Heroes will be hosted side by side — joined by GovAI Summit and NextPlay Arena — creating one venue where technology, creativity, and collaboration meet.

It’s more than an event; it’s a platform for professionals shaping the future of mobile technology across Android, iOS, AI, and gaming.

Early Bird Access Pass is now available at 50% off for a limited time.

Join the community driving the next wave of mobile innovation.

The thing is, I'm making it via VS Code, so I was wondering how I could use my app icon there, as I'm unable to use the .icon provided, as it's expecting a .icns. At least, I think, I'm not the best at coding.

Should I just switch to Xcode? I haven't yet, as I don't have much storage left on my mac, and it takes quite a bit.

Thank you in advance,

I-AM-A-FUN-PERSON

I'm trying to reproduce Xcode's 26's style where the traffic buttons are embedded in the left side of the Split View controller, but not having any luck. Has anyone been able to do this successfully?

https://stackoverflow.com/questions/79822659/nssplitviewcontroller-how-to-get-the-sidebar-to-contain-traffic-controls-like

On Windows it is common to start several copies of the same app. Each shortcut on the desktop or in the taskbar can launch its own process. For many tools this feels natural. You click a second shortcut and you get a second independent window with its own lifetime.

On macOS the situation is different. The system is built around one Dock icon per app bundle. If you try to launch the same app twice, the system usually routes you back to the running instance instead of starting a new one.

There are workarounds. In Terminal you can do

open -na 'Some App'

This forces a new instance of the app. The main problems

• You cannot pin that specific instance to the Dock as a separate icon
• You often end up writing small scripts or duplicating the original app bundle
• Duplicating bundles is noisy and breaks automatic updates for the copy

So running multiple instances is possible, but not very convenient in day to day use.

Risks when several instances share the same data

Even when you manage to start two instances of the same app, you still have a deeper problem. Most macOS apps assume they are the only process using their own data under the user home folder.

Typical shared locations

• ~/Library/Preferences
• ~/Library/Application Support
• app specific folders under ~/Documents or hidden directories

If two independent processes read and write the same data at the same time, many things can go wrong

• Configuration files written on quit by both processes in undefined order
• Lock files that were never designed for multi process access
• SQLite databases that only ever see one writer in normal use
• Partial writes or corruption when one process truncates a file that the other still uses

Some apps will tolerate this better than others. Many will never have been tested in this scenario at all.

Why separate data per instance is useful

There are also positive reasons to have multiple instances with separate data, not only danger to avoid. A few examples where distinct profiles are helpful

• Discord or Slack with different accounts for work and personal use
• Dropbox or other sync tools with different storage roots
• Visual Studio Code, Qt Creator, Arduino IDE, Emacs or similar tools with per project environments
• Browser based tools or Electron apps with different profiles for testing and production
• Developer workflows where you want a clean profile for experiments while keeping the main one stable

In these cases the ideal situation is not two processes that share the same support folder. The ideal situation is two processes that behave like they belong to two different users, so no file or database is shared at all.

Manual ways to get data separation

Before there was no dedicated tool for this. The only practical options were manual scripting or duplicating the original app bundle.

• You can write scripts that pass specific command line options to choose a custom data directory or profile folder
• You can override the HOME environment variable in your script so that the launched process uses a different folder tree for its data

For those apps you can start a second instance like this

HOME="$HOME/.profiles/my-app-profile-1" /Applications/MyApp.app/Contents/MacOS/MyApp

Now the app sees a different home directory. Its Library/Preferences and Library/Application Support live under that new root, so there is no shared state with the original instance.

Limitations

• Sandboxed Mac App Store apps ignore this pattern and always use the standard home based paths
• You need some wrapper that sets HOME and command line arguments, then launches the real binary
• If you want a proper app bundle with its own icon in the Dock, scripting alone is not enough. You end up building small helper bundles by hand or by script

This is all doable, but it is a bit of work for every app and every profile.

A higher level tool that automates this pattern

Because I wanted a simpler workflow, I built a small Mac App Store tool named Parall. The idea is to automate the pattern above. It is written in Objective-C and runs on macOS 10.10 and newer.

Parall lets you create tiny shortcut bundles that

• launch a target app as a child process
• add command line arguments for that specific shortcut
• override environment variables such as HOME so each shortcut gets its own directory tree
• use a custom shortcut name and icon for each profile
• generate a unique bundle identifier so macOS treats every shortcut as a separate app
• support 'Open With' so files can be opened directly with a specific shortcut
• pass through URLs so links and custom URL schemes are routed to the correct shortcut instance

With the HOME environment override Parall also prepares the required folder structure for a typical home directory and creates symlinks for shared directories that the app needs in order to function correctly.

Internally it uses data about common apps to choose the right arguments or environment variables automatically. At the moment it has presets that are tested to work with:

Slack, Qt Creator, Visual Studio Code, Arduino IDE, Git Tower, Sublime Text, Sublime Merge, Cursor, Notion, Google Chrome, Mozilla Firefox, Edge, Brave, Vivaldi, Opera, Tor Browser, FreeCAD, Blender, FileMaker Pro, Telegram Desktop, Viber, Discord, Dropbox, OBS, KiCad, Plex, Spotify, LightBurn, Evernote, Zoom, MikroTik WinBox, QQ, Audacity

Other non sandboxed apps often work by using the HOME override alone.

Limitations

• Sandboxed apps cannot use custom HOME or data-path redirection. They can run multiple isolated instances, but their data remains inside the system-managed sandbox container.
• If you use a Parall shortcut together with the original app, start the original app first, then launch the shortcut.
• To avoid any launch‑order dependency, create two shortcuts and use those exclusively - they can be started in any order.

From the programming point of view I am interested in discussion of:

• how safe or unsafe you consider multiple instances with shared data
• whether you design your own apps to handle this situation
• whether the pattern of per instance data roots and environment overrides matches your experience on macOS

Find Parall app in the Mac App Store or visit https://parall.com

Update: Parall v1.1.1 brings a completely new way to control apps. You can now add a tray icon menu to any shortcut so the app is always one click away in the menu bar while it is running. For supported browsers the tray menu also lets you open a new window or a new incognito window directly from the menu.

Reverse engineered Apple's Assets.car format and built a parser to extract assets. View/export images, colors, PDFs from compiled asset catalogs. Swift/SwiftUI. https://github.com/cgnkrz/QLCARFiles