Hacker News Reader

I've been wondering why webviews with native page transitions aren't a more commonly used thing. It improves the UX a lot by dealing with the abrupt navigation changes of regular web apps. There was a plugin for Cordova that did this (https://github.com/Telerik-Verified-Plugins/NativePageTransi...) but it's abandoned.

I use Turbo Native on iOS to do exactly this.

You render your mobile web view like normal, wire up a JavaScript handler (formerly known as Turbolinks), and push native screens on iOS. It works really well for CRUD and "boring" SAAS apps with little interaction outside of forms. And when you need higher fidelity dropping down to SwiftUI or UIKit is straightforward.

https://github.com/hotwired/turbo-ios

To make things even simpler, I built Jumpstart iOS, which takes care of all of the Swift boilerplate. Navigation, authentication, and push notifications all work out of the box after adding a few endpoints to your server.

https://jumpstartrails.com/ios

Same here, it’s something I wish Capacitor supported.

Last year I experimented with using NativeScript in a Capacior app to open native modals with a second webview. Since then Ionic have released “Capacitor Portals” which brings all the native apis available within the Capacitor webview to native apps, effectively allowing you to embed capacitor views in another app. I wander if there is the potential to combine the two to get the native view transitions.

Edit:

Just to elaborate a little further on my experiment. Effectively what you ended up with was the two webviews being able to communicate with each other as though you had used the window.open or frames JavaScript api in the browser.

Wow that’s a really good idea. I love it.

Because the UX of having a non-native app is, and will always be dogshit.

Because, specialy on android, is far slower…

> If you are building a social media app, either Native or React Native (or a combination) is probably the best way to go. You are aiming high so need the best performance and ux.

I'd also add that from a business perspective if your product heavily depends on or is entirely mobile-based then it often makes sense to go native and remove an extra party, you don't want to be stuck waiting for upstream fixes or features to land months after they've been released.

Agree! I have been building a React/Next capacitor application for a Dutch e-commerce with a colleague.

Up until now everything is fine for our purposes and performance is near native. Usually similar e-commerce apps require multiple teams, or at least 5+ employees, to release an app on web, Android and iOS. Due to the fact that we have just one single codebase, we can still manage it with the 2 of us.

I also recommend the Capacitor community on Discord in case you need help getting started.

>If you are building a b2b SAAS app I would probably reach for something like Ionic/Capacitor. You can share almost all you codebase with your web/PWA/desktop (electron) apps and can achieve it all with a tiny team. If you need a little more native functionality then adding in NativeScript to a Capacitor works very well.

Honestly nowadays with Expo I would never suggest doing a hybrid app anymore unless you have a large existing JS codebase you want to leverage. Expo makes React Native development so ridiculously simple from the point of scaffolding your app all the way through the app store submission process that there's really no productivity loss anymore vs. doing an Ionic app. The tooling has come so far in the last 10 years that you can just easily develop a native iOS app in Javascript like it's a web app now.

> The tooling has come so far in the last 10 years that you can just easily develop a native iOS app in Javascript like it's a web app now.

Agreed. I would even say in these past 3 years or so, React Native development has smoothed itself out. The experience of setting up an app and being productive in it coming in as a web developer is phenomenal. One thing is that the community support is still small compared to native or even React itself. Peformance too is lacking. I've been waiting for the new architecture Fabric to come in replacing JSC with JSI but it's taking quite a long time. There still isn't a clear estimate on it's release yet.

For mobile, if you ask me, the only sane cross-platform strategy is what Kotlin Multiplatform Mobile [1] intends to do: portable business logic, and leave the UI aspects to each platform, keeping them native.

Both Android and iOS have been making strides in simplifying DX for composing expressive UIs. It only makes sense to use those new Android Studio/XCode features as they come.

[1] https://kotlinlang.org/lp/mobile/

While I agree where Kotlin is going with their multi platform tooling is great, I do think it’s just one more option in an already good bag of options. And a strong one at that.

My one observation though is that for many (the majority?) of mobile apps the UI layer is the vast majority of the app, easily 70-80%. Especially for apps where the business logic is calling a http api, which most CRUD type apps are. For these a cross platform toolkit that abstracts away ui differences so you only have to build it once is a massive plus.

KMM shows promise for writing the same db/network logic for iOS, Android, Windows, and macOS. (less so on desktop, but it does work) Realized expectations give you a good way to extend that underlying layer a bit further. But you’re totally right — in the end, you still need to undetstand iOS and Android development, UI in particular, to make it work. It also doesn’t help that KMM is currently a buggy mess, Android Studio has a million issues with it, and the documentation is sparse to nonexistent for completely pedestrian use cases (good luck writing tests for anything). I hope it shapes up soon though.

I've been waiting for the right opportunity to use it and for it to mature a little more. I really wish we could go the other way since we have a bunch of existing Swift packages and our team is much stronger on iOS than Android.

For content creation apps, Qt is great: Krita, DaVinci Resolve, Allegorithmic, Qtractor, LMMS... (and my shameless plug ossia score)

The myth that Ionic is slower than react native (android native - > skia ) or flutter (skia) has to stop. The evidence isn't just there anymore, chromium is the open source library with the most human resources on earth (mlre than 1 million commits) and therefore has more optimization resources than any competitor. The addition of edpressivity through new features in newer releases does not slow the browser despite the very infantile and hand wavey idea of "bloat" that many HN readers share. In fact Ionic should be even faster than Electron since it embed many modern optimization practices inside the UI framework. Unfortunately it seems people have zero interest doing serious benchmarking of similar tasks on multiple GUI renderers so the myth stay pervasive. What is sure is that you will never actually have significant performance issues in Ionic or otherwise you're doing something wrong. Still the myth allows react native and flutter to survive relevancy despite their major ergonomics and expressive inferiority, but for how long? People are used to experience that Electron apps are usually better and faster. The smartphones double standard will break.

> Electron apps are usually faster.

Not my experience, and I'm not talking benchmarks. That said I barely use my phone and I'm thinking mainly about desktop applications. Mac-native apps are universally faster and more responsive than Electron-based equivalents.

Doing more work costs more resources than doing less work, and it's hard to beat JITing Javascript and manipulating and rendering HTML+CSS for wasteful computation, no matter how much you optimize it.

That said, I've used phone apps that were essentially some webpage in webview that were highly responsive and pleasant to use, so it's certainly possible to have a good experience with webapps.

Reducing the amount of Javascript and using simpler HTML+CSS would also probably go a long way to make these apps fasters and lighter. I remember using AJAX-based chat websites in the 2000s that ran perfectly fine on hardware far weaker than even a 5 year old phone, so how the heck does Slack have such poor performance? That's the real problem.

Completely agree with you on performance, certainly on any mobile device with less than 5yo tech. I think there are still a few performance problems on older/low-end hardware, that’s why for social media type apps I would recommend native. You would have the same perf problems with Flutter and React Native on that hardware.

I have only one significant complaint that effects Capacitor on iOS and it’s a WebKit bug (Ionic can’t fix it). With WebKit on iOS if you have an overflow:scroll with a text input of any kind (basically any app you build) the text cursor or selection highlight will remain visible outside the overflow area when you scroll. So for example if you select text in an input and scroll the view so the input is under a fixed toolbar, the selection highlight or cursor is visible infront of the toolbar. It looks very messy, I wish Apple would fix it. The minute you see it you know it’s not a native app.

> Still the myth allows react native and flutter to survive relevancy despite their major ergonomics and expressive inferiority, but for how long? People are used to experience that Electron apps are usually better and faster.

My concern with Ionic/React native isn't speed (I'm sure it's good enough), it's maintainability. I've been burned enough by the JS ecosystem to stay away from it when I can. It usually takes around 1 hour to update 6 months worth of Flutter framework & packages updates, I can't say the same about the javascript ecosystem.

On paper it looks awesome, in practice I just don't want to deal with those maintenance issues anymore.

I think the majority of Ionic apps have been built with Angular, which I believe has had a fairly clean upgrade path. The React and Vue binding are newer but both aren’t to hard to upgrade (ignoring the vue2-3 transition, Ionic only ever supported 3)

Plus, with Ionic in contrast to the majority of JavaScript frameworks, you are using one built by a company where the framework is the core business. They have a long track record and sustainable business. They aren’t going anywhere.

Maybe I've been a bit unfair and I should give it a go, I just had so many bad maintainability experiences in the JS world that I was just staying away from it if I can.

I personally prefer a set of libraries over an opinionated framework with integrated dev tools.

There is obviously no correct answer here, very good arguments on both sides.

Personally I prefer an opinionated framework, I don’t have to research library’s and tooling. It all just works and I have a single set of docs for reference.

What's the difference between Ionic and Capacitor?

Ionic is a html/javascript/css mobile ui framework using web components, with bindings for Angular, React and Vue. You can build PWAs, mobile web apps, or with Capacitor actual mobile apps with it.

Capacitor is a mobile app toolkit for building apps with web technologies in a webview. Effectively the successor to Cordova/PhoneGap. It’s built and maintained by the same team/company as that behind the Ionic framework.