Coder Legion - Recent posts tagged macos

Fine in Chrome, broken in Preview: two PDFKit gotchas for anyone who writes PDFs

Mon, 26 Oct 2026 00:16:01 +0000

This article was originally published on Hashnode: Fine in Chrome, broken in Preview. It is republished here with light edits.

Disclosure: we make LensUp's PDF editor, the browser tool where we ran into both bugs, so we have a direct connection to the product mentioned here. This write-up was drafted and edited with AI assistance; the bugs, test results and reproduction scripts come from our own testing, and the scripts are public so you can check every claim yourself.

We build a PDF editor that runs in the browser. It opens a PDF, lets you add text, a signature or a highlight, fill in form fields, and writes the result back as an incremental update. We checked every save with three renderers: pdf.js (Firefox and many web viewers), pdfium (Chrome) and poppler (most Linux tools). All three were happy.

Then we rendered the same files with Apple's PDFKit, the engine behind Preview on the Mac, the Files app on iOS and PDFs in Safari. It showed two problems none of the others did: a translucent highlighter that turned into an opaque bar or a sentence that vanished, and form answers printed twice on top of each other.

Neither problem shows up if you only test on Linux or in Chrome. Here are both, with small scripts that reproduce them on any Mac in a few seconds: github.com/ppop123/pdfkit-pitfalls.

Gotcha 1: an incremental update must use the same cross-reference form as the file it updates

Some background

An incremental update appends to a PDF instead of rewriting it. The new and changed objects go at the end, followed by a new cross-reference section that points back to the previous one. That's how signed PDFs stay signed, and it's why saving an edit doesn't mean rewriting the whole file: only the edit is written.

The cross-reference section comes in two forms. The classic one is an xref table followed by a trailer. PDF 1.5 added cross-reference streams (/Type /XRef), which usually come with object streams (/Type /ObjStm): many small non-stream objects compressed together into one stream.

We opened files for incremental update with pdf-lib (the @cantoo/pdf-lib fork, which supports incremental updates) and saved with the defaults, which turn object streams on. So whatever the original file used, our update ended in an XRef stream, with our new dictionaries packed into an object stream.

What PDFKit does with that

Take a one-page PDF that ends in a classic xref table and append a highlighter stroke: a yellow rectangle drawn through an ExtGState with 60% opacity and the Multiply blend mode. Written as a table-based update, it renders the same everywhere. Written as an XRef stream with the ExtGState inside an object stream, poppler still draws it correctly, but PDFKit shows an opaque yellow bar where the sentence was.

Render it with CG_PDF_VERBOSE=1 set, and CoreGraphics says why:

encountered unexpected object type: 7.
missing or invalid object number.
missing or invalid cross-reference stream.

It gives up on the update's XRef stream. Objects the update wrote out on their own are still found: the rectangle itself is drawn. Objects inside the update's object stream are not, and the ExtGState is one of them. Without it the rectangle is painted fully opaque, on top of the text.

The reverse breaks too. Over an original that ends in an XRef stream, an update written with a classic table gets:

