Maybe that's why they behave differently?

As you’re a solo dev, one of your most important resources is your mental capacity. Native platforms & their dev stacks are a world of their own.

Going with WebView allows you to spend your time on other things that matter more. It also helps you prototype quickly and get a feel for what works.

Later, after you have a better, more solid idea of what your game is, if performance is an issue, then you can convert parts of it (or all of it) to native.

(By the time your game is done, I suspect the mobile app dev landscape is going to be quite different than what it is now.)

Your last paragraph is interesting though, in what way do you think mobile dev is going to change?

(I'm not associated with Zed, just a happy user looking to share the goodness.)

We can speculate all day, but we should try to analyse these sorts of things from a learning perspective. What can we learn from Russia, China, etc? How are they better?

Well, the last couple sentences is me paraphrasing. But one thing that many in the West boast about is the ability to criticize the systems to improve said systems. Let's see if actions match the rhetoric.

In 20 years we'll look at a lot of things that are normalized today like we look at cigarettes now, in disbelief at how unhealthy it was.

https://faiface.github.io/par-lang/introduction.html

I just open a Claude Code Thread, tell it what I want, bypass permissions (my remote is a container), and let it work. And it works wonderfully!

I guess the “integrated” part of IDE is pretty important.

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.

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.

> Definitely every one of these is sluggish at best on a very modern machine but they are also full of UI annoyances.

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?

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.

A webview app is by design bad. Webviews were made for one thing - web views.

I thought it was some legal thing about App Store competition.

(In the context of "Apple has a private CSS property to add Liquid Glass effects to web content")

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

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

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!

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.

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

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.

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.

- 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

It does seem that many RN apps do React (not native) components when they need to do something custom, which may explain my sub-par, non-native experience with the RN apps I have used.

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

1. https://news.ycombinator.com/item?id=45250878

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)

AVFoundation on iOS especially.

Or you ship your HTML/JS and not just embed a URL?

The platforms provide more than enough capability to build basic WebView apps with minimal effort, and usually the DX is good.

Native experience for users, where the app appears in their app drawer/library. The app doesn’t disappear randomly like shortcuts do on iOS (maybe this is fixed now?).

Better DX for certain features, like notifications, storage, control of caching, local network device access, etc.

And it’s still usable as a website for everyone else on any platform.

Having used WebSockets a lot, I’ve realised that it’s not the simple fact that WebSockets are duplex or that it’s more efficient than using HTTP long-polling or SSEs or something else… No, the real benefit is that once you have a “socket” object in your hands, and this object lives beyond the normal “request->response” lifecycle, you realise that your users DESERVE a persistent presence on your server.

You start letting your route handlers run longer, so that you can send the result of an action, rather than telling the user to “refresh the page” with a 5-second refresh timer.

You start connecting events/pubsub messages to your users and forwarding relevant updates over the socket you already hold. (Trying to build a delta update system for polling is complicated enough that the developers of most bespoke business software I’ve seen do not go to the effort of building such things… But with WebSockets it’s easy, as you just subscribe before starting the initial DB query and send all broadcasted updates events for your set of objects on the fly.)

You start wanting to output the progress of a route handler to the user as it happens (“Fetching payroll details…”, “Fetching timesheets…”, “Correlating timesheets and clock in/out data…”, “Making payments…”).

Suddenly, as a developer, you can get live debug log output IN THE UI as it happens. This is amazing.

AND THEN YOU WANT TO CANCEL SOMETHING because you realise you accidentally put in the actual payroll system API key. And that gets you thinking… can I add a cancel button in the UI?

Yes, you can! Just make a ‘ctx.progress()’ method. When called, if the user has cancelled the current RPC, then throw a RPCCancelled error that’s caught by the route handling system. There’s an optional first argument for a progress message to the end user. Maybe add a “no-cancel” flag too for critical sections.

And then you think about live collaboration for a bit… that’s a fun rabbit hole to dive down. I usually just do “this is locked for editing” or check the per-document incrementing version number and say “someone else edited this before you started editing, your changes will be lost — please reload”. Figma cracked live collaboration, but it was very difficult based on what they’ve shared on their blog.

