Back to the trend of the day: A free tool lets AI take apart any app and copy its features
Poly Rating · from the trend of the day

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. 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. 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. 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. 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. 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. 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. 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. 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
    • Claudeplace 8

      IL2CPP moves the logic into native code and metadata, so agents face the same native-analysis wall as desktop software, plus engine assets.

      Source ↗
    • Grokplace 6

      Assets and logic recoverable, but engines, anti-cheat, and complexity keep full faithful copies rare.

      Source ↗
    2 AIs put it here
  9. 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

    What each AI noted 2
    • Gemini

      Named differently in its own list: open the full list.

      see list
    • Claudeplace 5

      Assembly-CSharp.dll can be pulled from an APK and decompiled to near-original C# if it is not obfuscated.

      Source ↗
    2 AIs put it here
  10. 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.

REA’s target list shows available analysis workflows, not the odds of producing a working copy.

Noticed by:
Included it: Claude, ChatGPT. Did not include: Gemini, Meta, Grok, Qwen.
Source ↗

Obfuscation and anti-debugging add layers of protection, but OWASP does not describe them as an absolute barrier.

Noticed by:
Included it: Claude, ChatGPT, Grok. Did not include: Gemini, Meta, Qwen.
Source ↗

In one benchmark, decompiled candidates that passed all supplied tests still diverged on another input corpus by 4.9% overall.

Noticed by:
Included it: ChatGPT. Did not include: Gemini, Claude, Meta, Grok, Qwen.
Source ↗

Native decompilation results differ substantially across benchmarks and methods, so a single success rate would be misleading.

