DEV Community: Devanshu Verma

Shipping a Mac app without a $99 Apple Developer account

Devanshu Verma — Wed, 21 Oct 2026 19:15:24 +0000

I build Kopi, a free, open-source (MIT) clipboard manager for macOS and Windows. It's written in Rust with Tauri 2 and React, and it's in alpha.

This post is about one decision that took more thought than any feature: how to ship a Mac app without paying Apple $99 a year. I wrote it up as a decision record in the repo (ADR 0006), and this is the longer story behind it.

The problem: $99 a year to open without a warning

On macOS, an app downloaded from the internet opens without a Gatekeeper warning only if it is signed with an Apple Developer ID certificate and notarized by Apple. Getting that certificate means joining the Apple Developer Program, which costs $99 a year.

For a commercial app that's a normal cost of doing business. Kopi is free and open source, and I decided it won't pay that fee every year. So the question became: what's the best Mac experience I can ship without it?

Why "just don't sign it" doesn't work

My first thought was the obvious one. Skip the paid certificate, sign the app ad-hoc (which is what you get by default when you build locally), and tell people to click through the warning.

That falls apart because of what Kopi does. A clipboard manager needs two macOS permissions:

Accessibility, so it can paste into the app you're using.
Pasteboard access ("Paste from Other Apps"), so it can see what you copy.

macOS doesn't remember these grants by app name. It ties them to the app's designated requirement, a rule baked into the code signature that says "this is the same app." For an ad-hoc signature, that requirement includes the build's own hash. Every new build has a new hash, so every new build looks like a different app to macOS.

In practice that meant my alpha testers lost both permissions on every update. Paste stopped working, history stopped recording, and they had to dig into System Settings and re-grant everything. For an app that ships frequent alpha updates, that's not something I could ask people to put up with.

The fix: a self-signed certificate that never changes

The key insight is that the designated requirement doesn't have to mention the build's hash. If you sign with a real certificate, even a self-signed one, the requirement can be based on the bundle identifier and the certificate instead.

So I created a self-signed code-signing certificate and stored it in the repository's secrets. Every release is signed with it. The resulting designated requirement looks like this:

identifier "in.devanshuverma.kopi" and certificate leaf = H"…"

That's the bundle identifier plus the hash of the certificate's leaf. Neither changes between builds. To macOS, version N+1 is the same app as version N, so the Accessibility and pasteboard grants carry over.

This doesn't make Gatekeeper happy. A self-signed certificate isn't trusted by Apple, so the app is still blocked on first open. But it solves the much worse problem of permissions resetting on every update.

You can check this yourself on any signed app:

codesign -d -r- /Applications/Kopi.app

One snag with Tauri

Tauri's bundler can sign macOS builds for you if you hand it a certificate through the APPLE_CERTIFICATE environment variable. The catch: its import only finds Apple-issued certificates, and it refuses to build a release without one. A self-signed certificate isn't Apple-issued, so that path doesn't work.

The workaround is to have the release workflow import the certificate into the keychain itself, then let the build sign with that identity.

Accepting the first-open block, and making it painless

With a self-signed certificate, Gatekeeper will block Kopi the first time someone opens it. I decided to accept that and put the effort into making the first launch as painless as I could, in three ways.

An install guide. INSTALL_ALPHA.md walks through it step by step. On macOS 15 Sequoia and later, you allow Kopi in System Settings → Privacy & Security. On macOS 14 Sonoma, you Control-click the app and choose Open. The guide also explains each permission and what happens if you don't grant it.

A .dmg background that shows the steps. Most people never read install docs, but everyone sees the disk image window when they drag the app to Applications. So the .dmg background itself shows what to do after the first block.

A one-line Terminal install. For people comfortable with Terminal, there's a script:

curl -fsSL https://kopi.devanshuverma.in/install.sh | bash

It downloads Kopi, verifies the download, and copies the app to Applications. The script doesn't quarantine the app, so Gatekeeper doesn't block the first launch.

