DEV Community: Oleh Veheria

Stack Overflow Mobile Questions Fell 95 to 99.5% Since 2022. The Whole Site Fell 99.1%

Oleh Veheria — Mon, 02 Nov 2026 08:14:30 +0000

The earlier posts in this series used Hacker News and npm. This one counts questions. Stack Overflow has a public API that returns the number of new questions for any tag in any date range, so I pulled quarterly counts for six mobile tags, swiftui, uikit, jetpack-compose, kotlin-multiplatform, react-native and flutter, plus the site total as a control, from Q1 2022 to Q3 2026.

Every tag fell by 95% or more. So did the site: from 356,065 new questions in Q1 2022 to 3,160 in Q3 2026, a drop of 99.1%. The mobile tags did not escape it, so question volume stopped working as a popularity signal. What is left is the mix between them.

What the counts say

New questions per quarter, from the Stack Exchange API. "Native" is swiftui, uikit, jetpack-compose and kotlin-multiplatform added together. "Cross" is react-native and flutter added together. A question with two of these tags counts twice in the sums.

Quarter	All SO	Native	Cross	Cross per native
2022-Q1	356,065	3,482	16,740	4.81
2023-Q1	269,315	3,308	11,687	3.53
2024-Q1	138,199	2,543	5,737	2.26
2025-Q1	48,755	1,074	1,984	1.85
2026-Q1	9,642	226	361	1.60
2026-Q3	3,160	78	84	1.08

Per tag, first and last quarter:

Tag	2022-Q1	2026-Q3	Change
flutter	11,998	62	-99.5%
react-native	4,742	22	-99.5%
swiftui	2,195	43	-98.0%
jetpack-compose	898	22	-97.6%
uikit	281	8	-97.2%
kotlin-multiplatform	108	5	-95.4%

Three readings.

The whole site collapsed, so absolute counts measure Stack Overflow. The drop accelerated from 2023, with the steepest quarters in 2025 and 2026. I did not test why. A common explanation is that developers ask AI assistants first, but nothing in this data separates that from other causes, so I would not lean on it.

The cross-platform tags fell faster than the native tags. React Native and Flutter together lost 99.5%, the four native tags together lost 97.8%, the site lost 99.1%. In Q1 2022 there were 4.81 cross-platform questions per native question. In Q3 2026 there were 1.08, and the ratio went down in most quarters in between.

Share of the site shows it from the other side, on small counts. The native tags were 0.98% of all new questions in Q1 2022 and 2.47% in Q3 2026, with a high of 2.75% in Q3 2025. React Native and Flutter together went from 4.70% to 2.66%, but that share stayed between 3.9% and 4.9% through 2025 and fell only in 2026 (3.74%, 2.73%, 2.66%), where the counts are small. The ratio above is the steadier signal.

What this does and does not say

Fewer questions about a framework does not mean fewer people using it. Flutter lost the most volume partly because it had the most to lose: it was the biggest of the six tags by far. A framework that produces fewer questions per developer, because tooling or documentation got better, would also show a decline. The hiring counts and the npm installs measure other things and answer different questions, so none of the three settles which stack is winning.

Limits

Counts are new questions with the tag at the time of the API call. Questions deleted later are not counted, so recent quarters may shrink in a later run as deletions catch up.
The Q3 2026 counts are small (22 for react-native, 5 for kotlin-multiplatform). A shift of a few questions moves a share noticeably.
Tags are chosen by the asker. Swift and Kotlin questions without a framework tag, and ios, android and swift tags, are not in the six.
Sums count a question once per matching tag, so the ratio is approximate.
Stack Overflow is one source and its audience changed over the window.
I ran the script twice and the two result sets were identical. Data retrieved 2026-11-01.

Method

import json, time, datetime as dt, urllib.request, gzip

TAGS = ['swiftui', 'uikit', 'jetpack-compose', 'react-native', 'flutter', 'kotlin-multiplatform', None] API = 'https://api.stackexchange.com/2.3/questions?site=stackoverflow&filter=total&fromdate=%d&todate=%d' ts = lambda y, m: int(dt.datetime(y, m, 1, tzinfo=dt.timezone.utc).timestamp())

def count(tag, a, b):
    url = API % (a, b - 1) + (f'&tagged={tag}' if tag else '')
    raw = urllib.request.urlopen(urllib.request.Request(url, headers={'Accept-Encoding': 'gzip'}), timeout=30).read()
    d = json.loads(gzip.decompress(raw))
    time.sleep(d.get('backoff', 0) + 0.3)
    return d['total']

for y in range(2022, 2027):
    for q in range(4):
        m = q * 3 + 1
        if (y, m) > (2026, 7): break
        a, b = ts(y, m), ts(y + (m + 3 > 12), (m + 3 - 1) % 12 + 1)
        print(y, q + 1, {(t or 'all'): count(t, a, b) for t in TAGS})

The API allows about 300 requests a day without a key, and this script makes about 133.

What I take from it

If you read a framework's health from Stack Overflow questions, the signal is gone: everything fell by 95% or more. The one thing that still moves is the relative mix, and there native tags held their ground better than React Native and Flutter. What I did not measure: GitHub issues, Reddit, or how many questions now go to AI assistants instead. Where do you look for evidence when you pick a stack?

My Read of Four Datasets: Native-Only Looks Like the Weakest Mobile Bet in 2026

Oleh Veheria — Sun, 01 Nov 2026 08:14:13 +0000

I spent the last week counting public data about mobile: Hacker News hiring threads, the job-seeker threads, Show HN launches and npm installs. This post gives my position on those counts. It is an opinion on partial data, and I mark where each claim comes from and where it stops. Three of the four sources are Hacker News, so they share one audience and do not confirm each other independently.

The four signals

Signal	Period	What moved	Post
iOS mentions in HN hiring posts	2023 H1 to 2026 H2	19.0 to 6.3 per thread, 0.33x	hiring threads
iOS seeker posts per hiring post	same	0.79 to 4.28, 5.4x	seekers
iOS titles on Show HN	same	10.6 to 29.0 per 30 days, 2.7x	launches
react-native npm downloads	Jan 2023 to Sep 2026	5.1M to 55.3M a month, 10.8x, control `react` 9.6x	npm

Android moves the same way in the two hiring-side rows: mentions fell 69% and seeker posts per hiring post rose 5.9 times. On Show HN it grew faster than iOS, 4.7 times. Show HN as a whole grew 3.4 times over the same period, so iOS titles took a smaller share of the board (0.91% to 0.74%) while Android took a larger one (0.46% to 0.64%).

My position

1. Among the stacks I could compare on both sides of the HN threads, native iOS and Android look the weakest. They lost the most mentions in hiring posts (about two thirds) and gained the most seeker posts per hiring post (5.4 and 5.9 times). Full stack moved 2.9 times and backend 3.7 times. I left AI out of that comparison because its keyword grew fastest (6.2 times) and is the noisiest. Flutter's mentions in hiring posts fell about as much, from 2.8 to 0.8 per thread, but I did not count Flutter seekers, so I cannot place it. Native is one of the groups getting harder, and in this sample it is furthest along.

