Most AppSec leads will recognize this meeting. A release is two days out. The source code scanner is green. Then someone asks a question the scanner was never built to answer: Is the build going to the App Store the same thing we scanned?

That question is the real line between source code analysis and binary code analysis. It isn't an old tool versus a new tool, or a developer tool versus a security tool. Source code analysis answers: did we write this safely? Binary code analysis answers: did we ship safely?

Both are fair questions. They are not the same question. In mobile, the distance between them is wider than most teams assume, because the code you write goes through compilers, bundlers, SDKs, and store packaging before it reaches a phone.

This piece is for the person who has to pick an approach, or defend one to a CISO. We'll cover how each works, where source access quietly breaks inside large companies, where binary analysis has real limits, and what to ask a vendor before you sign.

How source code analysis and binary analysis work,

end to end

Source code analysis reads what your developers write: Kotlin, Java, Swift, Objective-C, Dart, JavaScript. The scanner parses the code into a model of how data and control move through it, then runs rules over that model. User input reaching a query, a hard-coded key, a weak crypto call. Findings come back with a file and a line number, so a developer can fix them in the same pull request.

To run it, you need the repo, a scanner that supports every language in it, and usually the build setup. It runs early, often on every commit. That is its strength.

Binary code analysis starts from the compiled package: the APK or AAB for Android, the IPA for iOS. The analyzer unpacks it, decompiles or disassembles the code, reads the manifest or Info.plist, and catalogs every library and SDK inside. Then it runs its checks against what is actually there. Findings map to this build, this version, not to a branch.

To run it, you need the build file. No repo access, no language plugins, no build configuration.

So the two approaches read two different objects. The specific things that change between them (third-party SDKs, build flags, obfuscation) are covered in our comparison with code-centric SAST tools. This post is about the decision that sits above that list.

Source vs binary analysis · what each one reads

Source analysis skips the build entirely. Binary analysis reads its output, including the SDKs that never appear in your repo.

The source code you assume you have

Source code analysis works best when one team owns the repo, the languages, and the pipeline. Inside a large company, that is often not the case for the mobile app. The security team's access to source quietly depends on contracts, reorgs, and other people's goodwill.

A few patterns come up again and again:

• The app is built by an agency. In a 2021 Verimatrix survey of 150 financial-services security professionals, respondents said they outsourced mobile app development half the time and bought a white-label app 19% of the time (Business Wire). The repo lives with the vendor. What the security team reliably receives is a build to approve.
• The app came with an acquisition. The people who wrote it have moved on. The build steps live in one engineer's head, or nowhere.
• You ship code you didn't write. Payment, analytics, ads, and identity SDKs arrive compiled. A white-labelled app arrives whole. There is no source to scan, only a package.
• One app, five languages. Native Kotlin and Swift, a cross-platform layer, a C or C++ library underneath. One source scanner rarely covers all of it well, so some code goes unscanned without anyone deciding it should be.
• The code is being written faster than it is read. In Sonar's 2026 survey of more than 1,100 developers, respondents said 42% of the code they commit is AI-generated or AI-assisted, and only 48% always verify it before committing (Sonar). Source scanning still helps, but the build that leaves the pipeline is the one stable thing every change passes through.

None of this makes source scanning wrong. It means a program built on source alone has gaps that do not show up on the dashboard. The scanner reports on the code it was given, and nothing tells you what it wasn't given.

Regulators are asking about the shipped product too. Across payments, capital markets, EU product law and medical devices, the ask is converging on one thing: an inventory of every component in the software you release.

An inventory built from the shipped package describes what is actually in the product. An inventory built from your repo describes your intentions.

Cross-platform apps: the code you scan is not the code that runs

This is where the gap stops being theoretical. Two widely used cross-platform frameworks transform your source at build time into something a source scanner never sees.

• Flutter. Release builds compile Dart ahead of time (AOT) into native machine code. On iOS, App.framework holds an AOT snapshot of the app's Dart code (Flutter blog).
  On Android, it ships as a native library, libapp.so.
• React Native. Hermes has been the default JavaScript engine since React Native 0.70, and a release build compiles your JavaScript to Hermes bytecode at build time (React Native blog, React Native docs).

Cross-platform builds · source vs what runs

In both cases, the repo holds Dart or JavaScript, and the phone runs native code or bytecode. A rule that passed on the source tells you the source was clean. It says nothing about what the compiler, the bundler, or a plugin added on the way. If your mobile estate leans cross-platform, binary analysis is no longer a second opinion. It is the only view of the thing that runs.

The practical test for a vendor: ask them to analyze a release Flutter or React Native build, and show you findings that point into the compiled output, not just the manifest.

Where binary analysis falls short

We build binary-first tooling, so it would be easy to stop here. We won't, because a security lead who buys half the picture loses developers' trust by month two.

• No line number by default. A binary finding points to a class or method in decompiled code. Getting from there to the developer's file takes symbol files or a good mapping layer. Without that, fixes slow down.
• Obfuscation cuts both ways. Strong obfuscation is doing its job when it makes an app hard to read. It also makes static binary analysis shallower. Expect the vendor to tell you how depth changes on an obfuscated build.
• It needs a build. Binary static analysis runs once something compiles. If you want feedback in the editor on every keystroke, that is a source tool's job.
• It cannot see the server. Much mobile risk sits in the APIs the app calls. A package scan sees the endpoints, not how the backend handles them. That needs API and dynamic testing.
• Static is not proof. A pattern in the binary is a candidate, not an exploit. Without dynamic testing on a real device and some triage, you hand developers a long list, and they stop reading it.

Our position: let the binary be the source of truth for release decisions, because it is the thing that ships. Use source scanning where you own the code and want issues caught earlier. And judge any vendor, ours included, on how much of the list is real, reachable, and ready to fix.

How to decide: start from your situation, not the tool

The right lead approach depends on who owns the code and who asks you for proof.

Decision 2x2 · repo coverage vs audit proof

Find your app on the grid: the further left and higher it sits, the more your release decision should rest on the binary.

Eight questions to ask any vendor before you sign

1. Can you scan an APK, AAB, and IPA with no repo access? How long does one scan take?
2. Show me findings on a release Flutter build and a React Native build.
3. How does a finding map back to our source: symbol files, mapping files, or not at all?
4. What happens to depth on an obfuscated build?
5. Do you list every compiled SDK and library in an SBOM for each version?
6. How do you separate exploitable findings from pattern matches? Do you test on real devices?
7. Can the scan act as a pass/fail gate in our CI/CD pipeline?
8. Do you test the APIs the app calls, or only the package?
   
   

Vendor scorecard · 8 questions, scored by demo.

Where Appknox fits

Appknox assesses the build you ship. Upload an APK, AAB, or IPA, and the platform runs binary SAST, dynamic testing on real devices, and API testing, then builds a binary-based SBOM for that version. Triage separates real, reachable risk from noise. No repo access and no per-language setup.

• Cross-platform builds. Analysis runs on the compiled binary and doesn't depend on framework-specific constructs, so a Flutter or a React Native release build is assessed like any other app (How we test Flutter apps).
• Obfuscated builds. Detection doesn't rely on readable function names or symbols, so obfuscation has limited impact on what gets found.
• Speed. The static scan typically finishes in 60 minutes.

Already running a source scanner? Keep it. Put the binary at the release gate and see what the package holds that the repo didn't show.