Working at a company that uses react-native I wish nothing more than for the end of app stores and differing platform languages.
We're heavily considering just having a website next year with a mobile app using webview, and then native code for the native notifications, GPS and healthkit / health connect.
I feel like AI is changing the equation, its nearly better to write your business UI 3 times one for each platform.
It’s called a “WebView app” and you can get a really good experience on all platforms using them. Just:
- don’t make any crazy decisions on your fundamental UI components, like breadcrumbs, select dropdowns, etc
- add a few platform-specific specialisations to those same components, to make them feel a bit more familiar, such as button styling, or using a self-simplifying back-stack on Android
- test to make sure your webview matches the native browser’s behaviour where it matters. For example, sliding up the view when the keyboard is opened on mobile, navigating back & forth with edge-swipes on iOS, etc
I also went the extra step and got service workers working, for a basic offline experience, and added a native auto network diagnostic tool that runs on app startup and checks “Can reach local network” “Can reach internet (1.1.1.1)” “Can resolve our app’s domain” etc etc, so users can share where it failed to get quicker support. But this is an app for small-to-medium businesses, not consumer-facing, and the HTML5 part is served from the server and cached. I haven’t thought much about what you might need to do additionally for a consumer app, or a local-first app.
It’s because if a webview app experience is good, you don’t notice it, you only notice if it’s bad.
A while ago saw a blog link on HN that explained how Apple uses it everywhere and we never notice it because they are done well. Of course I can’t find that link now, I summon the HN gods…
On mobile the webview app experience is crap and it's immediately obvious that an app is not native. Simply nobody asks customers how they like it. The management assumes that as long as nobody complains and the users don't leave in droves, the experience must be impeccable.
It's often easy to tell, but my concern has shifted from "Why isn't this native? It's ugly/slow" to "Why isn't this a goddamn webpage? It can't justify neither its permissions nor its space".
> It’s because if a webview app experience is good, you don’t notice it, you only notice if it’s bad.
Aside from Apple’s apps (which imo are noticeably worse than the old ones, but that’s beside the point), what are some good WebView apps on iOS right now?
Somebody scraped the play store and checked the framework, so a list for Android WebView apps, built with capacitor, is here: https://capgo.app/top_capacitor_app/ Maybe an equivalent is there on iOS for the same app...
lichess is really good. Thanks for the info, I'm not surprised to learn it's a webview app, but it is really good.
It doesn't look native but who even cares. I think when a UI sucks or is unintuitive or buggy then "it's not native" is a sort of catchall easy complaint. Native is a crutch. Sometimes it's a good crutch (accessibility etc). But that's more about developer efficiency and bare minimums of polish.
Sadly i couldn’t find a reliable way to do it on Apple Store, it’s pretty hard to download from the store outside of apple device. If anyone know how i can do it too
Yes, Apple's apps are really really bad - including the app store. I am not even sure whether that app store can be considered a stand alone app or we should call it part of the OS.
A webview app is by design bad. Webviews were made for one thing - web views.
> It stands to reason that Apple wouldn't have developed this feature [liquid glass css property] if they weren't using it. Where? We have no idea. But they must be using it somewhere. The fact that none of us have noticed exactly where suggests that we're interacting with webviews in our daily use of iOS without ever even realising it.
There's some jump from _a property exists_ to _it must be used_, but a massive one from _a property exists_ to _Apple uses it everywhere and we never notice it because they are done well_.
If Apple are using it for the AppStore - then I defo Italy do notice it. The AppStore runs so badly.
I would be interested in any links to Webview apps that run really well, I’ve never seen one that I’m aware of but so many that I am aware of and are bad!
I have experienced the opposite with Zed, which has its own bespoke UI framework - it behaved somewhat unexpectedly and didn't work exactly how I'm used to an UI to behave giving me this uncanny feeling.
This kinda shows you how much effort and experience goes into getting an UI framework right, and the long tail quirks (of which there are a zillion) matter for UX, and while I appreciate they took on the task of breaking away from the browser, it's understandable why someone wants to ship an app on time and budget goes with a web based solution.
I've done it before on a personal project and I was pretty obsessed with user experience. For example, I changed the way buttons work (because they were natively links with Cordova, which trigger upon tap, not "finger lift", like native buttons). Also, implemented some gestures to e.g. switch between pages (tab-style navigation). While not really in line with system UI (wasn't my goal), I think usability is quite decent.
Well you haven't used the cutting-edge latest breed. Try using Uber in a browser. There's many high-quality apps today where you honestly cannot tell that it's a website running in a browser. There are many many more but I can only think of Uber off the top of my head.
I use Voyager, a client for Lemmy, on a daily basis and it’s my favorite mobile (iPad) app. Voyager is the spiritual successor to the Apollo client for Reddit.
The app uses Ionic’s Capacitor, which to my rudimentary understanding is the webview-based upgrade of Cordova. I’ve had far fewer issues with this app than the likes of Bluesky (react native) and Discord (I think also react native but not sure).
The webview approach seems to be the only way for a one-person team to feasible provide a cross-platform app with an app-store presence. Another promising alternative to Capacitor is Tauri Mobile which does essentially the same thing, but mobile doesn’t seem to be a high priority for them.
I installed this on Android, and unless iOS experience is massively different, this is not a good example:
- there's no touch feedback (ripple) on many of clickable components. Some that do have it look non-native, inconsistent and sometimes gets stuck
- the search bar on top app bar in `search` tab looks very non-native and non-standard (it's elevated on top of elevated app bar already)
- the lists look iOS-y, especially settings
- the settings list item has weird glitch where it loses background after touching (but not clicking)
- collapsing comments is pretty choppy (on a Samsung S25 so a pretty powerful phone)
- can't swipe down a bottom sheet (with post options/actions)
- it's just not android-y — the navigation is weird, the design is all over the place,
It's not unusable and it's a good tradeoff for a small team I guess. But this is nowhere near the experience a native app can provide, and has lots of small papercuts that would make for at least a slightly frustrating experience. It is a decent app don't get me wrong, but it's clearly not native
Like GP I haven't experienced many WebView based apps that are great so I had to give this a spin and I have to say it's actually pretty good! I would not have identified this as a WebView app if I didn't already know about it from this comment.
Do you use iOS by any chance? On android I've very noticed performance problems. Even in apps like Discord and Instagram. But Google maps and Duolingo are pretty bad at times for example. So it's not webviews that are the common denominator here
Gathering all the metaphors (I know) here for reference:
- "All toupées look fake. I've never seen one that I couldn't tell was fake." [1]
- All CGI in movies looks fake. It jumps out at me every time I see it."
- All WebView apps suck. Every one I've seen has a bad obviously-web-derived UI.
re: that last one though -- I'd at least acknowledge that WebView apps are roughly at the end of the early-2000's era of CGI: not exactly "The Rock in The Scorpion King" bad, but generally not at the level of Avatar or Les Misérables.
Using webviews on native platforms can look very appealing from a management perspective: a single codebase, simpler coordination, reduced UX overhead, and faster iteration cycles.
However, from the user's side, this approach often results in a buggy, inconsistent experience that lacks the responsiveness and smoothness of a true native app that elusive "snappy" feeling (i know, I hate that word too)
Companies usually choose this route because it's cheaper, but that same "cheap mentality" often seeps into the overall product quality. Corners get cut, bugs get ignored, and long-term maintenance becomes a mess.
From a developer's perspective, it's a nightmare
You're essentially expected to deliver on three platforms doing the work of three people for the same $
In theory, any web developer could handle it. In practice, you need to understand all the native platforms just to maintain some basic, stable integrations even with frameworks like React Native.
The result?
Maybe 20% of your time goes into actual feature development, 30% into testing, and the remaining 70% into fixing obscure, platform-specific bugs while working overtime under pressure from cost-driven management.
In my experience, developers will do almost anything to avoid dealing with the native parts of this kind of setup those tasks usually get dumped on whoever is most "familiar" with native, because it's such a pain to handle.
And let's not forget QA testing across these hybrid layers is an absolute nightmare as well.
In the end, my view is simple:
If a company can't afford dedicated native teams, they probably shouldn't build a native app.
(Of course, smaller apps with limited complexity should be fine)
Isn't there a high chance your app is going to be rejected from app stores because you use a web view? You can change your whole app completely upon approval.
Or you ship your HTML/JS and not just embed a URL?
If you still need to wrap a cross-platform web experience in a native container, I really begin to lose the plot. Once you are engaged with the iOS code signing monster, you might as well go all the way into the ecosystem.
To me, the web is the way around the app stores and codesign. I know how to visit HN on my iPhone despite there not being an official native app for it. It can work. The challenge is making it work in your particular case. Fear that the user wont know how to access the product seems to be a primary factor driving hyperbolic takes on how consumer apps must be built. Perhaps a bit of marketing budget (scan this QR code / visit this link) could eliminate a very expensive tech problem. Why fight visibility in the crowded App Store when there are countless other advertising channels you could pour your resources into?
> native code for the native notifications, GPS and healthkit / health connect.
Modern web can address everything here but the HealthKit item. You could consider handling this with a simple companion application that is exclusively about the collection and transfer of the data while respecting user privacy & consent procedures.
Push notifications and mental real estate by being “an app” are the primary business reason (based on both statsig experiments I’ve seen across my career as well as some intuition about behavioral psychology regarding the app mental real estate bit).
> its nearly better to write your business UI 3 times one for each platform.
Anyone have any experience of doing this for a complex and long-life app?
Sounds like a nightmare that would increase friction and decrease development fun by x10 because of the huge overhead and tedium of having to keep your features and tests in sync across platform for every change you want to iterate on, and requiring developers be proficient at multiple stacks.
I get the usual complaints about bad webview implementations, but separate native codebases sounds like a prohibitively enormous tradeoff if most users only perceive the UX as being a little better than a good webview implementation. I feel like I'm missing something that native codebases is suggested as if it's a simple alternative, or this is coming from people that aren't actually involved in this?
You don’t do that though. You write your logic in a common languages and then the UI is an external layer you switch with build settings. The thing is, yiur choice is usually c|c++. Or an embedded language like lua. RN has gone the latter route and then extend it further by using React as a DSL for the UI.
> You write your logic in a common languages and then the UI is an external layer
Isn't reimplementing all your UI widgets, views, layouts and interactions for multiple platforms still a ton of work though? I'm not meaning people using things like React frameworks, but the suggestion of sticking to native only.
If you do that, then you intent to take advantage of the native framework (or a mature one like qt for some platform). They are really expansive and you can create an interface very quickly. You usually get animations, themability, navigation,… for free and you’re mostly arranging the layout and writing glue code.
Also, you usually get better tooling in regards to instrumentation and the like.
I try this every decade. Love the first few months for speed. Then I end up paying the price later when I want to integrate "new OS feature X" or make a system gesture/style/animation feel native.
Lack of swipe for back on iOS is usually the easiest way to tell I'm looking at a web view.
I see some downvotes but you're correct. For example, in the App Store feature cards swipe left only bounces the card, you have to keep swiping to close. Swipe down closes it at once. It's not that far from the usual but has always felt strange to me. This same gesture won't close Home's new accessory card.
I recently downloaded the Moodle app and was surprised to find it's powered by Ionic and a webview, which I only realized due to CSS misconfigurations that caused the app to fall back to Serif font for CJK glyphs.
Recent mid-tier phones are powerful enough that webview has a negligible impact on performance.
CapacitorJS makes for a REALLY awesome app dev experience compared with React Native. It's basically just a really well integrated system for building exactly what you describe. The company I work at made the switch from an RN app to a CJS one and it was might and day in so many ways, performance included!
I personally have a preference for Apple's native frameworks. From a purely engineering standpoint, they're very well thought out and have very clear separations of concerns. Spending my time with their libraries helped me write good, scalable code for platforms beyond their own.
That said, platform lock-in is bad for business because it makes operations dependent on a single provider, but I have no delusions that a web front-end is better.
From an engineering standpoint, front-end web frameworks are less complete and require too many third-party libraries and tooling to assemble. From a UX standpoint, it's actually worse--almost every website you visit today spams you upfront with Google sign-in and invasive cookie permission requests that you can't refuse. But never mind that--from a purely business standpoint, a single platform accessible anywhere saves costs. Most importantly, however, the web is a "safe space" for deploying software anti-patterns without an intermediary entity (i.e an app store) to police your code, so you can do whatever the heck you want.
I'd wish for nothing more than the end of web and app front-ends in favor of purely structured data derived from natural language prompts by users. However, the more realistic mindset seems to be that: the front-end layer is such a high level of abstraction with a very low barrier to entry, so that its tech stack will be in constant flux, in favor of whoever's currently the best-financed entity seeking the most market share, the most developer mind-share, and the most behavioral control among its users.
That. And specifically, fuck Apple and their prohibition on JITs.
We have a React Native app that shares some code with a webapp, and that needs to do some geometry processing. So we're constantly playing the game of "will it interpret quick enough". Everything works fine in browsers, but in a RN app it often slows down to unusable speeds.
Could your processing work in a webview? i.e. webgl or webasm or similar and you communicate with it via postMessage. Something like Polygen might help with the scaffolding, but I have not tried it personally
Using apps made with Electron or those so-called "universal" UI frameworks I wish nothing more than for everything to be native.
They always have to give up some basic or hidden conveniences that native controls get for free, so they always feel slightly different and "off" in a weird way which induces a constant vague annoyance while using them, like walking with a little pebble in your shoe, or a sitting in an chair that isn't balanced right.
It's funny how even after 50 years UI still isn't "solved" ..before writing a universal API, we don't even have universal consensus, or at least some kind of standards authority, on how controls should behave.
Hell not even users can’t agree, as would be seen on any comments about this topic, on stuff like whether lists should scroll up when swiping down, or scroll down when swiping up :')
So you can get native behaviors when it’s critical. Like share sheets, push and many other critical features that only apps get even if the bulk of the experience can be done in a webview. This is because mobile OS platforms choose not to make these available to web apps, because app store profits are better for them than an open ecosystem where sites can do the same things as apps.
The <canvas> tag using webgl offers a lot lower access to buffers than you might imagine and is very accessible using JS/DOM. I've gotten surgical AR devices approved from FDA - if it works good enough for life or death situations - it can certainly work for a toy app.
It's rarely better to write the business UI 3 times for each platform.
At the time such decisions are made, maybe the platforms couldn't do what was needed, but those platforms do tend to evolve, but not remain tracked.
Flutter to me has been one of the platforms that can quietly ship to multiple platforms as long as the parameters of what you're after can be accomplished in Dart, and if needed a bit of custom code for any particular platform.
Unfortunately, all too often not enough. But then again often one has UX designers for that, but they are all too often off to build flying castles in Figma.
Visual design is only one part of UX- interaction design and information architecture are equally important components.
At my last two jobs, when I did v front end work I had to coach designers through UX on a regular basis, because the designers did as much for the marketing department as they did for the development team.
Sadly, UX as a discipline doesn't get much love from most companies.
Looks in concept very similar to React Native. So now we have React Native, Lynx.js (ByteDance/Tiktok) and Valdi all based on React. I think competition is good for devs. But not sure if any of those will create ecosystem and community big enough and fast enough to React Native.
React Native grew a lot this year and a lot of things got or will be improved and copied from Lynx or Valid:
- 3 modes of compilation (AOT, JIT) from Valdi will be in static hermes (RN) in coming months.
- native binding generation -> RN already have such official generator and also nitro/nitrogen, they also working on Node-API
- executing animation and JS code in different thread (Lynx.js) -> worklet library in RN from swmansion
- tailwindcss support (Lynx) -> uniwind in RN land.
I think Lynx.js maybe have better shot at React Native since they want to support other frameworks instead of only React.
after small digging they have Full VSCode debugging [0] which is nice. RN have Radon IDE but it's a paid sub. What's interesting Valdi using Hermes (the one from RN) so maybe there is a way to retrofit this to work for RN. Wondering if they did AOT and JIT by themselve or they using static hermes branch or using only hermes in dev mode.
I was at Snap during this project’s early days (Screenshop!) and spent a bit of time debugging some stuff directly with Simon. He’s a wonderful engineer and I’m thrilled to see this project out in the open.
Congratulations Snap team! Well deserved.
I'm surprised Snap of all companies invested in a cross-platform UI framework given how simple their app seems in comparison to more complex ones out there.
And more importantly, Snapchat seems like an app which could highly benefit from tight integration with native features (eg. camera, AR features, notifications, screenshot detection, etc.)
These companies have super talented engineers and can afford to invest in skunkworks projects like these when they can’t find any suitable options in the market.
More like "super talented engineers" will keep increasing cost of such projects until they get told this stuff doesn't generate revenue/cost cutting is happening, so work more on ad tech, leave or find external free labor("community") to maintain it.
As far as Im concerned, Snapchat is onw of the most complicated apps thats routinely used by hundreds of millions of people. You yourself listed all the features they have. And every one of them is pixel perfect, with insane amounts of time spent perfecting the user experience of every single ome of those features. In fact, the success of Snap could be attributed to how pixel perfect the app is.
I share your opinion, but I think of the comment above like this. If something thinks your ui "just makes sense" and is dead simple to use, then you know you've perfected it. That is the best compliment you can get.
You kind of just proved my point. If they want attention to detail and good performance then writing native is probably better. The simplicity that I was referring to was the number of views that need to be implemented. A cross platform UI framework would help if there were hundreds of views that needed to be built consistently but for the number of views in Snapchat, I think native implementations would probably be faster and cheaper.
As for the "success of Snap could be attributed to how pixel perfect the app is". I think the success of Snap can be attributed to a lot of things. But if you took a look at how unoptimized the Android experience was in 2017 when it was taking off I don't know how you could call it pixel perfect.
Snapchat, an app which half-assed picture taking so hard that it did so by simply snapshotting the camera preview, rather than bothering to take an actual photo.
Definitely one of the cooler projects to watch while I was there. I recall the goal was to open-source it from early on, so I'm glad to see it come to fruition!
I cannot possibly think of something I would want to use less. A Snapchat-developed UI framework where communication is done via Discord sounds like something carefully designed to repulse me.
I think it’s been changed since, but wow was it weird finding out that instead of taking photos, the Android app used to essentially take a screenshot of the camera view.
I worked on the camera in Instagram iOS for a while. There at least, there could be a 5,000ms latency delta between the “screen preview” and the actual full quality image asset from the camera DSP in the SOC.
I don’t know a thing about Android camera SDK but I can easily see how this choice was the right balance for performance and quality at the time on old hardware (I’m thinking 2013 or so).
Users didn’t want the full quality at all, they’d never zoom. Zero latency would be far more important for fueling the viral flywheel.
I worked on the Snapchat Android back in 2017. It's only weird for people who have never had to work with cameras on Android :) Google's done their best to wrangle things with CameraX, but there's basically a bajillion phones out there with different performance and quality characteristics. And Snap is (rightfully) hyper-fixated on the ability to open the app and take a picture as quickly as possible. The trade off they made was a reasonable one at the time.
Things have improved since then, but as I understand it, the technical reason behind that is that it used to be that only the camera viewfinder API was universal between devices. Every manufacturer implemented their cameras differently, and so developers had to write per-model camera handling to take high quality photos and video.
:) this is exactly how we used to do it even on iOS, back in the days before camera APIs were not made public, but Steve Jobs personally allowed such apps to be published in the iOS App Store (end of 2009) ...
> Valdi is a cross-platform UI framework that delivers native performance without sacrificing developer velocity. Write your UI once in declarative TypeScript, and it compiles directly to native views on iOS, Android, and macOS—no web views, no JavaScript bridges.
I looked at the source code (as an amateur application developer) and boy, is it over-engineered and complex! Then I remember having built a complex Cordova app more than a decade ago, where I had to make C++, JNI and Javascript interop all play nice and this project feels a lot like that. Lots of moving parts. I suppose this is just the way things are when you are targetting such different ecosystems as Android and iOS _natively_, at the lowest level.
As a solo-dev, I realize well that this project isn't for me. This could be a great tool for experienced folks who know what they are doing. I will stick to Tauri and React Native, it does 80% of what I care about with 20% of the effort. Or until someone builds a nice wrapper around this to make it easy to use (and also add targets for x86_64/aarch64 builds).
If you are curious how components' state is handled, they employed the React class components method:
// Import the StatefulComponent
import { StatefulComponent } from 'valdi_core/src/Component';
// ViewModel + State interfaces for component
export interface TimerViewModel { loop: number }
interface TimerState { elapsed: number }
// Component class
export class Timer extends StatefulComponent<TimerViewModel, TimerState> {
// Initialize the state
state = { elapsed: 0 };
// When creating the component, start a periodic logic
private interval?: number;
// Initialize the setInterval that will update state once a second incrementing
// the `elapsed` state value.
onCreate() {
this.interval = setInterval(() => {
// Increment the state to trigger a re-render periodically
const elapsed = this.state.elapsed;
const loop = this.viewModel.loop;
this.setState({ elapsed: (elapsed + 1) % loop });
}, 1000);
}
// When component is removed, make sure to cleanup interval logic
onDestroy() {
if (this.interval) clearInterval(this.interval);
}
// Render visuals will depend both on the state and the view model
onRender() {
<view padding={30} backgroundColor='lightblue'>
<label value={`Time Elapsed: ${this.state.elapsed} seconds`} />;
<label value={`Time Looping every: ${this.viewModel.loop} seconds`} />;
</view>;
}
}
I agree, this is the way. To be clear: I'm not a mobile developer, and have only dabbled with it over the years, but I'm generally familiar with the stacks.
If you want to simplify development of a cross-platform app, your work should start by architecting the software in a way that the core business logic is agnostic to the user interfaces. Then your web, mobile, and desktop GUIs, CLI, TUI, API, and any other way a user interacts with your program are simply thin abstractions that call your core components.
The complexity of each UI will inevitably vary, and it might not be possible to offer a consistent experience across platforms or to leverage unique features of each platform without making your core a tangled mess, so this is certainly not "easy" to do in practice, but this approach should avoid the bulk of the work of targetting individual platforms than if you had done it any other way. It should also avoid depending on a 3rd-party framework that may or may not exist a few years down the line.
One extra clarification: If the quality of your app is business critical you should really use the native UI toolkit to offer the best platform integration and user experience.
If your app is not business critical (you just have to offer it - example: dishwasher app, ..) you might get away with using a cross platform toolkit like flutter or react native. But even then this adds a 3rd party dependency as you mentioned which adds risk.
Writing an App in Swift on iOS is boring. The same thing is true for writing an Android app using Kotlin/Java. This is a good thing. Now your developers can concentrate on shipping great features.
This looks promising. I would love to see more examples of what this can do along with screenshots. As is, there is a single Hello World and the components library is “coming soon”. But if it can deliver what it promises that would be pretty cool. React Native is I think the main popular framework in this space.
I've worked and researched heavily in this field. If you want to write one codebase that hits all platforms with _actual native performance_ your only option at the moment is RN/Expo.
I often wonder how the economics are justified in making in house frameworks. What is it about Snapchat that requires a new framework but not other apps?
As opposed to what? As opposed to not using a framework or using some other framework?
Using frameworks is expensive by orders of magnitude. It’s additional code which greatly increases tech debt and slows the execution time of the given product pretty significantly. Think about it like this: a business with high confidence developers can ship a new SPA in a tenth of the time just using vanilla JavaScript that fully renders to screen with complete state restoration across the internet in less than a quarter second. That also means the business saves boat loads of cash by shipping faster, experimenting against its user’s behavior, and needing only a quarter of the headcount. So, where do you find these people and how do you retain them?
The economics are pretty simple and completely offensive/hostile to the developers. It’s ultimately about hiring and firing. Developers are a cost center to the business so the goal is to always eliminate training and turn them into a replaceable commodity. That’s it. That developers believe this is somehow a great empowerment is a double win for the employer.
The reason a company might introduce a new framework is because they encounter a problem not immediately solved by existing frameworks. The more frequently that same problem occurs the more a new framework pays for itself.
Valdi seems very similar in concept to React Native but Meta being the biggest competition to them you unlikely gonna depend on that even if better. Same reason ByteDance (Tiktok) doing Lynx.js (also similar to Valdi and React Native and also based on React).
The only FAANG scale companies that adopted React Native are Microsoft and Amazon because they aren't directly competing with Meta.
Given the user hostility of Google
and Apple (and the rest) and the rate at which they emulate competitors and try to crush them, I’d start at a small library or framework and not stop until I had a whole OS.
If the framework is used, eventually there will be 3rd party lib adding new features (from the top of my mind, maps), and someone will need to write the bridging with the native SDK. It means the bridge will most likely need to be written in objective-C instead of Swift
One of the Valdi's authors here.
It's using native views under the hood, like React Native, and there are 3 modes of compilation/execution for the TS source. It can be interpreted from JS (TS compiled to minified JS source), interpreted from JS bytecode (TS compiled to JS source, minified, then compiled to JS bytecode ahead of time), or compiled to native code directly (TS compiled to C ahead of time).
An AOT TS -> C compiler is fantastic - how much of the language is supported, what are the limitations on TS support? I assume highly dynamic stuff and eval is out-of-scope?
Most of the TS language is supported, things that are not can be considered bugs that we need to fix. Eval is supported but it won't be able to capture variables outside of the eval string itself. We took a reverse approach than most other TS to native compiler projects: we wanted the compiler to be as compatible with JS as possible, at the expense of reducing performance initially, to make it possible to adopt the native compiler incrementally at scale.
There are significant trade-offs with this compiler at the moment: it uses much more binary size than minified JS or JS bytecode, and performance improvements goes from 2x to sometimes zero. It's a work-in-progress, it's pretty far along in what it supports, but its value-proposition is not yet where it needs to be.
So now I can finally implement the most god-awful, ugly, cumbersome and unintuitive GUI methodology ever to face a large population of users into my own apps? This abomination that started the whole user-experience decline by making this kind of yuck the gold standard for apps today is finally open source?
I hope it has "load spam ads directly into the list the user was about to touch somehow the millisecond before they touch it using magical force field technology so they click the wrong thing every time" functionality. I've been missing that in my apps
It's a really wonky app. The main feature works fine, no issue. Their "Stories" section, I can't can navigate that at all, there a no hint to how it works, so I don't use it. Seems a little weird, given that this is where the ads are, why wouldn't Snapchat make that easier to use?
There's also views I can get into which I can't figure out how to leave, so I force close the app to get back.
I don't necessarily think that's a flaw of the framework, just how Snapchat designs their app.
Snap is the greatest innovator of user experiences in this generation. This is evidenced by the fact that literally every other social media app is just a hodgepodge copycat of sorts of what snap invented. For people who introduced themselves to tech with snap as one of their first apps, its the most intuitive thing ever.
When they first introduced video calls, schools had to close for a day.
Imagine then you come here and see someone calls it awful. Can't help but think its just an instance of "old man yelling at clouds".
Don't take me argument as one against the point that it was massively popular and influential, en contraire, that's often the common factor in things I tend to dislike: the norm/ the mainstream.
It's mostly subjective when talking UI, and a lot plays in too regarding the lack of competive platforms with different UI's.
My point is that (I think) they became popular because of their UI and UX. They remagined how a small touch screen user experience could be most intuitive if you dont come with legacy mindset. For people used to keyboard and mice this might look weird but snap makes sense to the newer generation.
If all the other apps look similar its because they copied it. This is like calling Citizen Kane boring.
All valid points. Made me actually think about the likely first actions an alien or newborn would take with a 2025 touch screen device. Chomp. Chew. Swipe.
If your entire company is all about making a single good app, I doubt having AI changes the architecture much. Its still an architectural decision of whether you're going to have a single codebase for your app and focus on a framework to transpile it. Either way you need actual teams of experts on iOS android etc, no single person is going to master all of them.
Working at a company that uses react-native I wish nothing more than for the end of app stores and differing platform languages.
We're heavily considering just having a website next year with a mobile app using webview, and then native code for the native notifications, GPS and healthkit / health connect.
I feel like AI is changing the equation, its nearly better to write your business UI 3 times one for each platform.
I did this and never looked back.
It’s called a “WebView app” and you can get a really good experience on all platforms using them. Just:
- don’t make any crazy decisions on your fundamental UI components, like breadcrumbs, select dropdowns, etc
- add a few platform-specific specialisations to those same components, to make them feel a bit more familiar, such as button styling, or using a self-simplifying back-stack on Android
- test to make sure your webview matches the native browser’s behaviour where it matters. For example, sliding up the view when the keyboard is opened on mobile, navigating back & forth with edge-swipes on iOS, etc
I also went the extra step and got service workers working, for a basic offline experience, and added a native auto network diagnostic tool that runs on app startup and checks “Can reach local network” “Can reach internet (1.1.1.1)” “Can resolve our app’s domain” etc etc, so users can share where it failed to get quicker support. But this is an app for small-to-medium businesses, not consumer-facing, and the HTML5 part is served from the server and cached. I haven’t thought much about what you might need to do additionally for a consumer app, or a local-first app.
I have never once experienced a WebView app that I would say had “a really good experience.”
It’s because if a webview app experience is good, you don’t notice it, you only notice if it’s bad.
A while ago saw a blog link on HN that explained how Apple uses it everywhere and we never notice it because they are done well. Of course I can’t find that link now, I summon the HN gods…
Maybe this https://blog.jim-nielsen.com/2022/inspecting-web-views-in-ma... and https://news.ycombinator.com/item?id=30648424?
On mobile the webview app experience is crap and it's immediately obvious that an app is not native. Simply nobody asks customers how they like it. The management assumes that as long as nobody complains and the users don't leave in droves, the experience must be impeccable.
It's often easy to tell, but my concern has shifted from "Why isn't this native? It's ugly/slow" to "Why isn't this a goddamn webpage? It can't justify neither its permissions nor its space".
> It’s because if a webview app experience is good, you don’t notice it, you only notice if it’s bad.
Aside from Apple’s apps (which imo are noticeably worse than the old ones, but that’s beside the point), what are some good WebView apps on iOS right now?
Somebody scraped the play store and checked the framework, so a list for Android WebView apps, built with capacitor, is here: https://capgo.app/top_capacitor_app/ Maybe an equivalent is there on iOS for the same app...
lichess is really good. Thanks for the info, I'm not surprised to learn it's a webview app, but it is really good.
It doesn't look native but who even cares. I think when a UI sucks or is unintuitive or buggy then "it's not native" is a sort of catchall easy complaint. Native is a crutch. Sometimes it's a good crutch (accessibility etc). But that's more about developer efficiency and bare minimums of polish.
Sadly i couldn’t find a reliable way to do it on Apple Store, it’s pretty hard to download from the store outside of apple device. If anyone know how i can do it too
It might not be possible but others have scraped just the app store and matched based on Android meta data: https://people.ece.ubc.ca/amesbah/resources/papers/mobilesof...
Yes, Apple's apps are really really bad - including the app store. I am not even sure whether that app store can be considered a stand alone app or we should call it part of the OS.
A webview app is by design bad. Webviews were made for one thing - web views.
Is this what you mean? https://news.ycombinator.com/item?id=45250759
(In the context of "Apple has a private CSS property to add Liquid Glass effects to web content")
Yes, thank you!
> It stands to reason that Apple wouldn't have developed this feature [liquid glass css property] if they weren't using it. Where? We have no idea. But they must be using it somewhere. The fact that none of us have noticed exactly where suggests that we're interacting with webviews in our daily use of iOS without ever even realising it.
There's some jump from _a property exists_ to _it must be used_, but a massive one from _a property exists_ to _Apple uses it everywhere and we never notice it because they are done well_.
If Apple are using it for the AppStore - then I defo Italy do notice it. The AppStore runs so badly.
I would be interested in any links to Webview apps that run really well, I’ve never seen one that I’m aware of but so many that I am aware of and are bad!
> Apple uses it everywhere and we never notice it because they are done well.
Done well as in: laggy, non-performant, break OS conventions and you can see elements load with the naked eye?
See App Store as an example: https://grumpy.website/post/0RsaxCu3P or Apple Arcade: https://grumpy.website/618 or...
The Arcade video, taking several seconds to load a few low resolution images, causes me pain.
A webview app can be good, but finding one is harder than finding russel's teapot :D
Can you give examples of good webview apps on iOS?
Not really. The difference between high quality web app and native app is very noticeable.
And between average native and average web view - it is night and day.
99% of web apps in desktop browser are laggy. And on mobile it feels like crap.
Sure if you are an expert in top1% you can probably get it working really good. But this is true only for 1 in 100 if not less.
I have experienced the opposite with Zed, which has its own bespoke UI framework - it behaved somewhat unexpectedly and didn't work exactly how I'm used to an UI to behave giving me this uncanny feeling.
This kinda shows you how much effort and experience goes into getting an UI framework right, and the long tail quirks (of which there are a zillion) matter for UX, and while I appreciate they took on the task of breaking away from the browser, it's understandable why someone wants to ship an app on time and budget goes with a web based solution.
I've done it before on a personal project and I was pretty obsessed with user experience. For example, I changed the way buttons work (because they were natively links with Cordova, which trigger upon tap, not "finger lift", like native buttons). Also, implemented some gestures to e.g. switch between pages (tab-style navigation). While not really in line with system UI (wasn't my goal), I think usability is quite decent.
In case you're interested, the app is named "QuickÖV" - not relevant to anyone outside Switzerland, but just for trying it out: https://play.google.com/store/apps/details?id=com.billhillap...
Well you haven't used the cutting-edge latest breed. Try using Uber in a browser. There's many high-quality apps today where you honestly cannot tell that it's a website running in a browser. There are many many more but I can only think of Uber off the top of my head.
I use Voyager, a client for Lemmy, on a daily basis and it’s my favorite mobile (iPad) app. Voyager is the spiritual successor to the Apollo client for Reddit.
https://github.com/aeharding/voyager
The app uses Ionic’s Capacitor, which to my rudimentary understanding is the webview-based upgrade of Cordova. I’ve had far fewer issues with this app than the likes of Bluesky (react native) and Discord (I think also react native but not sure).
The webview approach seems to be the only way for a one-person team to feasible provide a cross-platform app with an app-store presence. Another promising alternative to Capacitor is Tauri Mobile which does essentially the same thing, but mobile doesn’t seem to be a high priority for them.
I installed this on Android, and unless iOS experience is massively different, this is not a good example:
- there's no touch feedback (ripple) on many of clickable components. Some that do have it look non-native, inconsistent and sometimes gets stuck
- the search bar on top app bar in `search` tab looks very non-native and non-standard (it's elevated on top of elevated app bar already)
- the lists look iOS-y, especially settings
- the settings list item has weird glitch where it loses background after touching (but not clicking)
- collapsing comments is pretty choppy (on a Samsung S25 so a pretty powerful phone)
- can't swipe down a bottom sheet (with post options/actions)
- it's just not android-y — the navigation is weird, the design is all over the place,
It's not unusable and it's a good tradeoff for a small team I guess. But this is nowhere near the experience a native app can provide, and has lots of small papercuts that would make for at least a slightly frustrating experience. It is a decent app don't get me wrong, but it's clearly not native
Like GP I haven't experienced many WebView based apps that are great so I had to give this a spin and I have to say it's actually pretty good! I would not have identified this as a WebView app if I didn't already know about it from this comment.
Do you use iOS by any chance? On android I've very noticed performance problems. Even in apps like Discord and Instagram. But Google maps and Duolingo are pretty bad at times for example. So it's not webviews that are the common denominator here
Obsidian. In android it's the best markdown editor.
Gathering all the metaphors (I know) here for reference:
re: that last one though -- I'd at least acknowledge that WebView apps are roughly at the end of the early-2000's era of CGI: not exactly "The Rock in The Scorpion King" bad, but generally not at the level of Avatar or Les Misérables.1. https://news.ycombinator.com/item?id=45250878
Using webviews on native platforms can look very appealing from a management perspective: a single codebase, simpler coordination, reduced UX overhead, and faster iteration cycles.
However, from the user's side, this approach often results in a buggy, inconsistent experience that lacks the responsiveness and smoothness of a true native app that elusive "snappy" feeling (i know, I hate that word too)
Companies usually choose this route because it's cheaper, but that same "cheap mentality" often seeps into the overall product quality. Corners get cut, bugs get ignored, and long-term maintenance becomes a mess.
From a developer's perspective, it's a nightmare You're essentially expected to deliver on three platforms doing the work of three people for the same $ In theory, any web developer could handle it. In practice, you need to understand all the native platforms just to maintain some basic, stable integrations even with frameworks like React Native.
The result? Maybe 20% of your time goes into actual feature development, 30% into testing, and the remaining 70% into fixing obscure, platform-specific bugs while working overtime under pressure from cost-driven management.
In my experience, developers will do almost anything to avoid dealing with the native parts of this kind of setup those tasks usually get dumped on whoever is most "familiar" with native, because it's such a pain to handle.
And let's not forget QA testing across these hybrid layers is an absolute nightmare as well.
In the end, my view is simple: If a company can't afford dedicated native teams, they probably shouldn't build a native app. (Of course, smaller apps with limited complexity should be fine)
I made a (hobby) project that utilized this strategy (Flutter + wrapped webview app), and it honestly seems like the way to go for my needs.
Isn't there a high chance your app is going to be rejected from app stores because you use a web view? You can change your whole app completely upon approval.
Or you ship your HTML/JS and not just embed a URL?
It's mostly shipped with the web assets. But yes that would make it very difficult to get approved by Apple. Not by Google though
Works until you need complex native code for things like automatic image capture assisted by a bounding model.
There is no reason you can't do that via web. Image capture in a canvas gives you access to the raw image pixmap data.
Do you use some framework for "WebView app" ? Like Tauri, etc ? Or is everything coded from scratch ?
What is your app? Would love to try it out to get a feel for the experience.
Perhaps you mean PWAs and not WebView apps? WebView apps suck big-time.
At least now I know who the offending devs are.
If you still need to wrap a cross-platform web experience in a native container, I really begin to lose the plot. Once you are engaged with the iOS code signing monster, you might as well go all the way into the ecosystem.
To me, the web is the way around the app stores and codesign. I know how to visit HN on my iPhone despite there not being an official native app for it. It can work. The challenge is making it work in your particular case. Fear that the user wont know how to access the product seems to be a primary factor driving hyperbolic takes on how consumer apps must be built. Perhaps a bit of marketing budget (scan this QR code / visit this link) could eliminate a very expensive tech problem. Why fight visibility in the crowded App Store when there are countless other advertising channels you could pour your resources into?
> native code for the native notifications, GPS and healthkit / health connect.
Modern web can address everything here but the HealthKit item. You could consider handling this with a simple companion application that is exclusively about the collection and transfer of the data while respecting user privacy & consent procedures.
Push notifications and mental real estate by being “an app” are the primary business reason (based on both statsig experiments I’ve seen across my career as well as some intuition about behavioral psychology regarding the app mental real estate bit).
> its nearly better to write your business UI 3 times one for each platform.
Anyone have any experience of doing this for a complex and long-life app?
Sounds like a nightmare that would increase friction and decrease development fun by x10 because of the huge overhead and tedium of having to keep your features and tests in sync across platform for every change you want to iterate on, and requiring developers be proficient at multiple stacks.
I get the usual complaints about bad webview implementations, but separate native codebases sounds like a prohibitively enormous tradeoff if most users only perceive the UX as being a little better than a good webview implementation. I feel like I'm missing something that native codebases is suggested as if it's a simple alternative, or this is coming from people that aren't actually involved in this?
You don’t do that though. You write your logic in a common languages and then the UI is an external layer you switch with build settings. The thing is, yiur choice is usually c|c++. Or an embedded language like lua. RN has gone the latter route and then extend it further by using React as a DSL for the UI.
> You write your logic in a common languages and then the UI is an external layer
Isn't reimplementing all your UI widgets, views, layouts and interactions for multiple platforms still a ton of work though? I'm not meaning people using things like React frameworks, but the suggestion of sticking to native only.
If you do that, then you intent to take advantage of the native framework (or a mature one like qt for some platform). They are really expansive and you can create an interface very quickly. You usually get animations, themability, navigation,… for free and you’re mostly arranging the layout and writing glue code.
Also, you usually get better tooling in regards to instrumentation and the like.
I try this every decade. Love the first few months for speed. Then I end up paying the price later when I want to integrate "new OS feature X" or make a system gesture/style/animation feel native.
Lack of swipe for back on iOS is usually the easiest way to tell I'm looking at a web view.
But it's been about a decade so I'm due...
Swipe to go back can be implemented in frontend.
It's been a couple of years since I used it, but I think the Ionic framework has this feature.
https://ionicframework.com/
Lack of swipe back actually isn't an indicator. Apple doesn't even follow that pattern everywhere
I see some downvotes but you're correct. For example, in the App Store feature cards swipe left only bounces the card, you have to keep swiping to close. Swipe down closes it at once. It's not that far from the usual but has always felt strange to me. This same gesture won't close Home's new accessory card.
I recently downloaded the Moodle app and was surprised to find it's powered by Ionic and a webview, which I only realized due to CSS misconfigurations that caused the app to fall back to Serif font for CJK glyphs.
Recent mid-tier phones are powerful enough that webview has a negligible impact on performance.
CapacitorJS makes for a REALLY awesome app dev experience compared with React Native. It's basically just a really well integrated system for building exactly what you describe. The company I work at made the switch from an RN app to a CJS one and it was might and day in so many ways, performance included!
This is laughably wrong. Expo exported to a web target is the same or better than Capacitor.
How is this different than Expo?
https://developer.android.com/develop/ui/views/layout/webapp...
Is Cordova still actively developed? Or are people just rolling their own per OS these days?
I personally have a preference for Apple's native frameworks. From a purely engineering standpoint, they're very well thought out and have very clear separations of concerns. Spending my time with their libraries helped me write good, scalable code for platforms beyond their own.
That said, platform lock-in is bad for business because it makes operations dependent on a single provider, but I have no delusions that a web front-end is better.
From an engineering standpoint, front-end web frameworks are less complete and require too many third-party libraries and tooling to assemble. From a UX standpoint, it's actually worse--almost every website you visit today spams you upfront with Google sign-in and invasive cookie permission requests that you can't refuse. But never mind that--from a purely business standpoint, a single platform accessible anywhere saves costs. Most importantly, however, the web is a "safe space" for deploying software anti-patterns without an intermediary entity (i.e an app store) to police your code, so you can do whatever the heck you want.
I'd wish for nothing more than the end of web and app front-ends in favor of purely structured data derived from natural language prompts by users. However, the more realistic mindset seems to be that: the front-end layer is such a high level of abstraction with a very low barrier to entry, so that its tech stack will be in constant flux, in favor of whoever's currently the best-financed entity seeking the most market share, the most developer mind-share, and the most behavioral control among its users.
That. And specifically, fuck Apple and their prohibition on JITs.
We have a React Native app that shares some code with a webapp, and that needs to do some geometry processing. So we're constantly playing the game of "will it interpret quick enough". Everything works fine in browsers, but in a RN app it often slows down to unusable speeds.
Could your processing work in a webview? i.e. webgl or webasm or similar and you communicate with it via postMessage. Something like Polygen might help with the scaffolding, but I have not tried it personally
No, it's far too brittle. The latency is also terrible. In our case, we had to reimplement some parts in C++ to have reasonable performance.
Using apps made with Electron or those so-called "universal" UI frameworks I wish nothing more than for everything to be native.
They always have to give up some basic or hidden conveniences that native controls get for free, so they always feel slightly different and "off" in a weird way which induces a constant vague annoyance while using them, like walking with a little pebble in your shoe, or a sitting in an chair that isn't balanced right.
It's funny how even after 50 years UI still isn't "solved" ..before writing a universal API, we don't even have universal consensus, or at least some kind of standards authority, on how controls should behave.
Hell not even users can’t agree, as would be seen on any comments about this topic, on stuff like whether lists should scroll up when swiping down, or scroll down when swiping up :')
Then why bother making an app? The user can access the web app using the browser.
So you can get native behaviors when it’s critical. Like share sheets, push and many other critical features that only apps get even if the bulk of the experience can be done in a webview. This is because mobile OS platforms choose not to make these available to web apps, because app store profits are better for them than an open ecosystem where sites can do the same things as apps.
Both the things you mention have been possible on web and widely supported for a while.
https://developer.mozilla.org/en-US/docs/Web/API/Web_Share_A...
https://developer.mozilla.org/en-US/docs/Web/API/Push_API
And not having to wait a week between bug fixes being deployed is a major selling point that native just can't compete with.
We (they) wanted "easy accessibility" and "constantly seeing this app's icon" bs.
that only works if you have a simple app that displays some stuff from a server.
if you want to do something actually requires some compute, then suddenly this doesnt work so great
ex: youre prolly not going to want to edit images in JS
The <canvas> tag using webgl offers a lot lower access to buffers than you might imagine and is very accessible using JS/DOM. I've gotten surgical AR devices approved from FDA - if it works good enough for life or death situations - it can certainly work for a toy app.
It's rarely better to write the business UI 3 times for each platform.
At the time such decisions are made, maybe the platforms couldn't do what was needed, but those platforms do tend to evolve, but not remain tracked.
Flutter to me has been one of the platforms that can quietly ship to multiple platforms as long as the parameters of what you're after can be accomplished in Dart, and if needed a bit of custom code for any particular platform.
Isn't this how Hotwire works with Rails?
we shipped this last year. Best decision ever.
I saw another comment calling it "webview app", which is also valid, but we call it "hybrid app".
It’s a bad idea to put the fox (front-end developers) to guard the henhouse (great, consistent user experiences).
lol, yeah what do front ender devs know about UX. SMH…
Unfortunately, all too often not enough. But then again often one has UX designers for that, but they are all too often off to build flying castles in Figma.
Visual design is only one part of UX- interaction design and information architecture are equally important components.
At my last two jobs, when I did v front end work I had to coach designers through UX on a regular basis, because the designers did as much for the marketing department as they did for the development team.
Sadly, UX as a discipline doesn't get much love from most companies.
You could just use Kotlin Multiplatform and Multiplatform Compose instead.
Wholeheartedly agree.
Looks in concept very similar to React Native. So now we have React Native, Lynx.js (ByteDance/Tiktok) and Valdi all based on React. I think competition is good for devs. But not sure if any of those will create ecosystem and community big enough and fast enough to React Native.
React Native grew a lot this year and a lot of things got or will be improved and copied from Lynx or Valid:
- 3 modes of compilation (AOT, JIT) from Valdi will be in static hermes (RN) in coming months.
- native binding generation -> RN already have such official generator and also nitro/nitrogen, they also working on Node-API
- executing animation and JS code in different thread (Lynx.js) -> worklet library in RN from swmansion
- tailwindcss support (Lynx) -> uniwind in RN land.
I think Lynx.js maybe have better shot at React Native since they want to support other frameworks instead of only React.
after small digging they have Full VSCode debugging [0] which is nice. RN have Radon IDE but it's a paid sub. What's interesting Valdi using Hermes (the one from RN) so maybe there is a way to retrofit this to work for RN. Wondering if they did AOT and JIT by themselve or they using static hermes branch or using only hermes in dev mode.
[0] https://github.com/Snapchat/Valdi/blob/main/docs/docs/workfl...
I was at Snap during this project’s early days (Screenshop!) and spent a bit of time debugging some stuff directly with Simon. He’s a wonderful engineer and I’m thrilled to see this project out in the open. Congratulations Snap team! Well deserved.
I'm surprised Snap of all companies invested in a cross-platform UI framework given how simple their app seems in comparison to more complex ones out there.
And more importantly, Snapchat seems like an app which could highly benefit from tight integration with native features (eg. camera, AR features, notifications, screenshot detection, etc.)
Perhaps for the same reason we got Airbnb of all companies to create Lottie. https://lottie.airbnb.tech/#/
These companies have super talented engineers and can afford to invest in skunkworks projects like these when they can’t find any suitable options in the market.
More like "super talented engineers" will keep increasing cost of such projects until they get told this stuff doesn't generate revenue/cost cutting is happening, so work more on ad tech, leave or find external free labor("community") to maintain it.
As far as Im concerned, Snapchat is onw of the most complicated apps thats routinely used by hundreds of millions of people. You yourself listed all the features they have. And every one of them is pixel perfect, with insane amounts of time spent perfecting the user experience of every single ome of those features. In fact, the success of Snap could be attributed to how pixel perfect the app is.
And then you call it simple?
I share your opinion, but I think of the comment above like this. If something thinks your ui "just makes sense" and is dead simple to use, then you know you've perfected it. That is the best compliment you can get.
You kind of just proved my point. If they want attention to detail and good performance then writing native is probably better. The simplicity that I was referring to was the number of views that need to be implemented. A cross platform UI framework would help if there were hundreds of views that needed to be built consistently but for the number of views in Snapchat, I think native implementations would probably be faster and cheaper.
As for the "success of Snap could be attributed to how pixel perfect the app is". I think the success of Snap can be attributed to a lot of things. But if you took a look at how unoptimized the Android experience was in 2017 when it was taking off I don't know how you could call it pixel perfect.
Snapchat, an app which half-assed picture taking so hard that it did so by simply snapshotting the camera preview, rather than bothering to take an actual photo.
Definitely one of the cooler projects to watch while I was there. I recall the goal was to open-source it from early on, so I'm glad to see it come to fruition!
Same! I've worked with Simon on this and tried (and failed) to port it to web. Truly a smart guy - and congratulations to the rest of the team!
Would you use this framework for a project today?
“Composer” ;)
I cannot possibly think of something I would want to use less. A Snapchat-developed UI framework where communication is done via Discord sounds like something carefully designed to repulse me.
Tons of software projects have moved their communities to discord. Not saying it's a great thing, but you're self selecting out of the future.
If the future is unable to think critically, I'll stay in the past.
What would you use instead?
Self-hosted forums, github's built-in forums, IRC; Practically anything but Discord.
I’m not sure I trust snap of all companies to make a good cross platform framework after how terrible their android app has been.
I think it’s been changed since, but wow was it weird finding out that instead of taking photos, the Android app used to essentially take a screenshot of the camera view.
I worked on the camera in Instagram iOS for a while. There at least, there could be a 5,000ms latency delta between the “screen preview” and the actual full quality image asset from the camera DSP in the SOC.
I don’t know a thing about Android camera SDK but I can easily see how this choice was the right balance for performance and quality at the time on old hardware (I’m thinking 2013 or so).
Users didn’t want the full quality at all, they’d never zoom. Zero latency would be far more important for fueling the viral flywheel.
> Users didn’t want the full quality at all, they’d never zoom.
Dating apps use awful quality versions of the photos you upload too. Seems to be good enough for most people.
I worked on the Snapchat Android back in 2017. It's only weird for people who have never had to work with cameras on Android :) Google's done their best to wrangle things with CameraX, but there's basically a bajillion phones out there with different performance and quality characteristics. And Snap is (rightfully) hyper-fixated on the ability to open the app and take a picture as quickly as possible. The trade off they made was a reasonable one at the time.
Things have improved since then, but as I understand it, the technical reason behind that is that it used to be that only the camera viewfinder API was universal between devices. Every manufacturer implemented their cameras differently, and so developers had to write per-model camera handling to take high quality photos and video.
:) this is exactly how we used to do it even on iOS, back in the days before camera APIs were not made public, but Steve Jobs personally allowed such apps to be published in the iOS App Store (end of 2009) ...
> Valdi is a cross-platform UI framework that delivers native performance without sacrificing developer velocity. Write your UI once in declarative TypeScript, and it compiles directly to native views on iOS, Android, and macOS—no web views, no JavaScript bridges.
“We’ve got both kinds. Country and western!”
Favourite Blues Brothers quote!
I looked at the source code (as an amateur application developer) and boy, is it over-engineered and complex! Then I remember having built a complex Cordova app more than a decade ago, where I had to make C++, JNI and Javascript interop all play nice and this project feels a lot like that. Lots of moving parts. I suppose this is just the way things are when you are targetting such different ecosystems as Android and iOS _natively_, at the lowest level.
As a solo-dev, I realize well that this project isn't for me. This could be a great tool for experienced folks who know what they are doing. I will stick to Tauri and React Native, it does 80% of what I care about with 20% of the effort. Or until someone builds a nice wrapper around this to make it easy to use (and also add targets for x86_64/aarch64 builds).
Unfortunately no Linux, Windows or even HTML targets?
What does using native view mean? Do they invoke native ui controls instead of drawing their own? Seems similar to boden - https://www.boden.io/
If you are curious how components' state is handled, they employed the React class components method:
https://github.com/Snapchat/Valdi/blob/main/docs/docs/core-s...I miss the React class components. No need for 30 different and error prone useFunctions
Just write 2 native UIs in the 2 platform native languages and share a common core written in any language that offers a C like FFI.
How hard could it be?
I agree, this is the way. To be clear: I'm not a mobile developer, and have only dabbled with it over the years, but I'm generally familiar with the stacks.
If you want to simplify development of a cross-platform app, your work should start by architecting the software in a way that the core business logic is agnostic to the user interfaces. Then your web, mobile, and desktop GUIs, CLI, TUI, API, and any other way a user interacts with your program are simply thin abstractions that call your core components.
The complexity of each UI will inevitably vary, and it might not be possible to offer a consistent experience across platforms or to leverage unique features of each platform without making your core a tangled mess, so this is certainly not "easy" to do in practice, but this approach should avoid the bulk of the work of targetting individual platforms than if you had done it any other way. It should also avoid depending on a 3rd-party framework that may or may not exist a few years down the line.
Agreed.
One extra clarification: If the quality of your app is business critical you should really use the native UI toolkit to offer the best platform integration and user experience.
If your app is not business critical (you just have to offer it - example: dishwasher app, ..) you might get away with using a cross platform toolkit like flutter or react native. But even then this adds a 3rd party dependency as you mentioned which adds risk.
Writing an App in Swift on iOS is boring. The same thing is true for writing an Android app using Kotlin/Java. This is a good thing. Now your developers can concentrate on shipping great features.
This looks promising. I would love to see more examples of what this can do along with screenshots. As is, there is a single Hello World and the components library is “coming soon”. But if it can deliver what it promises that would be pretty cool. React Native is I think the main popular framework in this space.
This is so cool! I'm a React-Native developer, and I'm glad to see more options like this coming into existence.
I've worked and researched heavily in this field. If you want to write one codebase that hits all platforms with _actual native performance_ your only option at the moment is RN/Expo.
Flutter performs better than RN in my experience (mobile)
I often wonder how the economics are justified in making in house frameworks. What is it about Snapchat that requires a new framework but not other apps?
As opposed to what? As opposed to not using a framework or using some other framework?
Using frameworks is expensive by orders of magnitude. It’s additional code which greatly increases tech debt and slows the execution time of the given product pretty significantly. Think about it like this: a business with high confidence developers can ship a new SPA in a tenth of the time just using vanilla JavaScript that fully renders to screen with complete state restoration across the internet in less than a quarter second. That also means the business saves boat loads of cash by shipping faster, experimenting against its user’s behavior, and needing only a quarter of the headcount. So, where do you find these people and how do you retain them?
The economics are pretty simple and completely offensive/hostile to the developers. It’s ultimately about hiring and firing. Developers are a cost center to the business so the goal is to always eliminate training and turn them into a replaceable commodity. That’s it. That developers believe this is somehow a great empowerment is a double win for the employer.
The reason a company might introduce a new framework is because they encounter a problem not immediately solved by existing frameworks. The more frequently that same problem occurs the more a new framework pays for itself.
So developing a project with a framework takes 100x longer than using "vanilla javascript"? That is not my experience.
Not only does it take dramatically longer it also requires dramatically more people, which perfectly aligns with the Brooks’s Law.
Valdi seems very similar in concept to React Native but Meta being the biggest competition to them you unlikely gonna depend on that even if better. Same reason ByteDance (Tiktok) doing Lynx.js (also similar to Valdi and React Native and also based on React).
The only FAANG scale companies that adopted React Native are Microsoft and Amazon because they aren't directly competing with Meta.
Given the user hostility of Google and Apple (and the rest) and the rate at which they emulate competitors and try to crush them, I’d start at a small library or framework and not stop until I had a whole OS.
Is there an AI agent that excels that translating UI codes between SwiftUI, Jetpack Compose and web?
I wish the native iOS part was written in Swift rather than Objective-C like RN.
Why though? You aren’t interacting with it. What difference does it make?
If the framework is used, eventually there will be 3rd party lib adding new features (from the top of my mind, maps), and someone will need to write the bridging with the native SDK. It means the bridge will most likely need to be written in objective-C instead of Swift
How are you not interacting with it? It’s a UI library, no?
You are using the components, not interacting with that 3rd party code. Unless you are debugging/contributing back
So this is like all those other frameworks that compile to native components, except this one is natively Typescript?
I’ll take it
I think? there isn't a typescript runtime? just a build time? I'm not positive how business logic gets executed but:
> it compiles directly to native views
One of the Valdi's authors here. It's using native views under the hood, like React Native, and there are 3 modes of compilation/execution for the TS source. It can be interpreted from JS (TS compiled to minified JS source), interpreted from JS bytecode (TS compiled to JS source, minified, then compiled to JS bytecode ahead of time), or compiled to native code directly (TS compiled to C ahead of time).
An AOT TS -> C compiler is fantastic - how much of the language is supported, what are the limitations on TS support? I assume highly dynamic stuff and eval is out-of-scope?
Most of the TS language is supported, things that are not can be considered bugs that we need to fix. Eval is supported but it won't be able to capture variables outside of the eval string itself. We took a reverse approach than most other TS to native compiler projects: we wanted the compiler to be as compatible with JS as possible, at the expense of reducing performance initially, to make it possible to adopt the native compiler incrementally at scale.
There are significant trade-offs with this compiler at the moment: it uses much more binary size than minified JS or JS bytecode, and performance improvements goes from 2x to sometimes zero. It's a work-in-progress, it's pretty far along in what it supports, but its value-proposition is not yet where it needs to be.
Can this compiler be used outside of Valdi? TS to native AOT sounds incredible.
Rename it Snapp
So now I can finally implement the most god-awful, ugly, cumbersome and unintuitive GUI methodology ever to face a large population of users into my own apps? This abomination that started the whole user-experience decline by making this kind of yuck the gold standard for apps today is finally open source?
Color me yellow.
I hope it has "load spam ads directly into the list the user was about to touch somehow the millisecond before they touch it using magical force field technology so they click the wrong thing every time" functionality. I've been missing that in my apps
Now offering 4 swipe directions!
With instant, subpixel precision!
It's a really wonky app. The main feature works fine, no issue. Their "Stories" section, I can't can navigate that at all, there a no hint to how it works, so I don't use it. Seems a little weird, given that this is where the ads are, why wouldn't Snapchat make that easier to use?
There's also views I can get into which I can't figure out how to leave, so I force close the app to get back.
I don't necessarily think that's a flaw of the framework, just how Snapchat designs their app.
Snap is the greatest innovator of user experiences in this generation. This is evidenced by the fact that literally every other social media app is just a hodgepodge copycat of sorts of what snap invented. For people who introduced themselves to tech with snap as one of their first apps, its the most intuitive thing ever.
When they first introduced video calls, schools had to close for a day.
Imagine then you come here and see someone calls it awful. Can't help but think its just an instance of "old man yelling at clouds".
> have userbase
> introduce feature
Phwoar, ground breaking UX design there!
> When they first introduced video calls, schools had to close for a day.
Which schools, where? Are they in the room with us now?
> For people who introduced themselves to tech with snap as one of their first apps, its the most intuitive thing ever
Point camera. Press button. Pick users.
Gotta try real hard to screw that one up, UI wise.
I suppose you're just salty they didnt make a linux app.
Don't take me argument as one against the point that it was massively popular and influential, en contraire, that's often the common factor in things I tend to dislike: the norm/ the mainstream.
It's mostly subjective when talking UI, and a lot plays in too regarding the lack of competive platforms with different UI's.
My point is that (I think) they became popular because of their UI and UX. They remagined how a small touch screen user experience could be most intuitive if you dont come with legacy mindset. For people used to keyboard and mice this might look weird but snap makes sense to the newer generation.
If all the other apps look similar its because they copied it. This is like calling Citizen Kane boring.
> For people who introduced themselves to tech with snap as one of their first apps, its the most intuitive thing ever
By definition, the first app someone uses will be from their POV the most intuitive app ever. It will also be the least intuitive app ever.
All valid points. Made me actually think about the likely first actions an alien or newborn would take with a 2025 touch screen device. Chomp. Chew. Swipe.
xD
God forbid someone try something different. The app isn’t really made for people that only know how to doom scroll.
Ah yes, Snapchat, an app famous for its high performance, efficient apps, which definitely never made your phone hot and drained your battery.
Seriously, if there’s an app that sticks in my head for being noticeably laggy, you couldn’t pick a better example than Snapchat.
> Valdi – A cross-platform UI framework
I presume this is a Text UI. How does it compares with ncurses and termcap ? /s
Not related to this, but abandoning Key DB was the worst thing they could do.
Its hard to imagine not going fully native in the modern day with coding agents. Most of the code can just be clanked out.
If your entire company is all about making a single good app, I doubt having AI changes the architecture much. Its still an architectural decision of whether you're going to have a single codebase for your app and focus on a framework to transpile it. Either way you need actual teams of experts on iOS android etc, no single person is going to master all of them.
Not to troll , Do you need such shims in the era of llm ?
Yes? Dear lord I want determinism
by llm you surely mean tech debt generators right?
tech debt generator - another job AI is taking away from humans!
I’ll finally accept I’ve been replaced when they start leaving #TODO notes to themselves that never get fixed.
Not every user interface need to become a LLM chat app.