2. The mobile activity I can see did not disappear. Show HN titles about iOS and Android kept growing in absolute numbers. Installs of the main cross-platform toolchain rose about ten times, but react itself rose 9.6 times, so I do not read that as more builders. Whether more distinct people launch mobile apps than in 2023 is untested. What fell is the number of hiring posts that mention iOS or Android. I cannot tell whether those roles ask for native depth alone.

3. React Native sat in the least bad bucket on the two HN hiring-side measures. Its mentions in hiring posts fell 14% against 33% for the whole thread, and its seeker posts per hiring post rose 2.0 times against 5.4 for iOS. On Show HN its share of titles fell, on small counts. Expo is the part of the npm data that moved most against the control: its share of react downloads went from 2.2% to 5.2%. I take that as a reason to be able to show cross-platform work next to native depth. It does not argue for dropping native.

What would change my mind

A larger postings dataset with a clean iOS and Android split that does not show the two-thirds drop. I could not find one for 2025 and 2026, and that gap is why I counted myself.
October 2026 holding. It was the best month for native hiring in 2026 H2, 11 iOS and 9 Android hiring posts against 3 to 7 in July to September, though 2023 H1 averaged 19 iOS posts per thread. If November and December look like October, the ratio of iOS seeker posts to iOS hiring posts drops toward 3.4 and my 4.3 overstates the squeeze.
Evidence that Show HN titles grow faster than the number of distinct makers. If one person ships three times as many titles, the launch signal says less than I made it say.

What I would do with it

If your CV says iOS or Android and nothing else, add one thing you can show next to it: a cross-platform app or a backend service. The ratios above say those groups moved by smaller factors.
Compare ratios across groups. Raw npm downloads rose ten times for react itself, so any single count mostly measures the registry.
For one sample point: in 2026 H2 on HN, iOS-mentioning seeker posts ran at 4.3 per iOS-mentioning hiring post. That is a ratio of mentions in one corner of the market, and it is no forecast for any single opening.

Limits

All four sources are public and partial. HN skews to startups and to US and remote roles, and three of the four datasets come from it. npm counts include CI and automated installs. A keyword in a post is not an open role.
The periods differ: HN rows compare 2023 H1 with 2026 H2 averages, npm compares single months (January 2023 and September 2026).
The seeker ratio is a ratio of two noisy averages. One extra iOS hiring post per thread moves it from 4.3 to 3.7. The iOS hiring average is 6.3 in the first post and 6.2 in the second.
I did not measure salaries, seniority, location, app store data or anything outside these sources. Each earlier post lists its own limits, and the scripts are in them.
The counts will be rerun as more months arrive.

Where does your own pipeline disagree with this reading?

npm Downloads for React Native, Expo and Capacitor Grew 11 to 23 Times Since 2023. React Grew 10 Times Too

Oleh Veheria — Sat, 31 Oct 2026 08:13:48 +0000

The first three posts in this series used Hacker News: hiring posts, job seekers and launches. This one leaves HN and counts installs. The npm registry publishes daily download counts for every package, so I pulled 46 months for the main cross-platform mobile toolchains that ship through npm: react-native, expo, @capacitor/core, @nativescript/core and cordova. I added react as a control, because a rise in all of them at once says something about npm and not about mobile.

The three big toolchains grew 11 to 23 times in raw counts, and the control grew 9.6 times. Expo is the one that gained against it.

What the counts say

Monthly downloads in millions, from the npm downloads API. October 2026 covers 1 to 28 October only.

Month	react (control)	react-native	expo	@capacitor/core	cordova	@nativescript/core
2023-01	76.4	5.1	1.7	1.5	0.25	0.03
2024-01	96.7	8.1	2.4	1.6	0.25	0.06
2025-01	119.1	10.6	3.9	1.6	0.16	0.05
2026-01	275.4	18.9	10.5	4.7	0.14	0.07
2026-09	730.6	55.3	38.2	18.5	0.25	0.10
2026-10 (1 to 28)	666.0	51.9	39.5	19.4	0.23	0.09

From January 2023 to September 2026 the multiples are: react 9.6, react-native 10.8, expo 22.7, @capacitor/core 12.1, @nativescript/core 3.1, cordova 1.0.

The same data as a share of react downloads in the same month:

Month	react-native	expo	@capacitor/core
2023-01	6.70%	2.21%	2.00%
2024-10 (React Native peak)	10.12%	3.17%	1.48%
2026-04 (React Native low)	5.53%	3.45%	1.77%
2026-09	7.57%	5.23%	2.53%
2026-10 (1 to 28)	7.80%	5.93%	2.91%

Four readings.

Absolute counts mostly measure npm. react itself rose 9.6 times. Per day, its downloads were 26% higher in March 2026 than in February 2026, and a smaller step shows in react-native (+18%). I did not investigate why. Anything that installs packages on a schedule would show up here, so I would not read 10 times more downloads as 10 times more developers.

Expo is the clear relative gainer. Against react, its share went from 2.2% to 5.2% in September 2026 and 5.9% in October. Against react-native the ratio went from 0.33 to 0.69 and 0.76. Expo apps also depend on react-native, so the two series overlap and I did not measure by how much.

React Native's share of react swung, then recovered. Its share of react rose to a peak of 10.1% in October 2024, fell to 5.5% in April 2026 and recovered to 7.8%. That is a swing of nearly a factor of two inside two years, in both directions, and the end point is above where it started.

Capacitor grew slightly faster than the control, Cordova and NativeScript lost ground against it. @capacitor/core grew 12.1 times against 9.6 for react, with a share between 1.3% and 2.9%. cordova stayed between 0.14 and 0.25 million a month for the whole window, which is a share of 0.3% falling to 0.03%. @nativescript/core is tiny: 0.03 million to 0.10 million, 3.1 times against 9.6 for the control.

What this does and does not say

Package installs are not apps shipped or developers employed. The HN hiring posts showed React Native holding its place while native iOS and Android fell, and the Show HN counts showed React Native and Flutter losing share of launch titles. Install counts do not settle that. They say cross-platform JavaScript tooling is installed far more than in 2023 and Expo is growing faster than the rest of it. They do not say who is hired to use it.

Limits

Download counts include everything that fetches a tarball: developers, CI runs, mirrors and automated installs. I cannot separate them.
react is a control for npm-wide growth, but it also serves the web, so it is an imperfect one.
One npm package is not a whole framework. @capacitor/core is the core of Capacitor, not all its plugins.
Flutter, Kotlin Multiplatform and native Swift do not ship through npm. This post says nothing about them.
October 2026 is 28 days. Shares are unaffected by that; the absolute row is not comparable to a full month.
I ran the script twice and the two result sets were identical. The API data may be revised later by npm.

Method

import json, urllib.request, urllib.parse, time, datetime, collections
PKGS = ['react-native', 'expo', '@capacitor/core', '@nativescript/core', 'cordova', 'react']

def get(u):
    for i in range(8):
        try:
            r = json.load(urllib.request.urlopen(u, timeout=40))
            time.sleep(2)
            return r
        except Exception: time.sleep(15 * (i + 1))
    raise SystemExit('fail ' + u)

