u/sakaax

Solo iOS/macOS developer. I design, build, sign, notarize and ship native Swift/SwiftUI apps end to end — the full pipeline, no team, no hand-off.
Shipped:
• Cleared — native macOS app that catches App Store rejection reasons before submission.
• Preflight — open-source Swift package (MIT), extracted from Cleared’s build-parsing core.
• Luné — iOS app with real iCloud/CloudKit sync between two users (no account, no server).
My portfolio itself is shipped as a notarized macOS app (plus a web version) — the medium is part of the demo.
Good fit for: a native iOS/macOS app built from scratch, an existing app fixed/shipped/unblocked, or CloudKit / Live Activities / notarized distribution work.
Rate: ~€350/day, flexible by scope. Remote, EU hours.
Portfolio + full project details: sakaax.com

I shipped an app where two people (in my case two parents) share and sync the same data in real time, with no login, no account system, and no backend of my own — just CloudKit. Here are the things I wish I’d known before starting.
1. Private vs Shared database is the whole game.
Your own data lives in the private database. The moment you want someone else to see it, it has to move into a shared zone via CKShare. I underestimated how much the data model has to be designed around sharing from day one — retrofitting it later is painful. Decide early what’s “mine” vs “ours”.
2. CKShare + a custom zone, not the default zone.
You can’t share records that live in the default zone. You need a dedicated CKRecordZone for the shared root record. I lost time before realizing the default zone simply doesn’t support what I wanted.
3. The share-acceptance flow is easy to get wrong.
The second user accepts via a CKShare.Metadata (system share sheet → userDidAcceptCloudKitShareWith). Handling that entry point cleanly — especially cold launch vs app already running — took more iterations than the sync logic itself.
4. Conflict handling is on you.
CloudKit gives you server record changes, but “two people edited the same thing” resolution is your problem. I went with last-writer-wins on a per-field basis, which is fine for my use case but you should consciously pick a strategy, not discover you need one in production.
5. Test with two real iCloud accounts on two real devices.
The simulator + one account hides a lot. Most of my real bugs only showed up with two physical devices on two different Apple IDs.
The payoff: zero server cost, zero auth code, privacy by default (data lives in the users’ iCloud, not mine). The tradeoff: you live inside CloudKit’s constraints and you can’t just SELECT * FROM.
Happy to go deeper on any of these if useful. Curious how others handled conflict resolution — did anyone go beyond last-writer-wins without a server?

A few days ago I shared Preflight, the open-source core I extracted from my macOS app (Cleared). Next step: make those checks run in CI on every push. Sharing the design problem because it was more interesting than expected.
The naive version breaks immediately: a young project hasn’t filled in half its metadata, so a CI check that fails on every gap just gets ripped out on day one. A rejection-checker that’s annoying is worse than none.
So the design is two-mode:
• cleared check is advisory by default — exit 0, never breaks your build. It just reports.
• cleared check --strict ratchets on a baseline (.cleared/baseline.json): only new findings (regressions vs the baseline) fail the build. Pre-existing gaps never block you. You tighten over time instead of drowning on day one.
Some structure notes:
• It reads the build output (.ipa/.xcarchive), never the .xcodeproj — Xcode-version-agnostic. If your CI can build the app, this can check it.
• Build-only checks come from Preflight (MIT, free). The App Store Connect cross-check (build vs your real privacy labels — the part that catches silent 5.1.1 rejections) lives in a closed layer and is license-gated, because it needs your ASC credentials and can’t run without them.
• Distributed as a compiled binary (macOS arm64) — brew install sakaax/tap/cleared-cli.
I validated it on one of my own shipped apps and it surfaced two real findings, so it’s doing real work, not echoing a linter.
Repo: github.com/Sakaax/cleared-cli — feedback on the strict/ratchet model especially welcome.

EDIT (a few hours later): I'm off the waitlist — and I caught the exact moment in the logs. The bitmask went from 1535 → 2047, i.e. bit 9 flipped on, exactly as predicted. It activated on my Mac and iPhone within ~2 minutes of each other, which confirms it's tied to your Apple ID, not the individual device. One correction: the "error code 54" I mentioned wasn't actually the blocker (it still showed up after activation) — the real signal was just bit 9. Full breakdown in the comments.

