marcprux

> I’m not convinced by leptos’s html style view macro. It’s cute, but you lose out on autocomplete and other IDE integration.

Yes, that was exactly my thinking. In addition to more natural IDE support, relying on plain-old-Rust and not having a macro-processed DSL for the view specification makes it more comprehensible for LLM-driven development and testing (since the agents will likely know how to write correct Rust, but struggle with a bespoke DSL that it hasn't been trained on).

> Leptos signals are Send. You can write to them from other threads.

That's nice — I wasn't aware of that. Day's is main-thread-only, which is currently a significant limitation. I'll definitely look closer at leptos’s reactive_graph for ideas.

> You're also using SwiftUI's layout, while I'm leaning on taffy instead for css-style flexbox / grid layout support. I'd love to know more about the deep tradeoffs going on here.

I was tempted by Taffy, since it is very mature and widely-used, but ultimately chose to have the clankers implement something homespun for Day. One of the major reasons was that I can have fine-grained control over the measure passes for optimization. Measuring is cheap for most platforms, but Android (for example) requires a FFI hop via JNI to communicate back and forth between Rust and Android's Java SDK, and that can be quite expensive. So being able to control how these requests are batched together and optimized was important for getting good performance there (and also potentially for ArkUI and other platforms that don't have C/C++/ObjC bridges directly into their UI frameworks).

More broadly, though, I feel like Day's SwiftUI-style "parent proposes size, child decides" paradigm is better suited for native components, which tend to have more non-negotiable requirements for many of their control sizes and layout.

> Write and post about it - this is cool!

Yes, I plan to!

That sounds a lot like my Day (https://daybrite.dev) project! We should compare notes…

Are you confident that forking Leptos for this is the right choice? Do you like their HTML-ish DSL when applied to native apps?

I see two nines in there…

[delayed]

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.

> What % of Android users actually want this? Do they know or care?

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

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

And also Android[1]!

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

> There are still challenges with basics like compression

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

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

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

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

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.

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

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.

[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

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.

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

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.

Thanks! It has been a long time coming.

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

The Xcode build plugin in the /skip repo uses the binary created by /skipstone (which is the repository that was just opened).

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

You can make your own tap (which is just a GitHub repo) and manually clear the quarantine flag in a postflight step. E.g., see https://github.com/alacritty/alacritty/issues/8749

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.

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.

Also recommended: BIRDMAN or (The Unexpected Virtue of Ignorance)

You recall correctly, but that did end in 2015, when Apple ended the requirement that developers sign up for their paid developer program to be able to develop and test iPhone apps. I've written about that elsewhere: https://appfair.org/blog/gpl-and-the-app-stores#fn:3

The adb workaround for Android is essentially on par with being able to use Xcode's tooling to install apps on an iPhone: technically possible without paying a fee, but enough friction that no one would seriously consider as an alternative solution for publishing their apps to a general audience.

> Could you make the claim that F-Droid is actually safer that "Google Play Store"

That is essentially the assertion that we made in the prequel to this post (at https://f-droid.org/en/2025/09/29/google-developer-registrat...).

> But how much malware has been distributed via F-Droid versus "Google Play Store"

There's been only a single case of malware that we know of that has slipped into distribution on F-Droid (through a supply-chain attack on a transitive dependency), and it was caught within a day. So if we were feeling glib, we might have made the claim that "there is over 224 times as much malware on the Play Store than on F-Droid".

adb is a developer tool. You need a tethered and trusted computer to be able to transfer an app using adb, and you need to enable "developer mode" on the device, which is an arcane dance that involves navigation through an obscure tree of settings and then quickly tapping a mystery spot 5+ times. Google can't block adb, because that is how Android apps are developed and tested, just how Apple cannot block their developer tools from being able to transfer apps onto an iPhone.

This is so far from a realistic and acceptable substitute that I question the honesty of anyone who claims that "adb will still work, so no problem!"

I hope that explains my seemingly critical omission.

Author here. I admit I am rather startled by the tone of many comments here and the accusations of disingenuity. Splitting hairs about the origin of the term "sideload" does not change the fact that those who promote the term tend to do so in order to make it feel deviant and hacker-ish. You don't "sideload" software on your Linux, Windows, or macOS computer: you install it.

You have the right to install whatever you want on your computer, regardless of whether that computer is on your desk or in your pocket. That's a hill I'll die on. I'm dismayed to see that this sentiment is not more widespread in this of all communities.