Oh wow - this is deeply, insanely similar to what I’ve been working on. Including your Solidjs based api, and how you’re approaching reactivity and signals. I had no idea Day existed. Write and post about it - this is cool!
To answer your question, no. I’m not convinced by leptos’s html style view macro. It’s cute, but you lose out on autocomplete and other IDE integration. I’m doing a rewrite at the moment and I’m considering dropping it for the fluent api that sits underneath. Kind of exactly like what you’ve got.
I am however, currently using leptos’s reactive_graph - which contains the implementation of signal / memo / etc. I’m not sure how the implementations compare, but one difference from reading the docs is that Leptos signals are Send. You can write to them from other threads. You just can’t do tracked reads from non main threads. (And effects always fire on the main thread). This makes it easy for applications to do work in other threads to fetch data or do long running computations, then pass the results to the UI via a signal. Use threads or tokio or whatever - it all plays nicely together.
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. Like you, at the "ground level" I'm asking the underlying platform widgets to size themselves. The API taffy uses internally for this is even very similar - if not as well documented. Layout is cached and passed up the tree. Nodes are marked as dirty in the same way. I'm curious if these approaches are fundamentally the same, just with different APIs for developers. Or if there are real capability or performance differences.
> 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.
I was hoping to reply to this in detail but as I never got around to it, I'll keep it short: mostly it's about the editorial changes they make to the text, modernizing spelling etc. Many of the changes are unjustified IMO, and often detract from the charm of the original, and I'm uncomfortable reading a text I know has been tampered with in this way. Of course it's their project and they can do whatever they want, and they clearly love books, so with strong opinions there will be some that I may disagree with. I'd much rather read books from Project Gutenberg or Wikisource, both of which don't even correct obvious typos without marking up in some way that they've done so.
I also have many positive things to say about Standard Ebooks, but I don't think you were asking about those. :)
----
Edit: Without going into what I think are the most egregious sort of changes they introduce (which I think will require a longer post) and limiting myself to ones easy to find immediately:
See the earlier discussion (linked in a sibling comment here) where the editor-in-chief says it's ok to change punctuation because "The sounds out of his mouth do not include an apostrophe whether it's there in the spelling or not." (a very American view IMO): https://news.ycombinator.com/item?id=16956931
And looking at a recent commit on one of their books, here's a recent (https://github.com/standardebooks/agatha-christie_the-secret...) revert of one of their aggressive "modernizations" from 2024 (https://github.com/standardebooks/agatha-christie_the-secret...), that had, in line with their usual practice, changed "every one" to "everyone" (in one place even when referring to "a good many risks"), and the same commit made other changes (including one still present) like "they ought to have it lithographed. It must be a frightful nuisance doing every one separately." having the last four words turned into "doing everyone separately."!
On the “every one” example, that’s a definite mistake that shouldn’t have made its way in to the book in the first place. The production process has a specific step for “every one” (https://standardebooks.org/contribute/producing-an-ebook-ste...) that guides producers through making the correct choices when modern usage has two different possible choices. It shouldn’t have happened, but it’s a mistake that was fixed at least.
Your comment makes it sound as though the mistake was introduced by an inexperienced contributor who did not read the guide, when in fact it was introduced by the founder/editor-in-chief of the project. :) And in case it wasn't clear, only one of the mistakes was reverted, and the other one I quoted is still present in the book even as of this moment.
More broadly, the position of Standard Ebooks is that a modern reader would be distracted by spellings like "some one" and "every thing", and by time written like "2.30" instead of "2:30", and that books in British quotation style must be converted to American quotation style. I think most readers can in fact tolerate such small differences, and this position is frankly insulting — the punctuation and spelling of works are part of their character, and if anything, I'm more distracted by such anachronisms in style introduced as part of the Standard Ebooks process.
And to be honest, that position is totally reasonable, and the good thing is that you have the option of Gutenberg, Faded Page, and a bunch of other archival sites, also for free, if you don’t want that.
But nearly all print publishers also do what SE does. Why do you think they do, when it costs additional money and time to do that? A reasonable answer is that some, or a majority of, people prefer it.
> But nearly all print publishers also do what SE does.
Do they? To check, I tried to find a recent publication of Agatha Christie, and found the collection “Country Christie: Twelve Devonshire Mysteries” which says “First published by HarperCollins Publishers Ltd 2025”. It still has British-style punctuation (throughout the book), and times like “1.30”, “9.30”, “11.30”, “7.30 a.m.”, “12.30 p.m.”, and “8.30”. I checked a couple of other recent publications and admittedly they do modernize (though not in phrases like “every one of you”), but again I found the collection “The Last Seance: Haunting Tales from the Queen of Mystery” (2019) which does not. So it seems mixed.
In any case, I think it's fine to do what Standard Ebooks does, and if it were instead called something like “Modernized Ebooks with American punctuation”—if readers would know before picking one up—it would be totally unobjectionable. The name “Standard” gives the wrong impression. It's a bit like colorizing old black-and-white movies (or dubbing foreign-language movies instead of subtitling them): yes possibly even a majority of people may prefer it, but IMO it would be good to be more explicit what has been done.
It splits the community and number of possible volunteer hours for one. It also splits the canon into different versions. More projects fight for the attention attention (and possibly donations) of the audience.
There are lots of reasons it could be preferable to centralize. OTOH their mission is limited and some competition is healthy, if only to explore alternative ways to do things.
PG focuses on an accurate digital translation of the source material, sometimes hosting multiple different versions of the same text, and doing things like putting work into recreating the adverts at the back of some novels.
SE focuses less of preservation and more on making readers’ versions of the texts, like other publishing imprints. So there’s typography standardisation, a light-touch moderinisation of hyphenation and soundalike spelling, and things like author-wide collections of short fiction and poetry even if it didn’t previously exist.
Both are valuable, but they serve different segments.
Not the GP, but I also have mixed feelings about Standard Ebooks. They modernise texts for American readers. This means changing the punctuation, merging some words, altering the syntax, etc.
When I read an old novel, written two centuries ago in England, the little differences to modern English are part of the charm, and I certainly don't want any Americanism mixed in. For one of my favorite novels, The Forsyte saga, the author deliberately used some rare forms of words, which SE replaced with the mainstream forms.
SE editor in chief here. What you describe is incorrect. The only thing we do is very light sound-alike spelling modernization, like "to-night" -> "tonight". We do not do things like change from en-GB to en-US, replace old words with different modern words, or change text for "American readers", whatever that means. I have no idea where you got that impression.
I personally worked on the Forsyte saga. If you think something was done in error, please let us know and we'll be happy to fix it.
You may already be aware, but SE marks all commits making those kinds of changes as '[Editorial]', so it is generally trivial to use their tooling to build your own high-quality ebook without any of the editorial changes.
When I tried this in the past, it was non-trivial because the editorial changes are mixed with the technical changes. Reverting the editorial changes broke the technical changes.
Not parent, but while I can appreciate your viewpoint, I would like to point out that many many many books have abridged, reworded, simplified, or disambiguated versions for different audiences.
The Bible is I daresay the most famous of these. Translations aside, even the English versions have had significant alterations done to wording, spelling, and meaning depending on the version.
There's also the Great Illustrated Classics imprint for certain classic novels like H.G. Wells's The Invisible Man. (I read that one like 10 times as a kid and it's what got me into sci-fi as a whole I'd argue. Haha.)
Whether these alternate versions are good or bad is obviously up for debate and depends on the person, but I'm just saying that what SE does is hardly new in the publishing world.
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.
Thank you for standing against the Android Developer Verification enforced by Google. Now in addition to stopping using Youtube, replacing chrome with ungoogled chromium, I'm moving to de-googled AOSP builds, e.g., lineageOS, insted of stock OEM ROMs.
Do we think that maybe the 3,732 people who responded to a poll on Mastodon by an account centered around one side of this disagreement might potentially not be a representative sample of all Android users?
It's a bit hard to poll 4 billion devices, but out of all 4 billion devices I think it's safe to assume that the percentage of users who do care can be rounded up to maybe 1% at most.
Developers and enthusiasts are an extreme minority that's incredibly vocal. I think most people here disagree with Google's approach but too many people are pretending like their interests and use cases are significant on a "half the planet" scale.
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 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".
- From April 2025 there's https://blog.google/company-news/inside-google/around-the-gl... a blog post from a “VP, Government Affairs & Public Policy”, which mentions “people in Asia Pacific feel it acutely, having lost an estimated $688 billion in 2024” (I think this may be across all scams?) and ends with “Combatting evolving online fraud in Asia-Pacific is critical” after listing a bunch of random things (unrelated to Android) Google is/was doing. This suggests to me that Google was under some criticism/pressure from governments for enabling scams, and eager to say “see, we're doing something”.
> In early discussions about this initiative, we've been encouraged by the supportive initial feedback we've received. In Brazil, the Brazilian Federation of Banks (FEBRABAN) sees it as a “significant advancement in protecting users and encouraging accountability.” This support extends to governments as well, with Indonesia's Ministry of Communications and Digital Affairs praising it for providing a “balanced approach” that protects users while keeping Android open. Similarly, Thailand’s Ministry of Digital Economy and Society sees it as a “positive and proactive measure” that aligns with their national digital safety policies.
This shows that it was a negotiation with the governments/agencies in Brazil, Indonesia, Thailand that were breathing down on Google to do something.
- And the most recent https://android-developers.googleblog.com/2025/11/android-de... from November 2025 (which promised the “students and hobbyists” account type and the “experienced users” flow “in the coming months”) also has a “Why verification is important” section that mentions the “consistently acted to keep our ecosystem safe” and “common attack we track in Southeast Asia” and “While we have advanced safeguards and protections to detect and take down bad apps, without verification, bad actors can spin up new harmful apps instantly”.
The overall picture I get is less of “Google to suddenly abandon these iterative security improvements” but more like: under pressure from governments to stop scams, Google has been doing various things like the things you mentioned, and scammers have also been evolving and finding new ways to carry out scams at scale (like “impersonating developers”), and the latest upcoming change requiring developer verification on “certified Android devices” is simply the next step of the iteration. It sucks and feels like a wholesale lock-down, yes, but it does not seem a jarring disconnect from the previous steps in the progression of locking things down.
I guess it's too late now, but I think "sufficient" is much too strong a word to use for that position, and puts Google in a position where they can disregard you because they "know" that existing measures aren't "sufficient."
There could be many other factors, like abysmal patch policies. Many vendors still only do Android Security Bulletins (which are only vulnerabilities marked as high and critical), do them late (despite a three month embargo for patches), very delayed device firmware updates, and sometimes only for two or three years.
Many Android phones still do not have a separate secure element.
Also, the Play Store itself regularly contains malware.
In the end it is mostly about control, dressed up as protecting users. If it was about security, Google would support GrapheneOS remote attestation for Google Pay (for being the most secure Android variant) and cut off many existing phones with deplorable security.
The app store does contain malware, although arguably less than the play store. Apple devices would be much more secure without the app store. Apple should remove the app store.
Not OP, but my experience was most of the malware-like apps on App Store were top ads of apps with names similar to the original ones: such as Whatsapp or Office.
Like you said, for years now they have added more and more restrictions to address various scams. So far none of them had any effect, other than annoying users of legitimate apps, because all the new restrictions were on the user side. This new approach restricts developers, but is actually a complete non-issue for most, since the vast majority of apps is distributed via Google Play already.
In the section "Existing Measures Are Sufficient." your letter also mentions
> Developer signing certificates that establish software provenance
without any explanation of how that would be the case. With the current system, yes, every app has to be signed. But that's it. There's no certificate chain required, no CA-checks are performed and self-signed certificates are accepted without issue. How is that supposed to establish any form of provenance?
If you really think there is a better solution to this, I would suggest you propose some viable alternative. So far all I've heard for the opponents of this change is, either "everything is fine" or "this is not the way", while conveniently ignoring the fact that there is an actual problem that needs a solution.
That said, I do generally agree, with you that mandatory verification for *all* apps would be overkill. But that is not what Google has announced in their latest blog posts. Yes, the flow to disable verification and the exemptions for hobbyists and students are just vague promises for now. But the public timeline (https://developer.android.com/developer-verification#timelin...) states developer verification will be generally available in March 2026. Why publish this letter now and not wait a few weeks so we can see what Google actually is planning before getting everybody outraged about it?
Because without this early resistance, there wouldn't even be vague promises of hobbyist/student exemptions. I think it's important to make community objection to the entire idea known loud and clear, especially when changes like these are absolutely ratcheting.
Starting from their first announcement of this, Google has explicitly asked for comments and feedback from affected developers. They have a Google Form for exactly that linked on all the announcement pages.
The exceptions for students/hobbyist were always promised, but the "advanced flow" came later based on this feedback. AFAICT Google has, so far, only made things better after the initial announcement. I don't see why we shouldn't give them the benefit of doubt, at least until we have some specifics.
Pushing this open letter out just days/weeks before Google promised the next major update just seems off.
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.
> Flutter isn't going to be implementing these new interface conventions
To be fair reading those updates it sounds a lot more positive than this comment makes it seem. I.e. "they're pausing design updates while they figure out the best way to do it" rather than "they're not going to bother":
> This strategic pause on design updates gives us the space to ensure the long-term health and maintainability of Flutter's design libraries. We are committed to being transparent with our contributor community as we explore these options and will have more to share on our findings and future direction in the coming weeks.
and
> The material and cupertino libraries are being decoupled into standalone packages to accelerate feature development. All new work for iOS26 updates in Cupertino will happen in the new packages once established in flutter/packages.
Flutter's grim outlook? It's being used more now than ever before, with both enterprise use as well as 30% of all new free iOS app store apps are now using Flutter.
Flutter is undergoing a major refactor where they're decoupling Material and Cupertino into separate packages. This is the reason why they're not implementing those new conventions right away. The way you've framed it is pretty disingenuous.
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.
Well sorry. But Android UI is bad just bad. The settings, the menus. Its bloated and almost as if they deliberately made it annoying to use. It just sucks.
Have you seen iOS or macOS settings, like ever? Especially on macOS, the UI is infantile, you have settings in different menus that change each other (mouse / touchpad scroll direction, two buttons in two menus, they change each other). On iOS you have amazing features like a wheel spinning forever without telling you there is a problem and what it is (like, for an app with in-app purchases, you must have a payment configured, otherwise the app installation just spins forever).
Compared to that, my (OxygenOS version of) Android UI is pretty good, concise, flexible and customisable if I want to. I hate the ambiguity of gestures, so I keep the buttons for navigation. I don't want everything splattered on the home screen, so I use a different launcher than the default. The menus are all logical.
It's a valid opinion. People can have opinions and also not be "in a cult." I would say this default response is rather cultish in its own right by your own use of the word.
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.
I had a very quick glance at docs website, from Comparison page it says it uses native components, which is great. However, I did not find anything related to platform specific API usage, such as embedding camera into your view or using notification groups/channels? Is there a way to "offload" these parts to android, similar to what CMP allows you to do? (You can embed native iOS views inside Compose view or use expect/actual)
Are you confident that forking Leptos for this is the right choice? Do you like their HTML-ish DSL when applied to native apps?