How FlyTrap analyzes apps

1. What we analyze

For each app we examine the distributed application package, the same binary a user installs. On Android that is the APK or app bundle; on iOS it is the app package. We currently track 1557 apps, 116 SDKs from 88 vendors across 37 categories, and 9 build frameworks.

2. How detection works

Detection combines two passes. Static analysis reads the binary without running it: compiled classes and symbols, bundled native libraries, asset and configuration files, and the application manifest. Runtime inspection launches the app in an instrumented environment and observes what it loads and initializes in practice. Static analysis is broad; runtime analysis confirms what is really active. Where they agree, confidence is high.

SDK fingerprinting

Each SDK has a fingerprint: characteristic package names, class names, embedded library names, and resource markers. We match those fingerprints across native (Java, Kotlin, Swift, Objective-C), React Native, and Flutter builds. An SDK is only listed when its fingerprint is found. We do not infer an SDK from the presence of a related one, and we never require source code or cooperation from the developer.

Framework detection

The build framework (React Native, Flutter, native iOS or Android, Unity, Capacitor, Kotlin Multiplatform, and others) is identified from runtime markers and packaging signatures unique to each toolchain. Each app carries a detection confidence of low, medium, or high based on how many independent signals agree. That confidence is shown on the app page.

Permissions

Permissions are read directly from the Android manifest and the iOS Info.plist usage descriptions. We label each one by the platform's own protection level: standard permissions are routine, while sensitive or restricted permissions reach private data or hardware such as location, camera, microphone, contacts, and background activity. We report the permissions an app declares; declaring a permission is not the same as misusing it.

3. How the reports are computed

Signature SDKs

Category and framework reports do not just list the most common SDKs, because almost everything bundles the same handful of staples. Instead we rank by lift: how much more often an SDK appears in a group than in the rest of the catalog. An SDK is called a signature SDK only when it appears in at least 2 apps in the group and is at least 1.5x more likely there than elsewhere. The lift uses smoothed proportions so a single app cannot create a misleading spike. Categories need 4 apps and frameworks need 1 apps before they earn a report.

Rankings

Each ranking orders the catalog by one measurable trait, such as the number of SDKs an app bundles or permissions it requests. Rankings list the top 50 apps, and each ranking page documents its exact formula. No editorializing, no weighting we do not disclose.

Developer hubs

Developer hubs group apps by their store developer name, merging punctuation variants of the same studio. A developer needs at least 2 analyzed apps before a hub is generated, so the aggregate stats stay meaningful.

4. Freshness

The catalog is rebuilt on every deploy from the latest analysis runs, so SDK lists, permissions, and rankings reflect the most recent version of each app we have processed. App pages show the date each app was last analyzed, and report pages show the most recent analysis date across their set.

5. Limitations

• We report the version we analyzed. A newer release may add or remove SDKs and permissions before we re-process it.
• Detection identifies what an app contains, not how it behaves. A permission or analytics SDK being present does not prove how the data is used.
• Fingerprints can lag brand-new or heavily obfuscated SDKs. A missing SDK means we did not detect it, not that it is definitely absent.
• FlyTrap does not issue safety or trust verdicts. We give you the facts so you can decide.

6. Corrections

If you maintain an app or SDK and something here looks wrong, we want to fix it. Email [email protected] with the page and the detail in question and we will review it against the next analysis run.