DEV Community: Kirill Lukyanov

Making Money on the Web with AI in 2026: What's Growing, What's Dying

Kirill Lukyanov — Mon, 26 Oct 2026 15:09:19 +0000

If your page ranks first on Google and an AI answer appears above it, you get 58% fewer clicks. That's from Ahrefs. Meanwhile Cursor, a code editor, went from $2B to over $4B in annualized revenue in about four months, according to press reports. Those two numbers sum up what AI did to making money on the web: services that do the work grow, sites that sell answers shrink.

Short version: I wouldn't start an ad-funded content site in 2026, and I wouldn't build a Cursor competitor either. For a solo developer or a small team, the realistic options are a narrow paid tool for one profession, or doing AI implementation work for companies.

This is part 2 of a short series on how people make money with AI right now. Part 1 covered mobile apps; this one covers websites and web services.

What's growing: tools that do the work

The fastest money on the web this year is in tools that write code. Press reports put Cursor above $1B in annualized revenue by late 2025, $2B by February 2026 and over $4B by June. These are leaks, not filings, since the company is private. Even with a wide margin of error, it's one of the fastest ramps in software history.

Next come the builders, where you describe an app or site in plain language. Lovable reached $400M ARR by February 2026, per TechCrunch, and later reports put it near $600M by September. Replit's CEO cited $240M in 2025 revenue, with a stated goal of a $1B run rate by the end of 2026.

What they have in common: you pay for a result you can use, working code or a working site, not an answer to read. It's the same pattern as photo and video apps in part 1. People pay for things they can take away and use at work.

The second growing group is narrow B2B tools in the browser: decks, meeting transcription, product photos, documents. Productivity takes 15 of 50 spots in a16z's top consumer AI products by spend, and many of those live on the web rather than in the App Store. Companies pay for them, so prices are higher and churn is lower.

What's shrinking: sites that answered questions

On the other side are sites that lived on search traffic. The Reuters Institute, using Chartbeat data, found organic Google traffic to 2,500+ publisher sites fell 33% worldwide and 38% in the US between November 2024 and November 2025. Reference content was hit hardest: weather, horoscopes, TV listings, simple how-tos. Chartbeat data reported by Axios shows small publishers lost 60% of search referrals over two years, versus 22% for large ones.

The main driver is the AI answer above the results. Your page keeps the top spot but loses the visitors.

Two examples of what this looks like in money:

Chegg, a homework-help service, got most of its subscribers from Google searches for study questions. Q4 2024 revenue fell 24%, it hired Goldman Sachs to explore a sale, and in February 2025 it sued Google over AI Overviews.
Stack Overflow's monthly question volume fell back to 2009 levels, when the site had just launched. The decline started before ChatGPT, but sped up sharply after it shipped in late 2022.

Business models: what grows, what shrinks

My estimate of the entry bar is for one developer or a small team. Figures come from different sources and are measured differently, so don't compare them directly.

Model	Examples	Trend and numbers	Entry bar
Growing
Dev tools and builders	Cursor, Lovable, Replit, Bolt	Cursor: $4B+ annualized by June 2026 (press)	Closed: needs model budgets and investors
Narrow B2B tool in the browser	Gamma, Photoroom, Otter, Fireflies	Productivity: 15 of 50 in a16z top-50	Medium: best shot for a solo dev
AI implementation for clients	Automation, chatbots, integrations	Demand growing with company interest in AI (my estimate)	Low: needs experience, not capital
Flat
Thin wrapper over someone else's model	"One prompt plus a checkout"	Repeating the fate of mobile wrappers (my estimate)	Low, but ChatGPT and Gemini absorb the feature
Storefront for your own product or services	Landing pages, portfolios, app pages	Less from search, more from social, channels, newsletters (my estimate)	Low: you bring the traffic yourself
Shrinking
Ad-funded content site	Reference, how-tos, disposable news	−33% Google traffic worldwide, −60% for small publishers (Reuters Institute, Chartbeat)	Low, but the visitors are leaving
Affiliate reviews	"Top 10 vacuums", comparison pages	−58% clicks on position one with an AI answer (Ahrefs)	Low, but the AI answer takes the click
Q&A sites	Chegg, Stack Overflow	Chegg: −24% revenue in Q4 2024, lawsuit against Google	Closed

Why some grow and others shrink

The line comes down to one question: can AI deliver the result right inside the search box or chat window?

If a site's product is an answer, a text or a list, AI hands it out on its own and nobody clicks through. That's what happened to horoscopes, recipes, reference pages, reviews and homework answers. The site wrote a good answer, the search engine summarized it, and the ads on the site stopped getting impressions.

If the product is an action, chat AI doesn't replace it. It makes it cheaper and faster. Code has to run, a deck has to be shown to a client, a meeting has to be recorded and summarized, a business process has to be wired into a CRM. That happens in a separate service, and people pay for it.

The second takeaway: a website stops being a traffic source and becomes a storefront. People arrive from a channel, a newsletter, social media or a referral, not from a random search. You have to bring them yourself.

What could break this

Model costs. Builders like Lovable and Bolt pay for every model call. Users complain about credits burning fast, and margins are thin. If the provider raises prices or ships the same product, a business built on someone else's model takes the hit.

The platform ships it. ChatGPT already makes decks, spreadsheets and simple sites. What protects a narrow tool is depth: the customer's data, integrations, a workflow tuned to one profession.

Search will keep changing. The traffic numbers cover 2024–2025. AI answers keep expanding, and a model that looks "flat" today may be shrinking a year from now.

What I'd pick

I wouldn't start an ad-funded content site now. Even a great page at position one gets fewer and fewer clicks, and better SEO won't fix that. I wouldn't build a Cursor competitor either: that race is between companies with billions in funding.

A solo developer has two realistic paths. One is a narrow paid tool for a specific profession where AI removes the routine: marketplace sellers, accountants, lawyers, real-estate agents. It's the same logic as Cal AI in part 1, just in the browser and for businesses. The other is AI implementation for companies. That's what I do myself: automation and AI-powered services for businesses. Right now there's more demand for that than for "just a website".

You still need a site. Treat it as a storefront you bring people to, not as a machine that collects traffic from Google.

Originally published at klukyanov.ru.

Shorter weekly write-ups (in Russian) — on Telegram.

Where the Money Is in AI Apps in 2026: A Niche Map

Kirill Lukyanov — Wed, 21 Oct 2026 11:23:25 +0000

In 2025, people spent more money in regular apps than in games for the first time. Generative AI is the main reason. But if you're thinking of building "an AI app", the money is not where it looks like it is. Chat assistants are taken. Photo, video, voice, and AI tucked inside a daily habit are where people still pay. I build iOS apps, so I pulled together the numbers by niche and wrote down where a small team can still get in.

Short version: don't build another assistant. Build something that produces a file people keep, or remove the boring step from a task people already do every day. The second one is the realistic bet for a solo developer.

This is part 1 of a short series on how people make money with AI right now. This one is about mobile apps; part 2 covers websites and web services.

The market: there is money

According to Sensor Tower's State of Mobile 2026, consumers spent $167B in apps in 2025, up 10.6%. Non-game app spending grew 21% and passed games, which grew 1.3%. Generative AI apps were downloaded 3.8B times (double the year before), and their in-app revenue nearly tripled to over $5B.

Growth hasn't stopped. Sensor Tower projects AI apps will pass $4B in H1 2026, 36% more than H2 2025. Time spent doubled year over year, from 17.2B to 36B hours. More than 200,000 apps now mention AI in their descriptions.

That last number matters most. With 200,000 apps saying "AI", the label on its own sells nothing. What sells is the job it does.

Chat assistants: the field is taken

In Q1 2026, ChatGPT, DeepSeek and Google Gemini held almost 90% of time spent in AI assistant apps (Sensor Tower). Appfigures estimates ChatGPT made $187M net on mobile in October 2025, with Grok at $8.7M, Claude at $5M and Perplexity at $3.1M. Even companies with their own frontier models are 20–40x behind.

It wasn't always like this. In 2023–2024, thin wrappers did well: Appfigures puts ChatOn at $135M and Chat & Ask AI at $109M over two years. That was before OpenAI and Google shipped good apps of their own, when people searched the App Store for "ChatGPT" and installed whatever came up first. Today the free original beats any wrapper. That's my read, not a finding from the reports.

The niche map

Figures come from different sources and aren't directly comparable: some are net of store fees, some gross, some are company claims.

Niche	Who earns	Numbers	Barrier for a small team
General-purpose assistants	ChatGPT, Claude, Grok, Perplexity	ChatGPT: $187M net in Oct 2025 (Appfigures)	Closed
Video generation & avatars	Higgsfield, HeyGen, Runway, Kling, Synthesia	Higgsfield claims $1B annualized revenue (company claim)	High: generation is expensive, margins thin
Photo: editing, retouching, product shots	Photoroom, Evoto, FaceApp, Reface, Topaz	About ten photo tools in a16z's top 50 by spend	Medium: a narrow job works
Audio: music, voice, read-aloud	Suno, ElevenLabs, Speechify, Moises	Suno is #7 in a16z's top 50	Medium
Productivity: meetings, notes, slides	Otter, Plaud, Fireflies, Gamma, Notion	15 of 50 spots in a16z's top 50	Medium: higher prices, companies pay
Companions & roleplay	Zeta, Tipsy Chat, Character.AI	$165M general + $163M romance in H1 2026, gross (Appfigures via Decrypt)	Low technically, high on moderation and reputation
Homework & study	Gauth (ByteDance), Question.AI	~$2.5M net combined in 2024 on 15M installs (Appfigures)	High: big players plus free ChatGPT
AI inside a daily habit: food, health, fitness	Cal AI and narrow trackers	Cal AI: $40M+ trailing-12-month sales, acquired by MyFitnessPal in March 2026	Low–medium: best shot for a solo dev

The a16z ranking is the top 50 consumer AI products by US consumer spend (October 2026, YipitData), web and mobile combined. More than half of the list is photo, video and audio.

Why people pay for photo, video and voice

My interpretation, but it fits the numbers.

The result is a file. You read a chatbot answer and close it. A video, an edited photo or a voiceover gets saved, posted, sent to a client. It's easier to pay for something you can take away.
Free ChatGPT is worse at it. A general assistant can draw a picture. It won't batch-remove backgrounds from forty product shots at marketplace size.
Professionals pay. Marketplace sellers, photographers, creators and marketers treat these as work tools that pay for themselves.

The flip side is cost. Every video generation costs money, and an all-you-can-eat plan will put you in the red. Credits instead of unlimited, and expensive models only on the paid tier.

Where a solo developer fits: AI inside a habit

The most telling story of the year is Cal AI. Two high schoolers built a calorie counter by photo: snap your plate, get calories and protein. In under two years it passed 15M downloads, did over $40M in sales in the trailing 12 months, and MyFitnessPal bought it in March 2026 (terms undisclosed).

