DEV Community: Prince Jain

Rejected twice by App Review: two sandbox bugs that nearly killed my first macOS app

Prince Jain — Tue, 13 Oct 2026 09:34:37 +0000

i shipped my first macOS app last week. it got rejected twice by App Review, and both times the bug was the kind of thing you only learn by being bitten.

bug 1: entitlement keys do not take false

my entitlements.plist had camera, mic, and location keys set to false. my reasoning was "the app does not use these, so declare that." that is not how it works. entitlement keys only grant access; to deny access you omit the key. worse, those restricted keys were not in my provisioning profile, so amfid rejected the signature outright with "Restricted entitlements not validated - No matching profile found" and the kernel killed the binary at exec. Killed: 9, no window, nothing.

Guideline 2.4.5(i): invalid sandbox entitlements. fair enough.

bug 2: the sandboxed WKWebView blank screen

the app is a thin WKWebView wrapper around a local html/css/js ui, all bundled, zero network calls. on review, the window opened black and empty.

reproduced it locally with a debug WKNavigationDelegate: webContentProcessDidTerminate, every time. the log said com.apple.WebKit.WebContent "Application does not have permission to communicate with network resources". the WebContent process needs com.apple.security.network.client to even exist, fully offline file:// content included. apple documents this nowhere obvious. add the key, the process lives, the ui renders. didFinish fires, whole deck visible.

Guideline 2.1(a): app was incomplete on launch. also fair.

what shipped

Zero-Power Player is an offline audio player for study sessions: local files (mp3/aac/m4a/flac/wav) cached in IndexedDB, a binaural beat generator with 10/16/40 Hz presets, brown noise and rain mixer, a pomodoro timer, and a projector wall mode that puts a giant timer and track title up for the room. it idles around 0% cpu because decoding goes through native hardware paths.

free, no account, no ads, no analytics. macOS 15+.

https://apps.apple.com/us/app/zero-power-player/id6816212859?mt=12

source is public if you want to see how dumb the actual diff was: https://github.com/princejain756/Zero-Power-Player

the whole fix was deleting 3 xml keys and adding 1. two rejections, one week, for that.

I audited my AI agent stack: 92,413 tokens burned before the first message

Prince Jain — Mon, 12 Oct 2026 12:10:36 +0000

A while back there was a thread on r/mcp: "Running 15+ MCP servers can burn 60,000 tokens before your agent reads a message." Everyone in the comments was fixing it piecemeal: lazy-loading hacks, a homemade get-tool-help tool, grepping /context output by hand.

Nobody had built the diagnostic. So I did.

What it measures

ctxvitals launches each stdio MCP server in your config, sends a real initialize + tools/list, and counts the actual schema tokens each one injects into context. Then it does the same for skills, rules files, commands, and hooks across Claude Code, Cursor, Windsurf, Copilot, Codex, and Devin configs.

My results were bad

metric	value
skills installed	901
skill description tokens (always loaded)	39,402
MCP servers	15
tokens burned per turn	92,413
grade	F

The embarrassing part wasn't the number. It was why:

the same MCP server was configured under 3 different names, paying schema cost 3 times
a plaintext API key sitting in an env block
one server pointing at a binary that doesn't exist anymore

And after shipping per-tool rankings today (a Reddit suggestion), I found out claude-code's Read tool alone costs 7,487 tokens of schema. One tool.

It also checks security

hardcoded secrets in configs and skill files
exfil patterns (credential stores + network calls in the same file)
curl | sh installers
prompt-injection phrases
unpinned npx/uvx packages
duplicate registrations resolving to different binaries, which means which one answers your tool calls then depends on load order. supply-chain roulette.

Run it

npx ctxvitals

Zero dependencies, Node 18+. --html report.html for a shareable report, --json for piping, --no-probe if you don't want it launching servers. There's also a Claude skill so your agent can audit itself.

GitHub: https://github.com/princejain756/ctxvitals

Honest question: what does your stack burn? I've seen 92k (mine, embarrassing). Someone tell me the ceiling.

I counted the strangers inside famous npm dependency trees

Prince Jain — Mon, 12 Oct 2026 10:28:01 +0000

Your node_modules isn't yours. It's a crowd of strangers you invited in.

Every npm install is an act of trust. You vetted the package you typed; you didn't vet the hundreds of transitive packages that came with it, or the accounts that can publish the next version of each.

I built a zero-dependency CLI that reads package-lock.json and counts every npm account with publish rights in your tree. Then I ran it on famous repos.

The numbers

repo	packages	strangers	top stranger's share
Kong/insomnia	1,571	1,786	8.3%
axios/axios	1,416	809	12.9%
microsoft/vscode	1,179	710	10.3%
github/docs	1,014	710	11.1%
npm/cli	851	450	12.9%
microsoft/playwright	632	390	18.7%
ionic	491	340	21.2%

Insomnia's tree has more strangers than packages: 1,786 people can ship code into an app that stores your API keys.

The account at the top of three of those lists is the same person. ljharb can publish into 12.9% of npm's own CLI, 10.3% of VS Code's install, and 18.7% of Playwright. One account, three supply chains. sindresorhus alone is 21% of Ionic's tree.

Half the tree is one person

Roughly 55% of packages in every tree I checked are maintained by exactly one account. Not a small team — one person with publish rights.

npm audit checks for known vulnerabilities in versions you already have. It says nothing about who can publish the next version. That list is your actual attack surface — the xz backdoor was one overworked maintainer with commit access to a package half the internet ran.

Try it

npx dep-census              # your project's package-lock.json
npx dep-census owner/repo   # any GitHub repo's lockfile

Zero dependencies, MIT, ~150 lines of logic. Full leaderboard in LEADERBOARD.md:

https://github.com/princejain756/dep-census

npm only for now — yarn and pnpm lockfiles aren't parsed yet, and it says so in the readme.