def monthly(pkg, start, end):
    out = collections.Counter()
    d = start
    while d <= end:
        e = min(d + datetime.timedelta(days=89), end)
        u = f'https://api.npmjs.org/downloads/range/{d}:{e}/{urllib.parse.quote(pkg, safe="@")}'
        for r in get(u)['downloads']:
            out[r['day'][:7]] += r['downloads']
        d = e + datetime.timedelta(days=1)
    return out

start, end = datetime.date(2023, 1, 1), datetime.date(2026, 10, 28)
rows = {p: monthly(p, start, end) for p in PKGS}
for m in sorted(rows['react']):
    print(m, {p: rows[p][m] for p in PKGS})

The API rate-limits quickly, hence the pause and backoff. Data retrieved 2026-10-30.

What I take from it

If you choose a cross-platform stack today, npm installs say Expo is where the growth is relative to React Native itself, and Capacitor is growing a little faster than react. What I did not measure: downloads of Flutter's pub.dev packages, app store listings, or what the installs build. Does the Expo share match what you see in your own projects?

Show HN Got More Than Three Times Busier in Three Years. iOS and Android Launches Roughly Kept Pace With It

Oleh Veheria — Fri, 30 Oct 2026 08:13:22 +0000

Two earlier posts counted the jobs side of Hacker News. Mentions of iOS and Android in the monthly hiring threads fell by about two thirds, and the number of job seekers per hiring post rose five to six times for native mobile. The obvious follow-up question is whether people also stopped building mobile apps. The third thing HN can show is what gets launched. "Show HN" is where makers post what they built, so I counted titles with the same method.

The short answer: mobile launches did not fall. Show HN itself grew so much that iOS and Android launches grew with it.

What the counts say

Show HN stories whose title contains each word, averaged per 30 days so that half-years of different length compare. 2026 H2 covers 1 July to 29 October, 120 days.

Period	All Show HN	iOS	Android	AI	Claude
2023 H1	1,161	10.6	5.3	145	0.5
2023 H2	1,153	10.8	6.8	158	1.3
2024 H1	1,353	11.0	5.8	191	4.1
2024 H2	1,534	8.8	3.9	240	11.2
2025 H1	2,063	18.9	8.5	383	21.0
2025 H2	2,581	21.5	10.4	484	60.8
2026 H1	4,303	36.5	25.9	888	219.6
2026 H2	3,896	29.0	24.8	610	163.2

And the same data as a share of all Show HN titles:

Period	iOS	Android	React Native	Flutter	AI	Claude
2023 H1	0.91%	0.46%	0.11%	0.20%	12.5%	0.04%
2023 H2	0.93%	0.59%	0.16%	0.21%	13.7%	0.11%
2024 H1	0.82%	0.43%	0.11%	0.15%	14.1%	0.30%
2024 H2	0.57%	0.26%	0.18%	0.16%	15.7%	0.73%
2025 H1	0.92%	0.41%	0.07%	0.10%	18.6%	1.02%
2025 H2	0.83%	0.40%	0.08%	0.04%	18.8%	2.36%
2026 H1	0.85%	0.60%	0.07%	0.08%	20.6%	5.10%
2026 H2	0.74%	0.64%	0.06%	0.06%	15.7%	4.19%

Four readings.

The board got much busier. Show HN went from about 1,160 stories per 30 days in early 2023 to 3,900 to 4,300 in 2026, a factor of 3.4 to 3.7. I did not look into why. More makers, more automated submissions and cheaper building could all do this, and the counts cannot tell them apart.

iOS and Android launches roughly kept pace. iOS titles went from 10.6 to 29.0 per 30 days, Android from 5.3 to 24.8. As a share of the board, iOS slipped from 0.91% to 0.74% and Android rose from 0.46% to 0.64%. In absolute terms there are about three times more iOS launch titles per 30 days than in early 2023 and about five times more Android ones. The hiring side moved in the opposite direction over the same period, as the first post showed.

React Native and Flutter did not ride the wave. Their title counts stayed at roughly 7 to 20 per half-year while the board grew 3.7 times. Flutter's share fell by more than half and React Native's by about a third to a half, on counts too small to lean on. Titles say little about what is under the hood, so I would not read this as a framework ranking.

AI reached about a fifth of the titles, and Claude went from a handful of titles to thousands. "AI" went from 12.5% to 20.6% of titles in the first half of 2026 and 15.7% so far in the second half. "Claude" went from 3 titles in the first half of 2023 to 1,325 in the first half of 2026. The two overlap, so their shares cannot be added.

What this does and does not say

A launch is not a job. A lot of Show HN is side projects, open-source tools and one-person products, so more mobile launches does not mean more mobile employers. What the three posts show together is a split: the number of mobile launch titles is up, the number of companies posting roles for native mobile engineers is down. I did not test why, and I will not guess in a data post. One hypothesis I would check next is whether the launch count grows faster than the number of distinct makers, because a single person can now ship more titles.

Limits

Counts are exact-word matches in the title of stories tagged show_hn, from the HN Algolia API, retrieved 2026-10-29. Stories that Algolia does not index, such as removed ones, are not counted.
A title that names two terms counts for each, so the columns overlap and must not be added.
Word matching is on whole words with no prefix matching. My first run used the default prefix matching, which also matches longer words that begin with the search term, and it inflated the AI count by about 4%. Switching it off moved the first-half 2023 AI count from 911 to 874, and the numbers here use the stricter match.
Only titles are searched. An iOS app whose title says "Show HN: A habit tracker" is not counted.
2026 H2 has four months of data and uses a per-30-day rate. Short windows move more.
"Claude" and "AI" are matched as words and I did not read the titles one by one, so some matches may use the word in another sense.
I did not check how many Show HN stories are written or posted by automation.

Method

import json, urllib.request, urllib.parse, time, datetime
B = 'https://hn.algolia.com/api/v1/search_by_date?'

def get(u):
    for _ in range(6):
        try: return json.load(urllib.request.urlopen(u, timeout=40))
        except Exception: time.sleep(3)
    raise SystemExit('fail ' + u)

def count(word, lo, hi):
    p = {'tags': 'show_hn', 'hitsPerPage': 0,
         'numericFilters': f'created_at_i>={lo},created_at_i<{hi}'}
    if word:
        p.update({'query': word, 'restrictSearchableAttributes': 'title',
                  'typoTolerance': 'false', 'queryType': 'prefixNone'})
    return get(B + urllib.parse.urlencode(p))['nbHits']

def ts(y, m):
    return int(datetime.datetime(y, m, 1, tzinfo=datetime.timezone.utc).timestamp())

WORDS = {'all': '', 'iOS': 'iOS', 'Android': 'Android', 'React Native': '"React Native"',
         'Flutter': 'Flutter', 'AI': 'AI', 'Claude': 'Claude'}
for y in (2023, 2024, 2025, 2026):
    for a, b in ((1, 7), (7, 13)):
        lo, hi = ts(y, a), (ts(y, b) if b < 13 else ts(y + 1, 1))
        if lo > time.time(): continue
        hi = min(hi, int(time.time()))
        print(y, a, {k: count(w, lo, hi) for k, w in WORDS.items()})

Divide by the number of days in the window and multiply by 30 to get the per-30-day rate in the first table.

What I take from it

If you build and ship mobile apps, HN says you are in good company: more mobile launch titles appear every month than in 2023. If you are looking for a salaried mobile role, the hiring threads say there are fewer of them and more people competing. Both can be true at once, and the second one is the one I keep tracking for this series.