The model inside isn't theirs, and food recognition isn't unique. What worked: AI removed the most tedious step of a task people already wanted to do. Counting calories was always the goal; typing in every spoonful was the problem.

The recipe:

Pick a task people do regularly, daily or weekly.
Find the most tedious step: data entry, transcription, counting.
Let AI remove that step, and keep the rest a good ordinary app.

I do this in my own fasting app: calories from a photo are part of the daily log, and recognition runs on the phone through Apple Foundation Models, offline and with no API bill. When a request costs nothing, a free tier and a long trial don't turn into losses.

A habit also fights the other AI-app problem, churn. People leave AI apps faster than regular ones, and what keeps them is the recurring task, not the model. I covered that in an earlier breakdown of RevenueCat's data.

What can break it

The platform eats your feature. If your product is one button, it'll show up in ChatGPT, Google Photos or iOS itself. Data, history and a good workflow are what protect you.
Store rules. In April 2026 Apple briefly pulled Cal AI: it took payments via Stripe outside in-app purchase and showed the weekly price more prominently than the actual charge. It came back after fixes.
Cost. A cloud model is a variable cost per user. Do the math before launch, not after the first invoice.
Companions are their own thing. Hundreds of millions in revenue, but the top 10% of apps take 89% of it (Appfigures, 2025), and moderation and reputational risk are the highest anywhere.

What I'd pick

Not an assistant, and not a video generator: the first is taken, the second needs model budgets a solo developer doesn't have. I'd take a boring recurring task in a niche where people already pay for apps (food, fitness, health, bookkeeping, photos for sellers), have AI remove the most tedious step, on-device where possible, and sell an annual plan with a long trial.

Less exciting than "my own ChatGPT". But it's what the one real success story of the year looks like.

Originally published at klukyanov.ru.

Shorter weekly write-ups (in Russian) — on Telegram.

AI apps earn more but lose subscribers faster

Kirill Lukyanov — Mon, 19 Oct 2026 14:45:33 +0000

AI features make people pay faster. They also make people leave faster. RevenueCat's latest data shows AI subscription apps earn 41% more per paying user in year one, but only about one in five annual subscribers renews. For other apps it's closer to one in three. I build iOS apps with subscriptions, so I went through the numbers and wrote down what I'd actually change.

Short version: subscriptions are paid for by habit, not by the model inside the app. Judge an AI app by its second year, not its first month.

Where the numbers come from

State of Subscription Apps 2026 by RevenueCat, the company whose SDK handles roughly 20% of global subscription app revenue. The data covers 2025: 115,000+ apps, $16B+ in revenue, 1B+ transactions. An "AI app" here means one where AI is part of the core experience, which is 27% of the sample.

AI vs non-AI apps

Metric	AI apps	Non-AI apps	Difference
Revenue per payer, first month	$18.92	$13.59	+39%
Revenue per payer, first year	$30.16	$21.37	+41%
Trial start rate (of downloads)	8.5%	5.6%	+52%
Paid by day 35 (of downloads)	2.4%	2.0%	+20%
Annual plan renewal	21.1%	30.7%	−9.6 pts
Monthly plan kept for 12 months	6.1%	9.5%	−3.4 pts
Weekly plan kept for a year	1.2%	1.7%	−0.5 pts
Refund rate (median)	4.2%	3.5%	+0.7 pts
Share of monthly plans	59.8%	26.2%	×2.3

The top half of the table is about how well AI sells. People start trials more often, convert more often and pay more. The bottom half is about how well AI retains people, and it's worse on every line. Out of 100 annual subscribers, 21 come back for year two in an AI app and 31 in a regular one.

Why they leave

The report gives the numbers, not the reasons. What follows is my own reading of them.

People buy an effect, not a habit. Generating an avatar or reading calories off a food photo is impressive the first time. If the job is one-off, there's no reason to come back. Across categories, 26–40% of voluntary cancellations cite "not using it enough".
Monthly plans. 60% of AI subscriptions are monthly, compared with 26% for other apps. A monthly plan asks "still worth it?" every 30 days.
Expectations run ahead of results. Refunds are higher, and the ceiling is higher too: 16% vs 12.5%. The ad promises magic, the model sometimes gets it wrong, and the user notices while a refund is still easy.
Price. Model costs push AI apps to higher prices, and "too expensive" is the top cancellation reason, at 25–45% depending on category.

Five things I'd do with an AI app

Examples from my own apps are illustrations, not measurements.

1. Sell annual, not monthly. Annual plans renew less often than you'd like, but you collect twelve months up front. If the user cools off in month three, a monthly plan just ends. The median annual price in the report is $34.80, up from $31.60.

2. Use long trials instead of 3-day ones. Trials of 17+ days convert at 42.5% vs 25.5% for trials of four days or less. 55% of 3-day trial cancellations happen on day zero, so a short trial tests the wow moment, not the habit. In Clay Sniper, a shooting journal, I moved the Pro trial from three days to two weeks so a shooter gets at least a couple of range sessions in.

3. Put AI inside a recurring job. AI keeps users when it removes friction from something they do every week anyway, not when it's a standalone party trick. In Lunar Fasting, calories from a photo are one line in a daily log next to water, fasting and weight, not a separate "scan your food" screen.

4. Push marginal cost toward zero. Every cloud request costs money, which is why AI apps tighten freemium, shorten trials and add expensive AI tiers. That fights tactic 2. In Lunar Fasting, photos can be analyzed on-device with Apple Foundation Models, offline and free. The cloud is only used with the user's own API key. If a request costs nothing, a long trial doesn't lose money.

5. Don't give away a free tier you don't need. Hard paywalls convert 10.7% of downloads by day 35, freemium converts 2.1%, and annual retention is nearly identical (27% vs 28%). The paywall model decides how many people pay, not how many stay.

Modeling the economics

An AI app takes about 63% of its first-year revenue per payer in month one, roughly the same share as a non-AI app. The difference shows up only at renewal, outside a first-year window. If your ad bidding optimizes for short-horizon value, it's easy to overpay for AI users. Plan for a lower lifetime value than market averages suggest.

One more detail from the report: on Google Play, 32% of cancellations are failed payments rather than a user decision. On the App Store it's 15%. Part of your "churn" may be fixed by a card-update reminder, not by the product.

Bottom line

I wouldn't build the product around the model. Models get cheaper and more alike, and in a year your competitor will have the same one. I'd build around a job people come back to every week and let AI take the tedium out of it. Sell an annual plan with a long trial, run inference on the device where possible, and look at year-two revenue.

Originally published at klukyanov.ru.

Shorter weekly write-ups (in Russian) — on Telegram.

OpenAI dots: the agent that works while you sleep

Kirill Lukyanov — Sat, 17 Oct 2026 10:01:26 +0000

A regular ChatGPT conversation lives as long as the tab is open. Close it, and everything waits for your next message. On September 29 at DevDay, OpenAI showed the opposite: an agent that keeps doing the job after you've gone to bed. OpenAI calls it a dot. Each dot gets its own cloud computer with a browser, access to your apps, and its own memory, and it's on around the clock.

I went through what dots can do at launch, how their permissions work, what they cost and where the limits are. I haven't run a dot myself yet. OpenAI's announcement page returned 403 while I was collecting material, so the facts below come from detailed write-ups that cite OpenAI's announcement and help center. The key numbers match across three or four sources; where there's only one source, I say so.

This is a snapshot as of October 17, 2026. Dots are rolling out gradually, and details will change.

What a dot is

A dot is a persistent AI agent inside ChatGPT, running on GPT-6 Astra (released September 3). Four things set it apart from a normal chat:

Its own computer. A cloud machine with a browser that keeps running when you're not chatting. You can open it and watch what the agent is doing right now.
Access to your apps. Mail, calendar, Slack, spreadsheets: 4,000+ services via plugins.
Its own memory. A dot keeps notes separate from ChatGPT memory and learns from your corrections.
Unprompted work. When you don't give it anything, it looks for ways to help. OpenAI calls this proactive research.

Every dot has a name, a look and a handle like @yourname-dot. You can talk to it in ChatGPT on desktop and mobile, in Slack and Microsoft Teams, or call it by voice. Context carries across channels.

The example everyone repeats from the launch: an early tester's dot found an invoice he had forgotten to send, assembled it from an email thread and sent it as a PDF — after he approved it. The last part is the important one.

How it works: computer, plugins and Codex

A dot is a coordinator rather than a worker. It doesn't write code itself; it hands coding to Codex and heavy office work to ChatGPT Work. Those tasks show up as their own threads you can steer directly.

Cloud computer. Visible under Computers. You can hit Take over, drive the browser yourself and hand control back. Sign-in forms send credentials to the remote browser without the model seeing them; reusing a saved password requires your confirmation.
Your computer. Some sites block cloud browsers, so you can let a dot use your laptop via the ChatGPT desktop app (Allow access / Revoke access). One personal computer at a time, and it must be online with the app open.
Plugins. The same as ChatGPT, Work and Codex, with permissions per action: read email yes, send email no.
Limits. Talking to a dot doesn't count toward ChatGPT usage limits. Codex and Work tasks it starts do.

Memory: it learns, but you can't see the notes

A dot draws on the conversation, relevant ChatGPT memory and its own notes. The notes are the most controversial part of the system: you can't view, correct or delete individual entries. The only full reset is deleting the dot. Disconnecting a plugin stops new access but keeps what was already learned; turning off ChatGPT memory stops sharing but doesn't delete what the dot already received. Credentials, images and screenshots don't go into dot context.

For an agent that reads your mail for months, the lack of a "forget this" button is a real gap.

Four rules, and what a dot will never do on its own

The core of dots isn't the model, it's the permission system. Under Custom rules, every action gets one of four modes:

Take action without asking — routine where mistakes cost nothing.
Take action when you say so — pre-approved, executed on your command.
Ask before taking action — the dot prepares a draft and waits for your yes.
Hand off to you — the dot gets the task to the point where a human is needed.

On top of your rules sit limits you can't remove:

Password changes and money transfers always go back to you.
Purchases need approval, and advance approval only works for a specific purchase.
Permanent deletion and software installs may need approval every time.
Auto-review checks actions that touch accounts or share information, such as sending email, and can block, ask or stop. The dot can't turn it off.
Proactive research is read-only: it can't send messages, change app content or control a browser.

Pause stops the main task but not necessarily delegated or scheduled work, and nothing is rolled back: a sent email stays sent.

The safety numbers

From the GPT-6 Astra system card appendix, as reported in Flavio Copes's deep dive (the only source with the full set):

Prompt injection: 100 runs of 500 simulated emails, 16,600 attacks — none succeeded.
Adaptive attacker: 2,638 attempts, no success.
Scope violations in chained tasks: 8.6% with five tasks in between, 19.7% with ten. No severe breaches.
Permission changes mid-task: adapted in all 17 explicit cases; passed 45 of 49 episodes.
Data exfiltration by human red-teamers: all attempts failed.

