DEV Community: swift

How I built a multi-agent simulator as a native SwiftUI app

Guilherme Brasil — Mon, 19 Oct 2026 17:56:09 +0000

I built Sorcerer, a free, open-source macOS app (SwiftUI, macOS 15+, MIT) that simulates a community of AI characters reacting to a "what if…?" question. You write a hypothesis ("what if Lumen raised its plan from $9 to $14 a month?"), summon a cast, and watch them post, reply, react, change their minds and take actions, round by round.

Repo: https://github.com/gbrasil720/sorcerer · Site: https://sorcererapp.dev

This post covers how it works under the hood.

1. No API keys: drive the CLIs people already have

I didn't want to ship a model or ask anyone for a key. Sorcerer runs the official tools the user is already signed in to: the claude CLI (Claude Code), the codex CLI (ChatGPT), or a local Ollama.

The first problem: an app launched from Finder doesn't get your Terminal's PATH, so claude is "command not found". Sorcerer asks an interactive zsh once and remembers the answer:

/// The PATH your Terminal has. A login shell alone misses what ~/.zshrc adds (~/.local/bin, where
/// the claude installer puts it; nvm, bun…), so ask an interactive shell once and remember it.
static let userPath: String = {
    let p = Process()
    p.executableURL = URL(fileURLWithPath: "/bin/zsh")
    p.arguments = ["-ilc", #"printf '\n__SORCERER_PATH__%s' "$PATH""#]

It also has a 5-second deadline, because an interactive shell can hang on a prompt or plugin.

Then each provider is one switch case. Claude runs with no tools, no session file and no user settings. It uses stream-json because that output also carries the subscription's 5-hour and weekly usage windows, so the app can pause before you hit a limit:

"claude -p --tools '' --no-session-persistence --setting-sources '' --output-format stream-json --verbose\(pick)"
    + (onText == nil ? "" : " --include-partial-messages"),

Codex runs with codex exec --skip-git-repo-check --ephemeral -s read-only … -o <tmpfile> -. Ollama is a plain POST to http://localhost:11434/api/generate with "stream": true, which reads one JSON object per line.

2. Characters

A character is a plain Codable struct:

struct Persona: Codable, Identifiable, Hashable {
    var handle: String
    var role: String
    var bio = ""
    var traits: [String: Double] = [:]
    var interests: [String] = []
    var goals: [String] = []
    var mood = 0.0
    var memories: [String] = []
    /// handle → relation ("coworker", "rivals"). Optional so older worlds still load.
    var ties: [String: String]?
    /// Knows the brief's insider facts (employees, partners, friends of the team).
    var insider: Bool?

mood is the character's attitude toward the hypothesis, from -1 to 1. ties are how influence spreads. memories are one-liners the model writes each round.

3. A round is one prompt, and the rules live in pure functions

The simulation lives in Engine.swift, whose header says "Prompts and parsing. Pure functions, so the simulation rules are testable without a model."

Each round, roundPrompt gives the model the whole world:

the cast, with role, mood, ties, last 4 memories and last action
past events and anything injected this round
the last 24 posts, each with a stable id like A3 (third post of branch A)
what characters may know (more on that below)

The model plays every character and must reply with only JSON:

{"posts":[{"author":"handle","replyTo":"post id it answers, e.g. A3, or null","text":"...","mood":0.0}],"reactions":{"A3":{"agree":2,"disagree":1}},"memories":{"handle":"one short line this character will remember"}}

The prompt nudges toward realism: not everyone posts every round, opinions shift gradually, replies come most often from people with ties, and quiet characters still react with agree/disagree counts.

Then apply validates the output instead of trusting it. Unknown authors are dropped and moods are clamped. Actions must be on the experiment's allowed list. Only someone who left can "come back", and there's at most one invite per round. Because this is pure code, swift test covers it without calling a model.

4. Who knows what

You can point Sorcerer at a GitHub repo (through your own gh login), a folder, a site or files. It writes a brief where every fact is tagged public, insider or hidden. knowledge() builds each prompt's knowledge section: insider facts reach only characters marked insider, hidden ones reach nobody, and it ends with "Characters never quote facts they couldn't know." When reading sources, it only reads docs. .env files and keys are never opened, and characters see the brief, never your code.

5. Streaming half a JSON

To show "@wren is typing…" with words appearing live, Sorcerer parses the round's JSON while it streams:

/// Reads a round's JSON while it streams in. Complete post objects are decoded; the open one
/// yields its author and the text so far. Never throws: half a JSON is the normal case here.
static func partialRound(_ text: String) -> Partial {

It's a small hand-rolled scanner. It finds "posts", tracks brace depth and string escapes, decodes every closed {…} as a finished post, and pulls author and partial text out of the open one. Claude (with --include-partial-messages) and Ollama stream. Codex doesn't yet, and that's issue #21.

6. Forking the world

Forking copies the branch with the same people and the same memories, then starts a new path:

func fork() {
    guard let b = shown, let e = experiment else { return }
    let letters = "ABCDEFGHIJKLMNOPQRSTUVWXYZ".map(String.init)
    var copy = b
    copy.id = UUID()
    copy.name = letters[min(e.branches.count, letters.count - 1)]
    copy.parent = "from \(b.name) at r\(b.round)"
    mutate { $0.branches.append(copy) }
    switchBranch(copy.id)
}

To fork from a past round, rewind(_:to:start:) returns the branch as it stood after round n. It filters posts, events, actions and polls, drops people who joined later, removes memories tagged with later rounds, and rebuilds each mood from the posts. There's an honest comment in there: agree/disagree counts are totals, so reactions from later rounds stay on old posts. That's a known trade-off.

7. Counted, not guessed

Reports separate what the model judges from what the world counted. If six people answer a poll, the report says "would you pay $14 · no · 3 / 6" from the actual answers. An action tally only counts each person's latest action, so "upgrade" then "cancel" counts once, as cancel.

Stack

App: pure Swift, SwiftUI, Swift Package, no third-party dependencies. Run it with cd apps/macos && swift run and test with swift test.
Landing page: Bun + Turbo monorepo (React, TanStack Router, Tailwind, Hono, tRPC), deployed on Cloudflare Pages.
Releases: push a vX.Y.Z tag and CI tests, builds a universal DMG and publishes it.

Want to help?

I opened well-scoped issues with context, file pointers and acceptance criteria:

Tip: test with Ollama so you don't burn your Claude or ChatGPT limits.

Simulations surface possible reactions; they don't replace real-world evidence. I'd love to hear where it feels convincing and where it falls apart. Repo: https://github.com/gbrasil720/sorcerer

Apple's 4.3 spam check is a 30-second batch job. 22 rejections prove it

Matt Busel — Mon, 19 Oct 2026 17:26:28 +0000

Originally published at tensorust.com.

TL;DR: Apple App Review rejected 11 of my iPhone apps under Guideline 4.3 Spam. Then it did it again. Both times, all 11 rejections landed inside 30 seconds (30 s on October 5, 27 s on October 12), one email every 3 seconds, in an order that has nothing to do with the order I submitted them. Round two came 167.7 to 167.9 hours after I resubmitted, for every single app: a seven-day timer, accurate to 12 minutes. I filed three appeals with the App Review Board on October 5. 14 days later: zero replies. Today I ran my own "spam detector" over all 20 app repos as Apple saw them. The two most alike apps I have ever shipped are both live. Apple is not reviewing apps for 4.3. It is reviewing accounts, and it is not saying so.

If you came here from Google asking what "Guideline 4.3 spam" means: it is Apple's rule against duplicate apps. Part (a) bans "multiple Bundle IDs of the same app", and part (b) bans apps "indistinguishable from what's already widely available". The rejection usually says your app "shares a similar binary, metadata, and/or concept" with other apps, with "only minor differences". It does not tell you which app, which file or which screen. The short fix list is at the bottom: stop batch-submitting, reply before you resubmit, and book a call with App Review. The rest of this article is the receipts.

The 22 Guideline 4.3 rejection emails for 11 apps, Gmail timestamps, Oct 5 and Oct 12 2026. Static frame: batch.png.

11 apps, 30 seconds, one email every 3 seconds

On September 26, 2026 I submitted 11 new iPhone apps, all built from Windows with the no-Mac pipeline I wrote about before: Odometer (car maintenance), Parked (parking meter), Rooms (home insurance inventory), Pricebook (grocery prices), Pawprint (pet meds), Chores (kids' chore chart), Clockout (tips for service workers), Curve (grade calculator), Climbbook (bouldering log), Race Pace (running splits) and Cutoff (caffeine and sleep). The submissions were spread over 15.5 hours: the first at 7:10 AM Pacific, the last at 10:42 PM.

Nine days later, on October 5, every one of them got the same "There's an issue with your submission" email. I pulled the timestamps out of Gmail this morning. The first arrived at 5:29:32 PM Eastern. The last arrived at 5:30:02 PM. Eleven apps that each solve a different problem, for a different person, with a different design, judged in thirty seconds.

I also checked whether the decisions came out in submission order, the way a human working down a queue would produce them. They did not. The Spearman rank correlation between "order submitted" and "order rejected" is -0.06 for the first batch and 0.06 for the second. That is zero. Pawprint was submitted 4th and rejected 1st. Odometer was submitted 1st and rejected 11th. Whatever made these decisions, it was not a person opening apps one after another.

Eleven different apps, judged in thirty seconds. That is not a review. That is a for loop.

Round two: a seven-day timer, accurate to 12 minutes

Here is where I broke Apple's one rule, and I will own it. The rejection said: if you disagree, reply in App Store Connect and do not resubmit. I replied to all 11, answering all nine of App Review's questions per app. Then I resubmitted all 11 anyway, within 10 minutes (3:13 to 3:23 PM Pacific on October 5).

The second rejections arrived on October 12, between 6:04:46 and 6:05:13 PM Eastern. 27 seconds for 11 apps. But the wait is the weird part. Every app waited between 167.7 and 167.9 hours from resubmission to rejection. 168 hours is exactly seven days. Eleven apps, eleven waits, a spread of 12 minutes.

App Review emails, Submitted line in Pacific time vs email timestamp. Apple says 90% of reviews finish in under 48 hours.

For comparison, Apple's own App Review page says it reviews "at least 50% of submissions in less than 24 hours and 90% in less than 48 hours." When I timed all 64 App Review decisions on my account last weekend, the median was 73 hours, already worse than Apple's promise. Nothing else on my account ever waited a clean 168.

My read, and it is a read, not a leak: flagged accounts go into a holding queue with a one-week timer, and when the timer fires, the whole batch gets the same canned rejection. A human may press the button. Nobody is opening the apps. If you have a better explanation for 11 different apps landing on 7 days minus 15 minutes, I want to hear it.

I'm not the only one. Same week, same 30-second treatment

I went looking on X for other developers who got this in October 2026. It took one search. These are real posts, captured today, unedited.

On October 5, the same day as my first batch, @krPorsche918 posted that Apple rejected five of their apps "in the same minute, with the same sentence: Guideline 4.3 Spam." Their write-up has the best line anyone has written about this: "To me, 14 apps in 13 days was productivity. To Apple, it was a pattern." The same week, Apple approved all 53 in-app events on their live apps.

@krPorsche918 on X, Oct 5 2026, 275 views, captured 1:15 PM ET Oct 19 2026, real and unedited.

On October 8, @vovalukashov (Luka Shaw) asked the question everyone in the replies was thinking: "Looks like Apple stopped approving my new apps... Is this what happens to everyone who builds small apps that do one thing?" Three new apps rejected in four weeks, one of them twice. "Updates to my old apps still go through." 62K people saw it.

@vovalukashov on X, Oct 8 2026, captured 1:15 PM ET Oct 19 2026, real and unedited.

And on October 12, at 6:26 PM Eastern, 22 minutes after my second batch of 11 hit, @martindonadieu (Martin Donadieu, the Capgo founder) posted his App Store Connect screen: a wall of red "Rejected" badges and the caption "Moved from no review to almost all rejected LOL". 223K views. Three days later he posted again: rejected for 4.3 a second time, for a 100% local ticketing app that ran a 500-person event this summer and is already on Google Play.

@martindonadieu on X, Oct 12 2026, 22 minutes after our second batch, captured 1:15 PM ET Oct 19 2026, real and unedited.

Look at the pattern across all four of us. New apps die. Updates pass. My own account shows it: in the same window that killed 11 new apps twice, Apple approved updates to Chain and Minder (October 12) and six updates on September 29. All six of those September updates added the same paywall pattern the rejected apps had (Pro.swift; Purchases.swift in Chain), committed the same morning (September 26, between 9:26 and 9:29 AM Eastern). Same code, same day. Updates: approved in about 3 days. New apps: rejected twice. Luka says his updates go through. Porsche got 53 in-app events approved. Martin's existing apps are still up.

So here is where I disagree with Luka. His conclusion was "I guess it's a sign to focus on the ones already in the App Store." That is exactly the behavior this filter is training into every small developer, and it is the wrong lesson. The filter is not saying your new app is bad. It is saying your account is shipping too fast for Apple's comfort. Those are different problems with different fixes.

Was Apple right? I ran a spam detector on my own apps

Fair question: maybe my apps really are clones. I am one developer with 20 iPhone apps in 30 days, built with AI coding agents, all from the same pipeline. If anyone deserves a 4.3, it might be me. So this afternoon I tested it, instead of arguing about it.

The experiment: for each of my 20 local app repos, take the git commit Apple actually saw (for the 8 live apps, the last commit before their first approval; for the 11 rejected apps, the last commit before the October 5 resubmit). Then compare every pair of apps, 190 pairs, on five things a 4.3 filter could plausibly look at:

File tree overlap: Jaccard similarity of the tracked file paths (shared paths divided by all paths). This is the "skeleton".
Identical files: files that are byte-for-byte the same after replacing the app's own name.
Swift line overlap: share of distinct non-trivial Swift source lines the two apps have in common.
Store text overlap: overlap of three-word phrases in the App Store description.
Screenshot distance: the closest pair of store screenshots between the two apps, by 256-bit average hash (lower means more alike).

git ls-tree of each repo at its submit-time commit, fingerprint.py, 1:19 PM ET Oct 19 2026.

The honest result first, because it does not flatter me: the rejected 11 really do share a skeleton. Their median file tree overlap is 0.76, against 0.56 for the live apps. They share a median of 14 identical files per pair against 5, and about three times the Swift lines (0.067 against 0.021). Clockout and Odometer have literally identical file trees: the same seven Swift files, with the same names, in the same folders. If Apple's filter looks at project structure inside the binary, my rejected batch lights up.

Now the part Apple should explain. The single most similar pair of apps in all 190 is Baseline Ledger and Fairway Ledger, my tennis journal and my golf journal. They share a third of their Swift lines (0.333), 20 identical files, a 0.90 file tree, the most similar store description and the closest screenshots of any pair. Both were approved, two days apart, on September 22 and 24. Both are live today. Chain and Quiver share a 0.968 file tree. Both live.

fingerprint.py, 55 rejected pairs and 28 live pairs, each repo at its submit-time commit, Oct 19 2026.

And the things a human reviewer actually looks at, the store page and the screenshots, do not separate the two groups at all. Store text overlap: 0.010 for rejected pairs, 0.009 for live pairs. Screenshot distance: 76 against 82. A person scrolling the listings could not tell the rejected apps were "more similar". Only a machine diffing the bundles could.

fingerprint.py run 1:19 PM ET Oct 19 2026.

The one file every rejected app had

The fingerprint that splits the groups cleanly is not a similarity score. It is one file. All 11 rejected apps shipped Sources/Pro.swift in their first submission. None of the 8 live apps had it at first approval. Pro.swift is a StoreKit 2 paywall: the app is free, and a one-time $4.99 purchase unlocks the full version. Here is the top of Odometer's, at the commit Apple reviewed:

// Sources/Pro.swift (odometer repo, commit af40d3658)
/// Odometer Pro: one non-consumable. Keeping one car on schedule is free forever; Pro is the
/// whole garage and the paperwork.
@MainActor
@Observable
final class Pro {
    static let productID = "com.mattbusel.odometer.pro"
    /// The first build that has Pro in it. Anything earlier had every feature.
    static let firstFreemiumBuild = 2

    enum Reason: String, Identifiable { case costs, garage, history, export, settings; var id: String { rawValue } }

    private(set) var unlocked: Bool
    private(set) var grandfathered = false
    private(set) var product: Product?

    var price: String { product?.displayPrice ?? "$4.99" }

    func ask(_ why: Reason) { if !unlocked { paywall = why } }
    ...
}

The files are not copies of each other (no two rejected apps have an identical Pro.swift; each has its own product, its own free tier and its own reasons to upgrade). But the shape is the same: one non-consumable, one Pro class, one paywall sheet. The live apps were approved without it and only went freemium later, through updates submitted on September 26, the same day as the 11 new apps. Those updates sailed through on September 29.

Here is what I think is really happening, and Apple will never say it out loud. A brand-new free app with a $4.99 unlock, from an account that drops 11 of them in one day, is the exact silhouette of a template farm. The 4.3 text and its sister rule 4.2.6 are written about "commercialized template or app generation services". In 2026, with every coding agent able to spit out an app a day, the template farm and the solo dev with Claude Code look the same from the outside. Apple's filter judges the silhouette, and the human who signs off never opens the app. Correlation, not proof: 19 apps is a small sample. But it is a cleaner split than anything in the guideline text.

What I sent back, and what came back: nothing

The 4.3 rejection comes with nine questions: what the app does, who it is for, how it differs, how you tested it, whether it shares code with your other apps, and so on. I answered every one, per app, honestly. Including the parts that probably hurt me, like this from Odometer's reply:

"No shared framework or asset pack. Every screen, model, illustration and text is specific to Odometer. Two files follow a pattern I reuse: the StoreKit 2 purchase handling for its one non-consumable (the paywall's text, free/Pro split and look are specific to the app), and a test-only driver that steps through the app's screens to record the walkthrough video and is inactive in normal use."

Then I filed appeals with the App Review Board through Apple's form, which takes at most 5 apps and 2,000 characters per reason, so it took three forms (5 + 5 + 1). The argument was simple: all 11 were rejected within one minute with word-for-word identical text, so no individual review happened, and I asked for a human to open each app.

That was October 5. I searched my inbox this morning for anything from Apple since. There are Apple Ads billing emails, an iPhone Duo pre-order ad, and a notice that the App Review Guidelines were revised on October 16. There is no email from App Review or the App Review Board since the second batch on October 12, and nothing at all about the appeals. 13.8 days and counting.

That October 16 revision is its own small insult. Apple rewrote seven parts of the guidelines (new rules on creative assets and hidden features, payment links, child safety). Guideline 4.3 was not one of them. In the middle of a public wave of 4.3 batch rejections, the rule stayed word-for-word the same.

Apple's own numbers say you are not special

Apple publishes a yearly App Store Transparency Report. The 2025 edition counts 9,100,620 submissions reviewed and 2,093,244 rejected, about 23%. The Design section, which includes spam and copycats, accounts for 415,532 rejections. Apple's May 2026 newsroom post says it rejected more than 371,000 submissions for copying other apps, spam, or misleading users.

Now look at the line nobody quotes. The same report counts 26,305 appeals of app removals and 423 restorations. That is 1.6%. Back in 2021, Apple's Senior Director of App Review said in a court filing that the team had more than 500 human reviewers and that less than 1% of rejections are appealed. Do the arithmetic yourself: 9.1 million submissions a year is roughly 25,000 a day. 371,000 spam-type rejections is about 1,000 a day. Nobody is opening 1,000 apps a day with care. The 30-second batch is not a glitch in that system. It is the system.

Hot takes, ranked

4.3 has become a volume tax on solo developers. It does not catch clones. My two most similar apps are live. It catches accounts that ship more than Apple thinks one person should. In the AI coding era, that is every indie dev who is any good.
The App Review Board is a black hole for batch rejections. My bet: these 11 appeals get no human reply before November, and if they ever do, it will be one templated paragraph for all 11.
Apple will never publish 4.3 numbers by itself. The transparency report lists "4.3.0 Spam" only for removals (418 apps), never for rejections, because a per-guideline count would show how much of the "spam" fight is really a throttle on new developers.
Updates pass because updates already make Apple money. An update to a live app is a known quantity with a payment history. A new app is a cost. Every account in this article got updates approved during the same weeks its new apps were killed. That is not a coincidence, it is a business model.
Google is going to eat this. Martin's app was on Google Play a week before Apple rejected it a second time. When the indie dev's first launch moves to Android, Apple's "quality" story gets a lot quieter.

How to survive a Guideline 4.3 spam rejection

This is what I would do differently, from the data above and Apple's own pages. It is the advice I am now following myself.

Never batch-submit new apps. One or two new apps per account per week. Porsche's "14 apps in 13 days" and my "11 in one day" got the same answer. Updates to live apps can go as fast as you like.
Reply, and do not resubmit. The rejection says it, and I ignored it. My resubmits landed on a seven-day timer and died in 27 seconds. Answer the nine questions in App Store Connect and wait.
Launch new apps without the paywall, add IAP in an update. 0 of my 8 approved apps had a paywall at first approval; 11 of 11 rejected apps did. Small sample, but it is the one clean split I found, and the freemium updates passed every time.
If your apps are variants, merge them. 4.3(a) literally tells you to ship one app and sell the variations as in-app purchases. If a reviewer could describe two of your apps with one sentence, they will.
Book a call with App Review. Apple offers 30-minute Webex appointments with App Review to discuss the guidelines. Almost nobody mentions this. It is the only channel where a human has to look at you. It is my next move.
Appeal with specifics, one appeal per submission. Apple's appeal page asks for "specific reasons why you believe your app complies". Timestamps of a batch rejection are specific. So far they have not been enough, so pair them with item 5.

If you want the pipeline these 20 apps were built and shipped with (from a Windows PC, no Mac), the complete iOS-on-Windows guide covers it, and what 20 real apps cost to build has the money side.

The numbers so far

Rejected under 4.3, twice: 11 apps (22 rejections), October 5 and October 12, 2026
Time to reject 11 apps: 30 seconds (Oct 5), 27 seconds (Oct 12)
Submit order vs reject order: Spearman -0.06 and 0.06 (no relationship)
Wait on round two: 167.7 to 167.9 hours for all 11 (Apple says 90% within 48 h)
Appeals filed: 3 forms covering 11 apps, October 5. Replies: 0 after 13.8 days (inbox checked 1:10 PM ET, October 19)
Live on the US App Store today: 8 apps (iTunes lookup, 1:12 PM ET October 19), unchanged since October 17
Most similar pair of all 190: Baseline Ledger + Fairway Ledger, 33% shared Swift lines. Both live.
Paywall at first submission: 11 of 11 rejected apps, 0 of 8 approved apps

The data, and how to rerun it

Decision timestamps: the 22 "There's an issue with your submission" emails from Apple's App Review sender, pulled from Gmail with their "Submitted:" lines (Pacific Daylight Time) on October 17 and re-checked on October 19 at 1:10 PM Eastern for anything newer (none). Fingerprints: fingerprint.py run at 1:19 PM Eastern October 19 over 20 local repos, each at the commit before its decisive submission (git rev-list -1 --before=...), reading files with git show, PNGs excluded from file comparisons, the app's own name replaced with a placeholder before hashing. Live status: the iTunes Search API lookup for my developer account, 1:12 PM Eastern. Posts by @krPorsche918, @vovalukashov and @martindonadieu were captured from X at about 1:15 PM Eastern October 19, real and unedited.

So, @martindonadieu, @vovalukashov, @krPorsche918: check your own rejection emails. Did yours land within seconds of each other, and did your resubmits wait exactly a week? If three more accounts show the same 168-hour timer, this stops being my theory. Everyone else: has Apple's App Review Board ever actually answered your 4.3 appeal, and how long did it take? Drop your numbers in the comments.

Building iPhone apps without a Mac and want the pipeline set up on your own repo (signing, screenshots, fastlane submission and the review notes I now use)? The No-Mac iOS Pipeline is $299, first TestFlight build in 5 business days.

A macOS disk cleaner that shows the cost before it deletes

ran Guo — Mon, 19 Oct 2026 12:41:16 +0000

Most cleanup tools ask for the same thing: trust. You press Clean, a progress bar moves, a number goes up. What the number never tells you is whether the 12 GB it just removed was a cache the app rebuilds in ten minutes, or a project you spent the week on.

DiskWise is an open-source macOS cleaner built around one rule: before anything moves, show the cost of every item.

Two labels instead of a score

The scanner produces a list of reclaimable directories. Every entry gets one of two labels:

Harmless — caches, logs, temp files. They come back when needed.
Downloads again — recoverable, but only by downloading or rebuilding.

No score out of 100. A score invites arguments; a label forces a decision. Anything the scanner cannot describe with confidence stays out of the cleanup list.

Three steps, one delete path

Plan. The scan groups directories by cause: app caches, Xcode build artifacts, simulator data, node_modules, Homebrew downloads, Docker layers, AI coding tool sessions. You pick.
Confirm. The app restates the selection with paths and sizes. It feels redundant until you are staring at twelve similarly named folders.
Receipt. When it finishes, you get a summary of what moved, what is in the Trash, and how to undo.

The delete path is deliberately boring: FileManager.default.trashItem, plus two guards — a protected-path check and an allowed-root check. No rm, no privileged helper. Undo restores from the Trash, so there is no private journal that can disagree with the filesystem.

The scan is conservative, because the allowlist is the whole product

Every entry carries a written explanation: what this folder is, and what happens after it is removed. Developer locations are treated differently from caches. Xcode DerivedData, simulator devices, package manager caches, and node_modules are presented read-only: the app points at them, you decide what to do.

That is also why there is no "clean everything" button. Aggressive cleanup is easy to demo and hard to forgive.

The same guardrails for agents

diskwise mcp starts a local stdio MCP server with six tools: scan_disk, explain_path, plan_cleanup, execute_cleanup, undo_cleanup, cleanup_history. The protocol surface is intentionally narrow. An agent gets a plan it must execute explicitly, deletion still goes to the Trash, and the last operation can be undone. No network access, no telemetry.

What it is not

It is not a speed-up tool, an antivirus, or an app uninstaller. It shows where the space went, explains what each removal costs, and keeps the whole thing reversible. That is the entire product.

Repo: https://github.com/DreamOfXM/diskwise — free and open source, available from GitHub Releases and the Mac App Store.

Tagara: hold a key, speak, and the text appears at the cursor

Mateus Fonseca — Sun, 18 Oct 2026 21:51:54 +0000

Most of what I write during the day is faster to say than to type. So I built Tagara, a small dictation app for macOS.

Hold the right ⌥ key, talk, let go. The text is typed wherever your cursor is: the terminal, Slack, the browser, any text field. A sentence becomes text about 0.2–0.4 s after you release the key.

Everything runs on your Mac. Transcription uses the open Parakeet model on Apple Silicon's Neural Engine. The audio is never saved or sent anywhere, and there's no account. When idle it uses 0% CPU and the mic stays closed.

English and Portuguese, detected on every dictation
Puts your clipboard back the way it was after typing
Local history of the last 50 dictations (you can turn it off)
Native SwiftUI menu bar app, light and dark mode

Free and open source (MIT). macOS 15+, Apple Silicon. It isn't signed with an Apple developer certificate yet, so macOS asks you to allow it once.

Site: https://mateusfonsek.github.io/tagara/
Code: https://github.com/mateusfonsek/tagara

Feedback welcome, especially on accuracy and latency on different Macs.

iOS development on Windows: the complete guide (21 apps, no Mac)

Matt Busel — Sun, 18 Oct 2026 20:28:04 +0000

Originally published at tensorust.com.

TL;DR: You can do iOS development on Windows in 2026 if you rent the Mac part by the minute. I shipped 21 iPhone apps to App Store Connect from a Windows PC between September 10 and September 27, 2026, and 8 are live on the US App Store today. For this guide I pulled every CI run, every job step, every commit and every App Review email behind them on October 18: the median app went from its first commit to its first App Store submission in 2.2 hours, a release costs about 4 minutes of rented Mac time, and the thing that stopped 13 of the 21 apps was never Windows. It was App Review.

Short answer for the search. Xcode only runs on macOS, so "iOS development on Windows" really means splitting the work. You write the Swift, the project file, the store listing and the release scripts on Windows. A macOS machine you never touch compiles, signs and uploads. The cheapest version of that machine is a GitHub Actions macOS runner, which GitHub does not charge for on public repositories. You still need the $99 a year Apple Developer Program. You do not need Keychain Access, Xcode's Organizer window, or a Mac on your desk.

This is the pillar guide for everything I have written about the pipeline. It walks the whole path once, from an empty folder on Windows to "Ready for Distribution", and links the deep-dives where each step gets its own article: the CI pipeline and signing, what the 20 paid-for builds really cost, how long App Review took across 64 decisions, and one of the apps that came out of it. Everything below is real code from the app repos and real numbers pulled today.

Every app from first commit to today: git, the GitHub Actions API, Apple's App Review emails and the iTunes lookup API, pulled Oct 18 2026, 4:12 to 4:20 PM ET. Static version: timeline.png.

The data behind this guide

Every number here comes from records the pipeline already leaves behind, pulled on October 18, 2026 between 4:12 and 4:20 PM Eastern. Nothing was rebuilt for the article and no app was touched.

GitHub: all 384 workflow runs in the 21 app repos, every commit, and for each of the 81 successful App Store runs, every step with its start and end time, through the workflow runs and workflow jobs REST APIs.
Apple's emails: the 64 App Review decisions from the review time article, each with Apple's own "Submitted" timestamp. I checked the inbox again this morning: no new decisions since October 12.
The App Store: the iTunes lookup API for every app on my developer account, with version, release date and file size.
The code: a shallow clone of each repo, counting non-blank lines of Swift.

The collector is 40 lines of Python around the GitHub CLI. This is the core of it (collect.py, trimmed):

def api(path):
    r = subprocess.run(["gh", "api", "-H", "Accept: application/vnd.github+json", path],
                       capture_output=True, text=True, encoding="utf-8")
    if r.returncode != 0:
        if "429" in r.stderr or "rate limit" in r.stderr.lower():
            sys.exit("RATE LIMIT, stopping")
        return None
    return json.loads(r.stdout)

for repo in REPOS:
    runs, page = [], 1
    while True:
        d = api(f"repos/Mattbusel/{repo}/actions/runs?per_page=100&page={page}")
        if not d: break
        runs += d["workflow_runs"]
        if len(d["workflow_runs"]) < 100: break
        page += 1
    jobs = {}
    for r in runs:
        if r["name"] == "App Store" and r["conclusion"] == "success":
            jobs[r["id"]] = api(f"repos/Mattbusel/{repo}/actions/runs/{r['id']}/jobs")

Point it at your own repos and you get the same picture of your own pipeline: where the minutes go and which steps fail. It costs a few hundred API calls, well inside GitHub's hourly limit.

The headline numbers, before the how-to:

53,932 lines of Swift pushed to the 21 public repos, median 2,308 non-blank lines per app (the local working copies hold a bit more). No .xcodeproj in any of the 21 repos.
384 CI runs: 139 App Store runs, 165 Build runs, 18 review-video recordings, 62 GitHub Pages deploys. About 2,572 minutes on macOS runners, queue to finish.
First commit to first App Store submission: median 2.2 hours, fastest 25 minutes (Race Pace, September 27).
First submission to approval, for the 8 apps that got one: median 4.4 days, range 3.7 to 7.2.
Status today: 21 built, 21 submitted, 8 approved, 8 live. 0 of 21 approved on the first try.

What you can and cannot do on Windows

The split is cleaner than most forum threads make it sound. Apple's toolchain (the compiler with the iOS SDK, the code signer, the Simulator and the uploader) only ships inside Xcode, and Xcode only runs on macOS. Everything that is text, or talks to Apple over HTTPS, works from Windows.

Task	Where it ran for the 21 apps	Tool
Writing Swift and SwiftUI	Windows	any editor + coding agents
The Xcode project	Windows (as YAML), generated on the Mac	XcodeGen
Bundle ID, listing text, age rating, review notes, screenshots upload, in-app purchases	Windows	App Store Connect API from Python
The distribution certificate	Windows, once	Python `cryptography` + the API
Compiling for iOS, unit tests, Simulator screenshots	rented Mac	`xcodebuild`, `simctl`
Signing, uploading, submitting for review	rented Mac	fastlane
Creating the app record	a browser, once per app	App Store Connect website

That last row is the one surprise. The API can edit almost everything about an app, but our POST /v1/apps came back 403, so each new app record is one form in the App Store Connect website. It takes about a minute. Every other field is scripted.

What runs where in the pipeline behind the 21 apps.

Your options for the Mac part, compared

You need some macOS machine for the compile-sign-upload half. Here are the real choices, with what I could verify about each on October 18:

Option	What it is	The catch
GitHub Actions macOS runner (what I used)	A fresh macOS VM per job, Xcode preinstalled	Free on public repos. Private repos pay $0.062 a minute for the standard 3 or 4 core macOS runner. No screen: everything is scripted.
Expo EAS Build	If you write React Native with Expo, "iOS builds run on macOS runners hosted in Expo's macOS cloud"	Only for Expo/React Native projects. You trade Swift for JavaScript.
AWS EC2 Mac	A real Mac mini in a data center	A minimum allocation of 24 hours per dedicated host, so even a 4 minute build bills a day.
Cloud Mac rental by the month	A remote desktop on a Mac	You get the GUI, but you are paying for a whole machine to sit idle between releases.
Flutter	Cross-platform UI in Dart	Flutter's iOS setup page starts with installing Xcode. You still need one of the Macs above to build for iOS.
macOS in a VM on your PC	The "Hackintosh" route	Apple's macOS license limits installs to Apple-branded hardware. I did not try it and would not build a business on it.

My opinion: for a solo developer or a small studio, the CI runner wins by a mile. You only ever need the Mac for about 4 minutes per release, the machine is fresh every time (no "works on my Mac"), and the whole setup lives in one file in the repo. The cost of that choice is that you can't click anything, which turned out to be a feature: every fix became a line in a file the next app could read.

Step 1: get Swift onto your Windows machine

You don't strictly need a Swift compiler on Windows. None of the 21 apps were compiled locally; the feedback loop was a CI run in "compile" mode, whose compile step took a median of 35 seconds across 37 runs. Add the runner's startup and you get an answer in under two minutes.

If you want local feedback anyway, Swift has an official Windows toolchain, installed with winget install --id Swift.Toolchain -e --source winget after Visual Studio's build tools, and the Swift extension for VS Code gives you completion and errors. The limit is the SDK: SwiftUI, UIKit, StoreKit and WidgetKit are Apple frameworks, so on Windows you can compile and test the plain-Swift parts (your models, your date math, your parsers) but not the screens.

That split is a decent design rule anyway: keep the logic that matters (streak math, scoring, pricing) in plain Swift files with no import SwiftUI, and keep the views thin. Coding agents are much better at code they can reason about without a screen, and so are you.

What you do need on Windows: git, Python 3 (for the App Store Connect scripts), and the GitHub CLI to start the CI runs. If you run coding agents on this, read what broke running 20 agents on one PC first.

Step 2: describe the project in YAML, never in Xcode

An Xcode project file (project.pbxproj) is a large generated file with random IDs that you can't sensibly edit by hand, and you can't open Xcode on Windows to edit it for you. So the 21 repos don't have one. XcodeGen builds it from a short YAML file at the start of every CI run. This is Chain's real spec, trimmed (project.yml; Chain has an app plus a widget extension):

## Chain, XcodeGen project spec. The .xcodeproj is generated in CI, never committed.
name: Chain
options:
  bundleIdPrefix: com.mattbusel
  deploymentTarget:
    iOS: "17.0"
settings:
  base:
    MARKETING_VERSION: "1.2"
    CURRENT_PROJECT_VERSION: "1"
    CODE_SIGN_STYLE: Manual
    DEVELOPMENT_TEAM: ${DEVELOPMENT_TEAM}
targets:
  Chain:
    type: application
    platform: iOS
    dependencies:
      - target: ChainWidgets
    sources:
      - path: Sources
      - path: Resources/Assets.xcassets
        buildPhase: resources
    entitlements:
      path: Resources/Chain.entitlements
      properties:
        com.apple.security.application-groups:
          - group.com.mattbusel.chainhabits
    settings:
      base:
        PRODUCT_BUNDLE_IDENTIFIER: com.mattbusel.chainhabits
        PROVISIONING_PROFILE_SPECIFIER: "${APP_PROFILE}"
  ChainWidgets:
    type: app-extension
    platform: iOS
    sources:
      - path: Widgets
      - path: Sources/Shared

Three details carry weight. DEVELOPMENT_TEAM and the profile names come from environment variables, so no account identifier sits in the repo. CODE_SIGN_STYLE: Manual is deliberate; the signing section below explains why automatic signing can't work without a registered iPhone. And because the project is generated, there is never a merge conflict in a pbxproj, which matters a lot once two agents edit the same app.

The generate step on the runner took a median of under one second across 81 successful runs. It's the cheapest step in the pipeline and it removes the one file that makes iOS repos hostile to Windows.

Step 3: rent the Mac with one workflow file

All of the Mac lives in .github/workflows/appstore.yml. It has one input with three modes, started from Windows with gh workflow run appstore.yml -f action=dry_run:

on:
  workflow_dispatch:
    inputs:
      action:
        description: "What to do"
        required: true
        default: compile
        type: choice
        options:
          - compile       # build + unit tests, no simulator screenshots
          - dry_run       # build, sign, upload; do not submit
          - release       # everything, including submit for review

jobs:
  ship:
    runs-on: macos-15
    timeout-minutes: 90

compile is your local build button. dry_run puts a signed build in App Store Connect (and TestFlight) without asking Apple to review it. release does the same and submits.

Two runner traps cost real runs, and both are in the file as comments now. First, the Xcode that isn't there. On the macos-15 image, /Applications/Xcode_26.app existed but had no toolchain inside, so selecting it failed while ls listed it happily. The fix picks the newest Xcode 26 that is real:

      - name: Select Xcode 26
        run: |
          chosen=""
          for app in $(ls -d /Applications/Xcode_26*.app 2>/dev/null | sort -Vr); do
            if [ -d "$app/Contents/Developer" ]; then chosen="$app"; break; fi
          done
          if [ -z "$chosen" ]; then
            echo "no usable Xcode 26:"; ls /Applications | grep -i xcode; exit 1
          fi
          sudo xcode-select -s "$chosen/Contents/Developer"

Second, simulators that move. A hardcoded device name worked for six runs and failed on the seventh with "Unable to find a device matching the provided destination specifier", because the runner fleet doesn't always carry the same simulators. Now the newest available iPhone wins:

          name=$(xcrun simctl list devices available \
                 | grep -oE "iPhone [0-9]+ Pro Max" | sort -Vr | head -1)
          echo "SIM_NAME=$name" >> "$GITHUB_ENV"

Here is what a whole release looks like when it works, Chain 1.2 on October 8:

How Chain 1.2 went from one command on Windows to App Store Connect on Oct 8 2026. Step times from the GitHub Actions run log.

Where the Mac minutes actually go

This is the new measurement for this guide. GitHub's jobs API returns every step of every job with its start and end time, so I summed the time inside each step for all 81 successful App Store runs across the 21 apps: 646 minutes of step time in total.

Step start and end times from the GitHub Actions jobs API, 81 successful App Store runs in 21 repos, Sep 10 to Oct 9 2026, pulled Oct 18 2026.

The surprise is the top bar. 34% of all the Mac time went to capturing App Store screenshots in the Simulator, more than signing, uploading and submitting combined (16%). The unit tests of the first three apps (the games, the only ones with an XCTest suite in the release lane) took another quarter. The step everyone fears, code signing, was a rounding error once it worked: importing the certificate took a median of 1 second. Finding a simulator took 7%, which is the cost of not hardcoding one, and worth it.

The pipeline changed shape halfway through September, and the data shows exactly what that bought. The early apps captured fresh screenshots (and, for the three games, ran their tests) on every App Store run. Starting with the September 18 batch, most apps committed their screenshots to the repo once, and the App Store run became compile, sign and upload:

Median job time of a successful App Store run by where its screenshots came from. GitHub Actions jobs API, pulled Oct 18 2026.

The median successful run dropped from 12.0 minutes (44 runs) to 4.1 minutes (37 runs), and the slowest 10% went from 17.8 to 5.3 minutes. In fairness to the slow lane, it also ran the unit tests, so screenshots are not the whole difference. The point stands: a release should ship what a human already looked at, not re-shoot it. Tests and screenshots belong in the Build workflow that runs on every push, not in the one that talks to Apple.

The queue was never the problem. The median wait from "run requested" to "job started" was 10 seconds; the worst one was 17 minutes.

A release in the fast lane: Chain 1.2, Oct 8 2026, 4m 9s of job time. This was a dry_run, so it stopped after the upload.

Step 4: signing without a Mac (the part that broke)

Code signing is how Apple knows a build came from you. It takes a certificate (a public key Apple has signed), its private key, and a provisioning profile that ties both to your app ID. On a Mac, Xcode hides all of it. On a CI runner it's where the first app spent a morning. The full story is in Build an iOS app on Windows; here is the short version and the code that matters.

Glyphstorm's App Store runs on Sep 10 2026, 5:49 to 6:38 AM ET, the morning signing broke (github.com/Mattbusel/glyphstorm, captured Oct 16).

The expensive mistake was letting CI create the certificate. When fastlane's certificate step runs on a runner, the private key is born on a machine that is deleted minutes later. Apple keeps a certificate nobody can ever use again, and Apple limits how many distribution certificates an account can hold. Three failed runs orphaned three of them on September 10 before anyone noticed.

Never let CI create a certificate. Make the key once on your own machine, and let CI only import it.

So the key is made on Windows, by a Python script that generates it with the cryptography library, asks Apple's API to sign it, and pipes a .p12 straight into gh secret set. Every API call uses a short-lived token signed with your App Store Connect key (Store/asc.py, the token function; the key ID and issuer ID come from environment variables):

def token() -> str:
    """A fresh twenty minute ES256 token.

    Apple rejects anything longer lived than that, so this is minted per run
    rather than cached anywhere.
    """
    private_key = KEY_PATH.read_text()
    now = int(time.time())
    payload = {
        "iss": ISSUER_ID,
        "iat": now - 60,
        "exp": now + 20 * 60,
        "aud": "appstoreconnect-v1",
    }
    return jwt.encode(
        payload, private_key, algorithm="ES256", headers={"kid": KEY_ID, "typ": "JWT"}
    )

That twenty minute limit is Apple's rule, not a choice. On the runner, the certificate goes into a throwaway keychain, and one line in this step decides whether the job finishes or hangs forever:

          keychain="$RUNNER_TEMP/signing.keychain-db"
          security create-keychain -p "" "$keychain"
          security set-keychain-settings -lut 21600 "$keychain"
          security unlock-keychain -p "" "$keychain"
          echo "$DIST_CERT_P12" | base64 --decode > "$RUNNER_TEMP/dist.p12"
          security import "$RUNNER_TEMP/dist.p12" -k "$keychain" \
            -P "$DIST_CERT_PASSWORD" -T /usr/bin/codesign -T /usr/bin/security
          # Without the partition list, codesign blocks on a GUI prompt that
          # nobody can answer and the job hangs until it times out.
          security set-key-partition-list -S apple-tool:,apple:,codesign: \
            -s -k "" "$keychain" >/dev/null

Then fastlane asks for the App Store profile directly and signs manually. Automatic signing resolves a development profile during the archive, and a development profile needs at least one registered iPhone. An account with no devices gets "Your team has no devices from which to generate a provisioning profile" on an App Store build, which needs no device at all. Asking for the distribution profile directly skips the step that can't succeed.

fastlane reads the API key from the secret, so there is no Apple ID password and no two-factor prompt anywhere (fastlane/Fastfile):

  def asc_key
    app_store_connect_api_key(
      key_id: ENV.fetch("ASC_KEY_ID"),
      issuer_id: ENV.fetch("ASC_ISSUER_ID"),
      key_content: ENV.fetch("ASC_KEY_CONTENT"),
      is_key_content_base64: true,
      in_house: false
    )
  end

The app_store_connect_api_key action is the one to read. in_house: false tells it this is a normal developer account, not an enterprise one; getting that wrong produces an authentication error that says nothing useful. Build numbers are the other trap (Apple refuses a repeated one), so each build asks App Store Connect for the latest and adds one.

Step 5: screenshots and the listing, all from Windows

Apple wants iPhone screenshots at the 6.9 inch size, 1320 by 2868 pixels (see the screenshot specifications). Without a Mac you can't click around a Simulator, so each app takes a launch argument that opens a given screen with demo data, and the Build workflow loops through them on a fresh simulator with the status bar set to the classic 9:41 and a full battery. A fresh simulator matters: booting the runner's default one hung for over 15 minutes once.

The raw PNGs come back as a build artifact, a script on Windows puts a headline on each one, and the finished set is committed to fastlane/screenshots/. Chain's in-app purchase code even knows about it: in demo mode the store screenshots show the whole app unlocked, and the paywall shot shows it locked.

Four of Chain's ten App Store screenshots: raw captures from the CI simulator, headlines added by a script on Windows.

The listing text lives in plain files (fastlane/metadata/en-US/name.txt, subtitle.txt, description.txt, keywords.txt and so on), so it's reviewed and versioned like code. A second script pushes the rest of the listing through the API. Its header says what it does and the one thing Apple won't let it do (Store/listing.py):

"""The rest of the listing: age rating, review details, screenshots.

Everything here needs the app record to already exist, which is the one
step Apple's API refuses to do (`POST /v1/apps` returns 403 by design, so an app
record has to be created once in the web UI).

Usage:
    python Store/listing.py age-rating
    python Store/listing.py review-details
    python Store/listing.py screenshots
    python Store/listing.py finish        # everything that needs no binary
"""

Write the review notes like a test script for a stranger. Chain's notes tell the reviewer exactly how to reach each paid feature on a fresh install ("add three habits, then tap New habit again"), what the Health permission reads and why, and that no login is needed. Apple's 2.1 "Information Needed" responses were the second most common reason in my data, and most of them were answered by notes like these plus a video.

Step 6: testing when you can't hold the iPhone

You can't plug a phone into the CI runner, so testing happens in three layers.

A build on every push. The Build workflow compiles for the Simulator and walks every screen to capture screenshots, so a screen that crashes fails the push. Across the 21 repos it ran 165 times: 101 green, 19 red, 45 cancelled. Only the first three apps also run an XCTest suite in CI. That's thinner than it should be; if I started again, the plain-Swift logic would get tests on every push.
A recorded walkthrough. 20 of the 21 apps have a -demoAutoplay launch argument that clicks through the main flow by itself. A third workflow records it with simctl, and the video goes to App Review when they ask how something works. It ran 18 times, 18 green.
TestFlight. Every dry_run upload lands in TestFlight, so anyone with an iPhone can install the real signed build before it is submitted.

The recording step is short enough to copy (.github/workflows/review-video.yml, trimmed):

          rt=$(xcrun simctl list runtimes | grep -oE "com.apple.CoreSimulator.SimRuntime.iOS-[0-9-]+" | sort -V | tail -1)
          udid=$(xcrun simctl create review "com.apple.CoreSimulator.SimDeviceType.iPhone-16-Pro-Max" "$rt")
          xcrun simctl boot "$udid" || true
          xcrun simctl status_bar "$udid" override --time "9:41" --batteryState charged --batteryLevel 100 || true
          xcrun simctl install "$udid" "$app"

          xcrun simctl io "$udid" recordVideo --codec h264 --force capture/review.mp4 &
          rec=$!
          xcrun simctl launch "$udid" com.mattbusel.chainhabits -demoAutoplay
          data=$(xcrun simctl get_app_container "$udid" com.mattbusel.chainhabits data)
          for i in $(seq 1 600); do
            if [ -f "$data/Documents/demo_done" ]; then break; fi
            sleep 0.5
          done
          kill -INT $rec

The trick is the demo_done file: the app writes it when the walkthrough ends, so the recording stops at the right frame instead of after a guessed sleep. A recording run averaged about 8 minutes (148 minutes over 18 runs), which is why it lives in its own workflow and only runs when a review needs one.

A word on what this doesn't catch. The Simulator is not an iPhone: no real camera, no real motion sensors, no real HealthKit data. Minder's eyes react to the phone being picked up (Core Motion), and no Simulator run can exercise that; it needs a real device through TestFlight. If your app leans on hardware, budget for a cheap used iPhone or a friend with one. My bet is that this is the one place a Windows-only setup genuinely costs you something.

Step 7: in-app purchases with StoreKit 2

All 8 live apps are free with optional one-time purchases. The purchase code is plain StoreKit 2 and compiles on the runner like anything else. The part worth copying is how Chain decides what the user owns (Sources/Purchases.swift, trimmed):

    func refreshEntitlement() async {
        var has: Set<String> = []
        for await result in Transaction.currentEntitlements {
            if case .verified(let t) = result, t.revocationDate == nil, t.productType == .nonConsumable { has.insert(t.productID) }
        }
        // currentEntitlements works offline from StoreKit's own cache, so this is the truth,
        // including a refund taking an unlock away.
        owned = has
        publish()
    }

Transaction.currentEntitlements is the source of truth, refunds included, so there is no server and no receipt parsing. When Chain went from paid to free, people who had paid were grandfathered by reading AppTransaction, which says which build a person first downloaded:

    func checkPaidEra() async {
        guard !grandfathered, let result = try? await AppTransaction.shared,
              case .verified(let app) = result, app.environment == .production else { return }
        let build = Int(app.originalAppVersion.split(separator: ".").first ?? "") ?? Int.max
        if build < Purchases.firstFreeBuild && app.originalPurchaseDate < Purchases.paidCutoff {
            grandfathered = true
            UserDefaults.standard.set(true, forKey: "chain.grandfathered")
            publish()
        }
    }

The app.environment == .production guard matters: in the sandbox and in App Review, everyone looks like an original buyer, and the reviewer has to see the real paywall.

The purchases themselves are created from Windows through the API, with one exception that cost an evening. From the header of Store/iap.py:

Apple's API refuses the FIRST non-consumable of an app (STATE_ERROR.FIRST_NON_CONSUMABLE_MUST_BE_SUBMITTED_ON_VERSION),
even with the version already in an open review submission. For that one, attach it by hand on the version page
(In-App Purchases and Subscriptions, Select, tick it, Done), then Add for Review and Submit. Later purchases
can go through `submit`.

So the first purchase rides along with an app version, by hand, once. After that, purchases review fast: the 5 purchase-only submissions in my data were decided in a median of 12.2 hours, all approved. That's the quickest thing Apple reviews.

The errors you will see, and what each one really means

Apple's error messages are written for someone sitting at Xcode. On a CI runner they point the wrong way more often than not. These are the real ones from the 21 repos' logs and workflow comments, in roughly the order a new pipeline meets them.

The message	What it really means	The fix
Selecting `/Applications/Xcode_26.app` fails, though `ls` lists it	The runner image has a stub `Xcode_26.app` with no toolchain inside	Pick the newest Xcode 26 that has `Contents/Developer` (snippet above)
"Unable to find a device matching the provided destination specifier"	Not your project. This runner doesn't carry that simulator today	Choose the newest available iPhone at runtime
"Your team has no devices from which to generate a provisioning profile"	Automatic signing wants a development profile, which needs a registered iPhone, even for an App Store build	Manual signing with an App Store profile
"Could not find the newly generated certificate installed"	CI just created a certificate whose private key dies with the runner	Make the certificate once on your PC; revoke the orphans
"MAC verification failed during PKCS12 import (wrong password?)"	The password is fine. The `.p12` uses an encryption format the macOS `security` tool won't read	Export the `.p12` in the legacy format
A signing step that never ends	`codesign` is waiting on a keychain permission dialog nobody can click	`security set-key-partition-list` after the import
"You can't enable both :development and :adhoc"	fastlane counts a flag that is present as chosen, even when set to false	Leave those arguments out entirely
`Cannot find "MyApp.xcodeproj/../YES"`	`increment_build_number` drives Apple's `agvtool`, which gets confused by a generated project	Pass `CURRENT_PROJECT_VERSION` as a build setting: latest TestFlight build + 1
Simulator boot hangs for 15+ minutes	The runner's default simulator is in a bad state	Create a fresh device with `simctl create` per job
`403` on `POST /v1/apps`	The API does not create app records	Make the record once in the website; script everything else
`STATE_ERROR.FIRST_NON_CONSUMABLE_MUST_BE_SUBMITTED_ON_VERSION`	An app's first one-time purchase has to ride along with a version	Attach it by hand on the version page once; later purchases go through the API

Eleven messages, and every one of them cost at least one run before it was understood, most of them in the first two days. If you hit one that isn't on this list, the jobs API trick from the data section tells you exactly which step it came from and how long it ran before it died, which is usually enough to tell a configuration problem (fails in seconds) from a hang (fails at the timeout).

The learning curve: 13 failures, then zero

The pipeline wasn't good on day one. The first two apps, Glyphstorm and Clear the Strait, ate 13 failed App Store runs each, most of them on September 10. Pocket Beings, a day later, had 5. By the September 24 batch it was mostly zero, and the last ten apps shipped with no failed App Store run at all. Climbbook, Cutoff, Parked and Race Pace each went to App Store Connect on their first try on September 27.

Failed App Store workflow runs per app, apps in order of their first run. GitHub Actions API, pulled Oct 16 2026 (the Oct 18 pull is the same, 43 failures in all).

Nothing clever happened in between. Every failure became a comment in the workflow file, and the next app started from that file. That's the whole method, and it's why the data matters more than the code: the failures are concentrated in the first two days, so if you copy a pipeline that has already eaten them, you skip that part. Since the start, 139 App Store runs: 81 succeeded, 43 failed, 15 cancelled. The last two failures were version bumps on the evening of October 8 (Eastern); Pocket Beings went green two minutes after its failure.

A practical warning if a coding agent drives this loop for you: an agent fixing signing at 6 AM will happily "fix" the check instead of the problem. The guardrails I use are in stop coding agents editing tests.

App Review is the real bottleneck

Here's what the timeline at the top of this page shows when you look at it as a funnel. Every one of the 21 apps got a green, signed build and went to App Review. Thirteen are still not on the store.

Every app built Sep 10 to Sep 27 2026, status on Oct 18 2026. GitHub API, App Review emails, iTunes lookup.

The build half is fast and boring now. The first commit to first submission took a median of 2.2 hours, and 13 of the 21 apps were submitted within 3 hours of their first commit (the others waited on purpose, for batch submissions). Then Apple's half starts, and it is measured in days.

From the App Store review time data: 64 decisions, median wait 73 hours, against Apple's stated 50% within 24 hours and 90% within 48. Updates to apps already live took a median of 64 hours. New apps that got approved took a median of 70 hours on the round that approved them, and none of the 21 was approved on its first submission.

Every App Review decision for the 21 apps, Sep 10 to Oct 12 2026, from Apple's own emails (pulled Oct 17 2026; no new decisions as of Oct 18).

Plan for it like this: the first submission of a new app on a new account will probably come back with a question (guideline 2.1, "Information Needed"). Answer it with a short screen recording and clear review notes, and the second round is where approval usually lands. For the 8 apps that made it, first submission to approval took a median of 4.4 days, and first commit to approval 5.3 days.

Guideline 4.3: what happens when shipping gets too cheap

The 13 apps that aren't live are mostly one story. On October 5, Apple rejected 11 apps in 30 seconds under guideline 4.3 (spam) and 4.2.6, after they had waited 8.7 to 9.3 days. I replied to each and resubmitted; on October 12, all 11 came back rejected again, in another 30 second burst, exactly 7 days later.

The two guideline 4.3 batches as they landed in the inbox, Eastern time.

Look at which apps those are: the September 24 to 27 batches, the ones where the pipeline had zero failed runs. That's the plot twist of the whole project. Once shipping an app costs nothing, the question Apple asks changes from "does it work" to "is this different enough from everything else this account and the store already have". Guideline 4.3 is written for that: it covers near-copies of the same app and piling into categories that are already saturated.

My read, which I can't prove: a new account sending eleven utility apps in three days looks like a template farm to a reviewer, whatever is inside each binary. If I did it again, I'd ship two or three apps, let them pick up real users, and space the rest out. The pipeline makes speed free. App Review charges for it anyway.

What it costs

The full breakdown, with a calculator, is in iPhone app development cost. The short version for the Windows route:

Item	What I paid	If the repos were private
Apple Developer Program	$99 a year	$99 a year
A Mac	$0	$0
CI: 322 macOS runs, about 2,572 minutes	$0 (public repos)	about $159 at $0.062 a minute
One release today (4.1 min median)	$0	about 25 cents
Apple's cut of sales	15% under the Small Business Program

Every cost line for 20 of the apps, from the iPhone app development cost article (git, GitHub Actions API, iTunes lookup, pulled Oct 17 2026 at 1:12 PM ET; line counts from the local working copies).

The cost that doesn't show up in that table is the one in the funnel: an approved listing. Money can't buy you past guideline 4.3, only a different-enough product can.

What came out the other end

Eight apps on the US App Store as of this afternoon, all free with optional purchases. Every one of them is under 3 MB, because SwiftUI apps with no third-party SDKs are small: Clear the Strait, a game, is 0.6 MB. Chain, with widgets, alternate icons and eight in-app purchases, is 2.9 MB.

iTunes lookup API (US) for version, release date and file size; non-blank Swift lines in each public GitHub repo; approval times from App Review emails. Oct 18 2026.

None of these were written in Xcode, and none of them know it. If you're curious what a SwiftUI app built this way looks like from the inside, Minder's cartoon eyes are a good example: springs, saccades and blinks in a plain SwiftUI Canvas, compiled on a machine nobody ever saw.

A 7-day plan to ship your first iOS app from Windows

This is the order that would have saved the most runs, with the numbers above as a guide to how long each part really takes.

Day 1: accounts. Join the Apple Developer Program. Create an App Store Connect API key under Users and Access, Integrations, and store the .p8, key ID and issuer ID as GitHub secrets. Never commit them.
Day 2: the empty app. A public GitHub repo with project.yml, a "Hello" SwiftUI view, and the App Store workflow in compile mode. Get one green run. Expect the Xcode and simulator traps; use the snippets above.
Day 2: signing. Make the certificate on Windows through the API, save it as a .p12 in a secret, and import it on the runner with the partition list line. Run dry_run until a build appears in TestFlight. If CI ever made certificates for you, revoke the orphans.
Days 3 to 5: the app. Write it. Keep logic in plain Swift files and views thin. Add a -shot launch argument per screen and a -demoAutoplay walkthrough as you go, not at the end.
Day 5: the listing. Create the app record in the website (the one manual form), then push name, subtitle, description, keywords, age rating, privacy URL and review notes from the metadata files.
Day 6: screenshots. Capture them once in the Build workflow, add headlines on Windows, commit them. Never re-capture in the release lane: that's the 12 minute vs 4 minute difference.
Day 6: submit. release mode. Then wait about three days, answer the first question with a video, and expect approval on round two.

If you want the files rather than the instructions, the whole thing (the workflow with every trap commented, the Fastfile, the signing script, the App Store Connect scripts and an agent skill that walks through it) is what the No-Mac iOS Pipeline setup installs on your repo.

FAQ: iOS development on Windows

Can I install Xcode on Windows?

No. Xcode is macOS only, and there is no Windows version. What you can do is run Xcode's command-line tools on a rented Mac (a CI runner) and drive it from Windows, which is what this whole guide does.

Can I run the iOS Simulator on Windows?

Not locally. The Simulator ships with Xcode. On the runner it works fine without a screen: simctl boots devices, installs builds, takes screenshots and records video, as in the review-video step above. You see the results as files, not as a live window.

Do I need an iPhone?

Not to build, sign, upload or get approved: none of the 21 apps needed a registered device, once signing was manual. You do want one for anything that touches real hardware (camera, motion, HealthKit, haptics), through TestFlight.

What about Flutter or React Native?

Both still need macOS to build the iOS app. Flutter's iOS setup starts with installing Xcode. Expo's EAS Build is the exception that proves the rule: it runs the build on Expo's own Mac fleet. Either way, someone's Mac compiles it; the question is only whose.

Is running macOS in a virtual machine on my PC allowed?

Apple's software license limits macOS to Apple-branded hardware. I didn't go that way, and with free macOS runners for public repos there's little reason to.

How long does it take, start to finish?

In my data, the build side takes hours (median 2.2 hours from first commit to first submission) and the review side takes days (median 4.4 days from first submission to approval for the apps that got approved). A realistic first app is about a week, most of it waiting.

Does this work for iPad, widgets and in-app purchases?

Yes for widgets and purchases: Chain has a WidgetKit extension and eight purchases, all built the same way. The 21 apps are iPhone only (TARGETED_DEVICE_FAMILY: "1"), so iPad is untested here, but it's the same toolchain.

The numbers

What	Number	Source, pulled Oct 18 2026
Apps built and submitted from Windows	21	GitHub repos, App Review emails
Live on the US App Store	8	iTunes lookup API
Swift, all apps (non-blank lines)	53,932 (median 2,308)	shallow clones
CI runs, all workflows	384	GitHub Actions API
App Store runs: ok / failed / cancelled	81 / 43 / 15	GitHub Actions API
Median successful release run, then vs now	12.0 min to 4.1 min	jobs API, 81 runs
Share of Mac time spent on screenshots	34%	jobs API, step timings
Median first commit to first submission	2.2 hours	git + App Review emails
Median first submission to approval	4.4 days (8 apps)	App Review emails
Approved on the first try	0 of 21	App Review emails
Rejected under 4.3 (twice)	11	App Review emails

What's next

The 11 apps stuck on guideline 4.3 are the open problem, and they're a product problem, not a pipeline one. The next experiment is the opposite of the September sprint: fewer apps, each with something no other app in its category does, spaced out over weeks. I'll add the result here.

The question I'd like answered in the comments: if you ship iOS apps without a Mac, what was the one step you were sure needed one? Mine was signing, and it turned out to be the fastest step in the pipeline.

If you'd rather not spend your own September 10 on the signing traps, the No-Mac iOS Pipeline puts this exact setup on your repo, and if you want the app itself built, the fixed prices are here.

MacOS Spotlight Alternative

ugurgunes95 — Sun, 18 Oct 2026 20:05:23 +0000

I built my own Spotlight alternative without knowing Swift. There were a few things about Spotlight that bothered me, along with some macOS utilities I wished I had in one place. So I decided to try something different. Using AI and a little vibe coding, I built Lilith — an open-source macOS launcher tailored to my own needs. I described what I wanted, tried the results, gave feedback, and kept iterating until I had something I was happy with. I didn't write the Swift code myself, but it was interesting to see how far I could take an idea simply by knowing what I wanted to build.

Github

App Store review time: 64 real decisions, median 73 hours

Matt Busel — Sun, 18 Oct 2026 14:13:03 +0000

Originally published at tensorust.com.

TL;DR: I pulled every App Review decision email my developer account has ever received: 64 decisions on 21 iPhone apps, September 10 to October 12, 2026, each with Apple's own "Submitted" timestamp and the time the decision landed. The median wait was 73 hours. Apple's page says it reviews "at least 50% of submissions in less than 24 hours and 90% in less than 48 hours". Mine: 19% inside 24 hours, 27% inside 48. Updates to apps already on the store took a median 64 hours, in-app purchases on their own took 12, and 0 of 21 new apps were approved on their first submission.

Short answer for the search. If you are planning a launch in 2026, budget 3 days per review round for an update, 2 to 5 days for a brand new app's approval, and at least one extra round for a new app on a new account, because the first one usually comes back with a question. A review that sits for a week is not a slow approval. In my data, every wait longer than 5.1 days except one ended in a guideline 4.3 spam rejection.

If you are still at the "what will this cost me" stage, the free iPhone app cost calculator turns features into hours and dollars; this article is about the part no calculator shows, the calendar time between "Submit" and "Ready for Distribution". I build these apps from a Windows PC with no Mac (here is the pipeline), so every submission below went out from a CI job or the App Store Connect website, never from Xcode.

Every App Review decision for 21 iOS apps on one developer account, Sep 10 to Oct 12 2026, from Apple's own emails (pulled Oct 17 2026).

How long does App Store review take in 2026?

Here are the numbers, split the way you will actually meet them. "Wait" is the time from the "Submitted" line in Apple's email to the moment the decision email arrived, so it includes the queue, not just the minutes a reviewer spent with the app.

What you submit	Decisions	Median wait	Fastest	Slowest	Approved
In-app purchases only	5	12.2 h	11.7 h	13.4 h	5 of 5
Update to a live app	16	64.4 h	6.3 h	203.6 h	11 of 16
New app (normal rounds)	21	51.2 h	3.1 h	120.5 h	8 of 21
New app (the two 4.3 spam batches)	22	187.8 h	167.7 h	223.3 h	0 of 22
All	64	73.1 h	3.1 h	223.3 h	24 of 64

Two things jump out. Rejections and questions on new apps come back fast (the 13 normal ones had a median of 27.8 hours), because the reviewer stops at the first problem. Approvals take longer: the 8 first-version approvals had a median of 69.9 hours and none came back inside 48. So a quick reply is, statistically, bad news.

The experiment: one timestamp pair per email

App Store Connect does not give you a history of review durations. Your inbox does. Every decision Apple sends has the same shape: a subject that says either "Review of your App (iOS) submission is complete." or "There's an issue with your App (iOS) submission.", and a body line like Submitted: Oct 08, 2026 at 03:48 PM Pacific Daylight Time. The email's own sent time is the decision time. That is the whole dataset.

I searched Gmail with one search operator query, from:no_reply@email.apple.com newer_than:60d, on October 17, 2026. It returned 69 threads; 64 are decisions (the other five are the App Store Connect welcome, API access approval, two "Welcome to the App Store" notes and one "Thank you for submitting"). The account opened on September 10, so this is the complete history, not a sample. Then the parse:

# media/deepdive/review-time/analyze.py (trimmed)
PT = timezone(timedelta(hours=-7))  # Pacific Daylight Time, as printed in Apple's emails

def sub_dt(s):  # "Oct 08 03:48 PM" from the email body
    return datetime.strptime("2026 " + s, "%Y %b %d %I:%M %p").replace(tzinfo=PT)

for e, app, out, sub, by, kind in ROWS:
    s = sub_dt(sub); d = utc(e)          # e = the email's sent time, UTC
    h = (d - s).total_seconds() / 3600   # hours from Submitted to decision
    recs.append(dict(app=app, outcome=out, kind=kind, hours=round(h, 2), ...))

Each row is also tagged by what was in the submission: a new app's first version, an update, or in-app purchases on their own. I took that from the app's own records (the repos' commit history and my notes) and checked the ambiguous batch against the email body, which lists the items: Chain's October 8 night submission says In-App Purchases (6) and no app version. Rejection reasons are not in the emails at all (the body just says "We noticed an issue"), so those came from the Resolution Center texts I had saved and the replies I sent.

What this method cannot see: submissions I cancelled before a decision (no email, no row), and the exact moment a reviewer opened the app. If you want "time in review" rather than "time waiting", the App Store Connect API exposes the version state, but not its history, so you would have to poll it yourself.

Apple's 24 hour number vs mine

Claim from developer.apple.com/distribute/app-review (read Oct 17 2026); measured from my App Review emails.

Apple's wording is careful: it says it reviews half of submissions in under 24 hours. That can be true and still not match what you feel, for three reasons that show up in my data.

First, the clock starts in a queue. My approvals cluster at almost exactly the same elapsed time. Seven of the 16 updates landed between 63.5 and 64.5 hours, because they were submitted together on Saturday morning, September 26, and decided together within 32 minutes late on Monday night, Pacific time. Whatever the review itself took, the wait was set by when the queue reached them.

Second, Apple does not appear to work Saturdays on new decisions, at least not mine. Of 64 decisions, Pacific time: Monday 35, Friday 10, Thursday 7, Wednesday 5, Sunday 4, Tuesday 3, Saturday 0. The Monday pile is inflated by the two spam batches (22 decisions), but even without them nothing landed on a Saturday. So yes, App Review works on Sundays (two of the four Sunday decisions were approvals), but a Saturday morning submission still waited until Monday night.

Third, the slow tail is not random. Without the two 4.3 batches my numbers look a lot closer to Apple's: 29% inside 24 hours, 40% inside 48. The 22 spam rejections took 7 to 9.3 days each. Long waits were a signal, not bad luck.

The fast lane is in-app purchases. Five IAP-only submissions (new themes and packs for five live apps, sent through the API late on the night of Thursday, October 8) all came back approved between 11.7 and 13.4 hours later, within 95 minutes of each other. If you need to ship a new price point or a pack quickly, ship it as its own submission and leave the binary alone.

New apps: 0 of 21 approved on the first try

Reasons from the App Store Connect Resolution Center texts and my replies, Sep 10 to Oct 12 2026.

Every one of the 21 apps had its first submission returned. That sounds alarming until you read the reasons. Ten of the 21 first-round emails were guideline 2.1 "Information Needed" (the other 11 were the spam batch below), the routine questions a new developer account gets: send a screen recording of the app on a device, explain the main features, say whether it needs a login, list any external services. Apple's guidelines ask for this up front; the reviewers ask again anyway when the account is new.

The fix that worked was to stop treating the review notes as a formality. Every app now ships with a Store/review-notes.md that the pipeline pushes into App Store Connect's review details, written as a walkthrough a reviewer can follow in under a minute, including how to reach every paid screen:

# chain/Store/review-notes.md (trimmed)
No account, login or network connection is required.

IN-APP PURCHASES (StoreKit 2, all optional, Restore in Settings):
- Chain Unlimited (existing non-consumable): add three habits, tap New habit again; ...
- Streak Repair, $0.99 consumable: when a chain of 2+ days breaks, Today shows a
  "chain broke" banner and the rescue sheet opens. ... To see it on a fresh install:
  add a habit, open Week, tick the two days before yesterday, leave yesterday empty,
  then relaunch.

PRIVACY: no data is collected. No accounts, analytics, ads or third-party SDKs.

After the first 2.1 round, Chain, Ironbook and Quiver were resubmitted on September 22 at 4:21 AM Pacific with answers and a screen recording, and all three were approved 51 to 67 hours later. Of the 8 apps that made it to the store, the median time from the very first submission to the first approval was 4.4 days (range 3.75 to 7.2). That is the honest number to put in a launch plan for a new app on a new account: not 24 hours, closer to a working week.

The other first-round reasons are worth knowing because each one is cheap to prevent:

5.1.1 privacy, twice, same app. Minder, a focus timer whose cartoon eyes can follow your face (the eye animation is in this SwiftUI piece), was asked exactly what face data it collects, keeps and shares. The answer (one x/y position from Apple's on-device Vision framework, never stored) had to be in the privacy policy, not just in the reply. A week later it was rejected again because the privacy policy URL itself had stopped loading. I fixed the hosting, resubmitted six minutes after the email, and it was approved 24.8 hours later.
1.4.1, health claims need sources. Race Fuel gives carbohydrate, fluid and sodium targets for endurance races. Guideline 1.4.1 wants medical-adjacent numbers backed by citations. The fix was a sources screen with seven DOI-linked papers and a link under every figure.

Guideline 4.3: a week of silence, then 11 rejections in 30 seconds

The two guideline 4.3 batches as they landed in the inbox, Eastern time.

Eleven of my apps (a car maintenance log, a parking timer, a home inventory, a grocery price log, a pet medication tracker, a chore chart, a tip tracker, a grade calculator, a bouldering log, a running pace calculator and a caffeine cutoff calculator) were submitted on September 26. They sat in the queue for 8.7 to 9.3 days. Then, on Monday, October 5, all 11 rejection emails arrived between 5:29:32 PM and 5:30:02 PM Eastern. Same text for every app: guideline 4.3 Spam plus 4.2.6, apps made from a template or app generation service, with nine questions to answer. The Resolution Center showed every message timestamped 5:29 PM.

The rejection text was explicit about what to do next: if you think the app already complies, do not resubmit, reply to the message and answer all nine questions. I replied to each one (no public beta, tested through automated Simulator runs; a shared StoreKit purchase class and test driver, disclosed), filed App Review Board appeals for all 11, and also resubmitted all 11 that same afternoon. The resubmissions were the mistake. Seven days later, on Monday, October 12, 11 more rejections arrived within 27 seconds, each one 7.0 days after its resubmission.

What the data says about 4.3, as a reader planning your own launch:

The wait is the tell. In my data every review that ran past 5.1 days except one was a 4.3 rejection. The exception was Clear the Strait 1.1.1, which I resubmitted together with a long written explanation of how the game works after the reviewer asked; it took 8.5 days and was approved.
It is decided per developer, not per app. Both batches landed inside 30 seconds. Whatever the review was, it was not 11 separate sessions with 11 apps.
Do not resubmit unchanged. Apple's own email said a resubmission without substantial changes would be rejected again. It was, on a seven day clock, which cost a week per round.

Earlier I measured how much Swift code those apps actually share. The median overlap with the rest of the account was 34.5%, and the two most similar apps on the account (a golf journal and a tennis journal) are both live. Code similarity alone did not explain who got flagged; the numbers are in the iPhone app cost article. My read, labelled as a read: 11 single-purpose utilities from one new account, submitted the same morning, look like an app factory from the queue no matter how different the screens are. If you have several small app ideas, ship one, let it collect reviews and updates, and space out the rest, or fold them into one app with in-app purchases, which is exactly what guideline 4.3(a) suggests.

The whole calendar in one picture

Every submission start to decision, 34 days, from Apple's decision emails. Static version: calendar.png.

Seen as a calendar, the pattern is obvious. The first two weeks are short red bars (fast 2.1 questions) followed by green bars of two to five days. From September 26 on, the account splits in two: apps that were already live get updates through in about 64 hours, while the 11 new utilities sit in two long red bars that end in the same 30-second window each time.

After approval: live in minutes

Chain on the US App Store, screenshot Oct 17 2026. Its 1.2 update went live 1.9 minutes after the approval email.

The email says "it can take up to 24 hours" for an approved item to show up. For my 8 live apps, the public release timestamp came much faster. I read it from Apple's own iTunes Search API, which returns a currentVersionReleaseDate for every app a developer has on the store:

# every app on the account, with the release time of its current version
curl -s "https://itunes.apple.com/lookup?id=6810582483&entity=software&country=us"

Against the approval emails, that release time landed 0.7 to 7.5 minutes after approval, median 2.5 minutes, for all 8 apps. If your launch date matters (press, an ad campaign, a Product Hunt slot), choose a manual release so an approval at 2 AM does not go live before your announcement.

While you wait, you will want the state without opening App Store Connect. This is the status check every one of my app repos carries; it asks the App Store Connect API for the last five versions and builds:

# chain/Store/asc.py
def status():
    app = find_app()
    if not app:
        print("no app record for", BUNDLE_ID)
        return
    print(f"{app['attributes']['name']}  ({BUNDLE_ID})  id={app['id']}")
    versions = call(
        "GET", f"/v1/apps/{app['id']}/appStoreVersions", params={"limit": 5}
    )
    for v in (versions or {}).get("data", []):
        a = v["attributes"]
        print(f"  version {a.get('versionString')}: {a.get('appStoreState')}")

The submission itself is one fastlane call at the end of a CI job, using upload_to_app_store. The three submission_information answers matter more than they look: they are the export compliance, advertising identifier and content rights questions, and answering them in code means a submission never stalls waiting for someone to click through a form.

# chain/fastlane/Fastfile, lane :release (trimmed)
upload_to_app_store(
  api_key: asc_key,
  app_identifier: APP_IDENTIFIER,
  ipa: "build/Chain.ipa",
  # Submit, rather than leaving it sitting in Connect for a human to press
  # the button on. This is the last step and it is the irreversible one.
  submit_for_review: true,
  force: true,
  precheck_include_in_app_purchases: false,
  submission_information: {
    add_id_info_uses_idfa: false,
    export_compliance_uses_encryption: false,
    content_rights_contains_third_party_content: false
  }
)

Does App Store review work on weekends?

Partly. Four of my 64 decisions came on a Sunday, Pacific time: Pocket Beings' first approval at 4:05 PM on September 20, and three on the evening of October 11 (two 1.2 updates sent back, Chain 1.2 approved at 10:42 PM). None came on a Saturday. The 19 submissions I made on Saturday, September 26 were all decided on Monday night or later, and the five updates I sent on Thursday, October 8 came back Sunday evening and early Monday. If you can choose, submit Monday to Wednesday; anything sent Thursday or later, assume it lands after the weekend.

What I would do in your project

Plan in rounds, not days. One round is about 3 days for an update and 2 to 5 for a new app. A new app on a new account needs two rounds: budget a working week from first submit to approval.
Write the review notes like a test script. Login (or "no login"), where every paid screen is, how to trigger the edge cases, what data you collect. Attach a screen recording to the first submission so 2.1 has nothing to ask.
Check your privacy policy URL loads before every submission. One dead link cost me a full round.
Ship in-app purchases separately when speed matters. 12 hours, 5 of 5 approved.
Treat a review over 5 days as a warning. Prepare answers to the nine 4.3 questions before you need them.
When Apple says reply, do not resubmit. A resubmission without changes bought me another identical rejection, seven days later to the hour.
Fix and resubmit fast when the issue is concrete. Minder's broken privacy link: resubmitted in 6 minutes, approved in 25 hours.
Need it sooner? Apple has an expedited review request for critical bug fixes and time-sensitive events. I have not used it, so I have no number for it.
Measure your own. Run the same Gmail query on your account. Ten minutes gives you your real review calendar, which beats any average, including this one.

The data, and how to rerun it

Everything is in one folder: emails.py (the 64 rows transcribed from the emails, with the Gmail query and pull time), analyze.py (medians, buckets, batches, approval-to-live lag), summary.json (every computed number in this article) and make_charts.py (the charts). Pulled October 17, 2026 around 10:15 PM Eastern; the iTunes lookup ran at about 10:20 PM. Apple's claim was read from developer.apple.com/distribute/app-review the same night, and the submission flow is described in Apple's Submit for review help page. One developer account, 21 apps, five weeks: a small sample, but a complete one, and the only kind of review-time data you can actually verify.

If you are building on Windows and want the same pipeline (cloud builds, signing, screenshots, fastlane submission, the review notes template) set up on your own repo, that is the No-Mac iOS Pipeline, $299: your first TestFlight build from a Windows PC in 5 business days. If you would rather hand over the whole app, fixed-price builds are on /build/.

Understanding Macros in Swift

rahul bandal — Sun, 18 Oct 2026 12:57:42 +0000

Swift Macros, introduced in Swift 5.9, represent a significant evolution in how developers can generate and transform code. While many developers might be familiar with the basic concept of macros in other languages, Swift's implementation offers a safe, type-checked, and powerful way to reduce boilerplate and create highly expressive APIs without sacrificing compiler guarantees.

This article goes beyond a basic introduction, aiming to provide a deeper understanding of how Swift Macros work under the hood, their different forms, and how they…

Read the full article on Swift By Rahul → Continue reading

The complete tutorial includes Swift code examples, SVG diagrams, and step-by-step explanations on our website.

Using your own photo as an iPhone countdown widget background: what works, and what iOS won't let you do

BeforeGo — Sun, 18 Oct 2026 12:36:56 +0000

Short answer. Several iPhone countdown apps let you put your own photo behind the countdown. As of October 2026, Photo Countdown Widget lists your photo as the background with every widget free, and in our app, Countdown Widget: Any Event, your own photo is part of Countdown Pro. Whatever app you pick, the photo only shows on Home Screen widgets. Lock Screen widgets are drawn by iOS in a single tint, so a photo can't show there. In our app the photo shows with the Home Screen's Default or Dark look; with a Tinted or Clear Home Screen, iOS removes the widget background.

I build Countdown Widget: Any Event. Here's what I learned getting a photo to look right behind a number, in three widget sizes plus the app's own event page.

The Lock Screen won't show it, and that's iOS Lock Screen widget families (accessoryCircular, accessoryRectangular, accessoryInline) are rendered with the system's vibrant, monochrome treatment: colours are flattened, images become single-tone, and the container background is removed. So in our widget code those families draw no backdrop at all. Drawing a backdrop there would only fight the system material.

If you want your photo on the Lock Screen, set the photo as your wallpaper and put the countdown widget over it.

One photo, framed for each shape
A small widget is square, a medium one is wide, and a large one is close to square but much bigger. If you centre-crop one photo for all three, someone's face ends up cut in half in at least one of them. So the photo isn't stored as one crop. It's stored as a focus point plus a separate framing for each target: the event's own page, small, medium and large. The editor shows a preview for each one (Detail, Small, Medium, Large), and you drag the frame in each preview until it sits right, dragging its corners to resize it.
The number has to stay readable
A white number on a bright beach photo disappears. Three sliders handle that:

Opacity fades the photo into the backdrop colour.
Blur softens the detail behind the digits.
Text Contrast adds a scrim, so the text stands out without changing the photo itself.

Widgets get small JPEGs, prepared in advance
A widget extension runs with a tight memory budget and shouldn't be decoding a 12-megapixel photo. The app prepares renditions ahead of time: 1,200 px on the long edge for the event page, 690 px for widgets and 480 px for list tiles. The widget only ever loads a small JPEG.
Sync without stale pictures
The photo is stored as an attachment that syncs through iCloud. Each device builds its own renditions from it. Each rendition remembers which version of the photo it came from, so if you change the photo on your iPad, your iPhone doesn't keep showing the old one.

Doing it in Countdown Widget: Any Event

Tap Add Event and pick a ready-made event or Blank Event. For a countdown you already have, open it and tap the pencil to edit it. Then tap Backdrop.
Choose Custom, then Add Photo, and pick a photo.
In Photo adjustments, frame it in the Detail, Small, Medium and Large previews, then set Opacity, Blur and Text Contrast.
Tap Done, then add the widget to your Home Screen (Default or Dark look). Using your own photo needs Pro. Unlimited events and every widget size are free, with no ads. The app is on the App Store as "Countdown Widget: Any Event".

I Built a Remote to Answer Claude Code From My Phone

Lucas Neves Pereira — Sun, 18 Oct 2026 12:26:41 +0000

Hello there!

If you run Claude Code or Codex for real work, you know the moment. You start a task, it runs for a while, and you go make a coffee. When you come back, the agent has been waiting ten minutes for you to answer one question.

"The fix is in. What should I do with it?"

That question is why I built Farol Remote. It lets you answer your coding agents from your phone, wherever you are, while the work keeps running on your Mac or on your own server.

A bit of context

Farol is a macOS terminal I made for coding agents. Its sidebar shows every session with a small dot: hollow when idle, breathing while the agent works, rippling when it waits for you, filled when it's done.

It tells you when an agent needs you. But only if you're at your Mac.

So the idea was simple. Put that sidebar in my pocket. See the sessions, read the conversation, and answer with a tap.

What the phone does

The iPhone app lists your sessions with their status and opens each one as its agent's conversation, not as a wall of terminal text.

When the agent asks for an approval or a question, the answers show up as buttons. One tap and it carries on. You can also reply with a slash command, send a screenshot for the agent to look at, review what changed file by file, and start a new session in a project.

It notifies you when an agent waits or finishes. And a Live Activity on the lock screen keeps count of the agents that work or wait, even with the app closed.

One phone can know several Macs and servers at once. Your work Mac and a server you run agents on show up in the same list, each session labeled with its host.

The hard part: the middle

A phone and a Mac don't talk to each other directly over the internet. Your Mac sits behind a home router, your phone is on 4G, and neither can reach the other.

So there's a relay in between. Both sides connect out to it, and it passes messages along.

That raises the obvious question. If everything goes through a server, what can that server see? These messages are your code, your prompts, and a phone that can type into your terminal. I didn't want the answer to be "trust me".

The goal became this: the relay passes messages it cannot read, and keeps none of them.

Pairing, once

It all starts with a QR code. On the Mac you turn on Remote in Settings and press Show code. On the phone you scan it.

The code carries three things: the relay's address, the Mac's public key, and a secret made just for that code. It's a link, and everything rides after the #.

func (o offer) link() string {
    text, _ := json.Marshal(o)
    return "https://farol.sh/pair#" + base64.RawURLEncoding.EncodeToString(text)
}

The part after the # is never sent to a server. So the secret never reaches the relay, which means the relay can't pair a device of its own.

The phone answers with one sealed message that proves two things at once: it holds the key it claims, and it saw the secret. A code works once and lasts two minutes. After that, the Mac knows the phone's key and the phone knows the Mac's.

Every connection

Each time they connect, both sides say hello in the clear with their public key and a random number made for this connection.

Then each direction becomes its own HPKE stream, sealed to the other side's key and signed with ours. I used CryptoKit's Curve25519_SHA256_ChachaPoly suite. Here's the sending side on the Mac and the phone:

public mutating func connect(to peer: ChannelHello, trusting trusted: [Data]) throws -> Data {
    guard trusted.contains(peer.key) else { throw RemoteError.unknownDevice }
    let sender = try HPKE.Sender(
        recipientKey: Curve25519.KeyAgreement.PublicKey(rawRepresentation: peer.key), ciphersuite: Pairing.suite,
        info: info(from: side, with: peer), authenticatedBy: me.secret)
    self.peer = peer
    self.sender = sender
    return sender.encapsulatedKey
}

The info includes both hello numbers. So a recording of an older connection doesn't open on a new one, and messages only open in the order they were sealed. If one fails to open, the connection ends.

What the relay actually sees

Mostly bytes.

It sees a public key, and a room name that's the hash of the host's key. That's how a Mac and its phones find each other without the relay learning who they are.

func room(public []byte) string {
    sum := sha256.Sum256(public)
    return hex.EncodeToString(sum[:])
}

Then it sees encrypted messages and how big they are. It stores none of it, and its log holds totals only.

Notifications without reading anything

This one was fun. I wanted a notification when an agent waits, even with the app closed. That means Apple has to push it, and something has to ask Apple.

The Mac asks the relay to forward a push. The relay sees the phone's notification token and one word: waiting or done. Which session it's about travels sealed, for the phone alone.

The Live Activity works the same way. The host keeps it current through the relay, so the counts on your lock screen move while the app sleeps.

Running Claude Code on a server with tmux

Some people run their agents on a machine that stays on, so they can close the laptop. For them there's farol-host, a small Go CLI.

curl -fsSL https://farol.sh/host.sh | sh
farol-host setup

Setup connects the hooks for Claude Code and Codex, keeps farol-host running with systemd, and shows a QR code to scan. Then every tmux window on that machine is a session on your phone, like a tab in Farol on the Mac.

tmux new -s api -c ~/code/api
claude

One protocol, two languages

The Mac and the iPhone share a Swift package. The server speaks the same protocol, written again in Go.

Two implementations of the same crypto and messages is a great way to have bugs that only show up on a real phone. So they check each other.

The Swift tests write sample messages and a sealed conversation to JSON files. The Go tests open those files and must read them exactly. When a message changes, I regenerate them:

FAROL_WRITE_WIRE=1 swift test

If Go and Swift disagree on a single field, a test fails before any phone sees it.

What's not covered yet

I'd rather say this upfront.

If a host's key were stolen later, traffic recorded from a phone to that host could be read. A host also doesn't prove itself to the relay yet, so someone who learned a room's name could knock the real host off. They couldn't read or send anything, but it's still on my list.

And the pairing and the encryption haven't had an outside review. If that's your thing, I'd love a second pair of eyes. It's all in one small repo, on purpose.

Try it

Farol is free and open source. The iPhone app is free too, in beta on TestFlight. In Farol, open Settings, choose Remote, turn it on, press Show code, and scan it from the app.

The security parts live in farol-remote: the Swift package, the relay, and farol-host. The security page goes deeper than this post.

Hope you find it useful! Feel free to open an issue or contribute. And next time your agent asks you a question while you're out, you can just answer it. ☕

I built Bitcut: turn a long video into Shorts with captions on your iPhone

Alexey Yarmots — Sun, 18 Oct 2026 10:35:48 +0000

I'm Alexey, a solo developer, and I built Bitcut. It's an iPhone app that turns a long video (a podcast, interview, lecture or vlog) into vertical Shorts, Reels and TikToks.

Cutting clips from a long recording by hand means three jobs: finding moments that work on their own, adding captions and reframing to 9:16. Bitcut does all three on the phone.

What it does

Generate Shorts. It listens to what is said and picks moments that make sense on their own, ranked by quality. Trailer mode builds one reel from the strongest highlights; Parts splits a recording into equal clips.
Word-by-word captions. 18 caption looks with karaoke highlighting; you can fix text and timing right on the timeline.
Face tracking. A 16:9 video becomes 9:16 and the frame follows the speaker across scene changes.
Cuts on the beat. Cuts snap to the music, and speech is never cut mid-word.
A full multi-track editor: trim, split, voiceover, title cards, transitions, voice enhancement. Import from Photos, Files or a YouTube link.

Editing and rendering happen on the phone. For captions only the audio track is sent for transcription. You don't need an account to start.

What is free

The free plan has the full editor and 30 AI minutes a month; exports carry a watermark. Paid plans are listed on the App Store page. There are also free browser tools on bitcut.app/tools: a YouTube transcript and YouTube to Shorts.

What I would like feedback on

Clips where the chosen moment doesn't stand on its own: what was the video about?
Edits where the cuts feel wrong for the music: which genre and caption style you used.

Bitcut is on the App Store for iPhone and iPad (iOS 18+). I'll answer questions in the comments.

du Said Chrome Was Using 67 GB on My Mac. APFS Said 2. Here's a Script to Tell the Difference

Md Ayan bag — Sun, 18 Oct 2026 04:36:25 +0000

My MacBook Air was down to 18 GB free, so I went hunting. The biggest folder on the whole disk, according to du, was this:

/private/var/folders/…/X/com.google.Chrome.code_sign_clone   67G

Inside: 48 full copies of Google Chrome. None of them the version I actually have installed.

Then I measured it the way APFS actually stores it, and the 67 GB turned into about 2. Here's the folder, the trap, and a 30-line Swift script that measures any folder the same way.

(Written with help from an AI assistant. Every number and command was run on my own Mac.)

Check yours (read-only)

ls "$(getconf DARWIN_USER_TEMP_DIR)/../X/com.google.Chrome.code_sign_clone" | wc -l
du -sh "$(getconf DARWIN_USER_TEMP_DIR)/../X/"*

Mine printed 48 and 67G.

From what I can tell, Chrome makes one of these each time it launches after an update. The running browser keeps a validly signed copy of itself while the new version is swapped in underneath. They're meant to be temporary. On my Mac they weren't: 3 copies of Chrome 154 and 45 of 155.0.8059.40, while /Applications has 155.0.8059.80.

The trap: `du` doesn't understand clones

APFS can clone a file. The clone looks like a full copy to every tool, but it shares blocks with the original until one side changes. Chrome makes its copies as clones.

du, Finder's Get Info and most disk-map apps add every clone up at full size. 48 × ~1.4 GB = 67 GB that mostly doesn't exist.

APFS will tell you the truth, you just have to ask through getattrlist:

ATTR_CMNEXT_CLONEID: which clone family a file belongs to
ATTR_CMNEXT_EXT_FLAGS: bit 0 means "may share blocks"
ATTR_CMNEXT_PRIVATESIZE: bytes that belong only to this file

So: for each clone, count its private bytes, and count the shared part once per family.

The script

import Foundation

// Usage: swift realsize.swift <folder>
// Counts APFS clones once: each clone adds only its private bytes,
// and the shared blocks are counted once per clone family.
func attrs(_ path: String, _ bits: UInt32, _ n: Int) -> [UInt64]? {
    var al = attrlist(); al.bitmapcount = u_short(ATTR_BIT_MAP_COUNT); al.forkattr = bits
    var buf = [UInt8](repeating: 0, count: 4 + 8 * n)
    return buf.withUnsafeMutableBytes { b in
        guard getattrlist(path, &al, b.baseAddress, b.count, 0x21) == 0 else { return nil }
        return (0..<n).map { b.loadUnaligned(fromByteOffset: 4 + 8 * $0, as: UInt64.self) }
    }
}
let root = CommandLine.arguments[1]
var naive: Int64 = 0, real: Int64 = 0, families = Set<UInt64>()
let e = FileManager.default.enumerator(atPath: root)!
while let rel = e.nextObject() as? String {
    let p = root + "/" + rel
    var st = stat(); guard lstat(p, &st) == 0, st.st_mode & S_IFMT == S_IFREG else { continue }
    let full = Int64(st.st_blocks) * 512; naive += full
    // ATTR_CMNEXT_CLONEID | ATTR_CMNEXT_EXT_FLAGS; flag 1 = may share blocks
    if let c = attrs(p, 0x100 | 0x200, 2), c[1] & 1 != 0, let priv = attrs(p, 0x8, 1)?[0] {
        real += Int64(priv)
        if families.insert(c[0]).inserted { real += full - Int64(priv) }  // shared part, once
    } else { real += full }
}
let g = 1_073_741_824.0  // GiB, same unit as du -h
print(String(format: "du-style: %.1fG   on disk: %.1fG", Double(naive) / g, Double(real) / g))

0x21 is FSOPT_ATTR_CMN_EXTENDED | FSOPT_NOFOLLOW. You need Xcode's command line tools for swift.

On the Chrome folder:

$ swift realsize.swift "$(getconf DARWIN_USER_TEMP_DIR)/../X/com.google.Chrome.code_sign_clone"
du-style: 67.3G   on disk: 2.1G

67 GB on paper, about 2 GB on disk. Still waste (those clones keep old Chrome versions' blocks alive), but a 30× smaller problem.

It's a simplification: a file's "shared" part can be shared with files outside the folder, so treat the result as "roughly what deleting this folder gives back". (My app's stricter version credits those blocks to whichever file owns them, and lands on 1.8 GB for the same folder.) The honest final check is always df -h / before and after (and empty the Trash).

Should you delete them?

Probably fine, with two rules: quit Chrome completely first (Cmd-Q), and expect them back after the next update. Open the folder with:

open "$(getconf DARWIN_USER_TEMP_DIR)/../X"

…and drag com.google.Chrome.code_sign_clone to the Trash. Expect a GB or two back, not 67.

Why I care

Clones are everywhere now: Finder's Duplicate, pnpm's store, Chrome's copies. Any disk tool that sums file sizes will show you folders bigger than your drive, and you'll delete things expecting space you never get.

I ran into this while building Tidy Mac, a Mac cleaner. Full disclosure: it's mine. It counts clones once like the script above, labels what's safe to clear, and moves everything to the Trash first.

How many copies did your Mac have? Post your ls | wc -l in the comments. I'm curious if anyone beats 48.