Valdi – a Cross-Platform UI Framework That Delivers Native Performance

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

> it compiles directly to native views

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

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.

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.

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.

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.

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

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

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?

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 :')

I saw another comment calling it "webview app", which is also valid, but we call it "hybrid app".

Recent mid-tier phones are powerful enough that webview has a negligible impact on performance.

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.