And then… one day… the big one hits… where you have a multistep process and you want Y/N confirmation from the user or some other kind of selection. The sockets are duplex! You can send a message BACK to the RPC client, and have it handled by the initiating code! You just need to make it so devs can add event listeners on the RPC call handle on the client! Then, your server-side route handler can just “await” a response! No need to break up the handler into multiple functions. No need to pack state into the DB for resumability. Just await (and make sure the Promise is rejected if the RPC is cancelled).

If you have a very complex UI page with live-updating pieces, and you want parts of it to be filterable or searchable… This is when you add “nested RPCs”. And if the parent RPC is cancelled (because the user closes that tab, or navigates away, or such) then that RPC and all of its children RPCs are cancelled. The server-side route handler is a function closure, that holds a bunch of state that can be used by any of the sub-RPC handlers (they can be added with ‘ctx.addSubMethod’ or such).

The end result is: while building out any feature of any “non-web-scale” app, you can easily add levels of polish that are simply too annoying to obtain when stuck in a REST point of view. Sure, it’s possible to do the same thing there, but you’ll get frustrated (and so development of such features will not be prioritised). Also, perf-wise, REST is good for “web scale” / high-user-counts, but you will hit weird latency issues if you try to use for live, duplex comms.

WebSockets (and soon HTTP3 transport API) are game-changing. I highly recommend trying some of these things.

    How to Write in Cuneiform, the Oldest Known Writing System in the World

You can argue that, "well, obviously!" but correctness and exactness are what makes science, history, journalism, etc good, and allowing incorrectness like this is a step backwards.

I read a history book when I was a teenager (can't remember which one, unfortunately), and the author wrote a preface that said something along the lines of "Everything in this book is based on the published information I could discover during my research period of April to September 1999. I have chosen to write in absolutes--stating many things as certain and clear--but in reality there is still much we do not know about this time period. No history author should say their writing is fact and any good historian will make it clear that their work is composed of assumptions layered on assumptions. Please read these works with this in mind."

If you don't have a preface like that, you should add "known" to your title/sentence! I will argue with someone all day over this! I will die on this hill!

How to Write in Cuneiform, the Oldest Known (by the author) Writing System on Earth, the third planet from the Sun in the Milky Way galaxy, as of 2025 as long as you're a human without a major disability that would prevent you from using these techniques or are at least a being with similar hands and arms also able to obtain the necessary materials and can read and comprehend modern English if you aren't too busy doing other things and expect to live long enough to complete the task

You often get nitpickers going after some small technically correct detail which may be true but no reasonable person in the intended audience would ever actually need to be told. No one reading the original title would assume that the author had omniscient knowledge of the whole human history of writing beyond present archaeological fact and this doesn't need to be pointed out.

Of course, if you’re a fallibilist you believe that it’s always possible that you’re making a mistake. It seems unnecessary to always add “unless I am mistaken,” because that hedge always applies.

Writing has only been invented independently a few times in history, so it seems reasonable that cuneiform could be the first.

Why do we not see more writing in the archeological record? Maybe agrarian societies both motivate writing and are required to provide the free time to invent it? Or perhaps it was written on media that's subject to decay? If some society developed writing on tree bark 100,000 years ago, none of that is going to survive and we'd never know.

There was prehistoric (i.e. pre-writing) trade between Sumer and Egypt. Scholars have argued that the idea of writing based on the rebus principle—but not a specific writing system—may have been communicated one way or another through this trade contact.

Your claim that the cultures were "very strongly linked with near identical cultic symbols and building plans for temples" is a new one for me—and I volunteer at a museum of ancient near eastern archeology. The material culture of pre-Dynastic Egypt and Sumer are rather distinct from each other. And when we do get writing describing their religion, those are also rather distinct from each other.

Much like fossils, the vast majority of human writing is quickly lost to posterity. Paper, bark, and string decompose; clay and rock break; all writing materials can be repurposed for other writing (palimpsets) or other uses (reshaped to wall stones).

Still, given the paucity of known, independently invented writing systems... We may well know of all of them.