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.

2%, according to the keepandroidopen.org poll[^1]

[^1] https://techhub.social/@keepandroidopen/116251892296272830

[1] https://swiftpackageindex.com/search?query=platform%3Aandroi...

FWIW, there is an active discussion on this very topic: https://forums.swift.org/t/proposal-compression-library/8541...

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".

[^1]: https://support.google.com/android/answer/12623953

[^2]: https://android.googlesource.com/platform/prebuilts/fullsdk/...

There is a lot of opposition to this effort (e.g., keepandroidopen.org, which I organize) along with widespread distrust of the claimed motives for the program. And yet there is indeed a problem with the proliferation of malware in some regions (Southeast Asia being most frequently cited in reporting).

Recent advances like "Restricted Settings" in Android 14 and "Enhanced Confirmation Mode" in Android 15 have enacted technical barriers that address many of the most common scam/phishing/malware tactics. What additional technical measures could be implemented that would help protect vulnerable Android users against being victimized? Is a program of increasing awareness about personal security a viable solution? Or is the only solution to lock down the Android platform to require developer registration and verification before an app can be distributed?

Comments URL: https://news.ycombinator.com/item?id=47019921

Points: 5

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=46914953

Points: 1

# Comments: 0

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.

> 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.

[1] https://github.com/flutter/flutter/issues/170310

For framework/library development, you can of course build and test separately for each platform.

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.

[1]: https://skip.dev/blog/skip-and-kotlin-multiplatform/

[2]: https://talkingkotlin.com/going-from-swift-to-kotlin-with-sk...

[3]: https://skip.dev/docs/modes/

[4]: https://www.swift.org/android-workgroup/

[5]: https://www.youtube.com/watch?v=EIGl6GOo210

You can see a sample snippet at https://skip.dev/docs/components/accessibility/

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.

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.)

Thanks for pointing out that the /skip repo itself doesn't have a license. We'll fix that asap!

Users will need to `brew install myorg/mytap/appname` instead of just `brew install appname`, but I think that's the only real option at this point.

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.