What I did not measure: downloads, revenue, retention or anything outside HN. Does the split between more mobile launches and fewer mobile roles match what you see around you?

On Hacker News, Job Seekers Now Outnumber Hiring Posts 2.3 to 1. For Native iOS and Android It Is 4 to 1

Oleh Veheria — Thu, 29 Oct 2026 08:12:56 +0000

My last post counted the demand side of Hacker News hiring threads: native iOS and Android mentions fell by about two thirds between 2023 and 2026. The first post left one question open: what happened on the other side. Hacker News runs a second monthly thread, "Ask HN: Who wants to be hired?", where people post what they do and what they look for. If hiring posts shrank, did seekers shrink with them?

They did not. I counted both threads for the same 46 months. Same caveat as before: keyword mentions are not roles, and HN is one corner of the market.

What the counts say

Average top-level posts per thread that mention each term, 2023 H1 (six threads) against 2026 H2 so far (four threads, July to October). "Seekers per hiring post" is the seeker average divided by the hiring average.

Term	Hiring posts, 2023 H1 → 2026 H2	Seeker posts, 2023 H1 → 2026 H2	Seekers per hiring post	Change
All posts	371.7 → 248.5	379.8 → 568.2	1.02 → 2.29	×2.2
iOS	19.0 → 6.2	15.0 → 26.8	0.79 → 4.28	×5.4
Android	18.8 → 5.8	12.7 → 22.8	0.67 → 3.96	×5.9
React Native	11.3 → 9.8	23.7 → 40.2	2.09 → 4.13	×2.0
Any mobile term	54.5 → 26.2	65.8 → 102.0	1.21 → 3.89	×3.2
Full stack	93.5 → 58.8	88.5 → 162.2	0.95 → 2.76	×2.9
Backend	89.7 → 56.8	81.2 → 187.2	0.91 → 3.30	×3.7
AI or LLM	55.2 → 144.5	18.8 → 307.5	0.34 → 2.13	×6.2

In early 2023 the two threads were the same size, about 375 posts each. By autumn 2026 hiring posts per thread are down a third and seeker posts are up by half. October 2026 has the largest seeker thread in the whole window, 693 posts against 263 hiring posts.

Three readings, in order of how well the data supports them.

Native iOS and Android got hit hardest. Seeker posts that mention iOS went from 0.8 per hiring post to 4.3, and Android from 0.7 to 4.0. That is a 5.4 and 5.9 times change against 2.2 for the whole thread. Both numbers move the same way. They overlap, since many posts mention both, so they are one signal and not two.

React Native is the one mobile term that held. It started with more seekers than hiring posts (2.1) and ended at 4.1, a 2.0 times change, slightly less than the thread average. Part of that is a high starting base: a lot of seekers already listed React Native in 2023. It means React Native did no worse than the market, which is a low bar.

Mobile as a whole is not much worse than full stack. Any-mobile moved 3.2 times, full stack 2.9 times and backend 3.7 times. If you hold the view that mobile fell off a cliff while full stack stayed fine, this sample does not support it. Native mobile fell off a cliff. Full stack and backend also lost hiring posts and gained seekers, by a smaller factor than native.

The AI row grew the most, 6.2 times, but it is the least trustworthy one. Seekers can add "AI" to a skill line and hiring posts add it to company blurbs, so both sides can inflate the keyword.

Monthly counts for 2026 H2, so the October figures above can be checked:

Month	Hiring posts	iOS	Android	Seeker posts	iOS	Android
2026-07	257	7	6	489	25	20
2026-08	226	4	4	555	23	21
2026-09	248	3	4	536	22	22
2026-10	263	11	9	693	37	28

Limits

Counts are keyword mentions in free-text posts. A seeker who writes "iOS, Android, React Native, Python" counts once for each term, whether or not they want a mobile job.
A seeker thread is self-selected. I assume people who post there skew toward those without a quick alternative, but I have no data on that. It measures supply and not open roles, and I did not check how many seeker posts are duplicates or automated.
The 2026 H2 average uses four threads, 2023 H1 uses six. October 2026 is a single large seeker thread. Without it the all-posts ratio is 2.16 instead of 2.29, iOS 5.0, Android 4.5, React Native 3.65. Native goes up because October was the best month for native hiring in the window, 11 iOS and 9 Android hiring posts against 3 to 7 in July to September. The monthly counts are below.
Ratios of two noisy averages are noisy. iOS and Android hiring posts are about 6 per thread now, so one extra iOS post per thread moves the iOS ratio from 4.3 to 3.7.
This is HN only. Indeed Hiring Lab reports similar direction and size for Android and iOS postings on a different baseline, and that is the cross-check I have, not a confirmation of the ratio.

Method

Same source as the first post: HN Algolia API, threads by the whoishiring account, created on or after 2023-01-01, retrieved 2026-10-28, top-level comments only, one count per post per term. The script takes the thread title prefix as a parameter, so it covers both kinds:

import json, urllib.request, urllib.parse, time, re
B = 'https://hn.algolia.com/api/v1/'

def get(u):
    for _ in range(6):
        try: return json.load(urllib.request.urlopen(u, timeout=40))
        except Exception: time.sleep(3)
    raise SystemExit('fail ' + u)

def threads(prefix):
    out, page = [], 0
    while True:
        d = get(B + 'search_by_date?' + urllib.parse.urlencode({
            'query': f'"Ask HN: {prefix}"', 'tags': 'story,author_whoishiring',
            'hitsPerPage': 100, 'page': page}))
        out += d['hits']
        if page >= d['nbPages'] - 1: break
        page += 1
    out = [t for t in out if t['title'].startswith(f'Ask HN: {prefix}')
           and t['created_at'] >= '2023-01-01']
    return sorted(out, key=lambda t: t['created_at'])

P = {'iOS': r'\bios\b', 'Android': r'\bandroid\b', 'React Native': r'react[ -]native', 'full stack': r'full[ -]?stack', 'backend': r'back[ -]?end', 'AI/LLM': r'\bai\b|\bllms?\b|\bgenerative\b', 'any mobile': r'\bios\b|\bandroid\b|react[ -]native|\bflutter\b|\bswiftui\b|\bkotlin\b|\bmobile\b'}

for prefix in ('Who is hiring', 'Who wants to be hired'):
    for t in threads(prefix):
        tid, txt, pg = t['objectID'], [], 0
        while True:
            d = get(B + 'search_by_date?' + urllib.parse.urlencode({
                'tags': f'comment,story_{tid}', 'hitsPerPage': 1000, 'page': pg}))
            txt += [(h.get('comment_text') or '') for h in d['hits']
                    if str(h.get('parent_id')) == tid]
            if pg >= d['nbPages'] - 1: break
            pg += 1
        row = {'thread': prefix, 'month': t['created_at'][:7], 'top_level': len(txt)}
        row.update({k: sum(1 for x in txt if re.search(p, x, re.I)) for k, p in P.items()})
        print(row)

What I take from it

For someone whose résumé says iOS or Android and nothing else, the HN numbers show about four seeker posts per hiring post, up five to six times since 2023. A candidate who can also show React Native or backend work sits in the buckets that moved less. AI moved the most, for the reason above. That matches the shape of the first post, and I would still not treat HN as the whole market.