So I've been on the waitlist for the new LLM-powered Siri for about 5 days now (iOS 27 / macOS 27 "Golden Gate" dev betas). Important detail: Apple Intelligence itself is already active on my device — Translate, Writing Tools, all of it works. It's specifically the new Siri that's still behind a waitlist. Which made me curious: if the rest of Apple Intelligence is already running, what exactly is Siri waiting for? Is something still downloading? Is it my hardware?

So I plugged my iPhone into my Mac, opened Console.app, and started reading the unified logs while triggering AI features. One filter led to another and I went way deeper than planned.

Here's the whole journey. I've split it into what I'm sure of (it's literally in the logs) and what I'm guessing (Apple doesn't document this, so I'm inferring from internal names — flagged clearly). I'm a developer, not an Apple engineer, so if someone knows better, correct me. There's a "test it yourself" guide at the very bottom if you want to check your own device.

One thing first: the Settings screen is the only real source of truth for the waitlist status. Nothing in the logs shows a queue position or a progress bar — that counter just doesn't exist on the device. So this was never about skipping the line. I just wanted to understand the machine.

———

Part 1 — Starting with Siri on my own iPhone

The first thing I went looking for was the new-Siri status itself. And the first surprise:

The Siri models are already fully downloaded. While I'm still on the waitlist.

The asset status for every Siri component read as ready — speech recognition, language understanding, text-to-speech, on-device dialog, answer synthesis, a "planner" model, a shortcuts generator. All sitting on my phone, downloaded, done. Indexing finished days ago.

This flipped my whole understanding: being on the Siri waitlist does NOT mean you're still downloading anything. The bits are already there.

Then I found the reason it's still "off": the device reports itself as eligible for the new Siri (one flag literally says eligible: true), but a separate "enabled" flag is still off. That's why Settings still says waitlist. So there are two different gates — is my device capable (yes) and has Apple switched it on for my account (not yet). You can pass the first and still be stuck on the second.

That gap between "eligible" and "enabled" is where the real story is. So I went looking for the exact flags that encode it.

———

Part 2 — The capability bitmask, and the bit that's missing

This is the part I find most interesting, so bear with me — it's a bit of detective work.

Scattered through the Siri logs there's a value called siriLinwoodCapabilities ("Linwood" is, I believe, the internal codename for the new Siri — more on that in the guesses section). It's not a yes/no flag. It's a bitmask — a single number where each individual bit, read in binary, is its own on/off switch for a specific capability. This is a super common pattern in low-level code: instead of 11 separate booleans, you pack them into one integer.

Here's what I actually saw:

- On my Mac: siriLinwoodCapabilities = 1535
- On my iPhone: = 1247

At first those numbers look random. They're not. Convert them to binary:

- 1535 = 101 1111 1111 → bits 0,1,2,3,4,5,6,7,8,—,10 set
- 1247 = 100 1101 1111 → bits 0,1,2,3,4,6,7,10 set

The Mac (1535) has almost everything turned on — bits 0 through 8, plus bit 10. But bit 9 (value 512) is missing. That's the one hole in an otherwise full set. 1535 is literally 2047 − 512, i.e. "everything except bit 9."

So I have a device that's downloaded every model, reports itself eligible… but is sitting one specific bit short of a full house. My read (and this is a guess — flagged below) is that bit 9 is the server-granted authorization bit — the one Apple flips remotely when your account clears the rollout wave. Every local capability is set. The one that's missing is the one only Apple's servers can set.

It lines up with two other things I saw:

- a few other related fields were partially set too — one experience flag had its lower bits on but not the top one, another generative-model flag only had a couple of bits set. Consistent with "the device-side stuff is ready, the server-side stuff isn't."
- right next to all this, an error line: "updating Linwood eligibility failed, code 54," immediately after a line about a missing server-pushed config option. The way I read it: the device literally cannot finish enabling Siri because the config that would set that last bit hasn't been delivered yet.

Put together, the binary tells a clean story: the waitlist is a single missing bit, and only Apple can set it. Nothing you do locally — reboot, re-enroll, toggle settings — changes a server-authorization bit. (Big caveat: the exact meaning of bit 9 is my inference, not documented. But the bitmask values themselves, 1535 and 1247, are real and in the logs.)

———

Part 3 — Going wider into Apple Intelligence as a whole