The third line is the one I care about. In a chain of ten tasks, almost one time in five the agent steps outside its brief. That's not a hack, it's an agent forgetting what it was asked — and long chains of tasks over weeks are exactly how a dot is meant to work. OpenAI says it plainly: "Dots can still make mistakes, so always review consequential work."

Who gets it and what it costs

Plan	Dots	Price
Free, Go, Plus	No, no date	—
Pro	One dot; not in the EEA, UK or Switzerland	from $100/month
Business Premium	One dot, all supported regions	$100/user/month annually, $125 monthly
Enterprise, Edu, Healthcare	Beta, off until an admin enables it	via sales

The first dot is included, with extended limits for the first month after launch. Post-launch limits, extra dots and extra capacity have no published prices yet. Setup is desktop-only, and users under 18 can't use dots.

Dots vs. the competition

Product	What it is	Difference from dots
OpenAI dots	One always-on coordinator with its own cloud computer, 4,000+ apps	Delegates to Codex and Work, strict rules, no API
Grok Bot	Closest match: persistent cloud computer, scheduled work, asks before sensitive actions	Several named Bots instead of one agent
Cursor Projects	Coordinator for long-running coding work	Coding only, returns pull requests
Meta Muse	Consumer assistant for errands, travel and forms via the Muse app and WhatsApp	Free for most uses; a small-business version launched on DevDay

This comparison is based on product descriptions, not measurements.

What dots can't do yet

No email address of their own.
Can't call you; texting is a narrow beta for some US Pro users.
One primary dot per person; teams of dots are planned.
No API.
No way to inspect or clean memory entry by entry.

A developer's view: no API is a signal

I build apps and agents, so the first thing I looked for was a way to talk to a dot from code. There isn't one: OpenAI hasn't announced an API for dots. It's a ChatGPT product, not a developer platform.

The Codex link is telling, though. A dot can start a task in a Codex cloud environment while your computer is off, send work to your connected machine, or continue an existing Codex thread. OpenAI is building a hierarchy: on top, an agent that knows you and your work; below, specialized executors. If you build agents yourself, selling "an assistant that does everything" just got harder, while a niche executor with a clear interface is still in demand.

What I'd hand to a dot

A good dot task is recurring, spans several apps and ends in a draft:

Every Friday at 4 pm, match delivered projects to invoices, draft missing invoices, send nothing, message me a list.
Watch the Leads label, draft replies, ask before sending, flag anyone silent for 48 hours in Slack.
Weekly, compare stock with reorder levels and draft purchase orders for approval. Never place orders.

A bad task is one where mistakes can't be undone: money, passwords, unchecked emails to important people. Not because the dot is dumb, but because 19.7% out-of-scope on long chains is a lot for irreversible actions. Treat it like a new assistant: drafts first, then widen permissions one at a time.

Originally published at klukyanov.ru.

Shorter weekly write-ups (in Russian) — on Telegram.

Swift on Android, part 1: what the official SDK does and how it differs from KMP

Kirill Lukyanov — Tue, 13 Oct 2026 13:13:12 +0000

I ship an app on Kotlin Multiplatform, and when I counted the lines, the shared Kotlin code turned out to be just 14% of the codebase. So here's the question I keep asking myself as an iOS developer: what if the shared code had been Swift running on Android, instead of Kotlin running on iPhone? Since Swift 6.3 that's an officially supported option.

This is part 1 of a three-part series. Here I cover what actually shipped, how it works, what's in the Swift SDK for Android and what isn't, and how it compares to KMP feature by feature. Part 2 is hands-on, and part 3 is an honest side-by-side on a real app.

Why I care

MyCarCode, my car maintenance log, is built with Kotlin Multiplatform: shared logic in Kotlin, native UI on both sides (SwiftUI and Jetpack Compose, each with its own Flux stores). At build 8 I counted:

shared Kotlin code (commonMain): 1,574 lines
iOS UI and stores: ~9.8k lines of Swift
Android UI and stores: ~9.6k lines of Kotlin

That's roughly 14% shared code. For that 14% I paid with a second language on the iOS side, Gradle running inside the Xcode build, and a long fight with Firebase linking. If I mentally write the logic in Swift anyway, maybe Swift should be the one traveling.

What shipped and when

June 2025. The Swift project announced the Android Workgroup.
October 24, 2025. First nightly previews of the Swift SDK for Android on swift.org.
March 24, 2026. Swift 6.3: the "first official release of the Swift SDK for Android."
September 15, 2026. Swift 6.4, a day after Xcode 27. The getting-started guide currently targets SDK 6.4.1.

Important: this isn't Apple shipping Swift for Android. It's the open-source Swift project and its workgroup. SwiftUI, UIKit and Apple frameworks don't come along.

How it works

The SDK is a cross-compilation kit. You write a regular Swift package on macOS or Linux, and swift build targets Android instead of macOS. It relies on the Android NDK (the guide asks for LTS r30). The examples use aarch64 (devices) and x86_64 (emulator) with API level 23.

# 1. Swift toolchain matching the SDK version
swiftly install latest

# 2. The Android SDK itself
swift sdk install <archive-url> --checksum <sha256>
swift sdk list   # swift-6.4.1-RELEASE_android

# 3. Android NDK r30
export ANDROID_NDK_HOME=$PWD/android-ndk-r30

The output is a native .so per architecture. It isn't an app on its own: the app stays a regular Kotlin/Java Android project, the library ships inside the APK, and Kotlin calls into Swift through swift-java, the official bridge and code generator that produces Java wrappers over JNI.

It's a mirror image of KMP. In KMP, Android is home and Kotlin travels to iPhone as a native framework talking to Swift through Objective-C headers. With the Swift SDK, iOS is home and Swift travels to Android, talking to Kotlin through JNI.

What's in the box

The whole language. Same Swift 6.4 compiler, strict concurrency, async/await, actors, macros. No "lite dialect."
Standard library and Foundation. Dates, strings, Codable, JSON. Networking (URLSession) lives in FoundationNetworking off Apple platforms and is imported explicitly.
Swift packages. Anything that already builds on Linux and doesn't pull in Apple frameworks has a good chance of building for Android.
A two-way bridge. swift-java can call Swift from Kotlin and Java classes from Swift. Async Swift functions surface in Java as CompletableFuture.
Real-world proof. Skip Fuse builds whole SwiftUI apps for Android on top of this same official SDK.

What's missing

UI. No SwiftUI or UIKit on Android. Screens are Jetpack Compose; Swift stays under the hood (unless you adopt Skip and its rules).
Apple frameworks. SwiftData, Core Data, StoreKit, HealthKit, Combine stay on iPhone.
Service SDKs in Swift. Firebase, Google Sign-In, payments have Kotlin libraries for Android and Swift libraries for iOS, but no Swift build for Android. From shared Swift code you reach them through the Java bridge or Skip's wrappers. For MyCarCode, whose whole data layer sits on Firestore, this is the big one.
Comfortable debugging. It's a stated workgroup goal, but "set a breakpoint in Android Studio and step into Swift" isn't there yet. From the Android side the debugger sees generated Java wrappers.
A mature bridge. Early adopters report that every Swift error reaches Kotlin as a plain java.lang.Exception, and swift-java has open issues around async functions with generic results.

Swift SDK vs. KMP, feature by feature

This is based on documentation and other people's experience, not my measurements. My numbers come in part 3.

	Swift SDK for Android	Kotlin Multiplatform
Shared language	Swift	Kotlin
Status	Official since Swift 6.3 (March 2026)	Stable since November 2023
Home platform	iOS (Android is the guest)	Android (iOS is the guest)
Guest artifact	Native `.so` per ABI inside the APK	Native `.framework` via Kotlin/Native
Language bridge	swift-java over JNI, generated Java wrappers	Objective-C headers, SKIE, experimental Swift export
Async	`async` → `CompletableFuture` in Java	`suspend` → `async/await` in Swift (via SKIE)
Errors	Arrive in Kotlin as `java.lang.Exception`	Without `@Throws`, an exception crashes the iOS app
Shared UI	None (only via third-party Skip)	Compose Multiplatform, stable on iOS since 2025
Libraries	Swift packages that build off Apple platforms	Own ecosystem: Ktor, kotlinx, Koin, SQLDelight
Firebase in shared code	No native build; bridge or Skip	Yes: GitLive Firebase SDK (unofficial)
Debugging shared code	Good from iOS, weak from Android	Good from Android, weaker from iOS
Fits best	iOS-first teams	Android-first teams

In one sentence: both solve the same problem from opposite shores. Both share logic, not screens (Compose Multiplatform and Skip aside). Both make one platform live with a foreign language and a bridge. The difference is which team feels the bridge, and that KMP has two and a half more years of scars and libraries.

Who should try it now

My preliminary take, before installing anything myself:

Yes, if you have an iOS app with heavy logic that doesn't depend on services: calculations, parsers, validation, file formats, an offline engine. That code can go to Android nearly as is.
Yes, if your team is all-Swift and the Android version just needs to exist. Skip on top of the official SDK is the shortest path.
Not yet, if your shared layer is built on Firebase and other service SDKs. You'll be bridging to their Android versions, and the savings end there. KMP with ready-made wrappers is ahead.
Not yet, if your team is mostly Android developers who'd have to debug Swift through generated Java wrappers. KMP will feel like home to them.

What's next in the series

Docs tell half the story. They won't tell you how much a Swift library actually weighs inside an APK, how long the first setup takes, or where the bridge breaks on real code rather than "Hello, Android."

In part 2 I install the SDK on my Mac and try to build real logic from one of my apps for Android: actual models and calculations that live on iPhone today. What compiles on the first try, what needs rewriting, how big the result is, and whether I can call it from Compose at all.

In part 3: an honest comparison with KMP on MyCarCode. I kept a full log of what broke when Kotlin moved to iPhone: hand-unpacking Firebase into frameworks, duplicate symbols at link time, a crash caused by one forgotten annotation, and a bug where a screen wouldn't close itself after saving because the Kotlin code resumed on the wrong thread. I'll go through which of those the Swift SDK removes and which it just moves to the other shore.

A spoiler I'm not sure about yet: some of those rakes will turn out to be mirror images. We'll see.

Originally published at klukyanov.ru.

Shorter weekly write-ups (in Russian) — on Telegram.

ASO on my own apps: what actually moved App Store impressions in a month

Kirill Lukyanov — Mon, 12 Oct 2026 12:46:34 +0000

A month ago, almost nobody in the US or Europe could see my clay shooting app on the App Store: 97% of its impressions came from Russia, Kazakhstan and random countries. Today two thirds of impressions come from the US and Europe, and daily impressions are up 5×. And my Mac app went from #130 to #9 for "eye strain" in the UK store.