What I did not measure: seniority of the seekers, how many posts got a reply, location, or anything outside HN. If you hire mobile engineers, does a ratio of about four candidates per native opening match what you see in your own pipeline?

I Counted 46 Months of HN "Who Is Hiring": Native Mobile Fell by Two Thirds, React Native Did Not

Oleh Veheria — Wed, 28 Oct 2026 08:12:35 +0000

Everyone in mobile has a feeling that the market got worse. I wanted a number that someone else could rerun, so I counted. The source is the monthly "Ask HN: Who is hiring?" thread on Hacker News, from January 2023 to October 2026: 46 threads, about 15,000 top-level job posts. A keyword in a post is not an open role, and HN skews toward startups, so treat this as one sample of one corner of the market. Inside that corner, the result is clearer than I expected.

What the counts say

I compared the first six threads (January to June 2023) with the four most recent (July to October 2026). Average number of top-level posts per thread that mention each term:

Term	2023 H1	2026 H2 so far	Change
All posts	371.7	248.5	-33%
iOS	19.0	6.3	-67%
Android	18.8	5.8	-69%
React Native	11.3	9.8	-14%
Any mobile term	54.5	26.3	-52%
Full stack	93.5	58.8	-37%
Backend	89.7	56.8	-37%
AI or LLM	55.2	144.5	+162%

Three things stand out.

Native iOS and Android mentions fell by roughly two thirds. That is twice the drop in overall thread volume. React Native fell by 14%, less than the thread itself, so in this sample React Native kept its place while native lost it. Flutter, the other big cross-platform name, fell as much as native, from 2.8 to 0.8 posts per thread, so this is not a general cross-platform result.

Full stack and backend fell about as much as the thread did, 37% against 33%. Mobile as a whole fell 52%, so it lost more than the general web roles, but not by an order of magnitude. If you expected full stack to be booming while mobile collapsed, HN does not show that. Both shrank.

AI is the only bucket that grew. Mentions of "AI" or "LLM" went from 14.8% of posts in the first half of 2023 to 58.1% in the second half of 2026. Part of that is company descriptions ("an AI-powered platform for...") and not roles. It still tells you what a hiring post has to say about itself today.

Share of posts, by half-year

Period	Any mobile term	Full stack	Backend	AI or LLM
2023 H1	14.7%	25.2%	24.1%	14.8%
2023 H2	11.8%	25.2%	21.0%	22.0%
2024 H1	10.8%	26.8%	22.9%	26.6%
2024 H2	11.7%	27.3%	24.9%	33.6%
2025 H1	12.5%	29.7%	26.0%	41.6%
2025 H2	9.9%	29.3%	27.6%	50.6%
2026 H1	11.9%	28.1%	26.8%	54.9%
2026 H2 (4 threads)	10.6%	23.6%	22.8%	58.1%

As a share of posts, mobile dropped from 14.7% to about 12% by the second half of 2023 and then stayed roughly flat. Most of the share loss happened in 2023. The absolute numbers kept falling after that because the threads themselves shrank.

How this sits next to other sources

Indeed Hiring Lab reported in July 2025 that Android, Java, .NET and iOS developer postings were all down by more than 60% compared with early 2020. HN is a different sample on a different baseline, but the direction and size for iOS and Android match. Indeed also says ML engineer postings were up 59% from early 2020.

The Pragmatic Engineer wrote in June 2026 that frontend titles are disappearing fastest, followed by native iOS and Android ones. The article puts AI engineering openings up 60% in a year at top companies, against 7% for software engineering overall.

I looked for a public dataset that splits iOS and Android from backend and full stack for 2025 and 2026 and did not find one. Indeed groups them, the Pragmatic Engineer chart is paywalled, BLS has no mobile category, and the Stack Overflow developer-type pages I tried returned 404. That gap is part of why I counted myself. My earlier mobile hiring write-up covers the rest of the picture: the rebound is senior-led, and pay splits by level.

Method and limits

Source: the HN Algolia API, threads by the whoishiring account whose title starts with "Ask HN: Who is hiring", created on or after 2023-01-01. Retrieved 2026-10-27. October 2026 is mostly complete, so the 2026 H2 figures use four threads.
Only top-level comments count (the parent is the thread). A post counts once per term, however many times it uses it.
"Any mobile term" is ios, android, react native, flutter, swiftui, kotlin or mobile. The AI term is ai, llm, llms or generative. The last one is noisy, because it also matches mobile web and mobile phones as a product. The iOS and Android rows are the cleaner signal.
A keyword in a post is not an open role. "AI" shows up in company blurbs. HN skews to US and remote startups, not to the broader market. Dead and deleted comments may be missing from Algolia.
I ran the script twice. The second run reproduced the same counts for the months I compared.

The script is short enough to read in full:

import json, urllib.request, urllib.parse, time, re
B = 'https://hn.algolia.com/api/v1/'

def get(u):
    for _ in range(6):
        try: return json.load(urllib.request.urlopen(u, timeout=40))
        except Exception: time.sleep(3)
    raise SystemExit('fail ' + u)

threads, page = [], 0
while True:
    d = get(B + 'search_by_date?' + urllib.parse.urlencode({
        'query': '"Ask HN: Who is hiring"', 'tags': 'story,author_whoishiring',
        'hitsPerPage': 100, 'page': page}))
    threads += d['hits']
    if page >= d['nbPages'] - 1: break
    page += 1
threads = [t for t in threads
           if t['title'].startswith('Ask HN: Who is hiring') and t['created_at'] >= '2023-01-01']
threads.sort(key=lambda t: t['created_at'])

P = {'iOS': r'\bios\b', 'Android': r'\bandroid\b', 'React Native': r'react[ -]native', 'Flutter': r'\bflutter\b', 'full stack': r'full[ -]?stack', 'backend': r'back[ -]?end', 'AI/LLM': r'\bai\b|\bllms?\b|\bgenerative\b', 'any mobile': r'\bios\b|\bandroid\b|react[ -]native|\bflutter\b|\bswiftui\b|\bkotlin\b|\bmobile\b'}

for t in threads:
    tid, txt, pg = t['objectID'], [], 0
    while True:
        d = get(B + 'search_by_date?' + urllib.parse.urlencode({
            'tags': f'comment,story_{tid}', 'hitsPerPage': 1000, 'page': pg}))
        txt += [(h.get('comment_text') or '') for h in d['hits'] if str(h.get('parent_id')) == tid]
        if pg >= d['nbPages'] - 1: break
        pg += 1
    row = {'month': t['created_at'][:7], 'top_level': len(txt)}
    row.update({k: sum(1 for x in txt if re.search(p, x, re.I)) for k, p in P.items()})
    print(row)

What I take from it

For someone choosing a specialty, native depth alone is the weakest position in this sample, and most of the share loss came in 2023. React Native held up better than iOS or Android taken alone, while Flutter did not. Posts that mention AI are now the majority, and I read that as a sign that being able to show how you ship with coding agents matters more than it did in 2023.

What I did not measure: salaries, seniority, remote versus on-site, or anything outside HN. If you have a larger postings dataset with an iOS and Android split, I would like to see whether it shows the same two-thirds drop. Does it match what you see in your own hiring?

