REA’s target list shows available analysis workflows, not the odds of producing a working copy.
Can AI Copy an App? Top 10 App Types
A browser gets the website’s front end, but none of its unseen server logic—and even code that recompiles can still behave differently.
- No. 1: Android APKs
- 10 places
01Final list
The leading AIs each built their own list of ten independently. Here is one result that is easy to check: every place has a reason, a source, and the list of AIs that included it.
Order: from most to least AI agreement.
A bright badge means this AI put the entry on its list. A dim badge means it did not.
- 1
Android APKs
APK analysis can expose classes and methods, but OWASP lists anti-static and anti-dynamic controls that can raise the effort.
Included it: Gemini, Claude, ChatGPT, Grok, Qwen. Did not include: Meta.In their lists: Gemini: 4 · Claude: 4 · ChatGPT: 5 · Grok: 4 · Qwen: 4
What each AI noted 5
- Geminiplace 4
DEX bytecode decompiles back to structured Java and Kotlin source with over 75% test re-execution success.
Source ↗ - Claudeplace 4
JADX turns an APK back into readable Java, and agent tooling such as DexDec already targets it. One Bluesky user is quoted as copying an app's core feature in about 40 minutes.
Source ↗ - ChatGPTplace 5
The package can expose substantial client code, but mobile resilience measures are explicitly designed to frustrate inspection.
Source ↗ - Grokplace 4
DEX decompiles cleanly via JADX; R8 obfuscation is common but AI still maps features.
Source ↗ - Qwenplace 4
Standard Java/Kotlin bytecode decompiles cleanly, but R8/ProGuard quickly change the math.
Source ↗
5 AIs put it here - 2
Website front end
The browser receives the delivered HTML, JavaScript, and assets; that makes the visible client the easiest part to reproduce.
Included it: Gemini, Claude, ChatGPT, Grok, Qwen. Did not include: Meta.In their lists: Gemini: see list · Claude: 2 · ChatGPT: 1 · Grok: 1 · Qwen: 1
What each AI noted 5
- Gemini
Named differently in its own list: open the full list.
see list - Claudeplace 2
The browser receives every line of the front end, and REA needs only Chrome. The back end never arrives.
Source ↗ - ChatGPTplace 1
When the browser receives the page’s JavaScript and assets, the copier already has the part users see.
Source ↗ - Grokplace 1
Fully readable in the browser; AI copies structure and scripts with zero decompilation.
Source ↗ - Qwenplace 1
All logic ships to the browser in plain text; no decompilation or AI repair is needed to read it.
Source ↗
5 AIs put it here - 3
Electron and JavaScript apps
REA can inspect JavaScript and Electron artifacts without a native analysis engine, so much of the shipped client is directly readable.
Included it: Gemini, Claude, ChatGPT, Grok, Qwen. Did not include: Meta.In their lists: Gemini: 2 · Claude: 1 · ChatGPT: 3 · Grok: 2 · Qwen: 2
What each AI noted 5
- Geminiplace 2
A single unpack command extracts hundreds of thousands of lines of JavaScript and ASAR archive assets in seconds.
- Claudeplace 1
REA needs no native engine for static JavaScript analysis, so the whole app ships as readable files, and many Electron apps do their work locally.
Source ↗ - ChatGPTplace 3
A desktop wrapper does not hide its JavaScript bundle, though native add-ons add a harder boundary.
Source ↗ - Grokplace 2
ASAR-packaged JS often recovers modules and IPC without any decompiler; source maps sometimes present.
Source ↗ - Qwenplace 2
ASAR packages unzip into full project trees, exposing every UI and logic file directly to AI agents.
Source ↗
5 AIs put it here - 4
.NET apps
Managed assemblies retain metadata and CIL instructions that can be inspected statically; obfuscation and missing server logic still limit a faithful copy.
Included it: Gemini, Claude, ChatGPT, Grok, Qwen. Did not include: Meta.In their lists: Gemini: 3 · Claude: 3 · ChatGPT: 4 · Grok: 3 · Qwen: 3
What each AI noted 5
- Geminiplace 3
CIL intermediate metadata preserves variable types and method structures that let decompilers generate near-source code.
Source ↗ - Claudeplace 3
REA lists .NET as static-only with no extra engine, because IL keeps names and structure.
Source ↗ - ChatGPTplace 4
Managed assemblies retain more structure than stripped native code, but reconstruction still depends on what the program actually does.
Source ↗ - Grokplace 3
CIL and metadata yield near-source quality statically; REA inspects without extra engines.
Source ↗ - Qwenplace 3
Intermediate Language (IL) decompiles back to near-original C# with almost no loss of fidelity.
Source ↗
5 AIs put it here - 5
Native desktop apps
Native binaries need a separate analysis engine, and benchmark results vary: passing supplied tests still left 4.9% overall divergence on another input corpus.
Included it: Gemini, Claude, ChatGPT, Grok, Qwen. Did not include: Meta.In their lists: Gemini: 7 · Claude: 7 · ChatGPT: 7 · Grok: 5 · Qwen: 6
What each AI noted 5
- Geminiplace 7
Symbolic function headers guide AI decompilers to recover clean C syntax, reaching 40% re-execution rates.
Source ↗ - Claudeplace 7
This is the only REA target that needs Hopper, Ghidra or IDA, and the best published re-execution rates are about 69% on small test functions, falling to about 21% in one benchmark.
Source ↗ - ChatGPTplace 7
Even REA’s documented native route calls for a separate tool such as Ghidra, IDA, or Hopper.
Source ↗ - Grokplace 5
Pseudocode from Ghidra/Hopper works well when symbols remain; recompilation rates lag high-level languages.
Source ↗ - Qwenplace 6
AI needs Ghidra or Hopper to read them, and only recovers less than half of the original logic cleanly.
Source ↗
5 AIs put it here - 6
Server-backed apps
A copied client cannot reveal private server code, data, or rules; the result may reproduce screens without the features users need.
Included it: Gemini, Claude, ChatGPT, Grok, Qwen. Did not include: Meta.In their lists: Gemini: 10 · Claude: 9 · ChatGPT: 10 · Grok: 9 · Qwen: 10
What each AI noted 5
- Geminiplace 10
Over 90% of business logic, database transactions, and authorization rules never leave remote cloud hardware.
- Claudeplace 9
An agent can clone the client, but the recommendations, accounts, data and pricing logic stay on servers it never sees.
Source ↗ - ChatGPTplace 10
A convincing screen-level imitation may still fail at the feature users came for when the original service is gone.
Source ↗ - Grokplace 9
Client decompiles easily, but useful behavior (auth, business rules, data) lives on unseen servers.
Source ↗ - Qwenplace 10
The UI is fully visible, but 99% of the useful business logic lives on servers the copier never sees.
Source ↗
5 AIs put it here - 7
Protected mobile apps
Obfuscation and anti-debugging raise analysis costs, but OWASP presents them as added protection, not a guarantee that reverse engineering is prevented.
Included it: Claude, Grok, Qwen. Did not include: Gemini, Meta, ChatGPT.In their lists: Claude: 6 · Grok: 7 · Qwen: 8
What each AI noted 3
- Claudeplace 6
The same APK pipeline applies, but MASVS-RESILIENCE controls (anti-tamper, anti-debug, control-flow obfuscation) add cost, not impossibility.
Source ↗ - Grokplace 7
Harder than Android: no clean DEX equivalent; symbol stripping and App Store protections raise cost.
Source ↗ - Qwenplace 8
Control flow flattening and string encryption turn clean code into a maze that crashes LLM decompilers.
Source ↗
3 AIs put it here - 8
Unity IL2CPP and native games
IL2CPP moves managed code into native binaries, raising analysis effort; a successful code reconstruction still would not reproduce all game assets or services.
Included it: Claude, Grok. Did not include: Gemini, Meta, ChatGPT, Qwen.In their lists: Claude: 8 · Grok: 6
What each AI noted 2
2 AIs put it here - 9
Unity games using Mono
When game logic ships as managed code, it can be more readable than native game code; assets and licensed content remain separate limits.
Included it: Gemini, Claude. Did not include: Meta, ChatGPT, Grok, Qwen.In their lists: Gemini: see list · Claude: 5
2 AIs put it here - 10
WebAssembly apps
The browser can run the module, but compiled code is less transparent than ordinary JavaScript; no cited benchmark ranks whole WebAssembly apps.
Included it: ChatGPT. Did not include: Gemini, Claude, Meta, Grok, Qwen.In their lists: ChatGPT: 6
What each AI noted 1
- ChatGPTplace 6
The browser can run the module, but native-like compilation makes its logic less transparent than ordinary JavaScript.
Source ↗
1 AIs put it here
02Worth knowing
What the AIs noticed while building the list.
Obfuscation and anti-debugging add layers of protection, but OWASP does not describe them as an absolute barrier.
In one benchmark, decompiled candidates that passed all supplied tests still diverged on another input corpus by 4.9% overall.
Native decompilation results differ substantially across benchmarks and methods, so a single success rate would be misleading.
03Questions people ask
Can AI copy an app?
It can often recreate visible behavior and some shipped client code. Websites and Electron apps expose more client logic; server-side behavior remains out of reach from client files alone.
Source ↗Which AI can copy an app?
REA connects coding agents to analysis workflows for JavaScript/Electron, .NET, Android, websites, and native binaries. Its documentation describes coverage, not guaranteed success.
Source ↗How can I protect an app from reverse engineering?
OWASP lists obfuscation, anti-debugging, anti-tampering, and runtime protections as defense-in-depth measures. They raise effort but do not guarantee prevention.
Source ↗How can I protect an iOS app from reverse engineering?
Use layered resilience controls and keep sensitive decisions on the server where possible. OWASP describes these measures as added protection, not an absolute barrier.
Source ↗04How we counted
In plain words, no formulas.
1The question
Top 10 Kinds of Software an AI Agent Can Copy Most Easily, and What Stays Out of Reach
2Why this topic
It answers a question people keep typing, 'can AI copy an app', type by type. The answer comes from tool coverage, security standards and benchmark results together, and none of those sources ranks software types by itself.
3Where it applies
Global, by software type (websites, Electron/JavaScript, .NET, Android APK, native desktop, games, server-backed apps)
4What we looked at
- How much of the program's logic ships to the user in readable or easily decompiled form
- How strongly the type resists analysis through obfuscation, native compilation or symbol stripping
- How often decompiled code of this type runs again after AI processing
- How much of the useful behaviour lives on servers the copier never sees
- REA documentation — Lists target formats and analysis workflows; coverage does not show how often a working copy results.
- OWASP MASVS-RESILIENCE — Describes defense-in-depth controls against reverse engineering and tampering; it does not quantify how often they work.
- LLM decompilation benchmark — Tests whether decompiled programs compile and pass supplied tests; results cover benchmark programs, not whole apps.
5Who ranked
The leading AIs, each building its own list of ten independently and naming a source for every place: Gemini, Claude, Meta, ChatGPT, Grok, Qwen.
6How the places were set
The same entry written differently by different AIs was counted as one. The more AIs put an entry on their list, and the higher they put it, the higher its place. "AI agreement" shows how many of the AIs had it on their own list. Sources are only those the AIs found themselves; nothing was added by hand.
05Each AI's own list
🇺🇸 Gemini10 places · 2 notes
The same question, answered by Gemini alone. The final list above combines all the AIs.
- 1Static & Single-Page Web Applications
Delivers 100% of client execution logic directly to browser devtools with zero binary compilation barrier.
- 2Unpacked Electron & Node.js Desktop Apps
A single unpack command extracts hundreds of thousands of lines of JavaScript and ASAR archive assets in seconds.
- 3Managed .NET & C# Desktop Applications
CIL intermediate metadata preserves variable types and method structures that let decompilers generate near-source code.
Source ↗ - 4Unobfuscated Android APKs
DEX bytecode decompiles back to structured Java and Kotlin source with over 75% test re-execution success.
Source ↗ - 5Scripted Game Engine Projects (Unity / Godot)
Engine assemblies expose entire physics scripts and game loops unless compiled into specialized native IL2CPP blobs.
Source ↗ - 6Hybrid Cross-Platform Mobile Apps (React Native / Flutter)
Hermes bytecode and Dart AOT snapshots resist simple de-compilation but surrender UI layout trees and network contracts.
- 7Unstripped Native Desktop Binaries (C/C++ with Symbols)
Symbolic function headers guide AI decompilers to recover clean C syntax, reaching 40% re-execution rates.
Source ↗ - 8Stripped & Optimized Native Binaries (C/C++/Rust -O3)
Aggressive compiler inlining, loop unrolling, and vectorization cause AI re-executability to plunge under 22%.
Source ↗ - 9Commercial AAA Games with Kernel Anti-Cheat & DRM
Runtime virtualization and kernel hypervisors crash decompilation pipelines before an AI agent can read memory.
- 10Cloud-Native & Server-Backed Enterprise Software
Over 90% of business logic, database transactions, and authorization rules never leave remote cloud hardware.
What Gemini noticed
Decompiled code syntax is largely solved by modern LLMs, but Decompile-Eval reveals that semantic re-executability (running and passing unit tests) drops from 86% in managed CIL down to 11% in compiler-optimized -O3 native binaries.
The viral REA tool created by developer morluto bridges coding agents like Claude Code and Cursor to Ghidra and JADX, but its documentation explicitly warns that running automated reverse-engineering against untrusted local binaries operates without a sandbox.
🇺🇸 Claude10 places · 3 notes
The same question, answered by Claude alone. The final list above combines all the AIs.
- 1Electron and JavaScript desktop apps
REA needs no native engine for static JavaScript analysis, so the whole app ships as readable files, and many Electron apps do their work locally.
Source ↗ - 2Websites (front end)
The browser receives every line of the front end, and REA needs only Chrome. The back end never arrives.
Source ↗ - 3.NET apps and assemblies
REA lists .NET as static-only with no extra engine, because IL keeps names and structure.
Source ↗ - 4Android APKs (Java/Kotlin, unprotected)
JADX turns an APK back into readable Java, and agent tooling such as DexDec already targets it. One Bluesky user is quoted as copying an app's core feature in about 40 minutes.
Source ↗ - 5Unity games on the Mono backend
Assembly-CSharp.dll can be pulled from an APK and decompiled to near-original C# if it is not obfuscated.
Source ↗ - 6Android apps hardened with R8, packers and RASP
The same APK pipeline applies, but MASVS-RESILIENCE controls (anti-tamper, anti-debug, control-flow obfuscation) add cost, not impossibility.
Source ↗ - 7Native desktop apps (C/C++, stripped)
This is the only REA target that needs Hopper, Ghidra or IDA, and the best published re-execution rates are about 69% on small test functions, falling to about 21% in one benchmark.
Source ↗ - 8Unity IL2CPP and native games
IL2CPP moves the logic into native code and metadata, so agents face the same native-analysis wall as desktop software, plus engine assets.
Source ↗ - 9Server-backed apps and SaaS (client copy only)
An agent can clone the client, but the recommendations, accounts, data and pricing logic stay on servers it never sees.
Source ↗ - 10Heavily protected apps and games (virtualization, control-flow obfuscation, anti-debug)
Opaque predicates, instruction substitution and anti-instrumentation hit the weak spot of LLM decompilers, which already fail on 75-80% of functions even without protection (Decompile-Bench).
Source ↗
What Claude noticed
REA is mainly a bridge, not a new decompiler. Only its native-binary route needs Hopper, Ghidra or IDA. JavaScript, .NET, APK and website analysis run on lighter tools.
Published LLM decompilation scores for the same task type run from about 21% to about 69% depending on model and benchmark. Reported success is more a matter of method than of language.
OWASP says plainly that obfuscation raises cost but does not prevent reverse engineering. The lasting defence is keeping valuable logic on the server.
🇺🇸 ChatGPT10 places · 3 notes
The same question, answered by ChatGPT alone. The final list above combines all the AIs.
- 1Website frontend
When the browser receives the page’s JavaScript and assets, the copier already has the part users see.
Source ↗ - 2JavaScript app
The language often survives deployment in recognizable modules, imports, routes, and source maps.
Source ↗ - 3Electron app
A desktop wrapper does not hide its JavaScript bundle, though native add-ons add a harder boundary.
Source ↗ - 4.NET desktop app
Managed assemblies retain more structure than stripped native code, but reconstruction still depends on what the program actually does.
Source ↗ - 5Android APK
The package can expose substantial client code, but mobile resilience measures are explicitly designed to frustrate inspection.
Source ↗ - 6WebAssembly app
The browser can run the module, but native-like compilation makes its logic less transparent than ordinary JavaScript.
Source ↗ - 7Native desktop app
Even REA’s documented native route calls for a separate tool such as Ghidra, IDA, or Hopper.
Source ↗ - 8iOS app
A shipped app can be inspected, but OWASP’s mobile resilience guidance makes clear that protection is a practiced discipline, not a guarantee.
Source ↗ - 9Single-player game
A local game’s rules and assets may be present on the device, but compiled engines and native code raise the reconstruction cost.
Source ↗ - 10Server-backed app
A convincing screen-level imitation may still fail at the feature users came for when the original service is gone.
Source ↗
What ChatGPT noticed
REA’s own documentation separates target coverage from native-analysis requirements: native binaries need Hopper, Ghidra, or IDA, so “one tool handles everything” overstates what coverage means.
A decompiled program can compile and pass its supplied tests yet still diverge on additional inputs: the 2026 benchmark reports 4.9% overall divergence among such candidates.
OWASP frames mobile resilience as defense in depth. Obfuscation and anti-debugging raise cost; the guidance does not promise that reverse engineering can be prevented.
🇺🇸 Grok10 places · 3 notes
The same question, answered by Grok alone. The final list above combines all the AIs.
- 1Websites (client-side HTML/JS)
Fully readable in the browser; AI copies structure and scripts with zero decompilation.
Source ↗ - 2Electron / JavaScript desktop apps
ASAR-packaged JS often recovers modules and IPC without any decompiler; source maps sometimes present.
Source ↗ - 3.NET assemblies
CIL and metadata yield near-source quality statically; REA inspects without extra engines.
Source ↗ - 4Android APKs
DEX decompiles cleanly via JADX; R8 obfuscation is common but AI still maps features.
Source ↗ - 5Native desktop apps (with symbols)
Pseudocode from Ghidra/Hopper works well when symbols remain; recompilation rates lag high-level languages.
Source ↗ - 6Games (native, Unity IL2CPP, or engine-based)
Assets and logic recoverable, but engines, anti-cheat, and complexity keep full faithful copies rare.
Source ↗ - 7iOS apps (native Mach-O)
Harder than Android: no clean DEX equivalent; symbol stripping and App Store protections raise cost.
Source ↗ - 8Heavily obfuscated native binaries
Control-flow flattening and string encryption drop AI success sharply; re-execution often fails.
Source ↗ - 9Server-backed / thin-client apps
Client decompiles easily, but useful behavior (auth, business rules, data) lives on unseen servers.
Source ↗ - 10Pure SaaS / fully server-side systems
No meaningful client logic ships; AI can only scrape UIs or APIs, not copy the product.
Source ↗
What Grok noticed
REA itself needs no native engine for JS/Electron/.NET; binaries require Ghidra/Hopper/IDA you already own.
Server-side logic remains the strongest practical moat: a perfect client copy is often useless.
OWASP notes resilience controls (obfuscation, anti-debug) are defense-in-depth, not absolute—determined attackers with time always win.
🇨🇳 Qwen10 places · 3 notes
The same question, answered by Qwen alone. The final list above combines all the AIs.
- 1Websites (HTML/CSS/JS)
All logic ships to the browser in plain text; no decompilation or AI repair is needed to read it.
Source ↗ - 2Electron / JavaScript Apps
ASAR packages unzip into full project trees, exposing every UI and logic file directly to AI agents.
Source ↗ - 3.NET Assemblies
Intermediate Language (IL) decompiles back to near-original C# with almost no loss of fidelity.
Source ↗ - 4Android APKs (Unobfuscated)
Standard Java/Kotlin bytecode decompiles cleanly, but R8/ProGuard quickly change the math.
Source ↗ - 5Scripting Language Apps (Python/Ruby)
Bytecode or raw source files are often shipped directly in the installer package.
Source ↗ - 6Native Desktop Binaries (PE/ELF/Mach-O)
AI needs Ghidra or Hopper to read them, and only recovers less than half of the original logic cleanly.
Source ↗ - 7Games (Native / Custom Engines)
Assets and 2D logic (like 1996's DX-Ball) are easily revived, but modern 3D engine code stays opaque.
Source ↗ - 8Mobile Apps with MASVS-RESILIENCE-4
Control flow flattening and string encryption turn clean code into a maze that crashes LLM decompilers.
Source ↗ - 9Apps with RASP / Anti-Tamper (MASVS-RESILIENCE-3)
Environment detection and runtime integrity checks kill the debugger before the AI can read the memory.
Source ↗ - 10Server-Backed Apps / SaaS
The UI is fully visible, but 99% of the useful business logic lives on servers the copier never sees.
Source ↗
What Qwen noticed
Even the best AI decompilers only get about 46% of native binaries to run again perfectly without human repair.
The OWASP MASVS-RESILIENCE standard treats anti-reverse-engineering as a supplementary defense; it cannot fix broken server-side auth.
REA users have successfully revived 1990s abandonware like DX-Ball, proving old unoptimized native code is easier for AI than modern engines.