Since the rest of Apple Intelligence already works on my device, I wanted to watch those models actually run. So I started filtering on the inference processes and triggering the features that already work (Translate, Writing Tools).

On-device AI is genuinely running RIGHT NOW

I triggered Translate in Notes and watched a process called TGOnDeviceInferenceProviderService wake up and run a real model on the Apple Neural Engine — device opened, inference dispatched, success returned. The model that showed up is a ~300M-parameter instruction model.

So the on-device generative stack is fully alive on my phone today — it just isn't wired to Siri yet. The models running ≠ the new Siri being on.

What one inference actually looks like on the hardware

The richest find was the low-level Neural Engine daemon (aned), which is way less censored than the higher-level stuff. For a single model load I could see:

- weight buffers of ~127 MB each, ten of them → roughly 1.27 GB of weights loaded onto the Neural Engine
- the model's shape: 9 procedures, 210 inputs, 27 outputs, a 32 MB working buffer
- the full lifecycle: the daemon loads the model → builds a program on the chip → the kernel hands out a Neural Engine client → it runs → and it gets unloaded ~30 seconds later
- the kernel even logs a "Single-ANE System" — one Neural Engine, picked by the driver

The neat design detail: the model is loaded and torn down on demand, not kept in memory. Every request spins it up and drops it. RAM-saving by design.

There's a cloud path too — Private Cloud Compute

When I ran a heavier task — a long Writing Tools rewrite instead of a quick translate — a different process showed up entirely: the Private Cloud Compute client. The logs tie it straight back to the Writing Tools UI as the requester.

So the device has two backends: local (the Neural Engine + that 300M model) for light stuff, and cloud (PCC) for heavier requests. Both coordinated by a single daemon, modelmanagerd — one conductor, two orchestras. Each cloud request woke the process for a few seconds, with the system explicitly refusing to kill it mid-inference, then let it idle.

A scheduler decides when heavy AI work runs, based on heat & activity

Some of the AI maintenance tasks are gated by the system activity scheduler (dasd), which evaluates rules like "don't run if the device is active and warm" and "don't run above a thermal threshold," then defers the task. Same scheduler that handles backups and photo indexing — Apple just plugged AI into it. In practice: heavy background AI work waits until your phone is idle, cool, and ideally charging.

Where the trail goes cold

The higher-level processes mask the really juicy bits — model names, file paths, routing decisions — behind <private>. So I can see the activity and the sizes/shapes, but not request contents or exact model filenames. On iPhone that redaction is locked down. Worth saying so nobody thinks I saw more than I did.

———

The "I'm guessing here" section

Educated guesses from internal names + context. Hypotheses, not facts:

- "Linwood" — the codename all over the Siri capability flags. I read it (and so does the community) as the internal name for the new Siri vs the classic one. Codename, not gospel.
- Bit 9 / value 512 in the bitmask = the server authorization bit. This is my interpretation. The bitmask values (1535, 1247) are real; what each individual bit means is inferred.
- "Error code 54" = the device can't finalize eligibility because the server config hasn't been pushed. My reading of two adjacent log lines.

———

So, the actual answer to "what is the new Siri waiting for?"

Nothing on the phone. The Siri models are downloaded, the broader Apple Intelligence stack is already running generative inference on my device (Translate, Writing Tools), and the cloud path is wired up for the heavy stuff. What the new Siri is waiting on is a single server-side bit tied to your Apple ID and Apple's rollout waves — not a download, not your hardware, not anything you can speed up with a reboot or a re-enroll.

If you're staring at "Joined waitlist" wondering if there's a trick: there isn't. The capability is sitting right there on your device. Apple just hasn't flipped that last bit for your account yet.

———

Test it yourself

Want to check your own device? It's read-only and totally safe — you're just reading logs, not changing anything. You'll need a Mac.