Mobile hiring in 2026: fewer jobs, higher bar – what the data says

Oleh Veheria — Tue, 20 Oct 2026 14:35:48 +0000

People spent about $85 billion on non-game apps in 2025, up 21% (Sensor Tower, via TechCrunch, January 2026). It was the first year consumers spent more on apps than on games. Demand for mobile products is not falling.

Hiring for the people who build them is. Indeed Hiring Lab reported in July 2025 that iOS, Android, Java and .NET developer postings were each down more than 60% against early 2020, while software postings overall were down 49%. That is a US figure from mid-2025, and I have not found a 2026 mobile-only number. The broader index tells the same story: US software development postings stood at 74.4 in August 2026 against a February 2020 baseline of 100 (Indeed, August 2026).

So the market is smaller. But the more interesting fact is who it is smaller for.

1. The rebound is senior. From May 2025 to May 2026 software postings recovered, and senior roles made up 71% of that net increase (Indeed Hiring Lab, July 2026). Entry-level hiring did not come back: SignalFire's 2026 talent report has new-graduate hiring at large tech companies about 65% below 2019. A Stanford study finds employment of 22–25-year-olds in AI-exposed jobs 19% below trend, with no comparable gap for experienced workers.

2. The engineering mix is shifting. SignalFire's 2026 report has the AI/ML engineer share up 39% since ChatGPT and the front-end share down about 25%. Cross-platform keeps taking first versions: Flutter and React Native together accounted for roughly one in five new apps released in 2024 (Pragmatic Engineer).

3. The easy money is gone. Postings peaked in early 2022 and fell when zero interest rates ended (Indeed). Layoffs removed more than 150,000 tech jobs in 2024 alone (Layoffs.fyi via TechCrunch). Companies that kept shipping did it with flatter teams: at large tech firms an engineering manager now covers about 12 engineers, up from 10 (SignalFire).

4. Applying became a lottery. Applications per opening roughly doubled between 2022 and 2024 (Greenhouse, +102%). LinkedIn took about 11,000 applications a minute in mid-2025, and three quarters of US job seekers now use AI on their applications (Fortune, November 2025). A posting is not always evidence of a vacancy.

What this means if you build mobile apps for a living

The data does not say "mobile is dead". It says the market rewards a different profile than 2021 did.

Aim at the level the rebound is paying for. Senior roles were 71% of the net growth in postings; entry-level hiring at large tech firms is about 65% below 2019. Staff, lead and architect scope gets the openings. A "Senior iOS" title with feature-ticket scope competes with the largest pool.
Show AI-assisted delivery, not AI curiosity. AI/ML engineer share is up 39% in the engineering mix. Teams ask how you ship faster and safer with coding agents: review gates, tests, release discipline. Put one concrete example on your profile.
Be reachable by people, not forms. Applications per opening doubled in two years and three quarters of applicants use AI. A form entry is one of hundreds. A short note to the engineering lead or a recruiter who places mobile roles, naming one specific problem you solve, beats the form.
Cross-platform is a skill to add, not a threat to fight. Flutter and React Native were roughly one in five new apps in 2024. Native depth plus the ability to judge where sharing code is worth it is the senior-level skill.

What this means if you run a team that has to ship a mobile app

The scarce thing is not applicants. It is senior mobile judgment: someone who can decide what to build natively, what to share, how to keep releases boring, and how to use AI coding tools without lowering the bar. Those people exist, but in my experience they rarely come through a job board. For a team stuck in a six-month search, the fastest fix is often to bring senior mobile judgment in early, before the permanent hire, for example by promoting an internal lead or involving an experienced reviewer.

What I would watch next

A 2026 mobile-only postings figure. Indeed's last one is from July 2025.
Whether AI coding tools change the shape of mobile teams more than the size: fewer juniors, more senior reviewers.
Europe. Indeed notes Germany and France did not follow the rebound, and I could not find a reliable Spain-specific mobile number. If you have one, I would like to see it.

The numbers, with sources and dates, are on one page: https://veheria.tech/mobile-market-2026/?utm_source=devto&utm_medium=article&utm_campaign=mobile-market-2026 (that is the full write-up).

Modularizing a Legacy iOS App Without Stopping Delivery

Oleh Veheria — Sat, 05 Sep 2026 09:34:17 +0000

I spent a year migrating a smart-pet-device company's app off a single-target Objective-C codebase, module by module, while the team kept shipping releases the entire time. No feature freeze, no six-month rewrite branch nobody could merge back. +30% on performance and UX metrics by the end, and every release in between still went out on schedule.

Modularization gets sold as a build-time problem: split the app so Xcode compiles faster. That part's real, but it's not what makes it hard. The hard part is deciding where the boundaries actually go, because a wrong one costs you for years, and the stop-the-world rewrite to fix it later is exactly the thing you were trying to avoid.

Boundaries follow ownership, not folders

The obvious move is modularizing along the existing folder structure: pull Networking/ into a module, then UI/, then Models/. That produces modules that compile a bit faster and change nothing else, because the coupling that used to be implicit inside one target is now explicit across module boundaries, and just as tight.

The boundary that actually held on this migration was the one that followed who owned the code and how often it changed independently: a screen's data layer, its business logic, and its UI moved together as one unit, because that's the unit a single engineer or pair actually shipped changes to. A "shared utilities" module everyone imports and nobody owns is where modularization efforts go to die. It becomes a second monolith with extra ceremony bolted on.

Extract the smallest thing first, not the biggest

The natural first move is pulling out the biggest, most obviously reusable piece: the design system, the networking layer. Those are the wrong first extractions, because they're also the pieces with the most existing call sites, so proving the approach means touching the most files before you've proven anything.

The extraction that actually de-risks the migration is the smallest, most isolated feature module with the fewest dependents. Get its public interface defined, its internals hidden, and ship it in a real release. That's the proof the rest of the migration reuses. Start with the design system instead, and when something breaks in week three you can't tell whether it's the modularization approach or the size of the diff.

The interim is the project, not a phase you pass through

A half-modularized app has a monolith target and a growing set of extracted modules depending on each other in ways nobody fully mapped. Every new feature during that stretch has to decide whether it belongs in the module structure or the legacy target, and whether that decision gets revisited when the module graph shifts next month. Budget the interim with an explicit exit criterion. "60% modularized" isn't a real number when nobody's diagrammed the dependency graph it's measured against.

What actually breaks delivery mid-migration

Build times regress briefly while modules settle into their real dependency graph. Merge conflicts cluster in whatever file every module still touches, usually the app's root composition point, until that gets its own clear owner too. And team confidence dips: engineers who've shipped fast in the old monolith for years feel slower for a few sprints inside the new boundaries, before the structure starts paying that speed back. Name that dip to the team before it happens, not after someone asks why velocity looks worse this sprint.

The discipline that holds

Define a module's public interface before extracting its implementation. Ship one small module fully, in a real release, before touching a second. Track the interim as its own workstream with an exit criterion. And accept that the ownership map, not the folder structure, is what decides where a boundary actually goes.

If you're staring at a monolithic codebase and a roadmap that can't pause for a rewrite, that's exactly the kind of call I help teams make in a strategy session.