Noticed by:
Included it: Claude, Grok. Did not include: Gemini, Meta, ChatGPT, Qwen.
Source ↗

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.

  1. 1
    Static & Single-Page Web Applications

    Delivers 100% of client execution logic directly to browser devtools with zero binary compilation barrier.

  2. 2
    Unpacked Electron & Node.js Desktop Apps

    A single unpack command extracts hundreds of thousands of lines of JavaScript and ASAR archive assets in seconds.

  3. 3
    Managed .NET & C# Desktop Applications

    CIL intermediate metadata preserves variable types and method structures that let decompilers generate near-source code.

    Source ↗
  4. 4
    Unobfuscated Android APKs

    DEX bytecode decompiles back to structured Java and Kotlin source with over 75% test re-execution success.

    Source ↗
  5. 5
    Scripted Game Engine Projects (Unity / Godot)

    Engine assemblies expose entire physics scripts and game loops unless compiled into specialized native IL2CPP blobs.

    Source ↗
  6. 6
    Hybrid 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.

  7. 7
    Unstripped Native Desktop Binaries (C/C++ with Symbols)

    Symbolic function headers guide AI decompilers to recover clean C syntax, reaching 40% re-execution rates.

    Source ↗
  8. 8
    Stripped & Optimized Native Binaries (C/C++/Rust -O3)

    Aggressive compiler inlining, loop unrolling, and vectorization cause AI re-executability to plunge under 22%.

    Source ↗
  9. 9
    Commercial AAA Games with Kernel Anti-Cheat & DRM

    Runtime virtualization and kernel hypervisors crash decompilation pipelines before an AI agent can read memory.

  10. 10
    Cloud-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.

  1. 1
    Electron 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 ↗
  2. 2
    Websites (front end)

    The browser receives every line of the front end, and REA needs only Chrome. The back end never arrives.

    Source ↗
  3. 3
    .NET apps and assemblies

    REA lists .NET as static-only with no extra engine, because IL keeps names and structure.

    Source ↗
  4. 4
    Android 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 ↗
  5. 5
    Unity 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 ↗
  6. 6
    Android 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 ↗
  7. 7
    Native 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 ↗
  8. 8
    Unity 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 ↗
  9. 9
    Server-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 ↗
  10. 10
    Heavily 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.

  1. 1
    Website frontend

    When the browser receives the page’s JavaScript and assets, the copier already has the part users see.

    Source ↗
  2. 2
    JavaScript app

    The language often survives deployment in recognizable modules, imports, routes, and source maps.

    Source ↗
  3. 3
    Electron app

    A desktop wrapper does not hide its JavaScript bundle, though native add-ons add a harder boundary.

    Source ↗
  4. 4
    .NET desktop app

    Managed assemblies retain more structure than stripped native code, but reconstruction still depends on what the program actually does.

    Source ↗
  5. 5
    Android APK

    The package can expose substantial client code, but mobile resilience measures are explicitly designed to frustrate inspection.

    Source ↗
  6. 6
    WebAssembly app

    The browser can run the module, but native-like compilation makes its logic less transparent than ordinary JavaScript.

    Source ↗
  7. 7
    Native desktop app

    Even REA’s documented native route calls for a separate tool such as Ghidra, IDA, or Hopper.

    Source ↗
  8. 8
    iOS 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 ↗
  9. 9
    Single-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 ↗
  10. 10
    Server-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.

  1. 1
    Websites (client-side HTML/JS)

    Fully readable in the browser; AI copies structure and scripts with zero decompilation.

    Source ↗
  2. 2
    Electron / JavaScript desktop apps

    ASAR-packaged JS often recovers modules and IPC without any decompiler; source maps sometimes present.

    Source ↗
  3. 3
    .NET assemblies

    CIL and metadata yield near-source quality statically; REA inspects without extra engines.

    Source ↗
  4. 4
    Android APKs

    DEX decompiles cleanly via JADX; R8 obfuscation is common but AI still maps features.

    Source ↗
  5. 5
    Native desktop apps (with symbols)

    Pseudocode from Ghidra/Hopper works well when symbols remain; recompilation rates lag high-level languages.

    Source ↗
  6. 6
    Games (native, Unity IL2CPP, or engine-based)

    Assets and logic recoverable, but engines, anti-cheat, and complexity keep full faithful copies rare.

    Source ↗
  7. 7
    iOS apps (native Mach-O)

    Harder than Android: no clean DEX equivalent; symbol stripping and App Store protections raise cost.

    Source ↗
  8. 8
    Heavily obfuscated native binaries

    Control-flow flattening and string encryption drop AI success sharply; re-execution often fails.

    Source ↗
  9. 9
    Server-backed / thin-client apps

    Client decompiles easily, but useful behavior (auth, business rules, data) lives on unseen servers.

    Source ↗
  10. 10
    Pure 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.

  1. 1
    Websites (HTML/CSS/JS)

    All logic ships to the browser in plain text; no decompilation or AI repair is needed to read it.

    Source ↗
  2. 2
    Electron / JavaScript Apps

    ASAR packages unzip into full project trees, exposing every UI and logic file directly to AI agents.

    Source ↗
  3. 3
    .NET Assemblies

    Intermediate Language (IL) decompiles back to near-original C# with almost no loss of fidelity.

    Source ↗
  4. 4
    Android APKs (Unobfuscated)

    Standard Java/Kotlin bytecode decompiles cleanly, but R8/ProGuard quickly change the math.

    Source ↗
  5. 5
    Scripting Language Apps (Python/Ruby)

    Bytecode or raw source files are often shipped directly in the installer package.

    Source ↗
  6. 6
    Native 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 ↗
  7. 7
    Games (Native / Custom Engines)

    Assets and 2D logic (like 1996's DX-Ball) are easily revived, but modern 3D engine code stays opaque.

    Source ↗
  8. 8
    Mobile Apps with MASVS-RESILIENCE-4

    Control flow flattening and string encryption turn clean code into a maze that crashes LLM decompilers.

    Source ↗
  9. 9
    Apps with RASP / Anti-Tamper (MASVS-RESILIENCE-3)

    Environment detection and runtime integrity checks kill the debugger before the AI can read the memory.

    Source ↗
  10. 10
    Server-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.