Here is how I approach ASO as a solo developer, what I actually changed, what moved, what didn't, and what's next. Two live examples: Clay Sniper (iPhone + Apple Watch, a log for trap, skeet and sporting clays) and SafeYourEye (Mac, eye breaks and self-check vision tests).

About the numbers. All volume metrics below (impressions, page views, installs, ratings) are multiplied by the same constant. I don't publish real values, but proportions and dynamics are exact. Search rankings are real: a position says nothing about money. Revenue, subscriptions and ad budget are not shown at all.

What ASO is made of

ASO has two halves, and the order matters:

Being found — search ranking.
Being chosen — conversion from impression to page view to install.

Improving conversion is pointless while nobody sees the product page.

Search on the App Store is driven by a few fields:

Name — 30 characters, the heaviest weight.
Subtitle — 30 characters, second by weight.
Keywords — 100 characters, comma-separated, invisible to users.
Localizations — each language has its own set of these three fields. And each storefront also indexes several other locales: the US store reads es-MX, ru, zh-Hans, fr-FR and more on top of en-US. That's cross-localization: free extra keyword space.

Conversion is driven by screenshots, the App Preview video, ratings and Custom Product Pages (alternative versions of your page for different queries and ad groups). Promotional text (170 characters above the description) can be changed without review — leaving it empty means wasting a free lever.

The process: seven steps

#	Step	What I do	Why
1	Baseline	Impressions, page views, installs by source and country (`asc analytics`); rankings for 20–40 queries per target country	Without a "before", there's no proof. Apple keeps daily analytics for ~9 days, so I collect it weekly
2	Pick markets	Decide where the app should grow and where to leave it as is	Keywords, locales and screenshots target specific storefronts
3	Build the semantic core	App Store search suggestions, iTunes Search API results, competitor metadata, terms from the app's own code	Without paid tools you can't measure query volume, so I look at competition: how many apps rank and how relevant they are
4	Duplicate audit	Overlap between name, subtitle and keywords	A word repeated in keywords is wasted characters. In SafeYourEye, duplicates ate a third of the field
5	Spread across locales	Own name, subtitle, keywords per storefront language, plus a second keyword pool via cross-localization	Without its own locale, a storefront shows the default language — sometimes Russian
6	Ship and amplify	`asc metadata push` with the release, promotional text right away, Custom Product Pages for key queries	Metadata lives in the repo, so every change is a diff
7	Measure in 1–2 weeks	Repeat step 1, compare per country and per query	Indexing takes days; looking earlier means reading noise

All of this is wrapped into a Claude Code skill and a dashboard: one weekly command pulls App Store analytics for all my apps, rankings across target storefronts and a metadata snapshot with change history, through the official App Store Connect API.

Starting point: nobody saw the page

Clay sports live mostly in the US and Europe. In mid-September Clay Sniper looked like this:

72% of impressions from Russia and Kazakhstan, a quarter from random countries, 3% from the US and Europe.
Three locales: ru, en-US, de-DE. The primary language was Russian, so France and Italy saw the Russian page.
Not in the US top 100 for "trap shooting", "sporting clays", "skeet".
Zero Custom Product Pages, empty promotional text, no review prompt in the code.

The diagnosis in one line: no sales not because the page fails to convince, but because almost nobody sees it. The funnel wasn't leaking — it was tiny at the top. So: reach first, conversion second, paid traffic third.

What I changed

Date	Version	Change
Aug 23	1.1.0	Keywords rewritten around disciplines: "double, compact, fitasc, 5stand, scorecard" instead of generic "shooting, range, gun, hunting". First promotional text
Sep 21	1.2.0	German locale
Sep 26	1.3.0	French locale: "ball-trap", "carnet de tir", "compak"
Oct 1	1.4.1	en-GB with British terms ("DTL", "clay pigeon", "cartridges"), Italian. en-US keywords cleaned of words already in the subtitle
Oct 6	—	Apple Ads pilot in the US: competitor and niche queries, exact match
Oct 7	1.4.2	es-ES and es-MX (a second keyword pool for the US). 8 locales total
Oct 8	—	Apple approved 12 Custom Product Pages (trap, skeet, sporting, Apple Watch, stats…) in under a day
Oct 11	—	All 12 Custom Product Pages got versions in six more storefront languages, with their own keywords and screenshots

Both apps also got a system review prompt after a good moment (in Clay Sniper — a finished session). Ratings doubled over the period, average 5.0.

For SafeYourEye the audit found two problems: a third of the keyword field duplicated the name, and the app's real differentiator — vision self-checks on a Mac (acuity, contrast, astigmatism, Amsler grid) — wasn't searchable at all. For queries like "visual acuity" and "amsler grid", there are only 12–24 apps in results, almost none about Mac vision checks; for "Sehtest" in Germany we're the only one. New name: "SafeYourEye: Eye Strain Timer", subtitle "20-20-20 Break & Vision Test", plus en-GB, fr-FR and it.

Dynamics

Clay Sniper, daily averages by week (volumes scaled):

Week	Impressions/day	Page views/day	Impression → page	New installs/day	US + Europe share
Sep 16–20	1,020	80	7.8%	0	3%
Sep 21–27	1,193	71	6.0%	7	25%
Sep 28 – Oct 4	1,246	286	22.9%	21	30%
Oct 5–7	992	83	8.4%	0	36%
Oct 8–10	4,867	192	3.9%	8	68%

Geography flipped. The main result: target markets went from 3% to 68% of impressions. Locales started working.
Installs appeared. Zero new installs in the week of Sep 16–20, every week since Sep 21.
The late-September spike was a one-off. It matched the 1.4.0/1.4.1 releases, but conversion returned to 8% a week later. At these volumes I can't separate the metadata effect from noise, so I don't try.
A jump from October 8. Daily impressions grew 5×, almost all of it from the US and the UK. That same day Apple approved the 12 Custom Product Pages and my Apple Ads groups were switched to them. How much is ads vs. organic, the Apple Ads report will tell — next time. Page-view conversion dropped to 3.9%: the new audience sees the app but doesn't open it yet.
Apple backfills data. The first pull showed October 8 as almost empty; the next one showed it as the peak of the week. Don't draw conclusions from the last 2–3 days.

SafeYourEye gets fewer impressions (Mac App Store search is smaller): 105–185 a day, and zero new installs in a month. People find the page and don't open it. That's a conversion problem now, not a search one.

Rankings, before and after

Positions via iTunes Search API (close to the real App Store, not identical). "—" means not in the top 200. Before: Sep 23–27; after: Oct 9 for SafeYourEye, Oct 12 for Clay Sniper.

App	Country	Query	Before	After
SafeYourEye	UK	eye strain	130	9
SafeYourEye	Germany	eye strain	83	13
SafeYourEye	US	eye strain	170	39
SafeYourEye	Germany	eye health	126	54
SafeYourEye	France / Italy	pause yeux / pausa occhi	no locale	7 / 5
SafeYourEye	US	20-20-20 rule	11	—
SafeYourEye	US	eye care timer	39	100
Clay Sniper	US	clay shooting	—	29
Clay Sniper	Germany	Tontaubenschießen	—	8
Clay Sniper	France	ball trap	—	106
Clay Sniper	UK	clay pigeon	—	45
Clay Sniper	Germany	Wurfscheiben	4	5
Clay Sniper	US	trap shooting / sporting clays	—	125 / 108

There are wins and losses here, and that's the honest price of a decision. Swapping "Eye Care Timer" for "Eye Strain Timer" in the name lifted the broad query in three countries and dropped the narrow ones. The broad query brings more impressions, so it's a good trade — but if you only look at winners, ASO looks like pure growth.

Clay Sniper's head terms in the US, "trap shooting" and "sporting clays", have only just entered the top 200: niche leaders like HotClays sit there, and those words are only in my subtitle. "Clay shooting" holds in the 20s, but it jumps day to day (35th, 18th, 29th within four days), so I trust weekly trends, not single measurements. In the new locales "shooting log" (UK), "Wurftaube" (Germany) and "strozzatore" (Italy) landed in the top 5 right away.

What I learned

Locales beat keyword polishing. The biggest shift came not from tuning 100 characters but from the page speaking the storefront's language.
Custom Product Pages only accept words from the keywords field. Words from the name and subtitle can't be assigned. My two main pages, trap and skeet, ended up with zero US keywords. Plan your field split with future pages in mind.
Impressions and installs are different problems. SafeYourEye climbed in search and got zero installs. Search brings people to the page; the page has to do the convincing.
Finish metadata before submitting for review. While a version is waiting for review, you can't add a new locale. I once had to withdraw a submission to add languages.
No baseline, no proof. Apple keeps daily analytics for about nine days. If you don't collect regularly, a month later there's nothing to compare against.

What's next

Clay Sniper has a 90-day plan until December 22. The locale goal (7) is already exceeded with 8. The rest:

Keywords for Custom Product Pages — reshuffle words between fields so trap and skeet pages get their own queries.
A storefront for Western markets — demo data in US/UK screenshots still shows Russian clubs and ammo; reshoot it and add an App Preview to the main page with the next version.
Community — emails to federations and clubs in the US, UK, France and Italy with free access via offer codes, each link with its own campaign token.
Apple Ads — US pilot first, then the UK; money decisions only on numbers.
SafeYourEye — fix conversion: first two screenshots, promotional text, video.
The rest of my apps — two of them still rank nowhere, even for their own name. They're next.

The goal by year-end: 3× daily impressions vs. the start and 5× more ratings than today. I'll report back in a month.

Originally published at klukyanov.ru.

Shorter weekly write-ups (in Russian) — on Telegram.

An AI film crew made our app ad: who did what

Kirill Lukyanov — Fri, 09 Oct 2026 11:13:17 +0000

Seventeen seconds: a red-haired champion, a jittery rookie, tea from a tartan thermos and a shot at sunrise. There isn't a single real frame in this ad. AI agents wrote it, cast it, shot it and cut it, each in its own role. My job was to approve things and reject things.

Watch the ad (9:16, 1080×1920, 20.6 s, sound on): clay-sniper-ai-ad.mp4

The ad is for Clay Sniper, my iPhone and Apple Watch logbook for clay shooters. It took three days, October 7–9, from the approved plan to the final file: two for the shoot and the first cut, and one more for polishing. Here's who did what, which ideas went into it, and where it nearly fell apart.

Why generate an ad at all

Clay Sniper already has an App Preview on the App Store, and it's honest: a screen recording of the real app, the watch, a real gunshot sound. Apple doesn't accept anything else there. But that video only works for people who've already opened the product page. To get them there, you need something for the feed: Reels, Shorts, TikTok. Fifteen seconds, a story, faces, a joke. A solo developer can't shoot that with actors on a real range, so I had it generated.

This was the second attempt. The first ad, "Hands full", ran on a local video model on my second Mac: no voices, almost no faces. It taught me the main lesson about hooks (more on that below). For "The Legend" I switched to a cloud model that can hold characters, dialogue and sound.

The idea: even legends miss

