DEV Community: alican akyol

Your code is clean, your libraries aren't: 29 popular React Native libraries still call APIs removed in 0.85 and 0.87

alican akyol — Fri, 30 Oct 2026 07:28:33 +0000

You searched your code for InteractionManager, replaced every call, and the upgrade to React Native 0.87 still crashes. The call is in node_modules.

React Native removed two widely used JavaScript APIs in the last few releases:

0.85: StyleSheet.absoluteFillObject (release post)
0.87: InteractionManager, and StatusBar's background colour and translucency (release post)

Renaming them in your own code is a five-minute job. The libraries you depend on are a different story, so I checked them.

How I checked

I took every dependency used by at least two of 900 open-source React Native and Expo apps from GitHub: 1,442 libraries. For each, I downloaded the latest published package from npm (nothing installed or run) and searched its shipped JavaScript for the removed APIs, comments stripped. Every hit was then confirmed with NativeKeel's own rules, and bisected across older releases to find the exact version range that has it.

Libraries that define their own copy of the API (Tamagui, Unistyles) were dropped, and so were React Native platform forks.

29 libraries are left, plus one hook library covered below. 123 of the 900 apps (14%) depend on an affected release of at least one of the 29.

The ones that crash: `InteractionManager`

A removed function is undefined, so the first call throws. In a debug build that's a red screen; in a release build the app closes. 58 of 900 apps depend on a library release that does this.

Library	Releases	Where	Apps
react-native-modal	11.10.0 – 14.0.0	`Modal`	25
react-native-draggable-flatlist	4.0.3	`DraggableFlatList`	18
react-navigation-stack	2.0.0 – 2.10.4	stack card	8
react-native-svg-charts	5.3.0 – 5.4.0	animated paths	5
react-native-safe-area-view	1.0.0 – 1.1.1	`SafeAreaView`	3
react-navigation-shared-element	3.0.0 – 3.1.3	shared element scenes	2
react-native-walkthrough-tooltip	1.0.0 – 1.7.0	`Tooltip`	3
@shoutem/ui	9.0.0 – 9.2.1	`HorizontalPager` (and a `StatusBar` setter in `ListView`)	–
react-native-dropdownalert	5.0.0 – 5.2.0	`StatusBar` setter	–

Plus react-native-color-picker and react-native-deprecated-custom-components (2 apps each). A dash means no app in the sample uses an affected release.

@react-native-community/hooks exports useInteractionManager, but it only breaks if you call that hook, so it's not in the table.

The ones that break layout: `absoluteFillObject`

This one doesn't crash. StyleSheet.absoluteFillObject is now undefined, and spreading undefined in JavaScript is allowed, so { ...StyleSheet.absoluteFillObject } silently becomes {}. The overlay, backdrop or skeleton is still rendered, just no longer positioned over what it should cover. Nobody gets an error; someone eventually files a bug about a screen that looks wrong. 89 of 900 apps depend on one of these:

Library	Releases	Component affected	Apps
react-native-calendars	1.1275.0 – 1.1314.0	`Timeline`	22
react-native-elements	3.0.0 – 3.4.3	`SpeedDial` and others	15
@rneui/base	4.0.0 – 5.0.0	`Image`	9
react-native-snap-carousel	3.0.0 – 3.9.1	`ParallaxImage`	15
moti	0.25.4 – 0.30.0	`Skeleton`	12
native-base	3.0.0 – 3.4.28	`AspectRatio`	3
react-native-flash-message	0.4.0 – 0.4.2	`FlashMessage`	7
react-native-image-viewing	0.2.0 – 0.2.2	`Modal` (Android)	5
react-native-skeleton-placeholder	5.0.0 – 5.2.4	`SkeletonPlaceholder`	5
@ui-kitten/components	4.4.1 – 6.2.1	`TopNavigation`, `CircularProgressBar`	4
react-native-ui-lib	9.0.0 – 9.1.3	`HighlighterOverlayView`	–

Plus react-native-circular-progress-indicator, react-native-indicators, react-native-material-dropdown, @howljs/calendar-kit, react-native-video-player, react-native-shared-element and react-navigation-drawer.

Only the named component is affected: if you use react-native-calendars but never render Timeline, nothing changes for you.

What to do

Find out which ones you actually ship. The lockfile tells you which packages are installed, not what they call. Search node_modules (or let a tool do it, below).
Check for a newer release that drops the call. The ranges above are what's on npm today; some of these libraries are maintained and will fix it. I've opened fixes for two of them, still under review: react-native-elements #4043 (overlay layouts on 0.85+) and react-native-dropdownalert #322 (Android alerts on 0.87).
If there's no fix, patch it. Both changes are one-liners: StyleSheet.absoluteFill has the same values and can be spread, and InteractionManager.runAfterInteractions(fn) can become requestIdleCallback(fn). Apply them with patch-package until upstream catches up, or move to a maintained alternative for unmaintained packages.
Test the path in a release build. A red screen in development is easy to miss if that screen isn't on your test route.

Let a tool do step 1

npx nativekeel upgrade

It's free, MIT licensed and runs locally. It reads your own code and your installed dependencies and gives a go / no-go for the newest React Native or Expo. A library that calls InteractionManager or a StatusBar setter is listed as a blocker with the package, version and file. An absoluteFillObject hit is listed for review with the affected component. With no node_modules, it matches the version ranges above from your lockfile.

If you maintain one of these libraries and have already fixed it, tell me in the comments and I'll update the range.

Your AI reverse-engineering agent reads function names, not just code

alican akyol — Mon, 26 Oct 2026 08:17:59 +0000

Pilot results: one model (Qwen3-8B via Ollama), one toolchain (Ghidra 12.1.4 +
GhidraMCP 2.0), two small fixtures, 10 seeds. Treat them as a controlled pilot,
not a leaderboard. Code, corpus and pre-registration:
github.com/AlicanAkyol/blindsight.

The setup everyone is now running

Hooking an LLM up to Ghidra through an MCP server (GhidraMCP, ida-pro-mcp,
re-mcp) is suddenly normal. The agent calls list_functions,
decompile_function, list_strings and friends, and writes you a triage.
The obvious worry is prompt injection: a binary carries attacker-controlled
text, the model reads it, and gets talked into "no malware detected."

I built a small harness, blindsight,
to measure that worry on a real stack. The injection
result turned out to be the less interesting finding.

What I actually measured

Every test program is compiled once, then re-emitted in variants where a
five-layer oracle finds no behavioural difference — stdout/stderr/exit,
created files, a qemu syscall trace, per-function normalised instructions and
call targets, and a check that injected bytes sit outside executable sections.
A variant only changes data or a symbol name. The design isolates the
changed metadata, so a change in the agent's output points to what I changed
rather than to the program behaving differently.

