SparkCat is back. Kaspersky researchers published findings today confirming a new variant of the OCR-based crypto-stealing trojan has appeared in apps on both the App Store and Google Play. Same playbook as the 2025 campaign: apps that look completely legitimate — food delivery apps, enterprise messengers — quietly scanning users' photo galleries for cryptocurrency wallet recovery phrases using on-device OCR, then exfiltrating them to attacker-controlled servers.
Apple and Google both removed the offending apps. And for the typical "here's the security news" coverage, that's where the story ends.
But if you're an indie developer, the more interesting question is: how did it get through in the first place?
review caught it eventually. that's not the same as review prevented it.#
App review is reactive. Both Apple's and Google's review processes are reasonably good at catching known malware signatures and obvious policy violations. They're much weaker at catching malicious behavior embedded in SDK dependencies — especially when that behavior is conditional, triggered only in specific scenarios or after a delay.
SparkCat's iOS variant requested photo gallery access through what appeared to be standard user-facing features. The OCR scanning happened in a legitimate-looking SDK module. From a static analysis standpoint, the app looked clean. The malicious behavior emerged at runtime, in a context the review team likely never reached.
This is the supply chain attack pattern. It's the same reason the mobile security community has been raising alarms about third-party SDKs for years. Your app might be completely trustworthy. The analytics SDK you integrated two years ago might not be.
what this means for developers who aren't shipping crypto-stealing malware#
You're probably not shipping malware. But this story should still make you think about what's inside your app.
Every SDK you integrate is a surface area. If that SDK is compromised — by a malicious actor, a rogue employee at the SDK company, or even a poorly secured package registry — your users bear the consequences and your app bears the reputational and regulatory fallout.
A few things worth doing after this news:
Audit what's actually in your build. Do you know every SDK and library bundled in your current release? Many developers don't have a clear inventory. Tools like Xcode's dependency graph and Gradle's dependencies task can show you the full tree. Third-party tools like AppShield, Snyk, or NowSecure can flag SDKs with known vulnerabilities or suspicious behavior patterns.
Lock your dependency versions. Floating versions (e.g., ~> 2.3 in a Podfile) let SDK vendors push updates to your users without your review. Pin specific versions and review changelogs before bumping them.
Check SDK privacy manifests before you trust them. Apple requires privacy manifests for all SDKs that use sensitive APIs. If an SDK vendor doesn't have an up-to-date privacy manifest, that's a yellow flag — both for compliance and for due diligence.
Consider whether you need the SDK at all. Many integrations accumulate over time without periodic review. If you're still including an analytics SDK you stopped reading dashboards from in 2024, that's attack surface you can eliminate entirely.
the submission problem#
Here's the part that's particularly rough for indie developers: even if you're doing everything right, your app submission can be held up because of concerns triggered by an SDK you included in good faith.
This is increasingly common with compliance tooling. Privacy manifest issues, ad network SDK flagging, and supply chain concerns can all create delays or rejections even when the developer has no malicious intent. Apple's review process sometimes flags apps because a bundled SDK shares characteristics with known problematic ones — the review team doesn't always know (or communicate) whether the concern is the SDK or your specific usage of it.
what apple and google should do (but probably won't, fast enough)#
The real fix here is better SDK-level transparency and automated supply chain verification baked into the submission pipeline. Both platforms have the leverage to require SDK vendors to register builds with cryptographic hashes, making it trivially detectable when an SDK silently updates its behavior.
That work is happening slowly. Apple's privacy manifests are a step in this direction. Google's Play SDK Console is another. But neither currently prevents the kind of runtime-conditional behavior SparkCat used.
Until then, the defense is developer vigilance. Your users are trusting that everything inside your app binary was put there with their interests in mind. That trust extends to your dependencies — whether or not you put them there yourself.
Review what you're shipping. Not just your code.