An ad needs one promise, not a feature list. For a shooter's logbook, Claude put it like this: "Even legends miss. The difference is they know exactly where." The end card squeezes it into three words: KNOW YOUR MISS.

The camera style was mine: someone else's ad I liked. A field at golden hour, two armchairs and a side table in the grass, Wes Anderson symmetry, warm film grain, a cut every 2–3 seconds, snap zooms, whip pans, macro inserts. We cut three short silent clips from it and used them as camera-motion references only. The model was told not to copy the people, the props or the story, just the way the camera moves.

Two characters carry the story:

The Legend: a fictional champion with fiery red hair, amber shooting glasses pushed up on her head, an olive vest, a dry half-smile and slow, precise movements.
The Rookie: a jittery newcomer in a brand-new orange vest with the price tag still on the sleeve. He asks the question the viewer would ask.

He asks "How do you never miss?" She says "I do. I log them." and slides her phone with the stats toward him. Then she solemnly sips tea from a tartan thermos, walks to the station and smokes the clay. The tweed crowd erupts. The myth of the flawless shooter breaks, and the product shows up as evidence in her hand, not as a slide.

The crew: who did what

The most interesting part of the project is how the roles split. Two agents and one video model did the work, and each had its own job, just like on a real set.

Role on set	Who	What they did
Showrunner	Me	Brought the style reference, approved the plan and the heroine, accepted the draft, lifted the "no gun on screen" rule, picked a silhouette over a face for the shot, decided to upscale to 1080p in the edit, made the calls at every fork
Screenwriter	Claude	The promise, a four-part beat sheet, a six-shot storyboard, dialogue timing at 2.5 English words per second, a retention pass
Fact-checker	Claude	Checked every line and every screen against the app's code and real screenshots. Cut a feature that didn't exist
Character artist	Codex	Character sheets: the heroine full-length, from behind and as a portrait (two versions), the rookie. The model uses them to keep faces consistent shot to shot
Production designer	Codex	The location start frame: armchairs, table, thermos, crowd behind a rope, a phone with a bright green screen to replace later
Director	Claude	A brief for six cuts pinned to timecodes, the 180-degree rule, camera-motion references, a list of restrictions
Camera, cast, sound	Seedance 2.5	Shot every cut in one pass, played both leads and the crowd, voiced the lines, the range noise and the shots
Production coordinator	Claude	Launched the generation, watched the queue, saved the IDs of every piece so we could come back to them
Editor and sound	Claude	Edit decision list, cuts, subtitles, the KNOW YOUR MISS card, an App Store end card, the 1080×1920 upscale, frame-by-frame screen fixes, a real gunshot layered over the generated one
Censor	Claude	Caught what ad platforms reject: barrels pointing at the camera, revealing angles

Notice that Claude has the most roles but none of them involve drawing. It writes, counts, checks, briefs and edits. Codex and Seedance make the pictures; Claude writes their briefs and signs off on the result.

Fact-checking: a line that couldn't exist

In the first draft, the Legend answered dryly: "I do. Station four." Nice line. But Claude checked it against the app's code first and found per-station stats only in the competition schedule. You can't show a screen that doesn't exist in an ad, so the line became "I do. I log them.", and the phone got a real screen with a best series of 22/25.

The next day it turned out per-station stats do exist: a By station screen shipped in a newer version that lives in a different repository. Station 7 is red on it, 50%, which is KNOW YOUR MISS in a single picture. The second version of the ad shows exactly that screen.

The lesson goes back to the first ad. Its hook was that a gloved finger can't tap a phone screen, while the watch crown still works. I rejected the shots: on the range people wear thin shooting gloves, and those work with touchscreens just fine. The hook was false for the very audience it targeted. The rule since then: check everyday details against real life and features against the code, both before generating, not after.

Casting: character sheets

A video model doesn't remember what a character looked like in the previous shot. To make the red-haired Legend in cut one the same person as in cut six, you feed it a character sheet: full-length, from behind, and a portrait. Codex drew those.

I approved the heroine on the second try, and the rule was strict: the look gets approved before any video runs. Redrawing a picture takes a minute; reshooting an ad because the face is wrong takes hours.

Claude also set boundaries for the character: striking, but not sexualized. No body-focused angles, no cleavage, no bare skin. The charisma comes from light, gaze and that half-smile. The reason is practical: ad platforms reject such creatives, and the video model simply refuses those prompts. Other restrictions: no real people or athlete lookalikes, no logos. Even the thermos is unbranded, just tartan.

Storyboard: six shots in fifteen seconds

#	Time	On screen	Why
1	0–2.5 s	An orange clay bursts in slow motion. The crowd turns heads in unison. Caption: "She hasn't missed all day."	Hook: everyone is looking the wrong way
2	2.5–5 s	Whip pan to the armchairs, over the rookie's shoulder: "How do you never miss?" Snap zoom on her: "I do."	Character clash and the viewer's question
3	5–7 s	Macro: her hand slides the phone, per-station stats on screen. Voice-over: "I log them."	The product as evidence, not a slide
4	7–10 s	She pours tea from the thermos and takes a solemn sip. The rookie, out of focus: "...tea?"	The most shareable beat, a pause before the shot
5	10–12.5 s	Silence, a silhouette at the station against the sunrise, "Pull!", the shot, the clay turns to dust	The hook's promise is paid off
6	12.5–15 s	Perfect symmetry: she raises the thermos cap like a toast, the rookie copies her with an empty hand. KNOW YOUR MISS	Finale and one line of promise

A few professional rules Claude followed without being asked:

The 180-degree rule. In the dialogue the rookie is always on the left and she's on the right. The camera never crosses the line between them.
Varied shot sizes. Extreme wide, medium, macro, close-up, wide, wide. Never three of the same in a row.
Dialogue windows. Every line is timed at 2.5 words per second. "I log them." didn't fit the macro shot, so it became a voice-over on top of the phone.
Works with the sound off. Subtitles duplicate every line and sit between 15% and 75% of the frame height, clear of the Reels and TikTok buttons.

The shoot: the whole ad in one pass

Seedance 2.5 shot the first draft in a single pass: all six cuts from one generation. It got six references: three images (both character sheets and the start frame) and three video clips with the camera style. Every camera move in the prompt pointed to its reference: "over the shoulder like Video 1", "whip pan like Video 3".

The job sat in the queue for almost two hours. The draft came out at 480p, 14 seconds. A pleasant surprise: the model produced voices, intonation, the gurgle of tea and the crowd noise itself. No separate voice-over needed.

I accepted the draft with two notes. First, the gun wasn't visible in the shooting scene. That came straight from the prompt: Claude, being cautious, had banned close-ups of the gun, and the model removed it altogether. Second, Claude had composited a real stats screenshot onto the green phone screen, but at 480p the "Best series 22/25" line was unreadable.

Fixes: reshoot pieces, not the whole ad

Regenerating the whole ad for two notes means gambling everything that already works. The model shoots differently every time, and the heroine in the tea shot could come back as someone else. So Claude reshot only the weak pieces as separate generations. The first round, the phone and the shot, took about twenty minutes. The shot was later reshot once more, more on that below.

Piece	Draft v1	Final
Phone, 4 s	Green screen with a perspective-warped screenshot. Numbers blur at 480p	The model got our own clip as a "repeat this frame by frame" reference plus the By station screenshot. Motion repeated, screen drawn by the model, large station badges readable. Later the Russian demo clubs were swapped for US ones
Shot, 5 s	Silhouette from behind, no gun visible, a "pistol" pose	Third take: one shot from behind and slightly to the side, a silhouette at sunrise, the whole gun visible, no face. The prompt describes a long double-barrel shotgun and a proper trap stance; a pistol grip is banned
Phone in wide shots	A 26×12 px green rectangle on the table	We tried the splash screen and the icon; both dissolve into a blob at that size. The screen is now off: nearly black with a reflection
Length	15 s	20.6 s: 18 s of story from three generations with freeze frames at the joins, plus a 2.5 s end card

The biggest surprise was the phone screen. The assumption had been that you can't trust a model with small UI, so Claude always composited the real screenshot on top. It turns out that if you give the model its own clip as a motion reference plus the screen image, it repeats the shot and draws the UI itself. Large elements, numbers and badges, come out readable. Small text still drifts, so this only works for large on-screen elements.

The edit: an EDL and a censor

The final ad is assembled from pieces of three generations. Claude described it as an edit decision list: for every piece, the source, in and out points, which audio to use and whether to hold a freeze frame at the end. A build script assembles the video from that list and lays on the subtitles, the end card and the sound. The gunshot is a real one, taken from the App Preview recording, layered over the generated one.

The cuts inside the generated draft had to be found by hand: standard scene-change detectors found nothing in this video. Claude compared neighbouring frames pixel by pixel and located cuts by spikes in the difference, then timed the subtitles by the loudness of the audio track.

Censorship landed in the edit too. In the second take of the shooting scene the model swung the barrels straight at the camera for just over a second. That's a no-go for an ad, so Claude cut the piece entirely. What was left of the three-quarter view lasted about half a second and looked like a fragment. So I asked for the scene to be reshot differently: one shot from behind and slightly to the side, a silhouette against the sunrise. The whole gun is visible, and the barrels physically can't point at the camera. That third take made the final cut.

Polishing: one more day

The ad that looked done on the evening of October 8 wasn't ready to run: no app name, no App Store link, and the picture was still 480p. Polishing took another day, and the model didn't shoot a single new frame for it. It's all editing.

1080×1920 on our own. Regenerating in 1080p would have meant reshooting every piece and gambling the good takes again. So Claude upscaled the 480p sources during assembly with careful scaling and light sharpening. Subtitles and cards are drawn natively at 1080, so text stays sharp even where the picture is softer.
A 2.5-second end card. The last frame blurred, the icon, the name Clay Sniper, the subtitle from the App Store listing and the official Download on the App Store badge, taken from Apple's site rather than redrawn.
US clubs on screen. The phone close-up showed clubs from Moscow and Krasnodar at the bottom, the app's demo data. For a US campaign Claude captured a fresh screenshot with US demo data, clubs in Texas and Pennsylvania. Instead of regenerating the piece, the new card was pasted in frame by frame: on the close-up it's anchored to the old screen by keypoints; on the table, where the screen is tiny and in steep perspective, the screen corners are tracked frame to frame and motion blur is added to match.
The pump click. In the shooting scene the model generated the sound of a pump-action being racked. A double-barrel has no pump, and any shooter would hear it. Claude muted that third of a second.

One thing stayed as it was. In the phone piece the model zooms in until the screen fills the frame and the phone body disappears. I wanted the whole phone in her hand, but there's no such frame in the footage. We discussed three options: redraw the frame with a local model and paste in the screenshot, crop the zoom out, or reshoot the piece. We decided it doesn't hurt the ad.

What didn't work