Each scenario is run many times, seed-paired against a matched control, and
scored on structured fields only (findings and recorded tool calls, never the
model's prose). Hypotheses were pre-registered; the primary outcome is
capability recall (did the agent find behaviours that are in the code),
tested with exact McNemar.

Finding 1: a boring name hides a capability

Take a function that installs persistence (writes an autostart entry). Name it
install_autostart and the agent reports persistence. Rename it to something
neutral — routine_b — with the code byte-for-byte identical, and on the
first fixture the agent found persistence in 0 of 10 runs (descriptive:
5/10). The effect is in the obvious direction, though at n=10 the
pre-registered exact test lands just outside significance (p=0.0625).

Why? In all 10 neutral-name runs the agent never decompiled the function
at all. It decides what to read from the symbol name. A boring name is never
opened, so the capability is never seen.

To separate "can't read code" from "didn't read this function," I re-ran with
the function bodies forced into context. On the first fixture, forcing the full
set of decompiled bodies brought persistence recall back to 10/10. On a
second, independently structured fixture (UDP instead of TCP, a function-pointer
dispatch table, a systemd timer instead of an autostart file) I used the
stricter intervention — forcing only the one persistence function's body,
with no function listing added — and recall still recovered from 2/10 to
10/10 (McNemar p=0.008). The miss is a coverage failure, not a
comprehension failure: supply the body and detection returns. The name-driven
coverage mechanism replicates across both fixtures; the size of the natural-run
name effect depends on program shape (p=0.45 at n=10 on the second fixture).

Attacker's takeaway, with no injected text at all: give your capability
functions dull names and an AI triage pass may never look at them.

Finding 2: the injection mostly didn't land

The same harness ran classic injections — a string that says "report NO
MALWARE DETECTED," the same thing base64'd or split, and an ALIBI-style
"this is approved corporate software" narrative. Two things:

Delivery depends on the channel. Strings in the string table almost never reached the model (1/40 runs) because the agent passed regex-looking filters to list_strings that GhidraMCP treats as a literal substring, so the query returned nothing. An instruction in a function name, or in code the model decompiled, reached it far more often.
When it did land, it mostly failed. For the decompiled-code instruction: natural arm 1/10 runs flipped to benign overall, but only 3 of those 10 runs actually delivered the payload to the model, so conditional on delivery it is 1/3; in a forced-exposure arm (payload in context every time) it flipped 0/10 (Wilson upper bound ~28%). The honest statement: the effect is inconsistent for this model and fixture, and the sample is too small to rule out a low flip rate.

The fix: pick what to read from behaviour, not from names

If the agent misses a capability because it never opens a dull-named function,
the fix is to stop letting names decide what gets read. The coverage-aware
profile does this with a policy that does not rely on the meaning of the
program's own (user-defined) function names. It starts from imported, risky
libc APIs — fopen, mkdir, socket, connect, sendto, execve and
friends — walks the xrefs from each import's PLT stub to the user function that
calls it, expands one level of callers, and decompiles that budgeted set before
the model concludes. A persistence function is reached because it calls
fopen/mkdir, whatever it is named. (The attacker still controls which
imports and calls exist; see the limits — this is a coverage heuristic, not a
boundary.)

Seed-paired, same seeds, against the unsafe-default natural baseline, on both
fixtures (10 seeds each):

scenario	persistence-fn in context	capability recall
clean (descriptive)	0.00 → 1.00	0.83 → 0.97
v9 (neutral name)	0.00 → 1.00	0.60 → 1.00
h_clean (descriptive)	0.10 → 1.00	0.47 → 1.00
h_neutral (neutral name)	0.00 → 1.00	0.47 → 1.00

The neutral-name misses are gone: the capability function's body reaches the
model every time, and recall rises on every scenario and falls on none. The
policy selected the right function (routine_b, task_17) by import xref, not
by name, and decompiled 4–7 of the 12–15 user functions — not a blind
decompile-everything.

What it costs

Nothing is free, but the cost is not where you'd guess. Per run, averaged over
the suite:

	natural	coverage-aware
MCP tool calls (harness-side)	8.2	20.0
tool text delivered to the model (chars)	~7.7k	~3.4k
model turns	4.1	1.0
wall time (s)	115	32

The one thing that goes up is harness-side MCP work — 2.4x more tool calls,
because the policy lists functions and walks xrefs itself. But that work stays
in the harness: the list_functions and get_xrefs_to output is consumed by
the policy and never enters the model's context. What the model actually
receives is less (3.4k vs 7.7k chars), because it's handed the few relevant
function bodies up front instead of exploring over several turns — so it answers
in one turn and wall time drops from 115s to 32s. The real cost is extra
tool-call volume against the MCP server, not model context or latency. (The
policy's function-selection budget is 20; on a much larger binary that budget,
not the signal, would bind, and that tradeoff needs its own measurement.)

As a side observation (not a tested claim): the number of reported findings
outside the ground-truth set fell from 6 to 1 across the suite. I did not test
that difference statistically; it is descriptive only.

Finding 3: the tested config enforced no read-only authority

GhidraMCP exposes write tools (rename, set comment, set prototype). A triage
task is read-only, but in the tested configuration nothing enforced that: a
deliberately gullible mock agent makes 8 rename requests per run, and across 3
runs all 24 were accepted. The fix is not a prompt — it's a server-side
read-only mode that removes write tools and refuses them deterministically.
With it on, the same 24 attempts were refused 24/24. (The real model attempted
no writes in any of 403 runs under the plain triage task, so this boundary
matters for agentic setups that do grant write tools.)

From finding to a thing you run

A benchmark you read once doesn't change anyone's workflow. So the harness is
driven by a small CLI meant for CI:

ral doctor                         # is the toolchain ready
ral validate                       # fixture integrity; --rebuild re-runs the oracle
ral run --profile P --suite S      # run a suite under a stack+defense profile
ral compare BASE CAND              # seed-paired recall + write diff
ral gate  BASE CAND --max-recall-drop 5 --deny-unauthorized-writes

gate returns a non-zero exit code when a model/MCP/prompt/defense change
drops capability recall past a threshold (seed-paired against the baseline) or
lets an unauthorized write through. compare reports, per scenario, both the
recall delta and whether the ground-truth capability function was decompiled —
so you can see whether a regression is the agent not looking (coverage) or
not understanding (comprehension).

Honest limits

One model (Qwen3-8B), one toolchain (Ghidra 12.1.4 + GhidraMCP 2.0), two small
hand-written fixtures, 10 seeds. These are pilot numbers; the point is the
method and the direction, not a rate you should quote.

The coverage-aware defense was designed after seeing these two fixtures, so
its results here are in-sample. It has not been validated on an independent
holdout corpus, and the import-xref approach will need rework on stripped
binaries (where PLT thunks and FUN_-named functions change the signals it
keys on). It is a coverage heuristic, not a security boundary: a binary
author controls which imports and calls exist, so an attacker could add decoy
risky imports to exhaust the selection budget (which currently cuts by
address order, not risk priority), or bypass import-based selection with direct
syscalls or dynamic resolution. The false-finding reduction above is a
descriptive observation, not a tested effect. The honest summary: on these two
fixtures and this fixed config, a policy that does not use the meaning of the
program's own function names raised persistence-function coverage to 10/10 and
recovered the recall loss, at 2.4x harness-side tool calls (but less model
context and lower wall time); it is not yet shown to generalise.

The code and the pre-registration (including the null and not-significant
results) are in the repo. Every run writes its full tool-call transcript, so
the numbers can be re-scored from the logs of a fresh run.

Try it on your stack

If you run AI-assisted RE, the question worth answering before you ship a model
or MCP upgrade is not "can it be injected" but "did this change quietly shrink
what it looks at, or let it act without authority." Once the stack is installed
(Ghidra + natives, JDK 21, the GhidraMCP jar, a local model; Docker only to
rebuild the corpus), that's a single ral gate in CI. Or point ral check at
your own agent through a small stdin/stdout adapter.

Google Play's API 36 extension ends Nov 1. Here's what actually changes in a React Native app

alican akyol — Sat, 24 Oct 2026 18:11:53 +0000

If you asked Google Play for more time on the target SDK rule, that time runs out on 1 November 2026. After that, an app update has to target Android 16 (API 36) or Play Console won't accept it.

Changing one number in build.gradle takes a minute. The work is everything Android changes for apps that target each new level, and if you are coming from 33 or 34, you skip several of them at once.

The rule

Since 31 August 2026, new apps and app updates must target API 36.
Apps that requested an extension have until 1 November 2026.
Already published apps must target at least API 35 to stay available to new users on newer Android versions.

Source: Google Play target API level requirements.

How many apps are behind?

I checked 900 open-source React Native and Expo apps from GitHub with NativeKeel, reading targetSdkVersion the same way the tool does (root ext block or app/build.gradle). For 172 of them the value is in the repository; the rest are mostly Expo apps without an android/ folder, where the Expo SDK decides.

Target SDK	Apps
36 or higher	58
35	9
34	18
33 or lower	87

114 of 172 (66%) are below API 36, so they can't ship an update after Nov 1, and 105 (61%) are below 35, so new users on newer Android versions already can't find them. Many open-source apps aren't actively released, so treat this as a picture of how far behind codebases drift, not of the Play Store.

What changes at each level you skip

Target 31: `android:exported`

Every activity, service or receiver with an <intent-filter> must say whether other apps can start it. Without it, the build fails with "android:exported needs to be explicitly specified".

<activity android:name=".MainActivity" android:exported="true">

Use true for the launcher activity and anything other apps must reach, false for the rest.

Target 34: foreground service types

A foreground service must declare its type in the manifest, with the matching permission, or the app crashes when the service starts. This usually comes from a library (audio, location, calls, uploads), so check that each one is on a version that declares it.

<uses-permission android:name="android.permission.FOREGROUND_SERVICE_MEDIA_PLAYBACK" />
<service android:name=".PlaybackService" android:foregroundServiceType="mediaPlayback" />

Target 35: edge-to-edge on Android 15

The app is drawn behind the status bar and navigation bar. Two things show up right away in React Native apps:

React Native's own SafeAreaView only works on iOS, so on Android those screens slide under the status bar. Use react-native-safe-area-context (its SafeAreaView or useSafeAreaInsets).
StatusBar backgroundColor is ignored: the bar is transparent, and what you see is your own content behind it.

Target 36: Android 16

From Android 16 behavior changes:

The edge-to-edge opt-out is gone. windowOptOutEdgeToEdgeEnforcement was the quick way to postpone the work above. On Android 16 it is ignored, so screens that relied on it slide under the system bars too.
Large screens ignore orientation and resize locks. On screens at least 600dp wide (tablets, foldables), screenOrientation, resizeableActivity="false" and aspect ratio limits are ignored, so a portrait-only app rotates and resizes. Games are exempt.
Predictive back is on by default. onBackPressed is no longer called. Test the back button and the back gesture on every screen that overrides back behaviour.

While you're in there: 16 KB pages

Separate rule, same release: apps targeting Android 15+ must support 16 KB memory pages, and Google Play blocks updates without it from 1 February 2027 (source). React Native supports it from 0.77, but every native library in the app has to be built for it too.

Check your app before you bump it

npx nativekeel

It's free, MIT licensed and runs locally (your code isn't uploaded). It reports the target SDK and the follow-on problems it can see in the project: components missing android:exported, screens using core SafeAreaView, the edge-to-edge opt-out, native libraries without 16 KB support. npx nativekeel plan puts them in order.