What's the module in your own codebase that everyone agrees should be split out, and what's actually stopping the team from starting?

Originally published at veheria.tech/blog/modularizing-legacy-ios-app.

n8n vs Custom Code for Engineering Automation: The Decision, and the Bug That Proved It Right

Oleh Veheria — Fri, 04 Sep 2026 09:16:25 +0000

I built the pipeline that publishes this site's content in versioned code instead of n8n. Not a philosophical stance against no-code tools, a practical call, and one specific bug is why I still think it was the right one.

Why code, not a canvas

Four reasons drove it, in order of how much they actually mattered:

Review parity. Every change to how a post gets approved or published goes through the same PR review as the rest of the site. A workflow-canvas change doesn't get that by default.
Headless operation. Claude Code drives the queue directly, no GUI dashboard sitting between the agent and the task.
Existing infrastructure. A Telegram bot already handled approvals; there was no gap a workflow tool needed to fill.
One fewer service. Every extra tool in the stack is something else to patch and keep secure. Skipping it was the cheap option, not just the principled one.

The bug that proved it

On July 20, 2026, a scheduled post silently failed. The Buffer API adapter treated an error response as a normal one, never checked the status, so the X post never actually went out while the pipeline marked it published. Nothing threw, nothing alerted, the queue just quietly lied about what had shipped.

I found it the way you'd expect: read buffer.py, saw exactly where the status check was missing, fixed one line. Cheap once you can see it.

That's the part I can't picture happening the same way in a workflow canvas. I genuinely don't have a mental model for debugging that failure mode there, a canvas doesn't hand you the same thing a stack trace and git blame hand you in code. You'd be reading node configuration and hoping the tool's own logging caught the edge case, instead of reading the exact line that skipped a check.

What this is actually about

It isn't code versus no-code as a philosophy. It's about legibility when automation is wrong in a way that doesn't throw an error. A silent-fail bug is the worst kind, because nothing tells you to go look. The only thing that saved this one was that the fix path was a normal code review, on a normal file, in a language with a debugger and a blame command. That's a property of the tool, not of how careful I was that week.

If your automation stack can fail without telling you, the question worth asking isn't whether the tool is fast to build in. It's whether you'd actually be able to find the bug when it goes quiet.

If you're weighing a workflow tool against custom code for something that publishes or ships on your behalf, that's exactly the kind of tradeoff I help teams think through in a strategy session.

What's the automation in your own stack you'd have the hardest time debugging if it started failing silently?

Originally published at veheria.tech/blog/n8n-vs-custom-agents-engineering-ops.

CLAUDE.md for an iOS Team: What to Put In It (and What to Leave Out)

Oleh Veheria — Fri, 04 Sep 2026 09:16:07 +0000

My first CLAUDE.md for a client project ran 400 lines: architecture diagrams, the full MVVM-vs-TCA debate, a style section that just repeated SwiftLint's config in prose. Claude Code reads that file in full on every single turn, and it still missed rules buried near the bottom, because by line 340 they're competing with everything else for the model's attention. I cut it to 60 lines over two weeks. Same team, same codebase, fewer violations of the rules that actually mattered.

It's not documentation

The instinct is to treat CLAUDE.md like a README: a place to record everything true about the project. A README gets read once by a human who skims for the one section they need. CLAUDE.md gets read in full, by a model, every turn, and every line you add dilutes every other line's share of attention. That's the whole design constraint, and most CLAUDE.md files ignore it.

What earns a line

Non-obvious conventions. Not "we use MVVM," that's visible in five minutes of reading the code. "ViewModels never import UIKit" earns its place only if it's a rule someone actually broke once and it cost a day.

Constraints invisible in the diff. App Store review requirements, a minimum OS version the code doesn't yet reflect, a performance budget on one screen because a past ship got rejected for jank. An agent has no way to infer any of that from the code alone.

Repo-specific workflow gotchas. Which branch triggers a real deploy, which test suite is a known-flaky non-gate versus a hard one, where the actual source of truth lives when two files disagree. I run a merge gate across a few of my own repos, code only merges once CI is green and review found nothing blocking, and the single highest-value line in each CLAUDE.md is the sentence explaining that the gate exists and why a raw git merge is bypassing something on purpose.

What the agent never touches unsupervised. For me that's deploy config and anything security-sensitive. Naming the boundary explicitly is cheaper than discovering it was needed after something already broke.

What doesn't

Anything git blame or the README already answers. Aspirational rules no linter enforces, an unenforced rule just teaches the model that the file's rules are optional. Architecture history and rationale, useful for onboarding a human, irrelevant to the task in front of the agent right now. Anything a linter or type system already blocks mechanically; if SwiftLint already kills force-unwraps, writing "avoid force-unwraps" adds length, not signal.

The before/after: the 400-line version spelled out the Git branching strategy, every third-party dependency and why it was picked, and a style section duplicating the linter. The 60-line version points at the linter instead of repeating it, names the merge gate and why, and states the one ViewModel/UIKit rule an agent (and a couple of humans) had actually gotten wrong before. The short file is the harder one to write, it forces you to decide what actually matters instead of writing down everything you know.

This is the same standardize-the-few-things-that-compound instinct behind modularizing a legacy iOS app without stopping delivery: legislate the few rules that matter across the whole team, leave the rest to local judgment. And it only holds if the codebase backs it up. A CLAUDE.md pointing at "the linter enforces this" is only as good as that linter config being current and actually run in CI.

What's the longest-standing rule in your own CLAUDE.md that you're not sure is still true?

If you're standing up this workflow on an iOS team and want a second pair of eyes on what belongs in the file versus what's just noise, that's the kind of thing I help with.

Originally published at veheria.tech/blog/claude-md-for-ios-teams.

SwiftUI vs UIKit in 2026: A Staff Engineer's Decision Framework

Oleh Veheria — Fri, 04 Sep 2026 09:03:41 +0000

Every SwiftUI-vs-UIKit take argues which framework is better. That's the wrong question. The one that actually matters: which one can this specific team ship and maintain, on this specific timeline, without the codebase becoming the bottleneck. Framework superiority is a debate for a blog post. Team fluency and timeline are what actually decide a ship date.

Team fluency beats framework features

An experienced UIKit team moving to SwiftUI pays a real productivity cost during ramp-up, even on the exact greenfield work SwiftUI is theoretically best at. The framework being technically superior for a use case doesn't matter if the team writing it is slower in it for the next two quarters.

Decide per screen, not per app

The better unit of decision isn't the app, it's the screen. Complex animation work and legacy SDK integrations still favor UIKit. Forms and straightforward navigation favor SwiftUI. Forcing one framework across an entire app because it won the debate once is how you end up fighting the wrong tool on the one screen that needed the other one.

What breaks in year two, not year one

A screen that started as a simple form can grow custom interaction requirements a year later that the original framework choice never anticipated. The failure mode isn't picking wrong on day one, it's not revisiting the choice as a screen's requirements change underneath it.

The hiring cost nobody prices in

Junior engineers ramp on SwiftUI faster. Senior UIKit engineers take longer to become productive in SwiftUI than the migration timeline usually assumes. If your hiring plan and your framework plan aren't the same conversation, one of them is wrong.