The wink. I asked for a glance over the shoulder with a wink before the shot. The model never did it.
Resolution. The sources are 480p and the final is upscaled to 1080×1920. Fine for a phone feed, but softer than true 1080p.
The whole phone. The model zooms in so far that the phone body disappears. There's no frame with the whole phone in her hand.
Subtitles by ear. Timing was matched to the track's loudness; no human ear has checked it yet.

What I took away

It felt less like using a tool and more like working with a small film crew. I didn't write prompts or scrub a timeline. I looked at frames and said "yes", "no", "actually, let's show the gun". Claude kept the whole project in its head, from the promise to the last cut, and talked to each crew member in their own language: character sheets for Codex, a second-by-second brief for Seedance.

Second: fixes. Generate the whole ad once, then reshoot only the weak pieces. What works stays put, and a fix takes minutes instead of hours.

Third: fact-checking beats beauty. The most dangerous mistakes in this project weren't in the picture but in the meaning: a line about a feature the agent didn't find at first, and a glove hook that turned out to be false. A model will draw anything, so whether it's true has to be checked before you generate.

Originally published at klukyanov.ru.

Shorter weekly write-ups (in Russian) — on Telegram.

Google put AI chips in orbit: radiation is not the problem, heat is

Kirill Lukyanov — Wed, 07 Oct 2026 19:08:21 +0000

On October 1, another Falcon 9 lifted off from Vandenberg on the Transporter-18 rideshare, carrying about 130 payloads at once. Among the cubesats and Earth-observation satellites was a fridge-sized spacecraft that Google internally calls simply MVP. Inside are four server-grade AI chips, the same ones that run Gemini models in Google Cloud.

The headlines say "Google launched a neural network into space", and the obvious question is: why? Neural networks work perfectly well on the ground. The answer is more interesting than it looks. Google is not testing a model, it is testing a hypothesis about data centers. And the main problem this satellite has already surfaced is not the one everyone worried about before launch.

What actually flew

The spacecraft is the first prototype of Google's research effort Project Suncatcher. The bus was built by Planet, the company that already operates hundreds of Earth-imaging satellites. Google is responsible for the payload.


Launch	October 1, 2026, Falcon 9, Transporter-18, Vandenberg
Chips	4 TPU Trillium (v6e), a v6e-4 configuration, roughly one ground server
Power	Solar panels, about 1 kW
Orbit	Sun-synchronous dawn-dusk, about 650 km
Lifetime	About a year of planned operations, up to six years in orbit
Status	Contact established, the spacecraft is "operating as expected" (Travis Beals, project lead at Google)

The orbit is not random. In a dawn-dusk sun-synchronous orbit the satellite rides the terminator line, and the Sun almost never sets for it. By Google's own estimate, a solar panel there produces up to eight times more energy than the same panel on the ground: no night, no clouds, no atmosphere.

Radiation: an exam the chips passed on Earth

The obvious fear is space radiation. Server chips are designed for data centers, not orbit, and what usually flies is radiation-hardened electronics that lag generations behind in speed. If a commercial chip dies within a month, the whole idea dies with it.

So Google irradiated the chips first. At UC Davis's Crocker Nuclear Laboratory, Trillium TPUs were run under a 67 MeV proton beam, under real AI workloads rather than idle. The results were published as a preprint in November 2025 and later in the peer-reviewed journal Joule:

15 krad(Si): the maximum dose tested, with no permanent failures
~0.75 krad(Si): the dose a shielded chip accumulates over five years in orbit
2 krad(Si): the point where HBM memory started to show errors, the most vulnerable component
1 silent data corruption event: a wrong result that nothing flagged

That is a twentyfold margin over the five-year dose. Most bit flips are cleared by resetting the chip. The last item is the unpleasant one: an error that does not announce itself cannot be fixed by a reset. It has to be caught by checks in software. More on that below.

The real enemy is heat

Here is what looks like the main lesson of the first week. According to TechTimes, once in orbit the mission is defined not by radiation but by cooling. The chips run short Gemini queries in bursts of roughly fifteen minutes, after which compute has to stop so the radiators can shed the accumulated heat.

It feels counterintuitive: space is cold. But cold does not mean easy to cool. On Earth, air or water carries heat away from a server: convection. In a vacuum there is no convection. Only radiation is left, with the radiator glowing in the infrared. That is slow. Dissipating a kilowatt takes a lot of panel area, and every square metre is mass you have to launch.

In one line: energy in space is abundant, getting rid of heat is hard. An orbital data center is limited not by the power outlet but by the radiator.

A caveat: Google has not disclosed details of the duty cycle, and the fifteen-minute figure comes from TechTimes. But the physics behind it is unambiguous, and every orbital compute project runs into the same wall.

Why bother: the $200-per-kilogram economics

The motive is simple. Training and serving large models is bottlenecked by electricity: new data centers wait years for grid connections, and power systems cannot keep up with demand. In orbit the Sun shines almost around the clock, there is no land to pay for and no interconnection permits.

Google itself names the condition under which this works: launch costs must fall to about $200 per kilogram, roughly by the mid-2030s. Only then does an orbital data center match a ground one on energy cost. Today we are far from that number, and the whole bet rides on fully reusable super-heavy rockets like Starship.

Google's roadmap:

2026: one MVP satellite, to see whether a commercial TPU survives real flight
2027: two satellites with Planet, testing free-space laser links between spacecraft
Later: clusters; the research models a swarm of 81 satellites within a one-kilometre radius, linked optically

Laser links are the second key question after heat. Large models train on thousands of chips that constantly exchange data. If satellites cannot talk to each other at speeds comparable to cables inside a data center, the cluster becomes a collection of loners.

Who else is in the race

Google is neither the first nor the only one. Over the past year several players have reached orbit, each with its own approach.

Player	In orbit	Approach and plans
Google + Planet	Project Suncatcher: 1 satellite, 4 Trillium TPUs, ~1 kW (October 2026)	A decade-long research effort: two satellites with laser links in 2027, then clusters of 81
Starcloud	Starcloud-1 with an NVIDIA H100 (November 2025)	First data-center GPU in space, first model trained in orbit. Raised $170M at a $1.1B valuation (March 2026) and $250M more at $2.3B (August 2026)
SpaceX	A filing so far	In January 2026 filed with the FCC for up to a million data-center satellites at 500–2,000 km, linked via Starlink
Axiom Space + Kepler	2 orbital data center nodes (January 2026)	Processing other satellites' data in orbit, Kepler optical network at 2.5 Gbps
ADA Space + Zhejiang Lab (China)	12 satellites of the "Three-Body Computing Constellation" (May 2025)	744 TOPS per satellite, target of 2,800 spacecraft

The approaches split into two camps. China and Axiom build compute for space: satellites process their own imagery and data in orbit instead of pushing raw terabytes down a narrow link. That is pragmatic and pays off today. Google, Starcloud and SpaceX aim at something else, compute in space for Earth: moving the data centers that train and serve models into orbit. That is the $200-per-kilogram bet.

Starcloud stands apart: the startup not only flew the first data-center GPU, it also ran Google's Gemma model on it. In a sense, Google was beaten to "a neural network in orbit" with its own model.

What the skeptics say

Not everyone shares the enthusiasm. Commenting to TechTimes, astrophysicist Jonathan McDowell of the Harvard-Smithsonian Center for Astrophysics pointed to the cost of deorbiting: thousands of burning-up satellites leave combustion products in the upper atmosphere, and nobody really knows how that affects atmospheric chemistry. Space debris expert Moriba Jah of the University of Texas warns that mass deployments raise the risk of Kessler syndrome, a cascade of collisions that renders orbits unusable.

There are plain engineering questions too. Solar panels degrade by 0.5–0.8% a year. A broken chip in orbit cannot be replaced, while a ground data center swaps hardware every few years as faster generations ship. An orbital cluster ages together with its chips.

My take

What interests me most here is not space but how it changes the requirements for software. When hardware can return a wrong bit at any moment and goes off to cool every fifteen minutes, the program has to survive that: checkpoint, re-verify critical computations, resume calmly after a reset. On Earth we are used to assuming a server "just works". In an orbital data center that assumption is gone, and that single silent data corruption from the lab test says it louder than any number of kilowatts.

The MVP itself is not a data center. It is a check that the basic assumptions hold in real flight. It has answered the first question: the chips are alive. The second, what it costs to throw away heat, turned out to matter more than it looked on paper. The third, launch price, is decided not at Google but on SpaceX's launch pads. A real data center in orbit is probably a decade away if everything goes to plan. But for the first time it is not a slide deck, it is hardware that flies and answers queries.

Originally published at klukyanov.ru.
Shorter weekly write-ups (in Russian) — on Telegram.

Lunar Fasting: an intermittent fasting app that puts your Apple Health activity on the lunar calendar

Kirill Lukyanov — Sun, 04 Oct 2026 16:34:20 +0000

Intermittent fasting has one simple rule: eat inside a window, don't eat outside it. The rule is easy, keeping it is not. Some days the window holds effortlessly, other days you break by lunch and have no idea why. I wanted an app that doesn't just tick a timer but shows me, from my own data, which days are easier and which are harder.

That's how Lunar Fasting came about. It went live on the App Store on October 2, 2026: 157 days from the first commit, 28 builds, 656 automated tests and one App Review rejection. Below: how to pick a fasting interval, what the app does, and the two features it was really built for.

Fasting intervals: which one to pick

"16:8" means 16 hours without food and an 8-hour eating window. The longer the fast, the stricter the regime. The app supports six protocols:

Protocol	Fast	Eating window	In real life	Good for
12:12	12 h	12 h	Dinner at 8 pm, breakfast at 8 am — just no night snacks	Beginners
14:10	14 h	10 h	Dinner at 7 pm, breakfast at 9 am	A gentle next step
16:8	16 h	8 h	Eat from noon to 8 pm	The most popular one, the default
18:6	18 h	6 h	Eat from 1 pm to 7 pm, two meals	When 16:8 feels easy
20:4	20 h	4 h	Late lunch and early dinner in one short window	Experienced, for a while
OMAD	23 h	1 h	One meal a day	The strictest, only deliberately

The app is not a doctor: with diabetes, pregnancy, eating disorders or any chronic condition, talk to a doctor before you start.

My advice: start with 12:12 or 14:10 and move up when the current step stops taking effort. You can switch protocols any time, and past days won't be recolored — each day is judged against the goal that was active when it ended.

Fasting without a "start" button

Most fasting trackers have a timer you start and stop by hand. Forget to tap it and the day is lost. Lunar Fasting doesn't store fasting windows at all: they are derived from logged meals. Log breakfast and dinner, and the app knows how long you went without food.

A few rules came out of this, each pinned by tests. A 2 am snack honestly breaks the fast instead of stretching it. If you forgot to log yesterday's dinner, you don't get a 40-hour "record" — you get "no data". Log a meal retroactively and the whole chain recalculates.

Why lunar days, not calendar dates

