Xamarin & .NET MAUI Decompiler Online

Why a Xamarin APK Looks Empty

Open a Xamarin or .NET MAUI app in an ordinary APK decompiler and the result is disappointing: a couple of generated activity classes, a MonoPackageManager, some binding stubs, and nothing that resembles the app. That is not a decompilation failure. A Xamarin app is written in C#, and its Dalvik bytecode exists only to load the .NET runtime and hand control to managed code.

The actual program is stored somewhere a Java decompiler never looks. Older builds put individual .dll files in the APK's assemblies/ folder. Everything since then merges them into a single AssemblyStore — one binary container holding every assembly the app ships, each one usually LZ4-compressed. Neither layout is DEX, so JADX and its peers walk straight past it.

What You Get Back

• xamarin/assemblies/ — every .NET assembly recovered from the APK, decompressed and written as a normal DLL you can download and open in any .NET tool.
• xamarin/sources/ — one browsable C# project per application assembly: classes, methods, XAML-generated code, constants and resource identifiers.
• xamarin/README.txt — which store format was found, which architectures were present, how many assemblies were unpacked and which were decompiled.
• sources/, resources/, smali/ — the normal Android output for the Java wrapper, manifest and resources, kept intact beside the C#.

Every Store Layout, Old and New

Xamarin has changed how it packages managed code several times, and uploads span all of it:

• Loose assemblies — assemblies/*.dll, as shipped by classic Xamarin.Android and Xamarin.Forms. Plain PE files in the oldest builds, XALZ-compressed in later ones.
• AssemblyStore v1 — assemblies/assemblies.blob with a sibling assemblies.manifest naming the entries, plus per-architecture blobs such as assemblies.arm64_v8a.blob. Used through .NET 8 MAUI.
• AssemblyStore v2 and later — lib/<abi>/libassemblies.<abi>.blob.so or lib/<abi>/libassembly-store.so. From .NET 9 the store is wrapped in a stub shared library so Android's installer keeps it uncompressed; the assembly names are embedded in the store itself, so there is no manifest any more.

All of them are detected from the APK's contents rather than from file names, and the store is unpacked in-process — no Python helper, no external unpacker.

Bare XALZ DLL Files

If you have already pulled a .dll out of a Xamarin APK by hand, you can upload it on its own. Those files usually still start with the four bytes XALZ rather than MZ, and most .NET decompilers reject them with a message about missing managed metadata. Here the compression header is recognised and undone first, so the assembly decompiles normally.

Who Uses This

Xamarin and .NET MAUI are heavily used for enterprise, banking and line-of-business Android apps, which makes these APKs a common subject of security review. Recovering the C# is the difference between reading generated glue code and reading the app's actual authentication, storage and network logic.

Limits

• Framework assemblies are extracted, not decompiled. System.*, Microsoft.*, Mono.* and Xamarin.* are stock, public and enormous. They stay in assemblies/ so references resolve, and any one of them can be uploaded separately.
• Comments and local names are gone. .NET assemblies do not store them. Type, method, property and field names survive unless the app was obfuscated.
• Ahead-of-time compiled code is native. An app published with AOT also ships libaot-*.so machine code; the managed assemblies are still recovered, but the AOT images are not C#.
• Obfuscated builds stay obfuscated. A decompiler recovers what is in the assembly, including renamed identifiers.
• Split APKs may carry no assemblies. If you upload the architecture split of an app bundle, upload the base split too.

Frequently Asked Questions