Perhaps. And yet … 98% opposition from 4K respondents? I'd be very surprised to see any other poll that tilts the other way, regardless of sampling bias.
I am part of the team running keepandroidopen.org and corralling the signatures for the open letter opposing this program. We've been trying to get Google to reverse course on this program ever since it was announced.
As it stands, Android Developer Verification (ADV) is a death sentence for F-Droid, Obtainium, and other competitors to the Google Play Store, both commercial and non-commercial. We are disappointed that they are still trying to steamroll this through in the face of overwhelming public opposition.
There are numerous reasons to object to the program, but a few of the top ones are:
1. You own your computer, and you should be the sole decision-maker for what software you can install on it.
2. "Malware" means whatever Google says it means, and their terms and conditions change daily; today malware is banking scams, tomorrow it is … ad-blocking? VPNs? Their decisions are un-reviewable and opaque, and they have obvious commercial incentives to block certain kinds of (otherwise-legal) software.
3. Centralizing global developer registrations through a US corporation makes it subject to the rules (and whims) of the current regime. Citizens of sanctioned countries or members of sanctioned entities (like the International Criminal Court) will be legally barred from registering, blocking them from creating and distributing software _anywhere_ in the world (not just the US).
4. Scenarios that Google claims ADV will protect against — such as high-pressure phone calls manipulating vulnerable users into installing scam apps — have _already_ been addressed by incremental improvements to Android security over the years, such as "Enhanced Fraud Protection" introduced in Android 13 (and expanded in Android 15). Android has incrementally improved its security features over its near 20 years of existence. There is no evidence that anything has suddenly changed to justify such a disproportionate and extreme lockdown.
5. Being required to pay Google for the privilege of uploading your government identification so that you might be permitted to contribute to the Android software ecosystem is such an abominable insult to the developers that helped build the platform. It deserves all the utter contempt that has been heaped upon it thus far, and begs regulatory scrutiny from those few countries that still have the courage to stand up to these bullies.
We emphatically recommend against developers signing up for this program or endorsing it in any way.
I am the author of the letter and the coordinator of the signatories. We aren't saying "nuh uh, everything's fine as it is." Rather, we are pointing out that Android has progressively been enhanced over the years to make it more secure and to address emerging new threat models.
For example, the "Restricted Settings"¹ feature (introduced in Android 13 and expanded in Android 14) addresses the specific scam technique of coaching someone over the phone to allow the installation of a downloaded APK. "Enhanced Confirmation Mode"², introduced in Android 15, adds furthers protection against potentially malicious apps modifying system settings. These were all designed and rolled out with specified threat models in mind, and all evidence points to them working fairly well.
For Google to suddenly abandon these iterative security improvements and unilaterally decide to lock-down Android wholesale is a jarring disconnect from their work to date. Malware has always been with us, and always will be: both inside the Play Store and outside it. Google has presented no evidence to indicate that something has suddenly changed to justify this extreme measure. That's what we mean by "Existing Measures Are Sufficient".
It really isn't. Did you see their latest time estimate (https://youtu.be/W4olXg91iX8?t=538)? Late 2026 just to get the widget sets broken out into separate packages? And only then can they start considering modernizing them and trying to mimic the latest UI?
Flutter can't even get animations to look and feel right for iOS 18 and below (read through this thread and every other HN/Reddit thread that mentions Flutter vs. native components). Do you really think they'll ever get Liquid Glass looking and feeling convincing, let alone performing acceptably?
Read over the 100+ comments in the GH issue I posted. You see actual Flutter contributors — not people who merely vibe-coded a Potemkin L.G. demo and declared victory — saying that it is effectively impossible.
See my response below on the KMP question: the comparison with CMP mostly applies to Flutter as well.
> near-native mobile apps (the difference is almost negligible)
Not as of the advent of Liquid Glass on iOS (and, to a lesser extent, Material Expressive on Android). Flutter isn't going to be implementing these new interface conventions[1], and so the UI for these apps are stuck on the last generation and are already starting to feel outdated.
Flutter's grim outlook has resulted in a surge of interest in Skip, and it was one of the drivers for us to open up the platform and catch the wave. If you love Dart, or if your apps don't need to look native (e.g., games or very bespoke interfaces), then Flutter might continue to be acceptable. But everyone else is starting to look elsewhere, especially in cases where their business depends on their apps feeling premium and native.
No, you can configure it to just build and launch for iOS or Android separately. But we do recommend iterating on both in parallel for most of the UI work, just to make sure that everything stays in sync.
For framework/library development, you can of course build and test separately for each platform.
This is indeed a dilemma, but note that copyleft licenses like GPL or MPL do give you considerably more protection than a pushover license like MIT/BSD. I wrote about this last year at https://appfair.org/blog/gpl-and-the-app-stores.
Good question. I'll try to answer as objectively as possible, despite my bias towards Skip's approach.
Kotlin Multiplatform (KMP) enables you to target different platforms with your Kotlin. In the context of mobile apps, it allows you to compile your Kotlin to a native framework for iOS, so you can reuse your business logic. On iOS, the Kotlin is running in its own little garbage-collected runtime, but it sets up a bridge to Objective-C and Swift, so the iOS developers can communicate with it from their apps (the interface of which will typically be written separately for each platform). It is neat technology, and Skip integrates with it[1]. We were on their Talking Kotlin podcast in 2024 talking about it[2].
When targeting just the shared business logic and not the UI, Skip is, in some ways, the inverse of KMP: whereas they let you share Kotlin logic between the iOS and Android app, Skip lets you share the Swift logic. Skip operates in two different modes[3]: Skip Lite and Skip Fuse. Skip Lite is the original version of Skip, and transpiles your Swift into Kotlin. Skip Fuse is a later iteration and resulted from the formation of the Swift Android workgroup[4], of which we are founding members. In both modes, you can share your Skip business logic layer between multiple apps, and this is a popular application of Skip (e.g., see this talk at NSSpain[5]).
So that's the story for shared logic. Now onto the user interface part:
While I mentioned that Skip _can_ be used just for sharing business logic, it really shines when you build your whole app with it. You write your app in conventional SwiftUI, and Skip will translate it into the equivalent Jetpack Compose (which is now Android's official recommended way to build apps). Launching your app from Xcode will bring up both your iOS app in the simulator, and the equivalent Android app in the emulator. It is designed to be a single vertically-integrated app creation solution, and enables a single team (or a single developer) to iterate on both platforms at the same time, without any of the coordination overhead of building two separate apps for the two platforms.
KMP itself doesn't have an equivalent, but it does have a sibling project "Compose Multiplatform" (CMP), which is built on top of KMP and sort of does the opposite: it lets you write your app in Kotlin and Jetpack Compose and run it on iOS. But the way that it achieves this is different from Skip's approach: it doesn't use native controls on iOS, but instead paints pixels on the screen that mimic the native iOS UI (à la Flutter). The results are predictable: an uncanny valley UI that doesn't feel _quite_ right, and that struggles to keep up with the platform conventions. Notably, like Flutter, they won't be able to support Liquid Glass in any convincing form, and so apps built with it are going to be stuck on outdated iOS UI conventions. In short: CMP is native on Android but alien on iOS, whereas Skip is native on both platforms.
That's our take on the difference between the two. In fairness to KMP, they do have some distinct advantages in terms of reach: whereas Skip is squarely focused on just mobile platforms, KMP can target desktops and the web as well. If that is a priority for you, or you already have a lot of Kotlin experience or are invested in the ecosystem, then KMP might be a good fit for your needs. But if you like Swift and SwiftUI, and are happy working with the Apple developer tools, then you should give Skip a try. It really is magic.
Yes, as I just responded there, Skip uses the native toolkits and conventions on both platforms: SwiftUI on iOS and Jetpack Compose on Android. So you automatically get the platforms' built-in accessibility support.
Yes, the unique benefit of Skip is that you are using the real native toolkits on both platforms. So you get both SwiftUI's accessibility support via VoiceOver, as well as Jetpack Compose's support via TalkBack.
As we mentioned in the post, developer tools really need to be freely obtainable in order to gain mass adoption. In that sense, it was an easy strategic decision. And we felt that the time was right, given that Skip's benefits are being thrust to the foreground in light of recent developments.
Well, you're running both the iOS development tools (Xcode, iOS Simulator), plus the Android development tools (Gradle, Android emulator, and maybe Android Studio too). These add up.
16GB might be possible, though.
(Skip itself doesn't take much memory. If you run it headlessly as a SwiftPM plugin, you wouldn't need nearly that much.)
This is a neat hack, and I don't want to diminish the effort. But I fear that any such loader apk would be marked as malware by Google and nuked by Play Protect Services.
And as others mention, using adb (or Shizuku) might also be a workaround for tech-savvy users (for the time being). We list some other potential temporary workarounds at https://keepandroidopen.org. But none of it is viable for the other 99%.
There's really no solution to the dilemma other than stopping Google from implementing it altogether. And for that, we need regulatory action — which means we need to advocate and educate consumers and lawmakers about the threat that this poses.
Why?