A lunar day runs from one moonrise to the next, about 24 h 50 min. There are roughly thirty of them in a lunar month. Most lunar calendars compute them with a mean formula and are off by up to half a day. Lunar Fasting computes moonrise astronomically for your location and uses true new moon instants (Meeus), not averages.

To be clear: I don't claim the Moon affects appetite or how much you move. Science hasn't shown that. The app doesn't promise — it checks, on your own data.

Calories from a photo

Snap your plate and a vision model splits it into items — side dish, cutlet, salad — each with its weight in grams. Add a text hint for ambiguous dishes ("buckwheat with mushrooms, no oil") and accuracy goes up noticeably.

One deliberate decision: the model never computes the total. It only returns item names, grams and kcal per 100 g; the app does the arithmetic. Small models are surprisingly bad at mental math, and this way every number is visible and editable.

Recognition runs either on-device via Apple Intelligence (no network, no key, the photo never leaves the phone) or through your own key for OpenAI, Gemini, Qwen or DeepSeek, stored in the Keychain and sent straight to the provider. "Auto" mode tries on-device first. Meals are written to Apple Health too.

The main feature: your activity on the lunar calendar

On first launch the app pulls a year of activity from Apple Health — steps, active energy, workouts and stand hours — and keeps it updated, re-syncing the last week each time because watch data arrives late.

Four numbers become one activity index from 0 to 100. Each metric is normalized to a daily target and capped, so overachieving doesn't inflate it:

Component	Daily target	Weight
Steps	10,000	35%
Active energy	500 kcal	30%
Workouts	1	20%
Stand hours	12	15%

Without an Apple Watch, workouts and stand hours are almost always zero and the index would cap at about 65. So in statistics the app drops components you have no data for and renormalizes the weights.

Calendar days and lunar days don't line up, so each lunar day gets a weighted value from the two calendar days it overlaps, proportional to time. The charts show your average index for each of the thirty lunar days and each moon phase — your own year of movement, not someone's theory.

A forecast for the lunar month

The forecast is an additive model, and the app shows each day's breakdown:

Baseline — your mean index with a 45-day half-life, so recent weeks weigh more.
Weekday effect — 7 and 29.5 are incommensurable; without this axis, the weekly rhythm would leak into a fake lunar signal.
Recent trend — the last two weeks vs. baseline, decaying over the horizon.
Moon phase and lunar day number — hierarchical, and only if your history actually shows it.

The last part matters most: lunar effects go through empirical-Bayes shrinkage. With few observations they shrink to zero, so with no lunar pattern in your data the forecast honestly falls back to baseline, weekday and trend. There's an uncertainty band that widens with the horizon and a confidence level: the forecast appears after 21 days of history, medium confidence from 60 days, high from 180. With 60+ days the app also backtests itself: it hides the last two weeks, predicts them and compares the error with a naive "same as average" forecast.

Coming in 1.1: Google Health

If you wear a Google or Fitbit band with an iPhone, its data reaches Apple Health poorly: workouts go missing, calories and heart rate disagree, steps double. Lunar Fasting 1.1 adds a direct bridge: sign in with Google, and the app pulls workouts, steps, distance, active energy and heart rate from the Google Health API and writes them to Apple Health — deduplicated via HKMetadataKeySyncIdentifier, with Google's echo of Apple Health data filtered out. Band activity then feeds the index and forecast just like Apple Watch data.

One caveat: Google requires OAuth verification and a security audit for health scopes. Until then the feature runs in testing mode, capped at 100 users, so 1.1 ships it to a limited group first.

Free vs. Pro

Free: six fasting protocols, meals and manual calories, water, weight, daily ratings, lunar calendar, stats for steps, water, weight and calories, CSV export. No account, no server.
Pro: activity index, monthly forecast, calories from a photo. Weekly or yearly subscription with a 3-day free trial.

iPhone and iPad, iOS 17+, English and Russian. Get it on the App Store.

Would you trust a forecast that openly tells you when it has nothing to say?

Originally published at klukyanov.ru.

Shorter weekly write-ups (in Russian) — on Telegram.

Kimi K3, DeepSeek and GLM free from NVIDIA: I tested the claim and here is the catch

Kirill Lukyanov — Thu, 01 Oct 2026 09:42:31 +0000

A claim is going around: NVIDIA hands out a free API key for Kimi K3, DeepSeek V4.1 Flash and two flavours of GLM 5.3 — no credit card, fifteen minutes. I went through it myself. The models are real, the free tier is more generous than the reposts say, and there is one catch the headline leaves out: a phone number check that does not cover every country.

What NVIDIA gives away

NVIDIA Build is NVIDIA's catalog of hosted open models. The API is OpenAI-compatible: same /v1/chat/completions request, you only swap the base URL and the key. As of October 1, 2026, integrate.api.nvidia.com/v1/models lists 81 models, including the four most interesting open-weight releases of this autumn.

The part most reposts get wrong is the money. New accounts used to get roughly 1,000 credits, and people still quote that number. Credits are gone. NVIDIA's own account verification dialog now says "Unlimited API requests without daily limits". What is limited is the rate: threads on the NVIDIA developer forum converge on about 40 requests per minute per key, and a forum moderator stated in July that the limit depends on the model, use case and overall traffic and cannot be officially raised on the free tier.

40 RPM is 57,600 requests a day if you hammer it nonstop. For prototyping, a personal agent or evaluating a model on your own tasks, that is effectively unlimited. For production, NVIDIA points you to paid options: partner endpoints or self-hosted deployment.

The four models

All four are mixture-of-experts models, and all four ship with a 1,048,576-token context window.

Model	API ID	Total params	Active per token	Highlights	License
Kimi K3	`moonshotai/kimi-k3`	~2.8T	not stated	Long-horizon agentic coding, tool use, image input; thinking always on	Modified MIT
GLM 5.3	`z-ai/glm-5.3`	753B	~40B	Text, reasoning, tool calling	MIT with a clause for >$10B-revenue resellers
GLM 5.3 Flash	`z-ai/glm-5.3-flash`	320B	18B	Text + images, tools, structured output, thinking budget	MIT
DeepSeek V4.1 Flash	`deepseek-ai/deepseek-v4.1-flash`	552B	8B prefill / 16B decode	Multimodal, reasoning effort adjustable 1–100	MIT

Source: model cards on build.nvidia.com.

For coding I would start with Kimi K3 — it is the reason for the hype, and running it yourself takes a rack you do not have. Free access on someone else's GPUs is the only sensible way for most of us to try it. GLM 5.3 Flash and DeepSeek V4.1 Flash are for fast, cheap calls where you do not need the smartest answer.

The catch: phone verification

Sign-up itself is smooth: email, password, NVIDIA Developer Program account. No card, as promised. But on the API keys page you get a modal — "We'll need to verify your phone number" — and no key until you enter a one-time SMS code. NVIDIA frames it as fraud and abuse protection.

The country list is not global. Russia is not on it at all; under the list NVIDIA says it is "rapidly expanding worldwide availability". Kazakhstan is listed, but in my attempt with a Kazakh number the "Send Code to Phone" button never became active, and the page showed no error. I could not confirm whether Kazakh numbers go through.

I did not try to get around the check and would not recommend it: virtual numbers and borrowed SIMs violate the terms, and a key obtained that way can be revoked along with the account. So "fifteen minutes, no card" is true only if your phone number is from a supported country.

First request

If your number is supported, the first call takes a minute. Any client that lets you change the base URL works, including coding agents.

export NVIDIA_API_KEY="nvapi-..."

curl https://integrate.api.nvidia.com/v1/chat/completions \
  -H "Authorization: Bearer $NVIDIA_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "moonshotai/kimi-k3",
    "messages": [{"role": "user", "content": "Explain Swift async/await in three sentences"}],
    "max_tokens": 1024
  }'

Swap model for any ID from the table. One Kimi K3 detail: thinking is always on, and in multi-turn chats or tool calls you must send back the full previous assistant message, including reasoning_content and tool_calls, or it loses the thread.

My take

The offer itself is great: four of the strongest open models of the season, no payment, no daily cap, standard API. If your phone number qualifies, it is the easiest way to try Kimi K3 without renting hardware. Just know that "no card, fifteen minutes" quietly skips the phone step — and that step is where some of us stop.

Originally published at klukyanov.ru.
Shorter weekly write-ups (in Russian) — on Telegram.

Listen to your coding agent instead of reading it: how I save my eyes

Kirill Lukyanov — Tue, 29 Sep 2026 18:42:49 +0000

My working day at the computer used to be code and documentation. Now there's a third stream, and it turned out to be the biggest one: the agent's replies. Claude Code reports every step, explains what it changed, asks clarifying questions and sends summaries. All of it is text, and all of it is read with your eyes, in small terminal font.

By evening you feel it physically. So I put together a pair of my own macOS apps. The first one, SafeYourEye, makes sure my eyes actually get rest. The second one, PromtsMaker, takes part of the load off them: the agent talks to me by voice, and I answer by voice too. Here's how it works for me and how to set it up in ten minutes.

The agent writes more than I can read

With an agent your eyes don't get a break, they work harder. It writes the code, but I read its reports, check diffs and answer questions. Instead of typing text I read it, constantly, in small portions, switching between windows.

Yet most of what the agent writes doesn't need a screen. "Starting", "tests are green", "found two places where this is used, fix both?" can simply be heard. You need the screen for diffs and code; for status and questions, voice is enough.

Hence two fixes: don't let your eyes work without breaks, and move to audio everything that doesn't have to be read.

Half one: SafeYourEye keeps the breaks

Everyone knows the 20-20-20 rule: every 20 minutes, look at something about 20 feet away for 20 seconds. Almost nobody follows it, because 20 minutes fly by at work. Here's what the app does:

Timer. Counts a work session (5 to 60 minutes) and shows a break window with a 20-second countdown. A window is harder to dismiss than a banner.
Idle detection. Walk away from the computer and the session doesn't burn: time without keyboard and mouse isn't counted as work.
Distance and light. Using the camera, it hints when you sit too close to the screen or the room gets dark. Frames are processed on the Mac itself and never leave it.
Vision checks. Four self-checks on one screen, with history and a PDF export for your doctor. Not a diagnosis, a way to notice a trend.

With an agent the timer turned out to be especially useful. While the agent runs a long task I don't sit staring at the terminal, I take the break. The SafeYourEye window and the agent's summary often arrive at about the same time.

Half two: PromtsMaker gives the agent a voice

PromtsMaker started as a prompt editor: dictate a thought, the app cleans up the text and adds project context. You don't have to use prompts at all, though. Since version 1.4 the app has a bridge to the agent, and that alone is worth installing it for.

Inside PromtsMaker runs a local MCP server. Claude Code connects to it like to any other tool, and the agent gets a mouth and ears:

say — speak a short line during the work: "starting", "build passed";
ask_user — ask by voice and wait for a spoken answer: the app starts dictation itself and returns the transcript to the agent;
report_result — read the summary aloud, while details (diff, command output) stay as text in the panel;
wait_for_prompt — pick up a new task I dictated in PromtsMaker, without copying it into the terminal.