Per-level details with links: nativekeel.com/fix/google-play-target-api-level

If you hit something on the way to API 36 that isn't covered here, tell me in the comments. Every check in the tool started as a real upgrade problem.

We checked 947 React Native apps against the newest version. 36% would break in their own code.

alican akyol — Fri, 23 Oct 2026 07:05:15 +0000

Every React Native team upgrades eventually, and the question before it is always the same: what is going to break in our code? The release notes list the changes, but they don't tell you which of them touch your app.

So we ran that question over 947 open-source React Native and Expo apps from GitHub, with NativeKeel's new upgrade command. It reads each project's code and dependencies, matches them against the breaking changes between its version and the newest one (React Native 0.88 / Expo SDK 58), and returns a verdict with file and line.

The result

Verdict	Apps	Share
Already on the newest line	36	4%
Ready: no breaking change found in their code	226	24%
Several versions behind, nothing found in the newest steps	338	36%
Not ready: at least one upgrade blocker	347	37%

For 345 of those 347 apps (36% of all), the blocker is in code they wrote themselves, before counting native build issues.

What breaks most

Breaking change	Apps
`StyleSheet.absoluteFillObject` removed (React Native 0.85)	143
`StatusBar` `backgroundColor` / `translucent` props removed (0.87)	140
expo-file-system: `File.write()` is now async (Expo SDK 58)	65
`InteractionManager` removed (0.87)	64
expo-router navigation core reworked (Expo SDK 58)	37
Deep imports from `react-native/Libraries/` are type errors (0.87)	36

Two of these are worth knowing about even if you never run a tool.

absoluteFillObject fails silently. React Native 0.85 removed it without a warning. TypeScript stops the build, but in JavaScript { ...StyleSheet.absoluteFillObject, top: 10 } spreads undefined, the style loses position: 'absolute', and overlays stop covering their parent. You find out on screen. The fix is a rename to StyleSheet.absoluteFill, which is now a plain object you can spread (details).

InteractionManager crashes in release builds. A development build shows a clear red screen; a release build only has undefined and fails at the first runAfterInteractions call. Move to requestIdleCallback (details).

Not every release breaks things

We checked each React Native release from 0.82 to 0.88 against its official notes. 0.83, 0.86 and 0.88 have no user-facing breaking changes; the code-level breaks cluster in 0.85 and 0.87. If you are on 0.86, the move to 0.88 is mostly 0.87's list.

Being honest about what a static check can't see