Piping a script into bash from the internet deserves some care, so the script has a guardrail: it only installs a Kopi that is signed with Kopi's certificate. If the signature doesn't match, it doesn't install. As always, you can read the script before running it.

Updates: blocked once, never again

The first install is the only time Gatekeeper gets in the way. After that, Kopi updates itself with the Tauri updater.

The updater signs updates with its own key, separate from the code-signing certificate. It installs updates without quarantine, so Gatekeeper doesn't block them. And because every build carries the same designated requirement, the permissions survive too.

So the full experience for a tester is: one "Open Anyway" on day one, grant two permissions, and then updates just arrive. Kopi checks every few hours and installs in the background, and you can turn automatic updates off in Settings.

The options I rejected

Here's what else I considered and why I didn't go with it:

Option	Why not
Developer ID + notarization	Removes the first-launch warning, but costs $99 every year.
Ad-hoc signing only	Free, but Accessibility and pasteboard permissions reset on every update.
Mac App Store	Needs the same paid program, and Kopi can't run in the App Sandbox.
Homebrew cask	The official tap disabled casks that fail Gatekeeper on 2026-09-01, and `--no-quarantine` is gone. A personal tap could work, but it would have to clear the quarantine flag itself. Deferred unless testers ask for it.

The honest trade-offs

This approach is not free of costs. They just aren't monetary.

Every new user has to find "Open Anyway". It lives in System Settings, and macOS 15 made it harder to get to than the old Control-click → Open trick. The install guide, the .dmg background and the Terminal script all exist to soften this, but it's still a step a notarized app wouldn't need.

Some people won't install an app macOS warns about. That's a reasonable instinct, and I'm not going to argue anyone out of it. Kopi being open source means you can read the code and build it yourself, but I accept that some people will close the warning and move on.

The certificate's private key has to be guarded. Anything signed with that key is something macOS will treat as Kopi, including inheriting the permissions people granted. That's why it lives in the repo's secrets. If it were ever lost, I'd have to create a new certificate, and every user would have to re-grant their permissions once.

For a free, alpha-stage app, I think that's the right trade. If Kopi grows to the point where the first-launch warning is the main thing holding people back, I'll revisit it. That's what the decision record is for.

Try Kopi

Kopi is open source under the MIT license and in alpha on macOS (14 Sonoma or later, Apple silicon or Intel) and Windows 10/11. It keeps your clipboard history locally with no account, filters out password-manager content, and has optional end-to-end encrypted sync over your local network.

Website: kopi.devanshuverma.in
Repo: github.com/code-devanshu/kopi

If you try it, I'd love to hear what breaks. Issues on GitHub are the best place for bug reports, and Windows feedback is especially welcome right now.

I got tired of sketchy photo resizers, so I built one that never uploads your photo

Devanshu Verma — Wed, 07 Oct 2026 13:00:51 +0000

If you've applied for anything in India (a passport, a PAN card, UPSC, NEET, a bank exam), you've seen some version of this:

"Upload photograph: 35×45 mm, JPEG, under 50 KB."
"Upload signature: 60×20 mm, 10 to 20 KB."

You crop it in some app, export it, upload it, and the portal says no. Wrong dimensions. Or 53 KB. Try again.

The usual fix is to search "photo resizer online" and pick whichever site loads first. Those sites are covered in ads, and most of them upload your photo to a server. It's your face, going into an ID application, sitting on a machine you know nothing about. That bugged me enough that I built my own: FormPic.

What it does

You drop in a photo, pick the form, drag the crop box over your face and download. The file comes out at the exact pixel size the form wants and under the file size limit you set.

The part I care about most: the photo never leaves your browser. There's no upload step at all. It's free, there's no account, and there's no watermark. Once the page has loaded it keeps working offline, and you can take the photo with your phone or laptop camera instead of uploading one.