Testing isn't a rounding error

SwiftUI testing looks different enough from UIKit testing that a team can't assume the skill transfers by osmosis. That's ramp-up time you have to plan for explicitly, the same way you'd plan for a new build tool.

The framework, applied

Four situations, four different calls: a greenfield project with an experienced team defaults to SwiftUI. A stable, working UIKit codebase doesn't get rewritten for novelty. An active migration needs its dual-stack interim budgeted as its own tracked phase with a real exit criterion, not folded into "get to the target architecture" and hoped to resolve itself, the same underestimation shows up in modularizing a legacy iOS app without stopping delivery, where the interim ran months longer than planned for exactly this reason. And any individual screen gets evaluated on its own requirements, not on which framework the rest of the app happens to use.

If you're walking into this decision cold: don't start with the framework. Start with your team's fluency, your timeline, and which screens actually need what. The framework comparison is the easy 20% of the decision. The other 80% is admitting your team and your timeline are what's actually being decided, not React-Native-style feature checklists.

If you're staring at this decision on a real team with a real deadline and want a second opinion before committing, that's what I help with in a strategy session.

What's the one screen in your app where you'd pick the other framework if you were starting it today?

Originally published at veheria.tech/blog/swiftui-vs-uikit-2026.

llms.txt Implementation: The Part Nobody Measures

Oleh Veheria — Mon, 24 Aug 2026 07:00:05 +0000

My robots.txt has a line that says AI search and citation crawlers are "explicitly welcomed." I wrote that in July, four months after I'd already shipped an llms.txt file to this exact site. In that time I have not been able to confirm that a single one of those crawlers has ever opened it.

That is not the story you get from most llms.txt guides. Search "llms.txt implementation" and you get a dozen "Complete 2026 Guide" posts explaining the syntax, telling you to keep it to 20-50 curated links instead of dumping your sitemap, and listing which companies now publish one. All correct. All missing the part that actually matters once you have shipped it: how do you know it did anything?

What I actually shipped, and when

I added llms.txt to veheria.tech back in March, before I had more than two blog posts to point at (PR #63). It sat there as a curated summary: who I am, what I do, how to reach me. In July, once the AI-native engineering wedge posts started shipping, I updated it to list them explicitly (PR #84), each with a one-line description of what the post actually covers, not just a URL:

## Writing

- [Claude Code for iOS Development: The Workflow, Not the Setup](https://veheria.tech/blog/claude-code-ios-development/): where an AI agent is trusted in a real iOS team's loop, and where a human keeps the call.
- [A Claude Code Review Workflow That Saved 30 Minutes Per Engineer a Day](https://veheria.tech/blog/claude-code-code-review-workflow/): what to automate, what to keep human, and the one number measured after months of daily use.

Three posts, not twenty sitemap URLs. That was a deliberate call, not laziness. It is the same rule I run my code-review agents on: every finding has to cite a file, a line, and a concrete failure scenario, or it gets dropped. A link with no reason for a model to follow it is noise, whether it comes from an agent's review comment or from a sitemap dump into a file that is supposed to be curated. The entire pitch of llms.txt over a sitemap is that a human decided what matters. Paste the sitemap in and you have thrown that advantage away to save five minutes.

I left more out than I put in. The full site has language variants in English, Spanish, and Ukrainian; only the English canonical URLs made the file, because an assistant summarizing my work does not need three copies of the same claim. It has a contact page, a work page, and an about page; only /work earned a line, because that is the one page where the outcome of reading this file (someone reaching out) actually happens, and a model deciding whether to surface me is more useful with one clear next step than three competing ones. Every entry I kept had to answer "what does a model do with this that it could not do with the URL alone," the same test I apply to a code comment before I let it survive review. Most links fail that test. That is exactly why most llms.txt files, mine included at first draft, start too long and get cut, not the other way around.

The measurement problem nobody in the guides admits

Here is where it gets uncomfortable. I already run SEO on this site the way I run everything else here: headless, through scripts that pull Google Search Console and GA4 on a schedule. That pipeline can tell me, to the click, when a page gets indexed and what query it shows up for. It cannot tell me whether GPTBot, ClaudeBot, or PerplexityBot ever fetched /llms.txt.

The reasons are structural, not a gap in my scripts. GA4 fires on JavaScript execution in a browser; a crawler doing a raw HTTP fetch of a static Markdown file never runs a line of JS, so it never reports. Cloudflare Pages, on the free tier this site runs on, does not expose raw request logs, only aggregate analytics that do not break out user agents at the path level. The companies the guides cite as proof llms.txt "works" (Anthropic, Stripe, Vercel, Cloudflare) all run their own infrastructure with real access logs. A solo site on a hosting tier built for cheap static delivery does not get that visibility for free.

So the honest state of my llms.txt, four months in, is: it costs nothing, it might be read, and I have no instrument that would tell me either way. Before writing this I checked the other properties I run content or SEO for, not just this one. Most of them already ship an llms.txt. None of them, this site included, has any way to confirm a crawler opened one. Every guide I found treats adoption as the finish line. Adoption is the easy 90% of the work. The other 10%, knowing if it did anything, is the part that would actually justify spending more time on it, and nowhere in what I run had anyone, including me until an hour ago, gotten past the first 90%.

The mistake, and what I'd do differently

I have made this exact mistake before, on a bigger stack. When I put Claude Code agents into a multinational iOS team's review loop, I deployed first and picked the metric of record after, which meant the first stretch of tuning was against a feeling instead of a number. llms.txt is the same failure in miniature: I shipped the artifact and treated "it's live" as the win condition, without deciding up front how I would ever know if it earned its keep.

What I'd do differently is treat instrumentation as part of the ship, not a follow-up. Search Console will not help here; it reports on Googlebot's own crawl, not on GPTBot, ClaudeBot, or PerplexityBot fetching a static file. The version I actually plan to try next: a Cloudflare Pages Function in front of the /llms.txt route that logs the User-Agent header on every request before serving the file. Cheap to build, and it is the difference between "I hope a crawler reads this" and a line in a log that says one did. I did not build that when I shipped the file in March, or when I updated it in July. That is the mistake, not the file itself.

Should you still ship it

Yes, and the guides are right about that much. Adoption cost is minutes, the downside is zero, and being the entry that shows up when an assistant is asked to summarize your site is worth having even if you cannot yet prove the mechanism. What I'd change about how everyone, myself included, talks about it: stop writing as if shipping the file were the result. It is the setup. The result is whatever you can actually verify happened after, and right now, for anyone without an enterprise logging stack, that verification does not exist by default. Say that part out loud instead of implying the file is doing invisible work you cannot see.

This is the same judgment call that runs through most of what I write about putting AI agents into a real engineering workflow: the interesting question is never whether the tool is worth adopting, it almost always is. The interesting question is whether you built a way to tell if it is working, before you started telling other people to adopt it too.

If you are deciding where to spend engineering time on AI-visibility work versus everything else competing for the sprint, that kind of "does this actually move something, or is it cargo cult" call is exactly what I help teams work through in a strategy session.

If you have shipped llms.txt on your own site, have you found any way to confirm a crawler actually read it? I would like to know I am not the only one flying blind on this.

Originally published at veheria.tech/blog/llms-txt-implementation.