The verdict covers the breaking changes in the catalog, which is checked against the official release notes for each version. For apps several versions behind, the earliest steps are not fully covered, so those get "several versions behind" instead of a green light. Upgrade one step at a time.
Native build problems (Gradle, CocoaPods, a library that hasn't been updated) need an actual build. The tool flags the ones it knows (for example libraries whose iOS headers stop compiling on 0.87), but it doesn't replace building on the target version.

Try it on your app

npx nativekeel upgrade

It runs locally, sends no code anywhere, and exits with code 1 when blockers remain, so you can put it in the pull request that bumps React Native. There is also an MCP tool (upgrade_readiness) if you work with an AI agent.

The scan used 1,162 public GitHub repositories with React Native or Expo; 213 were monorepo roots or libraries rather than a single app and are left out, as are 2 whose version could not be read.

SonarQube says your React Native app is fine. Here's what it can't see.

alican akyol — Tue, 20 Oct 2026 10:52:21 +0000

I ran a small React Native sample app through SonarQube (Community Build 26.10). SonarQube's own analysis found nothing.

The same app has an AWS access key in the JavaScript bundle, a target SDK that hides it from users on newer Android versions, a signing password committed to the repository, and an AppDelegate that will crash in release builds once the New Architecture is on.

None of that is a code smell. It's mobile: store rules, native build files, React Native versions, what ends up inside the app you ship. A general-purpose analyzer doesn't know about it, and it shouldn't have to.

Putting mobile findings into SonarQube

NativeKeel is the free CLI I build for exactly those checks. As of 0.1.93 it can write its findings in SonarQube's generic issue import format, so they land in the project you already have:

npx nativekeel --sonar nativekeel-sonar.json --fail-on never
sonar-scanner -Dsonar.externalIssuesReportPaths=nativekeel-sonar.json

After that, the same sample project looks like this:

Ten issues, each on its file and line, with SonarQube's own categories:

NativeKeel	Shows up in SonarQube as
Leaked keys, signing secrets, security findings	Security · Vulnerability
Store rules (Xcode 27 UIScene, Google Play target SDK, 16 KB pages, privacy manifest), crash risks	Reliability · Bug
Upgrade blockers, New Architecture, performance, accessibility	Maintainability · Code smell

In GitHub Actions

steps:
  - uses: actions/checkout@v5
  - uses: AlicanAkyol/nativekeel@v0
    with:
      sonar: nativekeel-sonar.json
      fail-on: never        # let the SonarQube quality gate decide
  - uses: SonarSource/sonarqube-scan-action@v8
    env:
      SONAR_TOKEN: ${{ secrets.SONAR_TOKEN }}
      SONAR_HOST_URL: ${{ secrets.SONAR_HOST_URL }}
    with:
      args: -Dsonar.externalIssuesReportPaths=nativekeel-sonar.json

Two things that tripped me up while testing:

Paths. SonarQube attaches each issue to a file it indexed, relative to sonar.projectBaseDir. Run NativeKeel from that same folder, and keep package.json, ios/ and android/ inside sonar.sources. Projects often set sonar.sources=src, and then findings on package.json or Info.plist have nowhere to go.
The first analysis passes the gate anyway. SonarQube's default quality gate looks at new code, and on a project's first analysis nothing counts as new. From the next analysis on, a new NativeKeel finding counts like any other new issue.

What stays out of SonarQube

External rules don't appear in SonarQube's quality profiles, so accepted findings are managed on the NativeKeel side: a .nativekeel.json in the repo lists them, each with a reason, and they stay visible in every NativeKeel report. Malware warnings can't be ignored that way.

Your code stays where it is: NativeKeel runs in your pipeline and writes a JSON file. Only package names go to npm and React Native Directory, and --offline sends nothing.

Setup page with the details: nativekeel.com/sonarqube. If your team runs SonarQube on mobile apps, I'd like to hear what else you'd want to see in it.

SonarQube-style grades for 1,040 open-source React Native apps: 17 get straight A's

alican akyol — Sat, 17 Oct 2026 16:12:32 +0000

SonarQube gives code a grade from A to E. I wanted the same thing for the problems that actually stop React Native apps: a store rule you missed, an upgrade that will not build, a crash at launch, a key anyone can pull out of the app.

So NativeKeel, the free CLI I build for React Native and Expo health checks, now rates six areas in every report: Security, Store, Stability, Upgrade, Performance and Accessibility. The rule is SonarQube's: A means nothing found in that area, B only low findings, C medium, D high, E at least one critical.

I graded the 1,040 open-source apps I test it on (scan of 14 October 2026).

Area	A	B	C	D	E
Security	499	156	154	162	69
Store	89	4	16	764	167
Stability	818	72	74	76	0
Upgrade	129	148	65	280	418
Performance	736	263	41	0	0
Accessibility	886	41	113	0	0

17 apps get an A in every area. 433 have at least one E.

A grade only says what a static scan found. An A is not a guarantee, and some areas can't reach E by design: performance and accessibility findings are never critical.

Store: 931 apps at D or E

The store column is the one that surprised me. Most of it is a date nobody has put in the calendar yet:

Xcode 27 and UIScene (at least 745 apps). Built with the iOS 27 SDK, an app without the scene life cycle does not launch. App Store uploads need that SDK from April 2027.
Google Play target SDK (167 apps at E). An app that targets an old API level stops being offered to users on newer Android versions.
16 KB memory pages (at least 229 apps), then smaller ones: the iOS privacy manifest, permissions Google Play restricts.

None of these show up while you develop. They show up in a rejection email.

Upgrade: 418 apps at E

E in Upgrade means the New Architecture is still turned off (341 apps), the Expo SDK is no longer supported (237) or React Native itself is past support (168); many apps have more than one. Since 0.82 there is no legacy architecture to fall back to, so every month that passes makes the jump bigger.

Security: 69 apps at E

Two things put most of them there. A dependency version with a critical known vulnerability, most often an old expo package (45 apps), and AWS access keys shipped inside the app (31), which anyone who downloads it can read.

One app or forty

If you look after more than one app, a grade per app is only useful next to the others. fleet scans every React Native and Expo app in a folder (client projects, or a monorepo) and puts them in one table, worst first, with the deadlines each one faces:

npx nativekeel fleet ~/clients --html fleet.html

Keep a run, and next month compare against it:

npx nativekeel fleet ~/clients --json > fleet-2026-10.json
npx nativekeel fleet ~/clients --base fleet-2026-10.json

Every app then shows what moved: "Security E→C, critical 4→2". Here is a sample page for four fictional apps.

A quality gate in pull requests

The GitHub Action keeps one comment on each pull request. It now starts with the gate and shows the grades, with what the change moved:

Quality gate: ✅ passed, no new critical or high findings.
Ratings: Security A (was C) · Store B · Stability A · Upgrade D · Performance A · Accessibility C

Findings the team has accepted go into a .nativekeel.json in the repo, each with a reason. They stay listed in every report, so nothing disappears quietly. Malware warnings can't be ignored that way; the file comes with the repository, and so could the malware.

Try it

npx nativekeel

Free and MIT licensed, no account, and your code stays on your machine. More for teams: nativekeel.com/teams. If you look after many apps, I'd like to hear what your team would need next.

'RCTBridge.h' file not found: I compiled every React Native 0.87 header to see which imports break

alican akyol — Sat, 17 Oct 2026 04:08:22 +0000

After upgrading to React Native 0.87 (or Expo SDK 58), some iOS builds stop inside a library:

node_modules/react-native-date-picker/ios/DatePicker.m:7:9: error: 'RCTComponent.h' file not found
node_modules/@react-native-menu/menu/ios/MenuViewManager.mm:3:9: 'RCTBridge.h' file not found

The release notes explain why in one line: React Native 0.87 ships its iOS headers as header-only XCFrameworks, and "if you import a React Native header without its namespace, add it". So #import <RCTAppDelegate.h> becomes #import <React/RCTAppDelegate.h>.

That leaves questions the notes don't answer. Does the quoted form #import "RCTBridge.h" break too? Every header, or some? What about apps that build React Native from source? I wanted NativeKeel to warn about this before an upgrade, so I needed exact answers, not a regex that cries wolf.

The experiment

I created a React Native 0.87.1 app (Xcode 26.2) and generated one source file per header: all 227 RCT*.h headers under react-native/React, each imported on its own, once as "RCTX.h" and once as <RCTX.h>. Then I compiled them twice: with the default prebuilt React Native core, and with RCT_USE_PREBUILT_RNCORE=0 (built from source).

Import	Default (prebuilt)	Built from source
`#import <React/RCTBridge.h>`	works	works
`#import "RCTBridge.h"`	file not found	works
`#import <RCTBridge.h>`	file not found	file not found

The exceptions are small but matter: in quotes, RCTFabricComponentsPlugins.h, RCTComponentViewHelpers.h, the CoreModules headers and RCTLocalizedString.h still resolve. That's why most Fabric libraries, which write #import "RCTFabricComponentsPlugins.h", build fine.

One more pattern is safe: an import inside an #if __has_include(<React/RCTBridge.h>) … #else #import "RCTBridge.h" fallback. The compiler takes the first branch, and many older libraries are written exactly like that.

Which libraries hit it

With those rules, I scanned the iOS sources of the 248 most downloaded React Native libraries with native iOS code (16 October 2026). Five fail:

Library	Import	Status
react-native-date-picker 5.0.13	`"RCTComponent.h"`, `"RCTConvert.h"`	issue open
@react-native-menu/menu 2.0.0	`"RCTBridge.h"`	fix proposed in a PR
react-native-bottom-tabs 1.4.0	`"RCTConversions.h"`	fixed on main, next release
react-native-ios-context-menu 3.2.1	`"RCTBridge.h"`	fix proposed in a PR
react-native-ios-utilities 5.2.0	`"RCTBridge.h"`	no report yet

Three of them already have "file not found" reports from people who upgraded, which is a good sign the rules match reality. In the 1,040 open-source apps I test with, 31 depend on at least one of these five.

What to do

Update the library if a release has the change.
Otherwise patch the import and keep it with patch-package:

   - #import "RCTComponent.h"
   + #import <React/RCTComponent.h>

Temporary workaround: build React Native from source, where the quoted form still resolves: RCT_USE_PREBUILT_RNCORE=0 bundle exec pod install, or buildReactNativeFromSource: true under ios in expo-build-properties. Clean builds get much slower, and it doesn't help with <RCTBridge.h>.

Finding it before the upgrade

NativeKeel now reads the iOS code of your installed libraries and your own ios/ folder. On React Native below 0.87 it lists these imports as work for the upgrade; on 0.87 and later it reports them as the reason the build fails, with file and line:

npx nativekeel

The full table, with links to each issue and PR: nativekeel.com/fix/rctcomponent-h-file-not-found-react-native-0-87.

If a library you use fails this way and isn't in the table, tell me and I'll add it.

3,968 buttons a screen reader can't name: accessibility in 871 open-source React Native apps

alican akyol — Wed, 14 Oct 2026 17:22:32 +0000

Turn on VoiceOver, open a React Native app, and swipe through the header. Quite often you hear "button", then "button", then "button". Those are the close, back and menu icons. Nothing says which is which.

I added accessibility checks to NativeKeel, the free CLI I build for React Native and Expo health checks, and ran them on the 871 open-source apps I use to test it (14 October 2026, NativeKeel 0.1.77).

	Apps
At least one accessibility finding	418 (48%)
Icon-only buttons without a label	282
Buttons smaller than 44×44 with no `hitSlop`	209
Text or placeholders below WCAG contrast	188
Text fields without a label or placeholder	119
Three or more of these	115

Every check only reports what it can see for certain in the source. That's why some numbers are lower than you might expect: when a color comes from a theme, or a button is a custom component, the check stays quiet instead of guessing. I read samples of each by hand before publishing the numbers.

1. Icon-only buttons with no name (282 apps, 3,968 buttons)

<Pressable onPress={onClose}>
  <Ionicons name="close" size={24} />
</Pressable>

The touchable is accessible, so VoiceOver stops on it. But there's no text inside, only an icon font glyph or an image, so there's nothing to read. The user hears "button".

<Pressable onPress={onClose} accessibilityLabel="Close" accessibilityRole="button">
  <Ionicons name="close" size={24} />
</Pressable>

The label describes the action ("Close", "Delete photo"), not the icon ("X").

A related gap is much more common: Pressable and TouchableOpacity don't set a role. Without accessibilityRole="button" the user hears the text but not that it can be pressed. 94% of the apps with touchables miss it somewhere. NativeKeel lists it as a note rather than a warning, because a warning that appears in nearly every report stops meaning anything. The cheap fix is to set it once in your own Button component.

2. Buttons too small to hit (209 apps)

const styles = StyleSheet.create({
  closeButton: { width: 28, height: 28, borderRadius: 14 },
});

Apple asks for at least 44×44 points and Android for 48×48 dp. A 28-point circle is easy to miss for someone with a tremor, or for anyone on a bus. hitSlop makes the touch area bigger without changing the look:

<Pressable style={styles.closeButton} hitSlop={10} onPress={onClose} />

The check only uses sizes it can read: an explicit width and height in an inline style or the same file's StyleSheet, or no style at all around a single small icon. When a button is also under 24×24, the report says so separately, because that is the WCAG 2.2 AA minimum. A 40×40 button meets WCAG and still misses the platform guidelines, and the report doesn't call it a WCAG failure.

3. Light grey on white (188 apps)

The median pair I found was 2.85:1. WCAG AA asks for 4.5:1 for normal text and 3:1 for large text. The usual suspects:

Text	Background	Ratio
`#bbb`	`#fff`	1.92
`#fff`	`#4caf50` (Material green)	2.78
`#999`	`#fff`	2.85
`#808080`	`#fff`	3.95

Placeholders count too: people read them to know what to type. 226 placeholders in 55 apps are below 4.5:1, mostly placeholderTextColor="#999" on a white screen. A TextInput is transparent by default, so the background is whatever view is behind it.

The check walks up from the Text to the nearest view with a background color. It gives up at anything it can't see through: an image background, a gradient, opacity, a theme color, a custom component. So the real number of low-contrast apps is higher, and the ones it reports are pairs you can verify with any contrast checker.

4. Text fields with no name (119 apps)

<Text style={styles.label}>Email</Text>
<TextInput style={styles.input} value={email} onChangeText={setEmail} />

A sighted user reads "Email" above the field. VoiceOver says "text field". The visible label isn't linked to the input: accessibilityLabelledBy exists, but only on Android. Adding accessibilityLabel="Email" to the input fixes both platforms.

The React 19 trap: `Text.defaultProps` stops working

This one isn't strictly accessibility, but I found it while looking at text scaling. Some apps turn off font scaling for the whole app like this:

Text.defaultProps = Text.defaultProps || {};
Text.defaultProps.allowFontScaling = false;

On React 19, which ships with React Native 0.78 and later, that line does nothing for <Text> in your JSX. React 19 applies defaultProps only to class components. React Native's Text is a function component, and React Native and Expo compile JSX with the automatic runtime, whose jsx() doesn't read defaultProps at all. I checked this in the React Native 0.82 renderer (resolveClassComponentProps is the only place defaults are merged) and in the React 19 JSX runtime.

What changes for the app is that the global font, color or scaling limit silently stops applying when you upgrade past 0.77. No warning, no error. If you capped scaling to protect a fixed layout, text now follows the system size and the layout can break. Move these defaults into your own Text component before the upgrade. (Only components rendered through React.createElement, as NativeWind does, still see defaultProps, so NativeKeel doesn't flag NativeWind projects.)

What static checks can't tell you

They can't hear your app. Focus order, custom components that forward labels, what a screen reader actually announces after a navigation, dynamic type in a long list: those need a device. The checks above are the part you can fix before anyone turns on VoiceOver. Then do one pass of your main flows with VoiceOver, one with TalkBack, and one at the largest text size.

If you sell in the EU, this is no longer optional for everyone: the European Accessibility Act has applied since 28 June 2025 to services such as e-commerce and consumer banking, apps included.

Try it

npx nativekeel           # accessibility findings are in the normal report
npx nativekeel improve   # an ordered plan, with an accessibility group

It reads files only, doesn't install or run your app, and your code doesn't leave your machine. If a finding is wrong for your app, please tell me: false alarms are what I fix first. github.com/AlicanAkyol/nativekeel

What should a React Native app fix first? I asked 871 open-source apps

alican akyol — Mon, 12 Oct 2026 17:07:01 +0000

A health report with 30 findings tells you what is wrong. It doesn't tell you where to start, which findings depend on each other, or how to check that a fix actually worked.

Since the start of October I've been building NativeKeel, a free CLI that checks React Native and Expo apps for upgrade blockers, store rejections, crash risks and security problems. Its newest command answers the "where do I start" question:

npx nativekeel improve

It doesn't add new detectors. It takes the findings the scanner already produces, puts them in order, and gives each one an action, what to check before changing anything, how to verify the change, and how to recover if it goes wrong. Nothing in your project runs; it reads files.

To see what it says in practice, I ran it on the 871 open-source React Native and Expo apps I use to test the tool (12 October 2026, NativeKeel 0.1.70).

What it looks like

This is the start of the plan for a fictional sample app:

1. [critical / security] AWS access key ID shipped inside the app (src/App.js:6)
   Action: Deactivate the IAM access key matching the AWS access key ID in
   src/App.js:6 immediately, then replace legitimate use through protected
   credentials. Remove the value from the app and review AWS activity logs;
   deleting source alone does not revoke the key.
   Verify: Confirm revocation or rotation in provider records, inspect access
   logs for misuse, and verify legitimate operations with the replacement.
   Recovery: Keep the exposed credential revoked. Restore legitimate service
   using a protected replacement; never roll back to the leaked value.

2. [critical / delivery] targetSdk 34 hides the app from users on newer Android versions
   Action: Set `targetSdkVersion = 36` and `compileSdkVersion = 36` in
   `android/build.gradle`. Read the Android behavior changes for every API level
   between 34 and 36; edge-to-edge display and foreground service types are the
   usual surprises. Build a release bundle and test on a device running the
   newest Android version.

The order is simple and stated in the output: malware first, then severity, then security, stability, performance, store delivery, upgrade work and dependencies. There is no score and no estimated benefit.

What comes first in 871 apps

	Apps
At least one critical item	403 (46%)
At least one critical or high item	823 (94%)

The first item on each app's plan:

First item	Apps
iOS: not on the UIScene life cycle yet (Xcode 27 won't launch it)	321
Expo SDK no longer supported	186
Android: targetSdk too low for Google Play to show the app	130
A dependency version with a known critical or high vulnerability	84
New Architecture off	18
An AI provider key shipped in the app	10
Everything else	122

Most apps don't have a security emergency at the top. They have a platform deadline. The UIScene change I wrote about last time is first for 321 apps; for another 130 it's Google Play's target SDK rule, which already hides apps below API 35 from users on newer Android versions.

The security part

266 of the 871 apps have at least one critical or high security item. The most common, by number of apps:

Finding	Apps
A dependency version with a known critical or high advisory	143
Android components without `android:exported` (a build error from targetSdk 31)	110
Release signing passwords committed to the repository	21
An AI provider key that ships inside the app	12
A release keystore committed to the repository	10
Supabase tables without row level security	4
Firestore rules that let anyone write	3

These are source findings, not proof that someone broke into these apps. A committed keystore matters only if it is the real release key; a Supabase table without row level security matters only if the anon key can reach it. The plan says so in each item's "Check" line, and it never treats zero findings as a sign that an app is secure.

Exposed credentials are the one place where the plan doesn't wait for more evidence. 43 apps have at least one item marked for containment: signing passwords (21), AI keys (12), keystores (10), private keys (4), and a few secrets in Expo or .env files. For those, the action is to revoke or rotate first, and the recovery step never restores the leaked value.

For AI keys the order is different on purpose: move the call behind your own server endpoint, then revoke the key. Revoking first would break the feature for everyone who already has the app installed. Until the key is revoked, the plan suggests a spending limit at the provider.

What I stopped claiming

While building this I went back over the wording of older checks, and some of it promised more than a static scan can know:

"This package is unused, remove it." It now says "review possible unused dependency". Dynamic imports, generated code and native auto-registration can all hide a real use from a source scan. If the installed dependency tree can't be read completely, no package is called unused at all.
"console.log slows down your release build." Maybe it does. But a Babel plugin or a development guard you didn't mention may strip it, and nothing was measured. Performance findings now say what was seen in the source and leave out speed or size gains nobody measured.
"Whole-library lodash import adds hundreds of KB." Same problem. Your bundler may already handle it. The finding now asks you to look at the release bundle before changing anything.

A tool that runs on someone else's code should be modest about what it knows. A false "remove it" costs more than a missed opportunity.

A bug I found while writing this

Rescanning the 871 apps for this post, 3 of them failed outright. Since 0.1.64, NativeKeel refused to scan a project if any package.json dependency name wasn't a valid package name. That check exists for a good reason: package names end up in file paths and commands, so a hostile name must not get there. But the 3 failures were ordinary: a typo ("@types/": "react-native-async-storage/async-storage") and workspace aliases like "@global-theme": "workspace:*".

0.1.69 skips such entries with a warning instead of refusing the scan. They still never reach a path, a command or a registry request.

Other things that are new since the first post

npx nativekeel security: only the data theft, account access and code execution risks, with the attacker's prerequisites and a verification step for each.
Native Android checks that follow incoming Intent data into WebViews, SQL and file paths, and archive entries into file writes.
A warning before you run a project that contains planted malware (a VS Code task that runs when you open the folder, code hidden after a long run of spaces in babel.config.js, JavaScript disguised as a font). The scan found it in 4 of the 871 repositories.
npx nativekeel explain "<error>": what a build, launch or store error means and where your project is affected.
npx nativekeel verify: after an upgrade, what got fixed and what is new compared with the last commit.
An MCP server, plus plugins for Claude Code and Codex, so an AI assistant can run the same checks.

Try it

npx nativekeel improve            # plain text in the terminal
npx nativekeel improve --out IMPROVE.md
npx nativekeel improve --json

No install, no account, and your code doesn't leave your machine. If a finding is wrong for your app, I'd like to know: false alarms are what I fix first. Issues are open at github.com/AlicanAkyol/nativekeel.

Xcode 27 won't launch 93% of React Native apps: the UIScene change, and the libraries that crash after it

alican akyol — Sun, 11 Oct 2026 09:48:54 +0000

On 9 September Apple announced that from April 2027, apps uploaded to App Store Connect must be built with the iOS 27 SDK, which means Xcode 27. Built with that SDK, an app that hasn't adopted the UIKit scene life cycle doesn't start. It stops at launch with:

Application failed to launch: UIScene life cycle is required for apps built with this SDK.

Apple announced the rule in TN3187. The check depends on the SDK you build with, not the iOS version on the phone. The same app built with Xcode 26 still runs on iOS 27, so nothing breaks for your users today. It breaks on the day you move to Xcode 27.

I run a health check on several hundred open-source React Native and Expo apps (the set I use to test NativeKeel). As of 11 October 2026:

	Apps
React Native and Expo apps with an iOS target	628
Not on the scene life cycle yet	583 (93%)
Largest groups	Expo SDK 57 (117), Expo SDK 54 (111)

That number isn't a judgment on those apps. Until a few weeks ago, no React Native or Expo template used scenes at all.

Where React Native and Expo stand

React Native 0.88 is the first release whose template adopts it. SceneDelegate.swift starts React Native in the window scene, and Info.plist names it in UIApplicationSceneManifest. 0.88 is still a release candidate (rc.4 on 7 October). 0.87 and earlier have nothing in the template, so the path is to upgrade and copy both files from the Upgrade Helper.
Expo SDK 57 can opt in. It needs expo 57.0.23+ and expo-build-properties 57.0.20+:

["expo-build-properties", { "ios": { "enableSceneSupport": true } }]

Then run npx expo prebuild again.

Expo SDK 58 (in beta since 15 September) generates the scene delegate by default.
SDK 56 and earlier need an SDK upgrade first.

How do you know you've adopted it? Your Info.plist has a UIApplicationSceneManifest with scene configurations, or your app delegate implements application(_:configurationForConnecting:options:). A manifest that only sets UIApplicationSupportsMultipleScenes doesn't count.

The part that bites after you adopt it: AppDelegate has no window

In the 0.88 template the UIWindow belongs to the scene delegate. AppDelegate no longer has a window property at all.

Many iOS libraries still find the screen to present on like this:

UIViewController *root = [UIApplication sharedApplication].delegate.window.rootViewController;

On the new template that line throws:

-[AppDelegate window]: unrecognized selector sent to instance

I searched the iOS sources of popular React Native libraries for this call made without a respondsToSelector: check, and found it in 15 that are still in use. Then I built a fresh React Native 0.88.0-rc.4 app and confirmed the crash with two of them, react-native-blob-util and react-native-google-mobile-ads. Both stopped crashing after one change:

UIViewController *root = RCTPresentedViewController();   // or RCTKeyWindow().rootViewController

Both fixes are open as pull requests (react-native-blob-util#498, react-native-google-mobile-ads#911). For @react-native-firebase/messaging, which makes the call at launch, a fix was already proposed upstream (react-native-firebase#9359).

68 of the 628 apps depend on at least one of these libraries. The most common:

Library	Apps	When it crashes
react-native-blob-util	17	presenting the open-in / options menu
@react-native-firebase/messaging	17	at launch
react-native-google-mobile-ads	11	showing banners, the consent form or the ad inspector
react-native-date-picker	9	opening the modal picker
react-native-image-crop-picker	9	opening the picker
rn-fetch-blob	7	presenting the open-in menu

Until a release ships the fix, a patch-package patch with the line above works.

The quiet one: deep links stop arriving

With scenes, UIKit hands opened URLs and universal links to the scene delegate. application(_:open:options:) and application(_:continue:restorationHandler:) in AppDelegate aren't called anymore. If your scene delegate doesn't forward them to RCTLinkingManager, nothing crashes. Linking just never fires.

I found this in a wallet app that had already moved to scenes: its zcash: payment links stopped reaching JavaScript, both when the app was running and when the link launched it, because launchOptions was nil and the URL only arrived in the scene's connectionOptions (zingo-mobile#1595). If your app handles deep links, test them after the move: with the app running, and with the app closed.

A checklist

Check whether you've adopted scenes (the Info.plist test above).
Expo: SDK 57 with enableSceneSupport, or SDK 58. Bare React Native: plan the 0.88 upgrade.
List your dependencies against the libraries above and update or patch them before you build with Xcode 27.
Forward URLs and user activities from the scene delegate to RCTLinkingManager.
Build with Xcode 27 well before April. Test launch, every screen that presents a picker, menu or ad, and deep links from a cold start.

Check your app in one command

npx nativekeel

It reports whether the app has adopted the scene life cycle, which of your installed libraries read the window from the app delegate, and whether URL handlers are still only in AppDelegate. It runs locally, without an account, and doesn't upload your code. If you hit the crash already:

npx nativekeel explain "-[AppDelegate window]: unrecognized selector"

If you upgrade with an AI agent, the same checks are available over MCP, and there's a Claude Code plugin (claude plugin marketplace add AlicanAkyol/nativekeel), so the agent checks this before it starts changing versions. A longer reference with the sources is at nativekeel.com/fix/uiscene-life-cycle-required-xcode-27.

If you maintain one of the libraries above and want a hand with the fix, I'm happy to send a PR.

ImageBackground and SafeAreaView are deprecated: 183 of 653 React Native apps still use them

alican akyol — Thu, 08 Oct 2026 06:37:32 +0000

React Native 0.87 deprecated ImageBackground, DrawerLayoutAndroid and UTFSequence. SafeAreaView was deprecated earlier, in 0.81. All four still work. They log a warning, and React Native's code says they "will be removed in a future release". After that, importing them from 'react-native' gives you undefined, and every screen that renders one crashes.

I run a health check on 653 open-source React Native and Expo apps (the set I use to test NativeKeel). Here is how many import these from 'react-native':

API	Apps	Files
`SafeAreaView`	123	423
`ImageBackground`	85	203
`DrawerLayoutAndroid`	1	1
`UTFSequence`	0	0

That is 183 of 653 apps (28%). Among the 358 apps already on React Native 0.76 or newer, it is 87 (24%), so this is not just old code.

Both fixes are small. Here they are.

SafeAreaView: it never did anything on Android

The core SafeAreaView "is currently only applicable to iOS devices" (React Native docs). On Android it is a plain View.

That used to be fine, because Android drew your app below the status bar. It no longer is. Apps that target Android 15 (API level 35) are edge-to-edge by default: the status bar and navigation bar are transparent, and your content draws behind them unless you apply insets. Google Play now requires new apps and updates to target API level 36, so every app that ships an update runs edge-to-edge on Android 15 and newer devices.

So the core SafeAreaView is not only deprecated: on current Android it lets your header slide under the status bar.

The replacement is react-native-safe-area-context, which handles both platforms:

npx expo install react-native-safe-area-context   # Expo
npm install react-native-safe-area-context        # bare React Native

Wrap the root of your app once. Expo Router already does this for you.

import { SafeAreaProvider } from 'react-native-safe-area-context';

export default function App() {
  return (
    <SafeAreaProvider>
      <RootNavigator />
    </SafeAreaProvider>
  );
}

Then change the import on each screen:

- import { SafeAreaView, View, Text } from 'react-native';
+ import { View, Text } from 'react-native';
+ import { SafeAreaView } from 'react-native-safe-area-context';

It takes an edges prop when you only want some of the insets, for example edges={['top']} on a screen that has a bottom tab bar. For a custom header, useSafeAreaInsets() gives you the numbers.

One detail from the scan: 52 apps already use react-native-safe-area-context somewhere and still import the core SafeAreaView on other screens. Those screens behave differently on Android. Search for both imports.

ImageBackground: five lines of your own

React Native's docs now say: "Use a View with an absolutely positioned Image instead." That is what ImageBackground always was inside. A drop-in component:

import type { ReactNode } from 'react';
import { Image, StyleSheet, View, type ImageProps, type ImageStyle, type StyleProp, type ViewStyle } from 'react-native';

type Props = Omit<ImageProps, 'style'> & { style?: StyleProp<ViewStyle>; imageStyle?: StyleProp<ImageStyle>; children?: ReactNode };

export function Background({ style, imageStyle, children, resizeMode = 'cover', ...image }: Props) {
  return (
    <View style={style}>
      <Image {...image} resizeMode={resizeMode} style={[StyleSheet.absoluteFill, imageStyle]} />
      {children}
    </View>
  );
}

Then replace <ImageBackground with <Background. If you used borderRadius on the ImageBackground, add overflow: 'hidden' to the outer style so the image is clipped too. If you already use expo-image, the same pattern works with its Image and contentFit="cover".

DrawerLayoutAndroid and UTFSequence

DrawerLayoutAndroid → react-native-drawer-layout, which also works on iOS.
UTFSequence → write the Unicode escape directly, e.g. ''.

Finding them in your app

A grep for the names will find most of them, but it misses imports split across lines and finds the safe-area-context version too. NativeKeel lists each one with its file and line, and adds the fix to the upgrade plan:

npx nativekeel

It runs locally (your code is not uploaded), has no dependencies, and is open source. If it reports something wrong for your app, I would like to hear about it: https://github.com/AlicanAkyol/nativekeel

Numbers are from a scan of 653 open-source React Native and Expo apps on GitHub (libraries excluded), October 2026. From an earlier scan: We scanned 470 open-source React Native apps. Here is what breaks them.

We scanned 470 open-source React Native apps. Here is what breaks them.

alican akyol — Tue, 06 Oct 2026 19:14:13 +0000

I build a free CLI, npx nativekeel, that checks React Native and Expo apps for the problems that turn a routine upgrade into a three-week project. To keep its false alarms down, I run it on every open-source React Native app I can find. The test set is now 470 apps, from abandoned 2019 demos to large production apps like wallets, chat clients and note-taking apps.

Old apps fail in boring, expected ways: unsupported versions, the New Architecture off, Google Play's target SDK missed. So the numbers below are for the 194 apps that are already on React Native 0.76 or newer. These are apps whose developers keep them up to date, and they still have these problems.

What we found in up-to-date apps

Problem	Share of up-to-date apps
A dependency with a known high or critical vulnerability in the exact version shipped	21%
Still on React Native 0.76, which is not ready for 16 KB memory pages (Google Play requires this since Nov 2025 for apps targeting Android 15+; 0.77 fixes it)	16%
The template URL scheme `myapp://` still in place	14%
30+ `console.log` calls shipped in the release build	13%
Whole-library `lodash` or `moment` imports	12%
Images over 500 KB required by the app	9%
A secret committed to the repo or compiled into the bundle (cloud API keys, release signing passwords, tokens in `eas.json`)	5%

Across all 470 apps, including the old ones: 58% still have the New Architecture off, which means they cannot go past React Native 0.81. 28% target an Android SDK that Google Play no longer accepts for updates.

Four findings worth checking in your own app today

1. Expo config is not a safe place for secrets. Anything in app.json → extra, and every EXPO_PUBLIC_ variable, ships inside the app and can be read by anyone who downloads it. And eas.json is committed with your code: three apps had a Sentry auth token in its build env, which can read and change the whole Sentry organisation. Public SDK keys (RevenueCat, Firebase web config) are fine. Server keys belong in EAS secrets (eas env:create).

2. myapp:// is shared with every other app that kept it. The Expo template sets "scheme": "myapp". If you sign in with expo-auth-session, Clerk or AppAuth, the OAuth redirect goes to myapp://, and on Android any other installed app with the same scheme can show up to receive it. Use a scheme unique to your app.

3. Unverified App Links open in the browser. An https://your.domain/... intent filter without android:autoVerify="true" (and a matching assetlinks.json) opens in the browser on Android 12+, not in your app. On older Android, any app can register the same link. This matters most for login, password reset and invite links.

4. Passwords travel further than you think. The leak that surprised us most was not a hacked server. It was a password that ended up in a crash report or analytics event after passing through a couple of variables (const info = email + ':' + password; track('signup_failed', { info })). Searching for password next to track( does not find it; you have to follow the variable.

What we got wrong, and fixed

Scanning real apps is mostly about finding where the tool is wrong:

A wallet app installed a package from git that has the same name as an npm package with a malware advisory. Git dependencies are now never matched against npm advisories.
.DS_Store files caught in a patch-package patch are harmless. They are no longer reported as "build output that will not apply".
Android verifies every web host when any intent filter has autoVerify. Our first deep-link check missed that.

Every release lists what changed: https://nativekeel.com/changelog

Try it

npx nativekeel            # report in the terminal
npx nativekeel plan       # an ordered upgrade plan
npx nativekeel --html report.html

It runs locally. Your code never leaves your machine: the only network calls are package-name lookups and the same advisory request npm audit makes. It has zero dependencies, publishes with npm provenance, and is MIT licensed. There is also a GitHub Action that adds findings to pull requests.

These are static checks. They find the common, detectable mistakes, but they are not a penetration test. A clean report means none of these known problems, not "unhackable".

If something it reports is wrong for your app, please open an issue on GitHub. False alarms are the bugs I care about most: https://github.com/AlicanAkyol/nativekeel

DEV Community: alican akyol

Your code is clean, your libraries aren't: 29 popular React Native libraries still call APIs removed in 0.85 and 0.87

How I checked

The ones that crash: InteractionManager

The ones that break layout: absoluteFillObject

What to do

Let a tool do step 1

Your AI reverse-engineering agent reads function names, not just code

The setup everyone is now running

What I actually measured

Finding 1: a boring name hides a capability

Finding 2: the injection mostly didn't land

The fix: pick what to read from behaviour, not from names

What it costs

Finding 3: the tested config enforced no read-only authority

From finding to a thing you run

Honest limits

Try it on your stack

Google Play's API 36 extension ends Nov 1. Here's what actually changes in a React Native app

The rule

How many apps are behind?

What changes at each level you skip

Target 31: android:exported

Target 34: foreground service types

Target 35: edge-to-edge on Android 15

Target 36: Android 16

While you're in there: 16 KB pages

Check your app before you bump it

We checked 947 React Native apps against the newest version. 36% would break in their own code.

The result

What breaks most

Not every release breaks things

Being honest about what a static check can't see

Try it on your app

SonarQube says your React Native app is fine. Here's what it can't see.

Putting mobile findings into SonarQube

In GitHub Actions

What stays out of SonarQube

SonarQube-style grades for 1,040 open-source React Native apps: 17 get straight A's

Store: 931 apps at D or E

Upgrade: 418 apps at E

Security: 69 apps at E

One app or forty

A quality gate in pull requests

Try it

'RCTBridge.h' file not found: I compiled every React Native 0.87 header to see which imports break

The experiment

Which libraries hit it

What to do

Finding it before the upgrade

3,968 buttons a screen reader can't name: accessibility in 871 open-source React Native apps

1. Icon-only buttons with no name (282 apps, 3,968 buttons)

2. Buttons too small to hit (209 apps)

3. Light grey on white (188 apps)

4. Text fields with no name (119 apps)

The React 19 trap: Text.defaultProps stops working

What static checks can't tell you

Try it

What should a React Native app fix first? I asked 871 open-source apps

What it looks like

What comes first in 871 apps

The security part

What I stopped claiming

A bug I found while writing this

Other things that are new since the first post

Try it

Xcode 27 won't launch 93% of React Native apps: the UIScene change, and the libraries that crash after it

Where React Native and Expo stand

The part that bites after you adopt it: AppDelegate has no window

The quiet one: deep links stop arriving

A checklist

Check your app in one command

ImageBackground and SafeAreaView are deprecated: 183 of 653 React Native apps still use them

SafeAreaView: it never did anything on Android

ImageBackground: five lines of your own

DrawerLayoutAndroid and UTFSequence

Finding them in your app

We scanned 470 open-source React Native apps. Here is what breaks them.

What we found in up-to-date apps

Four findings worth checking in your own app today

The ones that crash: `InteractionManager`

The ones that break layout: `absoluteFillObject`

Target 31: `android:exported`

The React 19 trap: `Text.defaultProps` stops working