Try it here: formpic.devanshuverma.in

The sizes it knows about

These are the presets right now:

Document	Print size	Pixels	Resolution
Passport size	35×45 mm	413 × 531 px	300 DPI
US passport & visa	2×2 in	600 × 600 px	300 DPI
PAN card	25×35 mm	197 × 276 px	200 DPI
UPSC	35×45 mm	413 × 531 px	300 DPI
NEET	35×45 mm	413 × 531 px	300 DPI
IBPS	35×45 mm	200 × 230 px	set in pixels
SSC signature	60×20 mm	472 × 157 px	200 DPI

If your form isn't listed, you can type any width and height in pixels and lock the aspect ratio.

What makes these annoying is that you have to get the aspect ratio, the pixel dimensions and the file size right at the same time. Most tools I tried handled one of them and left the rest to me.

How it works without a server

A browser already has everything a photo resizer needs. You read the file, draw the cropped part onto a canvas at the target size, and encode it. With no backend there's nothing to store and nothing to leak, and no reason the tool can't run offline.

Here's a simplified sketch of the crop step:

async function cropAndResize(file, crop, width, height) {
  const bitmap = await createImageBitmap(file);
  const canvas = document.createElement('canvas');
  canvas.width = width;
  canvas.height = height;

  const ctx = canvas.getContext('2d');
  ctx.imageSmoothingQuality = 'high';
  // source rect (the crop box) -> destination rect (the form size)
  ctx.drawImage(bitmap, crop.x, crop.y, crop.w, crop.h, 0, 0, width, height);
  return canvas;
}

Getting under 50 KB without guessing

This was the fun bit. JPEG file size doesn't go up in a straight line with quality, so you can't just say "50 KB means quality 0.7." What does work is a binary search over the quality value until you find the highest one that still fits:

const toBlob = (canvas, q) =>
  new Promise((resolve) => canvas.toBlob(resolve, 'image/jpeg', q));

async function fitToSize(canvas, maxBytes) {
  let lo = 0.05, hi = 1, best = null;
  for (let i = 0; i < 8; i++) {
    const q = (lo + hi) / 2;
    const blob = await toBlob(canvas, q);
    if (blob.size <= maxBytes) { best = blob; lo = q; }
    else hi = q;
  }
  return best; // null means it's too big even at the lowest quality
}

Eight rounds gets you within about 0.4% of the best quality, which is plenty. If the photo is still too big at the lowest quality, there's a "Shrink to fit" option that lowers the pixel size too.

A few smaller things I spent time on:

Picking a form preset switches the output to JPEG, since that's what nearly every portal asks for. PNG is still there if you want a lossless copy to print.
The preset outlines are drawn to scale, so you can see the shape before you choose.
The Download button shows the final file size. You find out it's 48 KB before you're stuck on a slow government site at midnight, not after.
Nothing is kept. Close the tab and the photo is gone.

What it doesn't do

It won't change your background to white. I went back and forth on this, but doing it well in the browser is hard, and doing it badly looks worse than a plain wall. For now my advice is to stand in front of a white or light wall with even light. That fixes it most of the time.

A few questions I get

What's a passport photo in pixels? 35 × 45 mm at 300 DPI is 413 × 531 px. Some portals want a different upload size, though, so check the form and type its numbers in.

How do I get a photo under 20 KB? Pick JPEG, set Max file size to 20, and download.

Is it really not uploaded? Open DevTools, go to the Network tab and try it. You won't see the image go anywhere.

Tell me what's missing

I build and run FormPic on my own, and I add presets based on what people ask for. If your form or country needs a size that's not there, leave a comment with the form name, the size (mm or px) and any file size limit, and I'll add it.

I'd also like to hear from other devs about the UX, or about how you'd handle background removal client-side without shipping a huge model.

And if you know someone who's about to fight an exam portal, send them the link. It might save them an evening.

formpic.devanshuverma.in