failed to find start of cross-reference section.
font `Helvetica-7098480789' not found in document.

This time it's the original's object stream that gets lost, and the font was in it. The highlight is there; the sentence is gone.

Original's last section	Update written as	PDFKit
`xref` table	`xref` table	fine
`xref` table	XRef stream with object streams	loses the objects in the update's object stream
XRef stream	`xref` table	loses the objects in the original's object streams
XRef stream	XRef stream	fine

In our editor's checks, pdf.js, pdfium and poppler accepted all four combinations. That's exactly why a Linux-only test suite never caught it.

The fix

Look at where the original's last startxref points. If it lands on the keyword xref, the last section is a table; otherwise it's a stream. Then write the update in the same form:

// The form of the original's last cross-reference section: 'table' or 'stream'.
function xrefForm(bytes) {
  const tail = new TextDecoder('latin1').decode(bytes.subarray(Math.max(0, bytes.length - 2048)));
  const found = [...tail.matchAll(/startxref\s+(\d+)/g)];
  const offset = found.length ? Number(found[found.length - 1][1]) : NaN;
  if (!(offset >= 0 && offset < bytes.length)) return 'table';
  let i = offset;
  while (i < bytes.length && /\s/.test(String.fromCharCode(bytes[i]))) i += 1;
  return new TextDecoder('latin1').decode(bytes.subarray(i, i + 4)) === 'xref' ? 'table' : 'stream';
}

const doc = await PDFDocument.load(bytes, { forIncrementalUpdate: true });
// … edit …
const saved = await doc.save({ useObjectStreams: xrefForm(bytes) === 'stream' });

Hybrid-reference files, whose trailer is a table that also points to an XRef stream, end in a table, so they count as 'table' here.

Gotcha 2: PDFKit draws filled text fields itself

What PDFKit does

A form field's look is supposed to come from its appearance stream (/AP): a small content stream in which the writer draws the value. For a text field that has a value, PDFKit does something else. It draws the value (/V) itself with CoreText, in the font named by the field's default appearance string (/DA), and it drops the text-showing operators (BT … Tj … ET) from the appearance stream. Everything else in the appearance stream it still paints, such as paths and Form XObjects.

You can see the first half even with pdf-lib's own appearance. In the first row below, poppler draws pdf-lib's auto-sized Helvetica, while PDFKit ignores it and draws its own rendering of the value at a different size.

Why that bit us

Our text engine shapes text itself (joining Persian and Arabic, ordering mixed-direction text, falling back between fonts) and draws the result as glyph outlines, so every reader shows exactly the same glyphs. In a field's appearance, those outlines are paths. PDFKit painted the paths and then drew /V again with CoreText on top: two copies of every answer, as in the second row. On a real IRS W-9 the two copies didn't even line up, because PDFKit left-aligned its copy while our appearance was right-aligned.

None of these stopped the second drawing: making the field read-only, setting /NeedAppearances to false, removing the /Tx BMC … EMC marked content, or changing the font or color in /DA.

The fix

Write the value as text after all, just not in a real font: use a Type 3 font whose glyph procedures are the same outlines. PDFKit drops text-showing operators, Type 3 included, and draws the value once in its own rendering. pdf.js, pdfium and poppler draw the Type 3 glyphs, which are our outlines. That's the third row.

The trade-off is that in Preview you get PDFKit's rendering of the value (its font from /DA, its alignment), not yours. For us that was acceptable, since CoreText shapes Persian correctly.

Two related notes:

Dropdowns and list boxes are different. PDFKit doesn't redraw them, so for choice fields we kept the outlines.
Acrobat had its own problem with outlines. Acrobat Reader drew our outline appearances in some forms but left the box blank in others (fields created by pdf-lib, with a /MK background color). It drew the Type 3 version in both.

Bonus gotcha from Acrobat: Reader extensions (`/UR3`)

Many official forms, the W-9 among them, carry usage rights (/Perms /UR3, "Reader extensions"): a signature over the file as issued. Change the file and Acrobat Reader opens it with:

This document enabled extended features in Adobe Acrobat Reader. The document has been changed since it was created and use of extended features is no longer available.

Every save changes the file, so on save we now remove /UR3 and the older /UR from /Perms (and /Perms itself if nothing else is left). A certification signature (/DocMDP) stays. iText does the same thing with removeUsageRights. To be clear about what we've checked: we saw the warning in Acrobat Reader, and we haven't re-tested the fixed files there yet.

How to test with PDFKit without clicking through Preview

PDFKit is scriptable from Swift in about twenty lines: open the file with PDFDocument, draw page 1 into a bitmap with PDFPage.draw(with:to:) (form widgets included), and write a PNG. Run it with CG_PDF_VERBOSE=1 and CoreGraphics prints what it didn't like. The repo's render-pdfkit.swift does exactly that. qlmanage -t, the Quick Look thumbnailer, goes through PDFKit too.

If you compare against pdfium from Python: pypdfium2 doesn't draw form fields unless you call pdf.init_forms() first. Without it, every field looks empty, which is easy to mistake for a bug in your writer.

Takeaways

Three renderers agreeing on a file doesn't mean the viewer on every Mac and iPhone will. If your PDFs reach Apple devices, render them with PDFKit, in CI on a macOS runner or at least by hand.
In an incremental update, match the cross-reference form of the file you're updating.
For a filled text field, PDFKit draws the value itself. Avoid drawing the value into the appearance as paths; text in a Type 3 font works everywhere we tested.

The reproductions, in Node and Swift, are MIT-licensed: github.com/ppop123/pdfkit-pitfalls.

About the author: the team behind this post builds LensUp Scanner, a free set of browser tools for scanning documents and working with PDFs. If you have seen other PDFKit quirks, the pdfkit-pitfalls repo is open to issues and pull requests.

The Sending Side of APNs: A Mac Push Tester with Keychain Certificates and URLSession Client Auth

Fri, 23 Oct 2026 12:31:01 +0000

Originally published at https://bestlatestapps.com/blog/the-sending-side-of-apns/

Finding push certificates in the Keychain, importing .p12 files, answering APNs's client-certificate challenge in URLSession, building the exact request (path, headers, payload), sandbox vs production, silent pushes, and reading APNs's error responses, all without a server

In my article on Push Notification – Client, I covered the device side of APNs: permission, registration, device tokens and showing what arrives. This is the other end of the pipe.

When you're building push notifications, the slowest part of the loop is often the sending side. The backend isn't ready. Or it's owned by another team, or every test means deploying a change to a server just to see whether a payload renders. Push Notification – Tester is my Mac app for skipping all of that. You choose a push certificate from Keychain, paste a device token, write a JSON payload, pick Development (sandbox) or Production, and send. There's no server dependency.

This article shows how a tool like that works under the hood. It's all standard Apple API: the Security framework to find identities, URLSession to authenticate with a client certificate over HTTP/2, and Apple's documented APNs request format. The protocol facts are taken from Apple's APNs documentation. Where I describe how I'd build something rather than the shipped app, I say so.

1. Two ways to authenticate with APNs, and why a tester uses certificates

APNs accepts two kinds of provider authentication:

Token-based (a .p8 signing key): you sign a short-lived JWT and send it in an authorization: bearer … header. One key works for all your apps.
Certificate-based (a push certificate, often exported as .p12): the TLS connection itself proves who you are, using a client certificate.

Apple's docs show both. For a desktop testing tool, certificates have a practical advantage: developers already have them in their Keychain, and the whole authentication step happens in the TLS handshake. Nothing needs to be signed per request.

One consequence, straight from Apple's documentation of the request headers: the authorization: bearer <provider_token> header is for token auth only, and "APNs ignores this header if you use certificate-based authentication." apns-topic is still required: "In general, the topic is your app's bundle ID/app ID." Keep the two modes clearly separate in your code.

2. Finding push identities in the Keychain

An identity in Keychain terms is a certificate plus its private key, which is what TLS client auth needs. SecItemCopyMatching with kSecClassIdentity lists them. I'd filter to push certificates by their subject summary, which for APNs certificates names the push service and your bundle ID:

import Security
import Foundation

struct PushIdentity: Identifiable, Hashable {
    let id: String              // subject summary, also used as the display name
    let identity: SecIdentity
    var isProbablyPush: Bool { id.localizedCaseInsensitiveContains("Push") }
}

enum KeychainIdentities {
    static func all() -> [PushIdentity] {
        let query: [String: Any] = [
            kSecClass as String: kSecClassIdentity,
            kSecReturnRef as String: true,
            kSecMatchLimit as String: kSecMatchLimitAll
        ]
        var result: CFTypeRef?
        guard SecItemCopyMatching(query as CFDictionary, &result) == errSecSuccess,
              let identities = result as? [SecIdentity] else { return [] }

        return identities.compactMap { identity in
            var cert: SecCertificate?
            guard SecIdentityCopyCertificate(identity, &cert) == errSecSuccess, let cert,
                  let summary = SecCertificateCopySubjectSummary(cert) as String? else { return nil }
            return PushIdentity(id: summary, identity: identity)
        }
        .sorted { ($0.isProbablyPush ? 0 : 1, $0.id) < ($1.isProbablyPush ? 0 : 1, $1.id) }
    }
}

Sorting push certificates to the top and keeping the others is deliberate. Names vary by certificate type and era, and a tester that hides the one certificate you need is worse than one that shows a few extras.

3. Importing a .p12 file

The listing mentions ".p12 / .pem workflows". For a .p12 (PKCS #12), the Security framework does the parsing. SecPKCS12Import returns the identity inside, given the export password:

enum P12Import {
    enum Failure: Error { case wrongPassword, noIdentity, status(OSStatus) }

    static func identity(from data: Data, password: String) throws -> SecIdentity {
        let options = [kSecImportExportPassphrase as String: password] as CFDictionary
        var items: CFArray?
        let status = SecPKCS12Import(data as CFData, options, &items)
        switch status {
        case errSecSuccess: break
        case errSecAuthFailed: throw Failure.wrongPassword
        default: throw Failure.status(status)
        }
        guard let first = (items as? [[String: Any]])?.first,
              let identity = first[kSecImportItemIdentity as String] else { throw Failure.noIdentity }
        return identity as! SecIdentity      // CF type bridging: the dictionary value is a SecIdentity
    }
}

A clear "wrong password" message matters more than it looks. It's by far the most common failure when importing a .p12, and a generic error code makes people think the certificate itself is broken.

.pem files hold the certificate and key as text. The approach I'd recommend is to convert them to .p12 with openssl pkcs12 -export and import that. The import path then stays the same either way.

4. Answering the client-certificate challenge in URLSession

When URLSession connects to APNs, the server asks for a client certificate. You answer in a delegate method by building a URLCredential from the identity:

import Foundation

final class APNsClient: NSObject, URLSessionDelegate {
    private let identity: SecIdentity
    private lazy var session = URLSession(configuration: .ephemeral, delegate: self, delegateQueue: nil)

    init(identity: SecIdentity) { self.identity = identity }

    func urlSession(_ session: URLSession, didReceive challenge: URLAuthenticationChallenge,
                    completionHandler: @escaping (URLSession.AuthChallengeDisposition, URLCredential?) -> Void) {
        switch challenge.protectionSpace.authenticationMethod {
        case NSURLAuthenticationMethodClientCertificate:
            let credential = URLCredential(identity: identity, certificates: nil, persistence: .forSession)
            completionHandler(.useCredential, credential)
        default:
            // Server trust etc.: let the system evaluate Apple's certificate normally.
            completionHandler(.performDefaultHandling, nil)
        }
    }
}

Two notes:

Use a session-level delegate. The client-certificate challenge is a connection-level challenge, delivered to urlSession(_:didReceive:completionHandler:). There's also a task-level variant; implement the session one at minimum.
Don't override server trust. .performDefaultHandling for everything else means the system still validates Apple's server certificate. A testing tool is no excuse to disable TLS validation.

URLSession negotiates HTTP/2 automatically with servers that support it, and APNs requires HTTP/2 and TLS 1.2 or later. You don't need a custom HTTP/2 library.

5. Building the request: path, headers, payload

Apple's documentation spells out the request precisely: a POST to /3/device/<device token> on one of two hosts. I'd model it directly:

enum APNsEnvironment: String, CaseIterable {
    case development, production
    var host: String {
        switch self {
        case .development: "api.sandbox.push.apple.com"
        case .production:  "api.push.apple.com"
        }
    }
}

enum PushType: String, CaseIterable { case alert, background }

struct PushRequest {
    var environment: APNsEnvironment
    var deviceToken: String
    var topic: String                 // usually your bundle ID
    var pushType: PushType
    var payloadJSON: String

    func urlRequest() throws -> URLRequest {
        let token = deviceToken.filter(\.isHexDigit).lowercased()   // tolerate pasted spaces and <>
        var request = URLRequest(url: URL(string: "https://\(environment.host)/3/device/\(token)")!)
        request.httpMethod = "POST"
        request.setValue(topic, forHTTPHeaderField: "apns-topic")
        request.setValue(pushType.rawValue, forHTTPHeaderField: "apns-push-type")
        request.setValue(pushType == .background ? "5" : "10", forHTTPHeaderField: "apns-priority")
        request.setValue(UUID().uuidString.lowercased(), forHTTPHeaderField: "apns-id")

        let body = Data(payloadJSON.utf8)
        _ = try JSONSerialization.jsonObject(with: body)          // fail fast on invalid JSON
        guard body.count <= 4096 else { throw PushError.payloadTooLarge(body.count) }
        request.httpBody = body
        return request
    }
}

enum PushError: Error { case payloadTooLarge(Int) }

Each line maps to Apple's documentation:

Hosts. api.sandbox.push.apple.com is the development server and api.push.apple.com is production. A device token from a debug build only works against the sandbox, which is the single most common "my push never arrives" cause.
apns-push-type. It must "accurately reflect the contents of your notification's payload". It's required for watchOS and recommended for iOS, macOS, tvOS and iPadOS.
Payload size. Apple's docs say it's limited to "a maximum size of 4 KB (4096 bytes)", and must not be compressed. Checking it locally saves a round trip and a 413 response.
apns-id. It's optional, but setting your own UUID makes it easy to match a response to a request in your log.

6. Alerts, badges, sounds and silent pushes

The listing promises "Custom JSON payloads for alerts, badges, sounds, and silent content". I'd offer templates for each, since the shape of aps is where most mistakes happen:

enum PayloadTemplate: String, CaseIterable {
    case alert, badge, sound, silent

    var json: String {
        switch self {
        case .alert:  #"{ "aps": { "alert": { "title": "Hello", "body": "From my Mac" } } }"#
        case .badge:  #"{ "aps": { "badge": 3 } }"#
        case .sound:  #"{ "aps": { "alert": "Ding", "sound": "default" } }"#
        case .silent: #"{ "aps": { "content-available": 1 }, "refresh": "inbox" }"#
        }
    }
    var pushType: PushType { self == .silent ? .background : .alert }
}

The silent template follows Apple's "Pushing background updates to your app" guide: the aps dictionary contains only content-available, with custom keys alongside it, and the request uses apns-push-type: background with apns-priority: 5. The same guide warns that the system treats background notifications as low priority and "doesn't guarantee their delivery", and may throttle them. A tester should say that in the UI, so nobody spends an afternoon debugging a throttled silent push.

7. Sending, and reading APNs's answer

APNs replies with an HTTP status and, on failure, a small JSON body with a reason. Surfacing that reason verbatim is the most useful thing a tester does:

extension APNsClient {
    struct Outcome { let status: Int; let apnsID: String?; let reason: String? }

    func send(_ push: PushRequest) async throws -> Outcome {
        let (data, response) = try await session.data(for: try push.urlRequest())
        let http = response as! HTTPURLResponse
        let reason = (try? JSONSerialization.jsonObject(with: data) as? [String: Any])?["reason"] as? String
        return Outcome(status: http.statusCode,
                       apnsID: http.value(forHTTPHeaderField: "apns-id"),
                       reason: reason)
    }
}

And a human explanation for the common reasons, taken from Apple's "Handling notification responses from APNs":

Status / reason	What it means in practice
`200`	Accepted by APNs. Delivery to the device is a separate step.
`400 BadDeviceToken`	The token is invalid. Usually a sandbox token sent to production, or the reverse; Apple says to check "that the token matches the environment".
`403 BadCertificate` / `BadCertificateEnvironment`	The certificate is invalid, or doesn't match the server you chose.
`410 Unregistered` / `ExpiredToken`	"The device token is inactive for the specified topic", or has expired. Typically the app was deleted or the token changed; stop sending to it.
`413 PayloadTooLarge`	Over 4 KB.
`429 TooManyRequests`	Too many pushes to the same token. Apple says you can retry with a delay.

Apple's guidance is explicit that you shouldn't retry BadDeviceToken, DeviceTokenNotForTopic, Forbidden, ExpiredToken, Unregistered or PayloadTooLarge. A tester can turn that into a "fix this first" hint instead of a Retry button.

8. Real-world example: Push Notification - Tester

This is the approach behind Push Notification - Tester. The code above is written for this article, not the app's source.

At the time of writing, its Mac App Store listing shows:

Free, in Developer Tools
First released in June 2020
No ratings yet in the US store
Requires macOS 14.6 or later

How the listing maps to this article:

What the listing says	Where it's covered
"Select the push certificate directly from Keychain (.p12 / .pem workflows)"	Keychain identities and PKCS #12 import (sections 2–3)
"Send APNs pushes from your Mac with no server dependency"	`URLSession` client-certificate auth over HTTP/2 (section 4)
"Paste any device token and send in seconds"	Token clean-up and the request path (section 5)
"Target Development (sandbox) or Production environments"	The two APNs hosts (section 5)
"Custom JSON payloads for alerts, badges, sounds, and silent content"	Payload templates and silent-push rules (section 6)
"Perfect for verifying device tokens, validating certificates…"	Reading APNs's status and reason (section 7)

Pair it with its iOS sibling, Push Notification – Client, which shows the device token to paste and displays what arrives. Between the two, you can test both ends without a backend.

9. Before you trust a push test: a checklist

The environment matches the build. Debug and development builds use the sandbox; TestFlight and App Store builds use production.
The topic is the bundle ID the certificate was issued for.
apns-push-type matches the payload: alert for visible pushes, background (priority 5) for silent ones.
The payload is valid JSON, under 4,096 bytes, and not compressed.
Server trust is never disabled. Only answer the client-certificate challenge.
The reason string is read, and non-retryable errors aren't retried.
Silent pushes aren't expected to be guaranteed. Throttling is normal.
Certificates expire. Check the expiry date when you pick an identity.
For production backends, consider token-based (.p8) auth. Certificates are handy for testing, but tokens don't need yearly renewal.

Wrapping up

Sending a push is less magic than it seems: an identity from the Keychain, a credential in a URLSession delegate, and a POST to /3/device/<token> with four headers and a small JSON body. A good tester makes each step visible and turns APNs's terse reasons into plain advice, so the next time a push "doesn't arrive", you know within a minute whether it's the token, the environment, the certificate or the payload.

Try the app, or explore my other work:

Push Notification - Tester (Mac): https://apps.apple.com/us/app/push-notification-tester/id1516154713
Push Notification – Client (iOS): https://apps.apple.com/us/app/push-notification-client/id1516378834
All of my apps: https://apps.apple.com/us/developer/alok-singh/id1508795536
My portfolio: https://bestlatestapps.com/alok/

What's the strangest push-delivery bug you've chased? Share it in the comments.

— Alok Kumar Singh

Originally published at https://bestlatestapps.com/blog/the-sending-side-of-apns/

Best Mac mini for OpenClaw in 2026: Memory, Local Models and Prices

Thu, 22 Oct 2026 08:20:07 +0000

Originally published on the Macyou blog. Disclosure up front: I run Macyou, we rent dedicated Apple Silicon Macs. This post is about the hardware math for OpenClaw, which is the same whether the Mac sits on your desk or in a rack.

If OpenClaw talks to a hosted model such as Claude, GPT or Gemini, any Mac mini Apple sells today is enough, the base M6 with 16 GB included. Memory starts to matter only when the model runs on the Mac itself, and then it decides almost everything: which model fits, how much context it gets, and how fast it answers.

This post runs the numbers for every Mac mini configuration at the context length an agent actually needs, with US list prices after the M6 launch.

With a hosted model, any Mac mini will do

OpenClaw is a gateway. It holds your chat channels, tools, memory files and a browser for web tasks, and sends each turn to the model. With a hosted model the heavy work happens on the provider's servers, so the Mac only runs the gateway, a browser and macOS. The OpenClaw docs set an 8 GiB memory floor for their smallest local model recipe; a hosted model takes that load off the Mac entirely, so 16 GB leaves plenty of room.

If that is your setup, buy the cheapest Mac mini and stop reading. The rest is about local models.

With a local model, memory decides

An agent turn is not a chat message. OpenClaw sends its instructions, the tool list, memory and the conversation with every turn, so the model needs a long context window, and that context takes memory on top of the weights.

Two lines in the OpenClaw local models docs set the frame:

the managed llama.cpp recipes use a 64K context;
the docs advise against small or heavily quantized model variants.

So the question is not "does the model fit", it is "does the model fit with 64K of context and room for macOS".

The arithmetic

Weights in GB are parameters times bits per weight divided by 8. At Q4_K_M that is about 4.85 bits. Add about 15% for the runtime, add the KV cache for the context, and leave 3 GB for macOS. Generation speed follows memory bandwidth, because every token streams the weights it uses through the memory bus. Mixture of experts models read only their active experts per token, which is why they run faster than their total size suggests.

Here is the same arithmetic our Mac LLM calculator uses, small enough to check by hand:

# Memory and speed for a Q4_K_M model on Apple Silicon
BPW_Q4 = 4.85        # bits per weight for Q4_K_M, including GGUF overhead
RUNTIME = 1.15       # allocator and activations on top of the weights
OS_GB = 3            # left for macOS
EFF = 0.9075         # fitted on measured runs, base M4 and M5 Pro
PER_TOKEN = 0.00325  # fixed cost per token, seconds
MOE_READ = 1.3       # a mixture of experts model reads about 1.3x its active weights

def weights_gb(params_b, bpw=BPW_Q4):
    return params_b * bpw / 8

def needed_gb(params_b, kv_gb):
    return weights_gb(params_b) * RUNTIME + kv_gb + OS_GB

def tokens_per_second(read_gb, bandwidth_gbs):
    return 1 / (read_gb / (bandwidth_gbs * EFF) + PER_TOKEN)

# Qwen3.8 27B, dense, 64K context, M6 with 32 GB (170 GB/s)
print(round(needed_gb(27.8, kv_gb=4), 1))                  # 26.4 GB
print(round(tokens_per_second(weights_gb(27.8), 170), 1))  # 8.9 tok/s

# Qwen3.6 35B A3B, mixture of experts with 3B active, same Mac
print(round(tokens_per_second(weights_gb(3) * MOE_READ, 170)))  # 54 tok/s

The constants were fitted on measured runs on a base M4 and an M5 Pro, where the worst error was 4.6%. We have not measured an M6 yet, so the M6 figures below are estimates. Measured numbers and the raw JSON are on our benchmarks page.

What fits on each Mac mini at a 64K context

US list prices with the smallest SSD for each memory size (256 GB on the M6, 512 GB on the M5 Pro). Base prices from Macworld, memory upgrades from Daring Fireball, bandwidth from Apple's specifications.

Mac mini	US price	Memory bandwidth	Fits at 64K, estimated tok/s
M6, 16 GB	$899	153 GB/s	Llama 3.1 8B (26), Qwen 2.5 7B (27)
M6, 24 GB	$1,099	170 GB/s	Gemma 4 26B A4B (44), Qwen 2.5 14B (16)
M6, 32 GB	$1,299	170 GB/s	Qwen3.6 35B A3B (54), Qwen3.8 27B (9), Gemma 4 26B A4B (44)
M5 Pro, 24 GB	$1,699	307 GB/s	Gemma 4 26B A4B (71), Qwen 2.5 14B (28)
M5 Pro, 48 GB	$2,299	307 GB/s	Qwen3.6 35B A3B (85), Gemma 4 31B (14), Qwen3.8 27B (16)
M5 Pro, 64 GB	$2,699	307 GB/s	Llama 3.3 70B (6), plus everything above

Note the price context: the M6 starts at $899, up from $599 for the M4 generation, and Macworld found no refurbished M4 units in Apple's store in October. A lot of "Mac mini for OpenClaw" advice was written for the $599 machine.

Which one to buy

Hosted model only: the M6 with 16 GB, $899.
A local model on a budget: the M6 with 24 GB, $1,099, runs Gemma 4 26B A4B at about 44 tok/s.
The best value for a local agent: the M6 with 32 GB, $1,299, adds Qwen3.6 35B A3B at about 54 tok/s and Qwen3.8 27B with the full 64K context.
Headroom and speed: the M5 Pro with 48 GB, $2,299, reads memory at 307 GB/s, about 1.8 times the M6, fits Gemma 4 31B as well, and runs Qwen3.6 35B A3B at about 85 tok/s.

The wait before the first word

Generation speed is only half of an agent turn. Before the first word, the Mac has to process the whole prompt. On a base M4 we measured prompt processing at 531 to 1,720 tok/s for models from 3B to 14B (Ollama, July 2026). At 600 tok/s, every 10,000 new tokens of instructions, tools and history add about 17 seconds before the reply starts.

The llama.cpp server keeps the part of the prompt it has already processed and evaluates only what changed since the previous request, so later turns cost less as long as the start of the prompt stays the same. Prompt caching is on by default; the context size is a flag:

llama-server -m ./models/your-model-Q4_K_M.gguf -c 65536 --port 8080

Mac mini or Mac Studio

The Mac mini stops at 64 GB. At the same 64K context, Qwen3.8 Flash Next needs about 131 GB and DeepSeek V4 Flash about 225 GB, which means a Mac Studio with an M5 Ultra and 256 GB. The M5 Max Mac Studio goes up to 128 GB.

A Mac mini you already own

An M1, M2 or M4 Mac mini runs OpenClaw with a hosted model as well as a new one. For local models the same memory rules apply at lower speed: Gemma 4 26B A4B comes out at about 33 tok/s on an M4 with 24 GB, against about 44 on an M6 with 24 GB.

FAQ

Is 16 GB enough for OpenClaw?

Yes with a hosted model. With a local model at a 64K context, 16 GB holds only 7B and 8B models, and 24 GB is where Gemma 4 26B A4B fits.

How much memory does OpenClaw need?

The model decides, not the gateway. A hosted model needs no model memory on the Mac. A local model at a 64K context needs about 10 GB for Llama 3.1 8B and about 27 GB for Qwen3.6 35B A3B, plus room for macOS.

Mac mini M4 or M6 for OpenClaw?

With a hosted model the chip makes no practical difference. For local models the M6 reads memory faster, 153 GB/s with 16 GB and 170 GB/s with 24 or 32 GB, against 120 GB/s on the base M4.

Does the same apply to Hermes Agent?

Yes. Hermes Agent from Nous Research installs on macOS, Linux and Windows and works with hosted models or your own endpoint. Pointed at a local model on a Mac mini, it needs the memory in the table above.

Conclusion

With a hosted model, any current Mac mini runs OpenClaw; the 16 GB M6 is enough.
With a local model, budget memory for the 64K context, not just the weights.
24 GB is the first size that fits Gemma 4 26B A4B at that context.
32 GB adds Qwen3.6 35B A3B and Qwen3.8 27B, the best value for a local agent.
The M5 Pro with 48 GB buys about 1.8 times the bandwidth of the M6.
Prompt processing is the hidden wait in agent turns; keep the start of the prompt stable so the cache helps.
Above 64 GB, the answer is a Mac Studio.

Fake Zoom Mac Installer Skips Gatekeeper, Steals Data

Fri, 09 Oct 2026 22:46:10 +0000

What Happened: A Fake Zoom Installer on macOS

Jamf, a leading provider of Apple‑focused security solutions, recently uncovered a malicious installer masquerading as the official Zoom client for macOS. The installer is distributed through unofficial channels and is deliberately crafted to look identical to Zoom’s legitimate download page. When a user runs the package, the malware performs a “double installation”:

Legitimate Zoom binary – The real Zoom client is installed in the expected location, allowing the user to join meetings without suspicion.
Hidden infostealer – A second payload is dropped alongside Zoom. This component silently monitors the system, captures credentials, browser cookies, and other sensitive data, then exfiltrates the information to a command‑and‑control (C2) server controlled by the attacker.

Jamf’s analysis notes that the installer “uses a sneaky way to bypass Apple’s Gatekeeper protection against malware.” By exploiting a weakness in the notarization process, the malicious package is allowed to run without triggering the usual warnings that macOS users rely on.

Technical Breakdown of the Gatekeeper Bypass

Gatekeeper is Apple’s first line of defense against unsigned or malicious software. It checks that an app is notarized by Apple and that its code signature matches the published hash. The fake Zoom installer sidesteps these checks through a combination of techniques:

1. Dual‑Package Wrapper

The malicious DMG contains two separate installer bundles:

Zoom.pkg – A properly signed Zoom package downloaded directly from Zoom’s official servers. Because it is notarized, Gatekeeper passes it without issue.
Stealer.pkg – An unsigned, malicious package that is embedded inside the same DMG but is not directly presented to Gatekeeper. Instead, the installer script extracts and runs it after the legitimate Zoom.pkg finishes.

2. Post‑Installation Script Abuse

During the Zoom installation, a post‑install script is executed with elevated privileges. The script performs the following steps:

Verifies the integrity of the Zoom binary (a decoy check that always succeeds).
Copies the hidden stealer payload to /Library/Application Support/Zoom/ where it blends in with legitimate Zoom files.
Registers a launch daemon (com.zoom.helper.plist) that runs the stealer at login, ensuring persistence.

3. Code‑Signing Spoofing

The attacker re‑signs the stealer payload with a self‑generated certificate that mimics Zoom’s developer ID. macOS treats the certificate as valid for the duration of the installation, but the signature is never verified against Apple’s notarization service because the payload is never submitted for notarization.

These tactics collectively allow the malicious code to “fly under the radar” of Gatekeeper, a scenario reminiscent of the Zoom annotation flaw that was recently patched after an AI‑prompt exploit. For more context on how Zoom’s attack surface is being weaponized, see the detailed coverage here: https://ltdeveloperblogs.github.io/posts/zoomsday-hack-uncovered-using-fewer-than-20-ai-prompts.

Why It Matters for Users and Enterprises

Erosion of Trust in Trusted Platforms

Apple markets macOS as a secure ecosystem, and Gatekeeper is a cornerstone of that promise. When a widely used application like Zoom becomes a vector for stealthy malware, the perceived safety of the platform erodes. Users may become reluctant to install legitimate software, slowing productivity and increasing support overhead.

Data‑Theft Risks

The infostealer is capable of harvesting:

Credentials – Saved passwords from browsers, keychains, and VPN clients.
Corporate Information – Documents stored in local folders, meeting recordings, and shared drive links.
Session Tokens – Tokens for cloud services (e.g., Microsoft 365, Google Workspace) that can be reused for lateral movement within an organization.

A successful breach can lead to credential stuffing attacks, ransomware deployment, or espionage. Enterprises that rely on Zoom for remote collaboration are especially vulnerable because the legitimate Zoom client provides a convenient foothold for the attacker.

Compliance Implications

Many regulated industries (healthcare, finance, government) must demonstrate that they protect personal data under standards such as HIPAA, GDPR, or PCI‑DSS. An undetected infostealer could constitute a violation, resulting in fines and reputational damage.

Industry Impact and Response

Vendor Reaction

Zoom has issued a statement confirming that its official installers are safe and urging users to download only from the official website. The company is also reviewing its distribution channels to detect and block repackaged installers.

Apple, for its part, is expected to release an emergency update to Gatekeeper that tightens verification of nested installers. Historically, Apple has responded quickly to similar threats—recall the rapid patch cycle after the “XcodeGhost” incident in 2015.

Security Community Mobilization

Jamf’s disclosure has sparked a wave of analysis across the security community. Researchers are scanning popular download mirrors, third‑party app stores, and even corporate intranets for the same DMG hash. The incident also underscores the importance of endpoint detection and response (EDR) solutions that can spot anomalous post‑install scripts.

Broader Market Trends

The attack highlights a growing trend: malware that piggybacks on trusted software. As users become more security‑aware, attackers increasingly rely on “double‑installation” tactics to blend in. This mirrors the tactics seen in the Chinese Auto Giant Moves to Apple Wallet Car Keys article, where attackers attempted to exploit Apple’s ecosystem in the automotive domain. For a broader view of how Apple’s ecosystem is being targeted, see: https://ltdeveloperblogs.github.io/posts/yet-another-major-chinese-car-brand-is-preparing-to-support-car-keys-in-apple-wallet.

Mitigation and Best Practices

Immediate Steps for End Users

Download Only From Official Sources – Always obtain Zoom from https://zoom.us/download or the Mac App Store.
Verify Checksums – When a DMG is provided, compare its SHA‑256 hash with the value published on Zoom’s website.
Enable Full Disk Encryption – FileVault adds a layer of protection if the infostealer attempts to read unencrypted data.

Enterprise‑Level Controls

Application Whitelisting – Use macOS’s built‑in spctl tool or a third‑party MDM to allow only signed, notarized Zoom binaries.
Enable Gatekeeper Strict Mode – Administrators can enforce the --strict flag via spctl --master-enable --global-policy to reject any app that isn’t notarized, even if it’s bundled inside a signed installer.
Monitor Launch Daemons – Regularly audit /Library/LaunchDaemons/ and ~/Library/LaunchAgents/ for unexpected com.zoom.* plist files. The malicious installer registers a daemon named com.zoom.helper.plist; its presence outside of Zoom’s official documentation is a red flag.
Leverage Endpoint Detection & Response (EDR) – Deploy EDR rules that trigger on the creation of files in ~/Library/Application Support/Zoom/ that are not part of the official Zoom bundle, or on the execution of unsigned binaries from that directory.

Read the full breakdown originally published at https://ltdeveloperblogs.github.io/posts/this-fake-mac-zoom-installer-has-a-sneaky-way-to-bypass-gatekeeper/

Why Real-Time AI Face Swap Is Moving Beyond the Local GPU

Mon, 28 Sep 2026 20:00:30 +0000

A few years ago, “real-time face swap” usually implied a local setup: download the model, install the right runtime, make sure CUDA works, and hope the GPU has enough headroom to keep up with a webcam.

That model still makes sense for some users. But it is no longer the only practical architecture.

The more interesting change is that real-time AI video is starting to resemble another category developers already know well: modern LLM products.

The user interacts locally. The expensive model inference happens somewhere else.

We already accepted this architecture for LLMs

Running AI locally is not new, and smaller language models can work well on consumer hardware. But many of the most capable LLM products are delivered as cloud services for a simple reason: large models are expensive to keep in memory, expensive to run, and expensive to update across millions of different client machines.

So the browser or app does not try to become the entire AI stack.

It handles interaction, input, rendering, and some lightweight client-side logic. The heavy inference stays on infrastructure designed for it.

That separation gives the provider a controlled runtime and gives the user access to models that may not fit comfortably on their own machine.

Real-time AI video is moving in the same direction.

Local inference was the obvious starting point

For live video, local inference has one major advantage: no network round trip.

A simplified local pipeline looks like this:

camera
  -> local preprocessing
  -> local GPU inference
  -> output

That is attractive when latency is the dominant constraint and the user already has suitable hardware.

But productizing that architecture means inheriting the hardware diversity of every user:

different GPU vendors and generations;
different VRAM limits;
driver and runtime differences;
CUDA or alternative backend compatibility;
laptops with integrated graphics;
Macs with a completely different acceleration stack;
other GPU-heavy applications competing for the same resources.

For an open-source tool or a technical user who wants full control, that trade-off can be completely reasonable.

For a product aimed at ordinary users, it becomes a support problem as much as an inference problem.

Cloud inference changes who owns the hardware problem

Move the main model off-device and the pipeline changes:

camera
  -> encode
  -> network
  -> cloud GPU inference
  -> network
  -> decode / render

The GPU did not disappear. It changed ownership.

Instead of every user needing hardware capable of running the current model, the service provider can run inference on a known GPU environment and manage the runtime centrally.

That has several practical consequences.

First, model deployment becomes much more predictable. The backend team controls the GPU type, drivers, inference runtime, and model version.

Second, upgrading the model does not require every user to download a new multi-gigabyte package or reconfigure their local environment.

Third, the client device can be much less specialized. A normal laptop can participate in the workflow as long as it can capture video, encode/decode it, and maintain a good enough network connection.

This is very similar to the LLM split: the edge device becomes the interaction surface, not the place where the largest model must live.

The hard problem moves from compatibility to latency

Cloud inference removes one constraint and introduces another.

A local system asks:

Can this GPU process frames fast enough?

A cloud system has to ask:

Can the entire round trip stay fast and stable enough?

The latency budget now includes more than model inference:

capture
  + encode
  + upload
  + scheduling
  + inference
  + return transport
  + decode
  + render

This is why a fast model does not automatically create a responsive real-time product.

A 50 ms improvement in inference may not matter much if network jitter occasionally adds 300 ms. Likewise, reducing network time will not help if GPU scheduling becomes the bottleneck during load spikes.

For developers, this is the architectural trade: cloud inference converts an edge-hardware problem into a distributed-systems problem.

That can still be a good trade if the product team is better positioned to manage infrastructure than the end user is to manage an AI workstation.

Real-time video makes this harder than text

The LLM analogy is useful, but real-time video raises the difficulty.

Text requests are discrete. A user sends a prompt and waits for output.

A webcam never stops producing input.

If the system falls behind, it cannot simply keep processing an ever-growing queue of old frames. The result may be technically correct but visually stale.

So a real-time cloud pipeline also has to care about things such as:

frame freshness;
bounded buffering;
network jitter;
reconnect behavior;
sustained throughput;
end-to-end delay rather than isolated inference time.

This is where real-time AI video stops looking like “call a model API” and starts looking like an interactive streaming system.

A practical example: LiveFaceSwap AI

LiveFaceSwap AI uses this cloud-inference approach for its main real-time AI workload.

The user can open the browser, select a camera, and start a live face-swap session without installing the AI model locally or configuring a dedicated NVIDIA GPU for inference.

The Desktop app adds a system virtual camera so the processed output can be used in software such as OBS, Zoom, or Teams, while the main AI inference still runs in the cloud.

From a developer perspective, that is the important part of the architecture: the local client owns capture, interaction, and output integration; the cloud owns the heavy AI workload.

It is not “GPU-free” face swap. It is local-GPU-independent face swap.

Cloud will not replace local inference

There are still strong reasons to run AI locally.

Local processing can be the better choice when:

data must remain on the device;
the application has to work offline;
the user already owns powerful hardware;
the model or runtime needs deep customization;
predictable local latency matters more than broad hardware compatibility.

Cloud inference is not a universal upgrade.

What is changing is the default assumption.

As real-time AI models become heavier, a product no longer has to require every user to own hardware that can run them. The provider can concentrate that compute in the cloud and expose the capability to much lighter clients.

We have already seen this pattern reshape how people use LLMs.

Real-time AI video is beginning to follow the same path.

Application Tres

Sat, 26 Sep 2026 16:36:35 +0000

Apple came up with a gesture I use dozens of times a day.
And didn’t add it to its own mouse.
So I had to build it myself.

I often read texts in languages that aren’t my native language. First it was English. Now it’s Portuguese.
On a MacBook trackpad, there’s a handy gesture: triple-tap a word to open its definition in the system Dictionary.
No context switching: word → definition → keep reading.

At my desk, I use an Apple Magic Mouse. It has a touch-sensitive surface too, but for some reason, this gesture doesn’t work.
That surprised me. The gesture already exists in macOS, Dictionary already exists, and Magic Mouse supports gestures. Why not just connect the dots?

That’s how "tres" was born.

"Três" means "three" in Portuguese.

Tres adds triple-tap support to Apple Magic Mouse and triggers the same native Dictionary lookup.
It behaves just like the trackpad gesture and works in any app where macOS supports Look Up: browsers, Preview, Notes, Mail, and more.

The app is free and open source.
You can install it directly or via Homebrew.
The official website: https://izebit.com/tres

On the first launch, you’ll need to give the app access under:

System Settings → Privacy & Security → Accessibility

Hope it makes your daily reading a little easier.

Keeping a Web-Backed SSH Terminal Alive Across SwiftUI Navigation

Sun, 09 Aug 2026 04:53:28 +0000

A desktop SSH client can keep the remote connection alive and still give the user the impression that the terminal was reset. The failure often sits one layer above SSH: the UI destroys and rebuilds the terminal surface when the user switches to another section.

That distinction matters when a macOS app embeds xterm.js in WKWebView. The SSH process, terminal model, WebKit process, DOM, scrollback, focus chain, and visible geometry all have different lifetimes. Treating them as one SwiftUI view makes normal navigation surprisingly destructive.

This article describes the design rules we ended up using in a native macOS SSH client.

Why rebuilding is not a harmless refresh

A straightforward SwiftUI implementation conditionally creates the selected section:

if selectedSection == .terminal {
    TerminalSurface()
} else {
    FilesView()
}

When the condition changes, SwiftUI is free to dismantle the terminal subtree. If that subtree owns a WKWebView, the app can lose much more than a view object:

the WebContent process and xterm.js DOM may be destroyed;
scrollback stored only in the browser process disappears;
alternate-screen applications such as vim, nano, or top cannot be reconstructed from plain text;
restoring a bounded output snapshot may omit older history;
WebKit initialization and snapshot replay add visible latency;
focus and resize events can arrive in a different order after reconstruction.

Keeping the SSH handle alive does not solve any of these UI-state losses. The remote PTY may still be healthy while the local terminal surface has forgotten how to represent it.

Separate four lifetimes

The useful mental model is to separate at least four things:

Logical session: the tab, server identity, name, working directory, and user-facing state.
Transport session: the SSH handle and remote PTY that carry input and output.
Terminal renderer: the WKWebView, xterm.js DOM, parser state, and scrollback.
Visible attachment: whether that renderer currently participates in the AppKit view hierarchy and responder chain.

Navigation should normally change only the fourth lifetime. Closing a tab can end all four. A network failure may replace the transport while retaining the logical tab and renderer. Conflating those transitions is where most of the surprising behavior begins.

Mount once, then deactivate

After the terminal section is opened for the first time, keep its SwiftUI subtree mounted. Other sections can still be created normally, while the terminal surface changes visibility and interaction state:

if terminalHasLoaded || selectedSection == .terminal {
    TerminalSurface(isActive: selectedSection == .terminal)
        .opacity(selectedSection == .terminal ? 1 : 0)
        .allowsHitTesting(selectedSection == .terminal)
}

This preserves the representable and its coordinator instead of asking SwiftUI to rebuild them on every sidebar click. The isActive value also gives terminal-specific shortcuts, toolbars, and event monitors an explicit lifecycle. Hidden terminal controls should not continue handling keyboard shortcuts while the user is working in Files or Settings.

Opacity alone, however, is not sufficient for a WebKit-backed terminal.

Preserve the WKWebView object, not necessarily its attachment

On macOS, an embedded WKWebView participates in AppKit focus, drag registration, and window behavior. Keeping it attached but transparent can leave side effects in sections that should have nothing to do with the terminal.

A more reliable arrangement is:

let NSViewRepresentable return a lightweight container;
let its coordinator hold a strong reference to the WKWebView;
attach the web view to the container only while the terminal section is active;
remove it from the hierarchy while inactive, without releasing the object;
attach the same object again when the user returns.

The WebKit object, WebContent process, xterm.js DOM, parser state, and scrollback stay alive even while the view is temporarily detached. The rest of the app no longer has an invisible WebKit view interfering with hit testing or drag sessions.

This is different from serializing terminal text and creating a new renderer. It preserves the renderer itself.

Hand focus back before detaching

Focus is a correctness issue for terminals, not just polish. If the window's first responder remains inside the web view during a section switch, later keystrokes can be delivered somewhere the user cannot see. In the worst case, a stray character is interpreted by the remote shell.

Before detaching an active terminal web view:

Check whether the window's first responder is the web view or one of its descendants.
Explicitly clear or move the first responder.
Remove the web view from its container.
Disable terminal-only keyboard monitors and shortcut controls.

When reattaching, restore focus deliberately after the container is visible. Avoid assuming that SwiftUI's appearance callback and AppKit's responder-chain update happen in the same frame.

Freeze hidden geometry

A hidden but mounted view can still receive geometry changes. If its width follows every animation in the visible section, xterm.js may repeatedly run fit(), and each result may resize the remote PTY.

That creates a subtle class of bugs: opening a file-transfer panel or animating another page changes the dimensions of a terminal the user is not looking at. Full-screen terminal programs then redraw against "ghost" sizes.

Record the terminal's last active width and freeze the inactive container at that width. On reattachment:

align the web view to the visible container once;
let the renderer's resize observer compute the new rows and columns;
send one meaningful PTY resize instead of a frame-by-frame storm.

The same rule applies to side panels: reserve their width only in the section that owns them, not at a shared ancestor that also sizes the hidden terminal.

Keep output flowing without flooding the UI

Detaching the renderer should not pause the SSH transport. Output can continue updating the logical session and renderer while the user visits another section.

High-volume PTY output needs its own boundary. Read callbacks can arrive hundreds of times per second, while sending every chunk through the main thread and WebKit IPC creates unnecessary contention. A practical policy is:

deliver sparse output immediately so typing echo feels instant;
merge continuous bursts into roughly one flush per display frame;
update the bounded recovery buffer before notifying the renderer;
keep session logs on a separate path from visual replay.

The recovery buffer remains useful if WebKit really crashes, but it is no longer the normal navigation mechanism.

Test transitions, not just steady states

The most valuable tests are sequences:

start top, switch to Files, resize the window, and return;
scroll far back, visit Settings, and confirm the same scrollback remains;
focus the terminal, switch sections, type immediately, and verify nothing reaches SSH;
open and close a side panel while the terminal is hidden;
disconnect while hidden, then return and exercise the reconnect path;
close a terminal tab while its web view is detached and confirm observers and script handlers are removed.

These tests cross SwiftUI, AppKit, WebKit, and SSH boundaries. A unit test around one layer will not reveal the ordering failures between them.

The broader rule

View visibility and resource lifetime are not the same thing. A terminal is a long-lived interactive resource with a UI surface, not a disposable page. Once the logical session, transport, renderer, and visible attachment have separate ownership, navigation becomes predictable: switching sections changes what the user sees without quietly rebuilding the tool they were using.

Developer disclosure: I work on Nexus Shell, a native macOS SSH workspace. This article is based on implementation and debugging lessons from that work, not a benchmark against other clients.

Editorial note: This draft was prepared with AI assistance and reviewed against the current SwiftUI, AppKit, WebKit, and SSH implementation before publication.

Most macOS malware is loud. PamStealer isn't, and that's a problem for how we detect it.

Thu, 02 Jul 2026 22:43:22 +0000

I want to start with an uncomfortable admission about how a lot of us detect macOS malware: we are betting it will be loud. Our behavioral rules watch for curl and zsh spawning under a user session, osascript reaching for security, a process tree that announces itself. That bet has paid off for years because commodity macOS stealers were noisy. PamStealer is a commodity stealer, and it took the bet apart on purpose.

It starts where every Mac user is most conditioned to comply. Someone installs what they think is Maccy, a clipboard manager, and gets a prompt: "Maccy wants to make changes." They type their password. Most infostealers grab whatever you typed and run. This one runs your password through PAM first -- the Pluggable Authentication Modules stack macOS uses to actually authenticate you -- confirms it is real, and only then decides you are worth robbing. That single check is why Jamf Threat Labs named it PamStealer, and it is a small, precise example of the thing that makes the whole sample worth your time: it does the detectable work through the operating system's own machinery, so the process chains you are watching for never show up.

Two labs independently tore this campaign down -- Jamf, who named it, and ManageEngine, who track it as "Fake Maccy Stealer." I will lean on Jamf for the deepest internals and flag where the two diverge, because a couple of the divergences matter.

Stage one: a dropper that skips the shell

Delivery is the familiar macOS pattern with a twist. A compiled AppleScript, Maccy.scpt, ships on a disk image from a lookalike domain (maccyapp[.]com) and opens in Script Editor. Inside is an obfuscated JXA (JavaScript for Automation) payload that does the download.

The twist is that it does not shell out for the fetch. A normal AppleScript downloader reaches for curl or zsh, and every one of those is a process spawn your rules watch for. This one stages the payload through NSURLSession and the Objective-C bridge -- native APIs, no subprocess for the network stage.

It is not processless, though, and this is the part the first wave of coverage got wrong. Before launch it ad-hoc signs the staged bundle:

codesign -fs - --deep /path/to/staged.app

That codesign process, spawned by Script Editor against a bundle in Application Support, is a detection opportunity, and both teardowns flag it. It also drops a .Maccy marker file and launches hidden, no window, no Dock. So the honest read is narrower than "no artifacts": it skips the download chain you key on and leaves other artifacts in its place.

It is also picky about targets. The dropper derives a key from a host fingerprint -- CPU architecture, locale, keyboard layout, time zone -- and the encrypted config only unlocks on a matching machine. ManageEngine notes those checks double as a CIS geo-fence: it aborts on hosts that look Russian or post-Soviet. Names and config values rotate sample to sample while behavior holds, which reads as an automated builder, not hand-editing.

Stage two: Rust, a framework loaded at runtime, and a very loud clipboard

The payload is a stripped, arm64-native Mach-O in Rust -- uncommon in a stealer scene Jamf notes is dominated by Swift, Go, and Objective-C. Most strings decode at runtime, so static triage gets you the linked libraries and the ObjC selectors and not much else.

The evasion move worth internalizing: instead of linking Security.framework, it loads it at runtime. Its keychain-access capability never lands in the static import table. If your triage leans on the load commands, you will not see it there. It bundles its own SQLite and reads browser credential, cookie, and wallet-extension databases as files directly, and it encrypts exfil with ChaCha20-Poly1305, so the traffic resists inspection even though the .config it drops holds the C2 URL in cleartext.

Then it gets loud. Running as a fake Finder, Jamf's sample read the clipboard by spawning pbpaste on a loop -- every 10 to 30 seconds, for the whole run. A process posing as Finder, out of Application Support, shelling out to pbpaste every few seconds is about the loudest signature in the chain. Here is the first divergence to hold: ManageEngine's variant did the same theft in-process through NSPasteboard with no subprocess at all, so that noise is Jamf's sample, not a law of the campaign.

The password, and why PAM beats dscl for the attacker

Back to the namesake. Jamf watched it show an NSAlert with a secure text field, styled like a real authorization request -- "Maccy wants to make changes," account name pre-filled -- and validate what you type through the PAM API (pam_start / pam_authenticate / pam_end).

Why that matters for detection is the whole point of the piece. Other commodity stealers confirm a captured password by shelling out; MacSync uses dscl. That dscl call is a process you can catch. A PAM check runs in-process and spawns nothing. One less chain in the tree.

Get it wrong and it re-prompts. Get it right and it throws a decoy -- "'Maccy' is damaged and can't be opened. You should move it to the Trash," a near-copy of the real Gatekeeper warning -- so you trash the lure and assume a bad download while it is already persistent. Persistence uses login items, modern and legacy (SMAppService and LSSharedFileList), and it deliberately avoids the LaunchAgents and LaunchDaemons where detection coverage is densest. It masquerades as Finder with the genuine icon and delays its Full Disk Access request, made under that disguise, by up to 40 minutes so the prompt does not line up with launch.

Line the choices up and the philosophy is consistent: JXA over the Objective-C bridge instead of curl, a runtime-loaded Security.framework instead of a linked one, a PAM check instead of dscl, login items instead of the LaunchAgents everyone watches, a permission prompt decorrelated from launch.

It doesn't erase its footprint. It moves the footprint to where the old detections weren't looking.

This is the pattern now, not the exception

Here is my actual position, and I will mark it as opinion rather than a vendor finding: this is where the low end of macOS malware is going, and that should bother you more than a single clever sample would.

macOS detection leaned for years on the tells of noisy malware because commodity stealers were noisy. PamStealer is commodity -- ManageEngine ties it to a malware-as-a-service pattern, per-host binary rotation and all -- and it is quiet in exactly the places those rules watch. The uncomfortable part is not that one crew got clever. It is that quiet-native tradecraft is showing up in automated-builder, spray-to-a-lookalike-domain malware, which is precisely where techniques stop being exotic and become the baseline. The detection stack we built assumed attackers would announce themselves. That assumption is now a liability, and it is a liability at the cheap end of the market, which is the part that scales.

What this does NOT solve

I try to end these with the honest part, because it is the part that separates analysis from a press release.

Going native does not make this thing invisible. It makes it quieter against one class of detection. Everything else is still on the table. Named caches under ~/Library/Caches/com.apple.finder.core/, a .config with the C2 in cleartext, a codesign spawn from Script Editor, login-item registration, and in Jamf's sample a pbpaste loop are all sitting right there. ManageEngine's sample still tripped a VirusTotal engine at first submission. The C2 still has to talk.

It also does not get past behavioral EDR that watches the right things instead of the loud things -- framework loads, process lineage, a Finder doing something Finder does not do. And it does not get around the root cause, which is human: the entire chain needs someone to download from the wrong domain, run a script they should not, and approve a prompt they should have questioned. "Train the users" has never closed that gap and never will, because installing a clipboard manager off a lookalike domain is a normal act in an environment that makes the fake and the real indistinguishable until it is too late.

And honestly, the analysis itself does not fully close. Jamf and ManageEngine independently tore down the same campaign and diverge on what PAM is even for: Jamf documents the validate-your-password-before-stealing workflow the name is built on, while ManageEngine describes the binary linking libpam and infers it could intercept sudo and system-auth responses. Both saw PAM; they emphasize different uses. The Ethereum JSON-RPC endpoints Jamf found in the decrypted server config, and the one it caught the malware connecting to, have an unknown purpose -- resilient dead-drop or wallet recon, Jamf did not capture the calls and did not guess. If someone tells you they know exactly what this thing does end to end, they are out ahead of the public evidence.

So where does that leave your detection?

If you want to hunt it, the artifacts that survive are the boring, reliable ones:

A login item or Background Task Management entry pointing at a Finder or Software Update bundle in a user directory (sudo sfltool dumpbtm)
A process named Finder running from anywhere other than /System/Library/CoreServices/Finder.app
Script Editor spawning codesign against a bundle in ~/Library/Application Support/
A "Finder" spawning pbpaste on a loop or reading a Chromium credential database
An ad-hoc - code signature where you would expect a Developer ID

But the artifacts are not really the argument. Here is what I actually want to know from anyone running macOS detection at scale: are your rules still keyed on shell spawns, or have you moved them to framework loads and process lineage? And be honest with me -- has behavioral detection ever caught one of these native-tradecraft stealers in your environment before the IOCs dropped, or is on-disk matching still doing the real work? I have a suspicion about the answer, and I would genuinely like to be wrong.

Originally published at blog.vertexops.org.

Signatures in macOS: Identity, Integrity & Trust

Thu, 21 May 2026 11:25:38 +0000

Every app on macOS carries a digital signature — and it’s more important than most people realize.

Here’s what signatures actually do:

✅ Identity — Confirms who created the app
✅ Integrity — Ensures the app hasn’t been modified or tampered with
✅ Trust — Helps macOS decide whether the software is safe to run

Apple’s code-signing system works alongside Gatekeeper and notarization to protect users from malicious software and unauthorized changes.

Why it matters for developers
• Prevents app tampering
• Builds user confidence
• Required for smoother app distribution on macOS
• Essential for enterprise and production apps

Security isn’t just about writing code — it’s about proving your code can be trusted.

Homebrew: el gestor de paquetes que todo usuario de Mac debería conocer desde el día uno

Tue, 14 Apr 2026 03:27:36 +0000

title: Homebrew: el gestor de paquetes que todo usuario de Mac debería conocer desde el día uno
published: true

tags: spanish, macos, terminal, productivity

Hay una herramienta que debería venir preinstalada en cada Mac que sale de fábrica.

No viene. Y nadie te avisa que existe hasta que llevas meses instalando software de la manera más lenta y tediosa posible.

Se llama Homebrew. Y cuando la descubres tienes exactamente dos reacciones: "esto es increíble" seguido inmediatamente de "¿por qué nadie me dijo esto antes?"

¿Qué es Homebrew?

Es un gestor de paquetes para Mac. En lugar de entrar a un sitio web, descargar el instalador, hacer clic en "siguiente, siguiente, siguiente, aceptar" y arrastrar el ícono a Aplicaciones — todo ese proceso se convierte en esto:

brew install nombre-del-programa

Un comando. El software queda instalado y listo.

Cómo instalarlo

Abre la terminal y copia esto:

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

Verifica que quedó bien:

brew --version
# Homebrew 4.x.x

Los comandos que vas a usar el 90% del tiempo

# Instalar herramienta de terminal
brew install git

# Instalar app con interfaz gráfica
brew install --cask iterm2

# Actualizar todo
brew update && brew upgrade

# Ver qué tienes instalado
brew list

# Desinstalar
brew uninstall nombre-del-paquete

# Limpiar archivos temporales
brew cleanup

El tip que cambia todo — Brewfile

# Guarda toda tu lista de paquetes
brew bundle dump

# En un Mac nuevo, instala todo de una vez
brew bundle install

Configuras un Mac nuevo en 10 minutos en lugar de un día entero. Eso solo ya justifica instalarlo hoy.

Artículo completo con todos los detalles, la lista de apps que instalo en cada Mac nuevo y cómo conectar Homebrew con tus dotfiles en CommandCat — contenido tech en español sobre macOS, Linux, productividad y cultura geek.

From 1.4s to 53ms: Optimizing zsh Startup on macOS

Wed, 11 Feb 2026 13:52:03 +0000

Every time I opened a terminal, I waited. Not long — maybe a second and a half — but long enough to notice. Long enough to be annoying. I finally decided to profile my zsh startup, and what I found took it from 1.4 seconds down to 53 milliseconds.

Here's what I learned.

Profiling with zprof

Zsh has a built-in profiler. Add zmodload zsh/zprof at the top of your .zshrc and zprof at the bottom, then open a new shell:

# top of .zshrc
zmodload zsh/zprof

# ... your config ...

# bottom of .zshrc
zprof

My initial profile told a clear story:

Culprit	Time	% of startup
NVM (`nvm.sh`)	~430ms	31%
Completion subprocesses (kubectl, helm, gh, ...)	~400ms	29%
`compinit` (full rebuild every time)	~240ms	17%
`brew shellenv`	~30ms	2%
`go env GOPATH`	~20ms	1%
Everything else	~280ms	20%

Four of these five are subprocess calls — things like eval "$(brew shellenv)" or source <(kubectl completion zsh) that fork a process just to produce some static text. That's the low-hanging fruit.

Optimization 1: Lazy-load NVM

NVM was the single biggest offender. Sourcing nvm.sh on every shell startup cost ~430ms, and I don't use node in every terminal session. The fix: wrapper functions that defer loading until you actually call nvm, node, npm, etc.

Before:

export NVM_DIR="$HOME/.nvm"
[ -s "/opt/homebrew/opt/nvm/nvm.sh" ] && \. "/opt/homebrew/opt/nvm/nvm.sh"
[ -s "/opt/homebrew/opt/nvm/etc/bash_completion.d/nvm" ] && \. "/opt/homebrew/opt/nvm/etc/bash_completion.d/nvm"

After:

export NVM_DIR="$HOME/.nvm"

_nvm_lazy_load() {
  unfunction nvm node npm npx corepack 2>/dev/null
  [ -s "/opt/homebrew/opt/nvm/nvm.sh" ] && \. "/opt/homebrew/opt/nvm/nvm.sh"
  [ -s "/opt/homebrew/opt/nvm/etc/bash_completion.d/nvm" ] && \. "/opt/homebrew/opt/nvm/etc/bash_completion.d/nvm"
}

nvm()      { _nvm_lazy_load; nvm "$@" }
node()     { _nvm_lazy_load; node "$@" }
npm()      { _nvm_lazy_load; npm "$@" }
npx()      { _nvm_lazy_load; npx "$@" }
corepack() { _nvm_lazy_load; corepack "$@" }

The wrapper functions replace themselves on first call via unfunction, then delegate to the real command. Cost at startup: zero. Cost on first node invocation: ~430ms (once).

Optimization 2: Hardcode static values

Several lines in my config were spawning subprocesses to compute values that never change:

# Before — subprocess every startup
eval "$(/opt/homebrew/bin/brew shellenv)"
export PATH="$PATH:$(go env GOPATH)/bin"
. "$HOME/.cargo/env"

These produce the same output every time. Just paste the result directly:

# After — zero subprocesses
export HOMEBREW_PREFIX="/opt/homebrew"
export HOMEBREW_CELLAR="/opt/homebrew/Cellar"
export HOMEBREW_REPOSITORY="/opt/homebrew"
export PATH="/opt/homebrew/bin:/opt/homebrew/sbin:$PATH"
[ -z "${MANPATH-}" ] || export MANPATH=":${MANPATH#:}"
export INFOPATH="/opt/homebrew/share/info:${INFOPATH:-}"

export GOPATH="$HOME/go"
export PATH="$PATH:$GOPATH/bin"

export PATH="$HOME/.cargo/bin:$PATH"

Leave a comment like # regenerate with: brew shellenv so future-you knows where the values came from.

Optimization 3: Cache completions into fpath

This was the big one. My original config eagerly sourced completions from 12 different tools on every shell startup:

# Before — 12 subprocesses, every startup
command -v kubectl  &>/dev/null && source <(kubectl completion zsh)
command -v helm     &>/dev/null && source <(helm completion zsh)
command -v minikube &>/dev/null && source <(minikube completion zsh)
command -v gh       &>/dev/null && source <(gh completion -s zsh)
# ... 8 more tools

Each source <(tool completion zsh) forks a subprocess AND evaluates thousands of lines of shell code. Minikube's completion alone is 5,000 lines.

The fix has two parts:

For completions: write them to files in an fpath directory. Compinit loads these lazily — only when you actually press TAB on that command:

ZSH_COMP_CACHE="$HOME/.zsh-completion-cache"
[[ -d "$ZSH_COMP_CACHE" ]] || mkdir -p "$ZSH_COMP_CACHE"

_cache_fpath() {
  local name="$1"; shift
  local cache_file="$ZSH_COMP_CACHE/_$name"
  local -a stale=($cache_file(N.mh+24))
  if [[ ! -f "$cache_file" ]] || (( $#stale )); then
    "$@" > "$cache_file" 2>/dev/null
  fi
}

command -v kubectl &>/dev/null && _cache_fpath kubectl kubectl completion zsh
command -v helm    &>/dev/null && _cache_fpath helm    helm completion zsh
# ... etc

fpath=($ZSH_COMP_CACHE $fpath)

For plugins that must run at startup (fzf keybindings, direnv hook, oh-my-posh prompt), cache their init output and zcompile for faster sourcing:

_cache_source() {
  local name="$1"; shift
  local cache_file="$ZSH_COMP_CACHE/$name.zsh"
  local -a stale=($cache_file(N.mh+24))
  if [[ ! -f "$cache_file" ]] || (( $#stale )); then
    "$@" > "$cache_file" 2>/dev/null
    zcompile "$cache_file" 2>/dev/null
  fi
  source "$cache_file"
}

_cache_source fzf fzf --zsh
_cache_source direnv direnv hook zsh
_cache_source oh-my-posh oh-my-posh init zsh --config ~/.poshthemes/theme.omp.json --print

Both functions use a 24-hour cache expiry via zsh glob qualifiers. Delete ~/.zsh-completion-cache to force a refresh.

I also cached compinit itself — a full rebuild only runs once per day, and otherwise compinit -C skips straight to the dump file:

autoload -Uz compinit
local -a zcompdump_stale=(~/.zcompdump(N.mh+24))
if (( $#zcompdump_stale )); then
  compinit
else
  compinit -C
fi
{ zcompile ~/.zcompdump } &!

The bug that almost ruined everything

After implementing all of this, I ran time zsh -i -c exit. The result: 1.59 seconds. Slower than before.

I profiled again and saw this:

num  calls                time            self            name
-----------------------------------------------------------------
 1)   15   1180.06  97.34%  1169.02  96.43%  _cache_completion
 2)    1     26.83   2.21%     7.49   0.62%  compinit

The caching function was taking 97% of startup time across 15 calls. The caches existed on disk but were being regenerated every single time. The staleness check was broken.

I restructured the approach — separating completions (fpath-based, lazy) from plugins (source-based, eager) — and tried again. Same problem: _cache_fpath at 72%, compinit doing full rebuilds.

The bug was in this line:

if [[ ! -f "$cache_file" || -n "$cache_file"(#qN.mh+24) ]]; then

This looks reasonable. The glob qualifier (#qN.mh+24) means "match if the file is older than 24 hours, with N (nullglob) to return empty string if no match." The -n test checks if the result is non-empty.

The problem: glob qualifiers don't expand inside [[ ]].

Zsh's [[ ]] conditional construct does not perform filename generation (globbing). The string "$cache_file"(#qN.mh+24) is treated as the literal path with (#qN.mh+24) appended as text. Since that string is always non-empty, the condition is always true. Every cache was being regenerated on every startup. The caching was doing nothing.

The same bug affected the compinit staleness check:

# Also broken — compinit was doing a full rebuild every time
if [[ -n ~/.zcompdump(#qN.mh+24) ]]; then

The fix: expand the glob into an array variable first, then check its length:

local -a stale=($cache_file(N.mh+24))
if [[ ! -f "$cache_file" ]] || (( $#stale )); then

Regular variable assignments DO perform globbing. The (N.mh+24) qualifier (no #q prefix needed outside [[ ]]) expands the glob, and $#stale gives us the match count. If the file is older than 24 hours, stale contains one element; otherwise it's empty.

This is a subtle footgun. The code looks correct, it doesn't produce errors, and the caches are created — they're just never reused. Without profiling, you'd never know.

Result

$ time zsh -i -c exit
zsh -i -c exit  0.03s user 0.02s system 93% cpu 0.053 total

53 milliseconds. A 96% reduction from 1.4 seconds.

Here's what each optimization contributed:

Optimization	Savings
Lazy-load NVM	~430ms
Cache completions into fpath (lazy compinit)	~500ms
Cache plugin init scripts + zcompile	~200ms
Hardcode brew/go/cargo	~50ms
compinit -C (cached dump)	~170ms
Total	~1,350ms

The first shell open after 24 hours takes a couple of seconds to regenerate caches, but every subsequent shell is instant. You can force a full refresh anytime:

rm -rf ~/.zsh-completion-cache ~/.zcompdump*

Takeaways

Profile first. zprof told me exactly where the time was going. Don't guess.
Subprocess calls add up. Each eval $(...) or source <(...) forks a process. Twelve of them cost almost a full second.
fpath > source for completions. Compinit loads completion functions lazily from fpath. Don't eagerly source thousands of lines you might never use.
Test your caching actually works. A cache that regenerates every time is worse than no cache — it has the overhead of both the generation AND the file I/O.
Glob qualifiers don't work inside [[ ]]. This is the kind of bug that looks correct, produces no errors, and silently destroys your performance. Expand globs into variables first.

Beyond rbenv and pyenv: Achieving Reproducible Dev Setups with Nix

Sun, 20 Jul 2025 18:59:08 +0000

Setting up a development environment is a painful process, as I discussed previously when detailing how mine evolved to the combination of home-manager and Ubuntu Make. Little did I know, the article gained significant traction and likely resonated with many fellow developers. Coincidentally, I got into a new job earlier in the month, and this necessitated a revision to the setup on a MacOS environment. How did it go? Turbulent would be an appropriate adjective to describe the whole experience, as you may expect.

From Dotfile Hacks to Open Source: My Development Environment Evolution

A cute illustration from Copilot

The macOS Catalyst: A New Job, A New Challenge

Replicating a development setup over multiple machines can be a hard problem, and ensuring it works on different operating systems significantly increases that complexity. As we delve deeper into the topic, you will see how I shoot myself in the foot repeatedly, and the corresponding steps to recover.

Why a Mac?

Photo by Claudio Schwarz on Unsplash

Before starting my new role, I was asked if I would prefer a Linux machine or a Mac for work. Though I am relatively comfortable with a Linux machine, I picked Mac as I reckoned it is easier to get enterprise apps whenever necessary. I also reiterated this same reason when my coworker and I were pairing up for a task.

Despite working mostly with Ubuntu, I do have a Intel iMac for video calls and functioning as a second screen for documentation and web project previews. A minimal home-manager setup worked mostly fine, and I assumed expansion of the setup for development would be as painless.

Oh, how wrong I was.

As the assigned MacBook Pro became my primary device for work, all the minor problems surfaced. First, my shells were not initialized properly in the terminal emulator. After getting that fixed, I got adventurous and decided to retire rbenv to manage Ruby versions. Coupled with the struggle to set up my code editor, I was amazed how my feet survived all the gunshots.

Diving into the Rabbit Holes: macOS and Interpreter Woes

How hard can it be?

Photo by Nachristos on Unsplash

If one is looking for a statement to best represent underestimation, that would be it. Looking back, the problems look very trivial, but each was a great learning opportunity. Hang on tight, as we are going into a deep dive into all the rabbit holes I fell into with the revised setup, and to learn how to overcome them.

Compared to Windows, macOS offers a more familiar environment for developers with experience in Linux. We can interact with the system through a similar command-line interface. With a package manager, we can even add different shells not shipped with the operating system, like my favourite fish shell. Trying to configure an iTerm2 profile for fish is exactly the first hole I fell into.

Why would macOS not source .profile in a graphical session?

Unlike Ubuntu, macOS does not source .profile in a graphical session. Most of the time, the script updates the PATH variable, making locally installed applications discoverable. Subsequently, shell initialization scripts (like .bashrc for bash and config.fish for fish) then set up individual application based on the environment defined in .profile.

Multiple variations was attempted, until I stumbled upon a Q&A on superuser. Thinking it would be useful, I sent the proposed answer to Gemini and asked if it would be applicable for my case. Turns out I only needed a little tweak.

/bin/sh -lc "exec -l /path/to/fish"

This is a breakdown of the command:

/bin/sh: This specifies that the command should be executed by the Bourne shell, launching a new instance of this basic shell.
/bin/sh -l: this tells the shell to launch as a login shell, ensuring it sources standard login files like .profile.
/bin/sh -c: This tells the shell to execute the command provided in the string that follows.
exec: This crucial command tells the shell to replace the current /bin/sh process with a new process (in this specific case, the fish shell).
exec -l: This tells the new shell (e.g., fish) to launch as a login shell itself.
/path/to/fish: This is the full path to your fish shell executable. With the -l flag in the exec command, this fish shell will then source its own login initialization configuration file (e.g., config.fish).

Similarly, the command can be adapted to work with byobu, my preferred terminal multiplexer. The -l flag is omitted for the exec command as byobu is not a shell.

/bin/sh -lc "exec /path/to/byobu new-session"

For completeness’ sake, the setup for a bash profile is a lot simpler, as it sources .profile and .bashrc properly when launched as a login shell -l itself.

/path/to/bash -l

What a ride.

Shifting from Python to Ruby as my main development language presented an opportunity to review the toolings involved. Previously I relied on pyenv to provide isolated Python interpreters for individual projects. Eventually, the functionality was replaced by uv, which also manages pre-built CPython distributions as well. Unfortunately, I wasn’t aware of an alternative for Ruby, and had to continue relying on rbenv for the purpose.

One of the main goals of using home-manager, as discussed in the previous article, was to achieve idempotency and to isolate dev packages from the system package manager (such as apt in Ubuntu). Thus, we need to first define the packages in the home-manager flake file, as shown below:

packages = with pkgs; [
    ...
    # dev libraries
    openssl
    zlib-ng
    bzip2
    readline
    sqlite
    ncurses
    xz
    tcl
    tk
    xml2
    xmlsec
    libffi
    libtool
    libyaml
    libxml2
    libxslt
  ];

Essentially, this yields an isolated filesystem namespace that is unrecognized by the operating system. In order to get the compiler to utilize the pulled development package, we need to tell rbenv where to look for them, as shown in the shell script below:

#!/usr/bin/env sh

export CPPFLAGS="-I$HOME/.nix-profile/include $CPPFLAGS"
export CFLAGS="-I$HOME/.nix-profile/include $CFLAGS"
export LDFLAGS="-L$HOME/.nix-profile/lib $LDFLAGS"
export PKG_CONFIG_PATH=$HOME/.nix-profile/lib/pkgconfig:$HOME/.nix-profile/share/pkgconfig:$PKG_CONFIG_PATH
export C_INCLUDE_PATH=$HOME/.nix-profile/include:$C_INCLUDE_PATH
export INCLUDE_PATH=$HOME/.nix-profile/include:$INCLUDE_PATH
export LIBRARY_PATH=$HOME/.nix-profile/lib:$LIBRARY_PATH
export LD_LIBRARY_PATH=$HOME/.nix-profile/lib:$LD_LIBRARY_PATH

$HOME/.nix-profile/bin/rbenv install -vf 3.3.5

It worked fine, though I always found this a dirty hack, as it required explicitly defining the flags and include paths. There has to be a better way.

The Nix Pivot: Discovering a Declarative Path

If not rbenv, then how do we approach Ruby version management? Turns out we can use another feature provided by Nix to build a development environment through a declarative manner. So how is this relevant to the problem we are looking at though?

Photo by Jonathon B. Carreño on Unsplash

A friend of mine had been hinting for a while that I could completely replace rbenv with Nix but I didn’t explore deeper. That changed when I saw the announcement of the gemini-cli app. In the installation guide, it called for npx, but the tool was not available as a Nix package. After some exchanges with Gemini, it suggested I look into nix shell, and the conversation quickly evolved into an introductory session on nix develop.

Just a side note, gemini-cli was already packaged not long after the announcement, no need for npx. If I were to follow the installation guide, npx could be made available through a nix shell -p nodejs session. In case you missed how this could be related to our original problem, the equivalent for Ruby would be nix shell -p ruby.

What if I need to install gems that require some special dev libraries?

You just unlocked the reason the conversation turned into an introduction to nix develop. Like home-manager, the input for the command is a flake file, written in the Nix programming language, declaring the development environment setup. Naturally, this added complexity made me hesitant to commit to this strategy. I was still trying to get more comfortable with home-manager and wanted to take more conservative baby steps in adopting additional features offered by Nix.

Essentially, there are two important components to be declared in the flake: the list of packages and an initialization shell script. For example, we can define a development environment sporting Ruby 3.3 with the list of packages like so:

buildInputs = with pkgs; [
  # fish is kept so that fish-specific completions from
  # packages can be made available.
  fish
  # Git is needed for fetching gems from git repositorie
  git
  # The Ruby interpreter (3.3.8 as the time of writing)
  ruby
  # Bundler for managing Ruby gems.
  bundler
  # Common dependencies for building native extensions.
  cmake
  gcc
  gnumake
  # Libraries often required by gems.
  openssl
  pkg-config
  libmysqlclient
  shared-mime-info
  re2
  readline
  zlib
] ++ lib.optionals stdenv.isDarwin [
  # Add macOS-specific dependencies.
  libiconv
];

Secondly, the initialization script definition

shellHook = ''
  # Ruby-specific setup
  export FREEDESKTOP_MIME_TYPES_PATH="${pkgs.shared-mime-info}/share/mime/packages/freedesktop.org.xml"

  echo "Ruby dev environment activated for ${system}!"
'';

Incorporating these into the flake file makes nix develop a superior method to set up a development environment. Compared to just listing packages in nix shell, the shellHook component allows more control and further manipulation, enabling us to set up proper environment variables and run initialization commands. Additionally, the declarative nature of a flake file also means it is highly reproducible and can be easily shared.

A Harmonious Setup: Validation and Reflection

Remember I needed to redefine library path and compiler flags to compile Ruby interpreters? That problem eventually came back while I was installing gems for work projects. Long story short, I gave in and adopted nix develop. Does it work out of the box? Does the adoption of nix develop stop me from shooting myself in the foot?

In order to be cautious, I replicated and adapted the flake for my bigmeow side project, which is still managed by Poetry, and hence relied on pyenv. Fortunately, a satisfactory outcome was achieved after a few iterations. On the other hand, direnv also offers some integration with nix develop. Automated activation of a development environment can be achieved by adding one line to the respective .envrc:

use flake /path/to/folder # the folder that contains the flake.nix declaration

Photo by Sigmund on Unsplash

Applying the Ruby counterpart also went rather smoothly. There were some problems in the earlier iterations, but they were mostly trivial, and all it took was a regeneration by Gemini. Compared to the relatively smooth sailing in environment setup, taming my code editor to work with it was a lot more frustrating.

In recent years, most extensions bridging the code and development tools would often bundle the tool together. For instance, if I install an extension to format Python code with ruff formatter in Visual Studio Code, it would bundle ruff itself in the package. This saves the developer from needing to declare ruff as a dependency of the project.

Likely due to the highly modular design, the experience was a lot more complicated in the Ruby world. One of my work projects defined an ancient version of the Rubocop formatter, and none of the editor extensions offered in the marketplace would work with it. Forcing the extension to use the bundled gem would fail, because it wouldn’t work with the equally outdated rubocop extension gems (rubocop-rails, rubocop-minitest) installed in the project.

Updating the lock file is not a practical solution and I was stuck there for a while. Thankfully a coworker shared that I could explore the ruby-lsp extension. Apparently, this extension makes it possible to refer to an alternative Gemfile, i.e. I could have a Gemfile for all the development tools saved outside of the project. In this particular case, I could have a Gemfile like this

source "https://rubygems.org"

gem "ruby-lsp"
gem "rubocop", "1.26.1"
gem "rubocop-rails"
gem "rubocop-minitest"

Solving that yields an functional setup that I was happy enough for work. Looking back, everything seemed rather trivial, but in reality I was stuck for a couple of days. Despite the added complexity, getting all these parts working together felt like putting together puzzle pieces. Getting them configured correctly is giving the same satisfaction as solving a complex jigsaw puzzle.

Is this increased complexity worth the effort? Would there be a better alternative strategy out there? I am curious to know about them and am open to recommendations and corrections. Meanwhile, I do find the revision to retire version managers a fruitful learning experience. Another part I liked about the current implementation is the elimination of explicit declaration of dev packages to build the interpreters. If you ask me, I would say replacing the version managers and removing dev packages for interpreter compilation with nix develop flake files is totally worth the effort.

Throughout this journey, Gemini served as a valuable editorial companion, helping refine my prose. However, the voice and code remain entirely my own. I welcome your feedback and recommendations in the comments below, and invite you to subscribe to my Medium for more content on my development adventures!

Containerization on macOS vs. Linux: A Security and Isolation Comparison, Including Darwin Containers and OSXIEC

Mon, 24 Mar 2025 21:03:43 +0000

Containerization on macOS vs. Linux: A Comparative Look

Containerization has revolutionized application deployment and management, providing lightweight, portable, and isolated environments for running software. While Linux has been the dominant platform for containerization technologies like Docker, macOS introduces unique challenges. In this article, we explore the differences between containerization on macOS and Linux, the role of System Integrity Protection (SIP), and a deeper look at OSXIEC—a native containerization solution for macOS. Additionally, we'll examine Darwin Containers, a project that ports containers to Darwin-based platforms like macOS but requires to turn off SIP protection, and the implications of disabling SIP.

Containerization on macOS vs. Linux: Key Differences

1. Namespaces and Kernel Isolation

Linux containers leverage the namespace feature of the Linux kernel to isolate processes, file systems, networking, and more. This is essential for creating secure and lightweight containers that don’t interfere with the host system or other containers.

macOS, however, uses a different Unix-based kernel (Darwin), which does not support Linux namespaces. As a result, macOS containers cannot achieve the same level of isolation as their Linux counterparts. While macOS can achieve some form of containerization, it typically doesn't offer the same degree of process isolation or resource management.

2. System Integrity Protection (SIP)

System Integrity Protection (SIP) is a security feature on macOS designed to safeguard the system by preventing even root users from making changes to certain protected files and processes. This limits the ability to tamper with critical parts of the operating system, providing an extra layer of defense against malware or unauthorized system modifications.

SIP is especially important in the context of containerization. On macOS, containerization tools like OSXIEC respect SIP to ensure the integrity of the host system. While SIP limits certain capabilities, it’s a trade-off for increased system security.

Disabling SIP, however, removes these protections, allowing greater control over the system. While this can be useful for some containerization solutions that require deeper system access, it exposes the system to higher risks of compromise. Therefore, developers should weigh the potential benefits of turning off SIP against the increased security vulnerabilities.

3. File System Isolation

Linux containers use namespaces to isolate file systems, ensuring that containers only have access to their own files and not to files on the host system or other containers. On macOS, file system isolation isn't as robust, as the system doesn’t provide the same namespace-based separation.

However, with tools like OSXIEC, developers can still containerize applications in macOS, providing an environment where applications can be isolated from the host system. Nonetheless, a root user on macOS could potentially bypass these restrictions.

4. Networking and Virtualization

Linux containers can create complex virtual networks, set up custom bridges, and handle inter-container communication using network namespaces. macOS, however, lacks this level of native networking support, which complicates the creation of isolated virtual networks for containers.

OSXIEC addresses this by offering network containerization features, allowing you to set up VLANs and create isolated networks for containers along with assigning ips to individual containers. While this is an improvement over other macOS containerization solutions, it's not as mature or flexible as Linux container networking, which has been refined over years of development.

5. Security and Isolation

Security in containerized environments is a critical concern, especially when evaluating the level of isolation between containers and the host system. On Linux, containerization is achieved through namespaces and cgroups, which provide strong isolation between containers and the host, limiting potential security risks. However, a root user within a container can potentially access or manipulate certain system resources if the isolation is not properly configured.

On macOS, containers like OSXIEC offer some level of isolation, but it is less robust compared to Linux-based containers. macOS doesn't have the same namespace-based isolation mechanisms that Linux provides, which makes containers on macOS more vulnerable to security risks. Moreover, while System Integrity Protection (SIP) adds an additional layer of security to prevent unauthorized system modifications, it does not fully mitigate the risks associated with container isolation.

While OSXIEC containers offer some security features, such as vulnerability scanning, they are inherently less isolated than their Linux counterparts. This means that containers on macOS could be more susceptible to security breaches if not properly managed. Developers and security professionals need to be aware of these limitations and carefully assess the security risks when deploying containers on macOS.

Why We Use SIP: Protecting macOS Systems

System Integrity Protection (SIP) is a critical security feature in macOS that prevents unauthorized modifications to critical system files, processes, and directories, even by users with root access. While this may limit some containerization capabilities, it is a necessary security measure to protect against malware and other forms of system compromise.

In the context of OSXIEC, SIP ensures that the integrity of the macOS host is maintained even while containerized applications are running. Disabling SIP would provide more control over the system but at the cost of reducing security. In environments where security is paramount, it is crucial to maintain SIP to ensure that the system remains protected.

Darwin Containers: Porting Containers to macOS

Darwin Containers is an open-source project aimed at bringing containerization to Darwin-based platforms like macOS. It provides a port of container technologies (like Docker) to macOS by emulating the required kernel functionalities on the Darwin platform. However, it’s important to note that Darwin Containers requires disabling System Integrity Protection (SIP) in order to function.

Pros and Cons of Disabling SIP for Darwin Containers

Pros:

Full Kernel Access: Disabling SIP gives Darwin Containers full access to the system’s kernel, allowing it to implement containerization features such as namespace-based isolation and network management that macOS doesn't natively support.
Improved Functionality: With SIP disabled, Darwin Containers can work similarly to Docker on Linux, offering better performance and greater flexibility in terms of container features.

Cons:

Security Risks: Disabling SIP exposes the system to potential security threats. Without SIP, a compromised application or malicious software could gain elevated privileges and make modifications to critical system files. This increases the risk of system compromise.
System Stability: Turning off SIP can lead to system instability, as certain macOS protections are bypassed. This could result in unforeseen issues, especially if updates or patches are not applied correctly.
Limited to Development Environments: Since disabling SIP is generally not recommended for production environments, using Darwin Containers is primarily suitable for development and testing environments where security is less of a concern.

While Darwin Containers provides a method for running Docker-like containers on macOS, the requirement to disable SIP presents a significant trade-off. For users who value the security and integrity of their macOS system, this may not be an acceptable solution.

Introducing OSXIEC: A Secure Native macOS Containerization Solution

While Darwin Containers offers a Docker-like experience for macOS, it comes with the significant downside of requiring SIP to be disabled. This can leave the system vulnerable to security risks. In contrast, OSXIEC is a native macOS solution that respects SIP, ensuring that users can containerize applications while keeping their systems secure.

Key Features of OSXIEC:

Native macOS Integration: OSXIEC works natively with macOS without requiring the use of virtualization or disabling SIP.
Secure Isolation: Containers created with OSXIEC provide a level of isolation, but without the need to turn off critical system protections like SIP.
Networking Support: OSXIEC offers container networking, including VLANs and isolated virtual networks.
Security Focused: OSXIEC is built with security in mind, ensuring that your macOS system remains safe from tampering while running containerized applications.

Conclusion

While Darwin Containers provides an option to bring Docker-like containerization to macOS, it requires disabling System Integrity Protection (SIP), a feature designed to protect the system from tampering. This trade-off may be acceptable for certain use cases, especially in development environments where security concerns are lower. However, for those who prioritize system integrity, OSXIEC provides a safer alternative by respecting SIP while offering native containerization features.

Whether you choose Darwin Containers or OSXIEC, it's important to understand the trade-offs between system security and functionality. If you’re looking for a macOS-native containerization solution that maintains high security standards, OSXIEC may be the right choice. However, if you need more advanced container features and are willing to accept the risks associated with disabling SIP, Darwin Containers would be better.

Interested in learning more about OSXIEC? Check out the official repository and get started with containerizing your macOS applications today.

Or interested in learning more about Darwin Containers? Check out the official repository and get started with containerizing your macOS applications today with docker though.

Coder Legion - Recent posts tagged macos

Fine in Chrome, broken in Preview: two PDFKit gotchas for anyone who writes PDFs

Gotcha 1: an incremental update must use the same cross-reference form as the file it updates

Some background

What PDFKit does with that

The fix

Gotcha 2: PDFKit draws filled text fields itself

What PDFKit does

Why that bit us

The fix

Bonus gotcha from Acrobat: Reader extensions (/UR3)

How to test with PDFKit without clicking through Preview

Takeaways

The Sending Side of APNs: A Mac Push Tester with Keychain Certificates and URLSession Client Auth

1. Two ways to authenticate with APNs, and why a tester uses certificates

2. Finding push identities in the Keychain

3. Importing a .p12 file

4. Answering the client-certificate challenge in URLSession

5. Building the request: path, headers, payload

6. Alerts, badges, sounds and silent pushes

7. Sending, and reading APNs's answer

8. Real-world example: Push Notification - Tester

9. Before you trust a push test: a checklist

Wrapping up

Best Mac mini for OpenClaw in 2026: Memory, Local Models and Prices

With a hosted model, any Mac mini will do

With a local model, memory decides

The arithmetic

What fits on each Mac mini at a 64K context

Which one to buy

The wait before the first word

Mac mini or Mac Studio

A Mac mini you already own

FAQ

Is 16 GB enough for OpenClaw?

How much memory does OpenClaw need?

Mac mini M4 or M6 for OpenClaw?

Does the same apply to Hermes Agent?

Conclusion

Fake Zoom Mac Installer Skips Gatekeeper, Steals Data

What Happened: A Fake Zoom Installer on macOS

Technical Breakdown of the Gatekeeper Bypass

1. Dual‑Package Wrapper

2. Post‑Installation Script Abuse

3. Code‑Signing Spoofing

Why It Matters for Users and Enterprises

Erosion of Trust in Trusted Platforms

Data‑Theft Risks

Compliance Implications

Industry Impact and Response

Vendor Reaction

Security Community Mobilization

Broader Market Trends

Mitigation and Best Practices

Immediate Steps for End Users

Enterprise‑Level Controls

Why Real-Time AI Face Swap Is Moving Beyond the Local GPU

We already accepted this architecture for LLMs

Local inference was the obvious starting point

Cloud inference changes who owns the hardware problem

The hard problem moves from compatibility to latency

Real-time video makes this harder than text

A practical example: LiveFaceSwap AI

Cloud will not replace local inference

Application Tres

Keeping a Web-Backed SSH Terminal Alive Across SwiftUI Navigation

Why rebuilding is not a harmless refresh

Separate four lifetimes

Mount once, then deactivate

Preserve the WKWebView object, not necessarily its attachment

Hand focus back before detaching

Freeze hidden geometry

Keep output flowing without flooding the UI

Test transitions, not just steady states

The broader rule

Most macOS malware is loud. PamStealer isn't, and that's a problem for how we detect it.

Stage one: a dropper that skips the shell

Stage two: Rust, a framework loaded at runtime, and a very loud clipboard

The password, and why PAM beats dscl for the attacker

This is the pattern now, not the exception

Bonus gotcha from Acrobat: Reader extensions (`/UR3`)