The agent has one rule: don't read walls of text. One or two sentences aloud; a long result only after "read it all?". Without that rule the first version of the bridge honestly read everything.

I run the bridge live with Claude Code and OpenCode. The protocol is standard, MCP over HTTP, so any agent that can connect MCP servers over HTTP should work. Codex CLI supports such servers, but I haven't tested it with the bridge myself yet.

What it looks like on an exercise bike

My favourite scenario. A long task: rewrite a module, run the tests, fix whatever breaks. No reason to watch it in the terminal.

Dictate the task into PromtsMaker as a normal sentence. The app strips the "umm"s and fixes terms using the project glossary. Sending it to the agent is ⌘⏎, no window switching.
Get on the bike. The screen is far away; I don't need to read it.
The agent works and talks. Short updates are spoken, and I know where it is without looking.
The agent asks, I answer by voice. At a fork it asks out loud, the app starts dictation, I say the answer, the agent continues.
The summary is spoken. If it's clear, I dictate the next task right away. I look at the diff later, in one pass, instead of in bits for an hour.

Double benefit: my eyes rest on the far distance instead of the terminal, and my body moves while the agent does work that needs only a couple of spoken answers from me.

Eyes or ears: what moved where

What's happening	Before	Now	Who helps
Give a task	Type or paste into the terminal	Dictate, ⌘⏎	PromtsMaker
Know which step the agent is on	Watch terminal output	A short spoken line	PromtsMaker, `say`
Answer a clarifying question	Read it, type an answer	Hear it, answer by voice	PromtsMaker, `ask_user`
Get the result	Read the whole report	Spoken summary, details as text	PromtsMaker, `report_result`
Review diff and code	Eyes	Eyes, in one pass at the end	—
While the agent works long	Sit at the screen and wait	Break or exercise bike	SafeYourEye
Don't overstay at the screen	Hope you remember	Break window every 20 minutes	SafeYourEye
Sat too close, room got dark	Don't notice	Camera hint	SafeYourEye

The code I always review with my eyes, and that's fine. Tool names are for the agent; users never need to know them.

How to set up the same pair

Both apps are for macOS and are in the Mac App Store. PromtsMaker is free (macOS 14+). SafeYourEye runs on macOS 13+, it's free to download, with full features in a Pro subscription ($2.99/month or $19.99/year).

Install SafeYourEye and set the session length. You can skip camera access: distance and blink hints turn off, the timer keeps working.
Install PromtsMaker and open your project folder in it.
Enable the agent bridge. The app starts the server on 127.0.0.1 only, generates an access token and shows a ready-made connect command.
Connect Claude Code with that command. It looks like this (the app picks the port, the token is added as an Authorization header):

claude mcp add --transport http promtsmaker http://127.0.0.1:8765/mcp

Tell the agent "wait for tasks from PromtsMaker". On first connect it stores the bridge rules in its own memory; you don't need to add instructions to project files.
Allow speech recognition when macOS asks. Better do it right away: the agent's first voice question otherwise waits on the system prompt, and you can't answer until it's dismissed.

What's next: read any reply with one key

The bridge works when the agent decides to say something. But sometimes the session runs in a plain terminal, without the bridge, and you'd rather listen to the reply than read it. For that, the next PromtsMaker update adds a global hotkey: it reads the latest Claude Code reply for the project in the open tab, and pressing it again stops. The app strips Markdown first, so you don't hear asterisks and hashes.

It already works in my dev build and will ship in the next App Store version.

Originally published at klukyanov.ru.
Shorter weekly write-ups (in Russian) — on Telegram.

Fitbit Air and iPhone: why your band's data gets lost on the way to Apple Health

Kirill Lukyanov — Mon, 28 Sep 2026 09:30:09 +0000

I wear a Google Fitbit Air on my wrist and carry an iPhone. Sounds like a normal combo. In practice it's two health worlds that barely understand each other: the band counts steps, heart rate, sleep and workouts, the Google Health app shows all of it, but Apple Health — where every other iPhone app gets its data — receives only part of it, and not always in the right shape.

I ran into this as a developer: one of my apps builds activity analytics on top of Apple Health, and with the band's data the analytics started to lie. Here's what's actually broken, why it's hard to fix, what the paid bridges on the App Store cost, and how I built my own.

Two "Health" apps that refuse to be friends

Apple and Google store health data in fundamentally different ways. Apple Health (HealthKit) lives only on the phone: an encrypted on-device database with no cloud API. Google Health is the opposite — a cloud service: the band sends data to the phone, the phone sends it to your Google account, and that's where it lives.

To move data from one world to the other you need a program that runs on the iPhone, downloads data from Google's cloud and writes it into Apple's local store. Nobody else can do it: Google's cloud can't reach the database on your iPhone, and Apple only lets apps on the device itself write to it.

For years Google simply didn't ship such a program. When HealthKit launched in 2014, Fitbit said outright it had no plans to support it, and Fitbit owners with iPhones lived on third-party utilities for a decade. Only in August 2026, in version 5.05, did the Google Health app learn to write to Apple Health itself. Problem solved? Not quite.

What gets lost on the way

The official sync works, but with losses. On my own data:

Workouts go missing. Some workouts recorded by the band never show up in Apple Health, although they're in Google Health.
Calories and heart rate don't match between the two apps for the same day.
Duplicates. The same steps and calories land in Apple Health twice and inflate the daily total.
Some metrics don't transfer at all, e.g. heart rate variability (HRV) — even the coverage of the update admits it.

If you only glance at steps, that's cosmetic. But fitness apps, food diaries and training plans read Apple Health and draw conclusions from an incomplete, partly doubled picture.

Why it's hard to do right

Different data models. In HealthKit a workout is a single object with calories and distance inside. In Google's model it's a set of separate points: an exercise segment, per-minute calories, per-minute distance. Copy everything as-is and calories inside a workout are counted twice.
The echo. Google Health also reads Apple Health (iPhone steps, Apple Watch workouts), uploads them to Google's cloud, and they come back as "Google data". A bridge that can't tell its own records from the echo grows duplicates on every sync.
The locked phone. Apple Health's store is encrypted while the iPhone is locked, so nothing can be written. Background sync works in fits and starts, and long history imports die when the screen turns off.
Old paths are closing. Many cheap bands have been writing to Google Fit for years. Since May 1, 2024 new developers can't sign up for its APIs, and they shut down at the end of 2026. The replacement is the Google Health API, which has its own strings attached (see below).

Paid bridges on the App Store and what they cost

All of them are free to download and charge via in-app purchases. US App Store prices as of September 28, 2026:

App	Subscription	Lifetime	Rating
Fitbit Sync To Apple Health (Syncfit)	$4.99–9.99/mo, $19.99–39.99/yr	$59.99	4.6 (19,688)
Fitbit to Apple Health Sync (myFitnessSync)	$5.99–9.99/mo, $9.99/wk, $39.99/yr	$39.99–59.99	4.3 (29,189)
Power Sync for Fitbit	auto-sync $1.99/mo, $7.99/yr (daily totals only)	$14.99	4.2 (15,642)
Power Sync: Fitness to Health	$5.99/wk, $10.99/mo, $19.99–24.99/yr	—	4.5 (12,888)
Fitbit to Health Sync Solver	$9.99/wk, $39.99/yr	$59.99	4.5 (3,250)
Fitbit Sync to Health App	$9.99/wk, $19.99/mo, $39.99/yr	$59.99	4.1 (1,628)
Fitbit to Apple Health Sync · (StepsApp)	Pro: $4.99 or $19.99	—	4.3 (374)

The typical price is $39.99/year or $59.99 lifetime. The Fitbit Air costs about $100, so you're asked to pay almost half the band's price again just to get its data onto your iPhone properly. Weekly $9.99 plans add up to roughly $520 a year — five times the band.

One caveat matters more than price: nearly all of these are built around the Fitbit / Google Health account. If your band writes to the old Google Fit, a bridge may not see its data. Test on the free trial before paying for a year.

How I built my own bridge

I didn't want to pay for a bridge, but my app's analytics had to be fixed, so I wrote the sync myself: the app pulls data straight from the Google Health API and writes it into Apple Health. (Turn off Google's own sync in that case, so you don't have two sources of the same thing.) The core work took one day; the interesting part is the pitfalls.

API. Google Fit REST is closed to new developers, so it's the Google Health API v4 (dataTypes/{type}/dataPoints). All its scopes are classified as Restricted — more on that below.
Sign-in without a secret. Google officially expects a web-server client with a client secret, and you can't ship a secret inside an iOS app. An iOS client with PKCE via ASWebAuthenticationSession worked — no backend, no Google SDK. Tokens live in the Keychain.
Dedup the Apple way. Every HealthKit sample gets HKMetadataKeySyncIdentifier like gh:<type>:<point id> plus HKMetadataKeySyncVersion. A repeated sync replaces the record instead of adding a new one.
Echo filtering. Points that came into Google from Apple Health (platform HEALTH_KIT) are skipped, otherwise you get a loop.
Whole workouts. Workouts are built with HKWorkoutBuilder with calories and distance inside, and per-minute calories/distance that fall into the workout window are dropped so the day doesn't count them twice.
History in chunks. Fresh days first, then history from newest to oldest: workouts and sleep up to a year, steps and calories 90 days, heart rate 30. Progress is stored per metric, so an interrupted sync resumes where it stopped.
Keep the screen on. During a manual sync the idle timer is disabled, and if the phone gets locked anyway the user sees a clear hint instead of a database error.
Format surprises. 64-bit numbers arrive as strings, distance comes in millimeters and sits somewhere other than the docs suggested — the first parser version crashed on a real response. The mapper is covered by tests on trimmed real data.

The main limitation isn't technical. Until the app passes Google's OAuth verification and a third-party security audit, the feature runs in testing mode: at most 100 users, and the Google sign-in expires every 7 days. Fine for personal use, not for everyone. The paid bridges above prove the path is passable — it just takes weeks and money.

What to do right now if you own a Google band

Turn on the official sync in Google Health: add Apple Health in the connections settings. It's free, and for steps and sleep it's often enough.
Set source priority in Apple Health: open a metric → Data Sources & Access → Edit, and put the band above the iPhone so phone and wrist steps don't add up.
Compare a week of workouts in Google Health and Apple Health. No differences — you need nothing else.
If workouts go missing and they matter, pick a bridge from the table — but start with the trial and check your data.
Keep one bridge. Official sync plus a paid app at the same time is the shortest path to duplicates.

What's next

The sync already works in my test build, and I'm going to ship it as a separate app — just the Google Health → Apple Health bridge, nothing else. No name yet: Google verification comes first. I'll write about it when it's out.

Originally published at klukyanov.ru.
Shorter weekly write-ups (in Russian) — on Telegram.