1. Connect & open Console
2. - Plug your iPhone into your Mac with a cable.
3. - Open Console.app (it's built into macOS — search it in Spotlight).
4. - In the left sidebar, click your iPhone under "Devices."
5. - In the top toolbar, make sure Action → Include Info Messages and Include Debug Messages are both ON (otherwise you miss the good lines).
6. Filter, then start streaming
7. - In the search bar (top right), start with just Siri — seriously, that one word alone surfaced basically everything I found (the capability flags, eligibility, the bitmask, all of it). It's by far the best starting point.
8. - Once you want to go deeper into specific subsystems, try these one at a time: Linwood, siriLinwoodCapabilities, eligibility, TGOnDeviceInferenceProvider, aned, modelmanagerd.
9. - Hit Start streaming (the ▶ button) so it captures live.

Pro tip: don't paste raw logs into a chat box. Apple Intelligence logging is extremely verbose — you'll generate thousands of lines in seconds and blow past any context limit. Instead, save the logs to a .txt or .md file and upload the file to the LLM. Way cleaner, and the model can actually grep through it.

Then use a prompt like this:

&gt; You are helping me reverse-engineer the Apple Intelligence / new Siri pipeline from macOS/iOS unified logs (Console.app). I've attached a log file captured while triggering Siri and AI features on a device that is still on the new-Siri waitlist.
&gt;
&gt; Please analyze it and tell me:
&gt; 1. Asset/model status — which Siri/AI model components are downloaded and marked ready (look for asset status flags, mobileassetd, model catalog entries).
&gt; 2. Eligibility vs activation — find any "eligible" / "enabled" / "isLinwoodEnabled" flags and tell me whether the device is eligible but not yet enabled.
&gt; 3. The capability bitmask — find siriLinwoodCapabilities (or similar bitmask values). Convert the number to binary and tell me exactly which bits are set and which are missing. Flag any single missing bit.
&gt; 4. Error codes — find any "eligibility failed" / "code 54" / "missing ... options" lines and explain what they suggest about server-side config.
&gt; 5. Live inference — find evidence of on-device inference (TGOnDeviceInferenceProviderService, ANE / aned, model load/unload, weight buffer sizes) and any Private Cloud Compute client activity.
&gt;
&gt; Important: clearly separate what is EXPLICIT in the logs from what is your INTERPRETATION. Don't invent log lines. If something is redacted as <private>, say so. Be concise and use the actual values from my file.

That'll walk you through your own device the same way I went through mine. If your bitmask is different from my 1535 / 1247, I'd love to see it in the comments — it'd help figure out what each bit actually means.

———

Methodology: everything here was read off Console.app unified logs on the iOS 27 / macOS 27 dev betas, triggering features manually and decoding what surfaced. "Sure" = explicit in the logs; the guessing section is clearly labeled. Not affiliated with Apple.

Sharing a Mac app I built (it’s mine, paid). Cleared is a native macOS tool for iOS developers: you drop in a build, it inspects it locally and tells you what’s likely to get rejected by App Store review before you submit — privacy manifests, missing usage strings, SDK/privacy-label mismatches, paywall requirements, etc.
What might interest this sub specifically:
• Native SwiftUI, monochrome “case file” design — not an Electron wrapper.
• 100% local. Your build and your App Store Connect key never leave your Mac.
• On-device AI for the explanations (no API key, nothing phones home) — with bring-your-own-key as an option.
• The build-parsing core is open source (Preflight, MIT) so the “nothing leaves your Mac” claim is verifiable: github.com/Sakaax/preflight
• Direct download (notarized DMG) or Homebrew — no Mac App Store sandbox limitations.
It’s niche (you need to be shipping iOS apps for it to matter), but if you are, it saves you the multi-day rejection loop.
3-day trial, then €15 lifetime (one-time). Feedback welcome.
cleared.sakaax.com

Je test Claude Design depuis sa sortie. Tout le monde parle du Figma killer des prototypes des slides ok.

Mais en jouant avec je suis tombé sur un truc que personne mentionne, il génère aussi des vidéos de promo. Pas juste des animation de prototype, du vrai contenu video exportable.

J’ai pas encore creusé en profondeur (combien de prompts pour un truc clean, format max, qualité comparé à Runway/Pika) mais le premier essai était sérieux.

Du coup ça pose une vrai question pour les devs indé qui font leur landing page dans Claude Code, est ce qu’on peut juste rester dans l’écosystème Anthropic pour 80% des besoin design + promo et garder Runway/Kling pour les cas extrêmes ?

Et la question qui me trotte derrière, est ce qu’Anthropic finira par sortir son propre model de génération video à la Sora ? Parce que si Claude Design fait déja ça avec Opus 4.7 imaginez avec un model dédié video derrière.

Quelqu’un d’autre a testé la génération video dans Claude Design ? Vos limites rencontré ?