4 ms·

I think developers often want to find a “one true cross platform toolkit for all cases” and I don’t believe that will ever exist. It depends so much on both you

I think developers often want to find a “one true cross platform toolkit for all cases” and I don’t believe that will ever exist. It depends so much on both your app/market but also the skills and experience within your team. No 1 priority is move quickly. Flutter is brilliant, and probably the way to go, for some apps. A great example of a successful Flutter app is the Sonos app, relatively simple and responsive ui talking to an api. No “rich” or user supplied content. Although they haven’t replaced their desktop app with the flutter app, my guess is that it is the plan. I think Flutter is brilliant for that type of IOT app, banking/crypto/utilities also the sort that would work well. I don’t think it’s best placed if you want to start using WebViews for some content, when I was last looking at it a year ago there were serious problems. 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. 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. For an e-commerce app I would probably go Iconic/Capacitor too, the Amazon app for example is mostly webviews. Productivity apps are much more difficult to recommend for as you probably need large native components.

udbhavs 5y ago
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/NativePageTransitions https://github.com/Telerik-Verified-Plugins/NativePageTransi...) but it's abandoned.
- samwillis 5y ago
  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.
- danielvaughn 5y ago
  Wow that’s a really good idea. I love it.
- ohgodplsno 5y ago
  Because the UX of having a non-native app is, and will always be dogshit.
- joemasilotti 5y ago
  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 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 https://jumpstartrails.com/ios
- mamcx 5y ago
  Because, specialy on android, is far slower…
amelius 5y ago
I personally prefer a set of libraries over an opinionated framework with integrated dev tools.
- samwillis 5y ago
  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.
The_rationalist 5y ago
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.
- samwillis 5y ago
  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.
- sirwhinesalot 5y ago
  > 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.
stragio 5y ago
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.
newlisp 5y ago
What's the difference between Ionic and Capacitor?
- samwillis 5y ago
  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.
jcelerier 5y ago
For content creation apps, Qt is great: Krita, DaVinci Resolve, Allegorithmic, Qtractor, LMMS... (and my shameless plug ossia score)
sirius87 5y ago
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/ https://kotlinlang.org/lp/mobile/
- samwillis 5y ago
  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.
  - vanilla_nut 5y ago
    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.
- jamil7 5y ago
  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.
jamil7 5y ago
> 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.
ramesh31 5y ago
>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.
- zjyeung 5y ago
  > 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.

udbhavs 5y ago

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/NativePageTransitions https://github.com/Telerik-Verified-Plugins/NativePageTransi...) but it's abandoned.

samwillis 5y ago
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.
danielvaughn 5y ago
Wow that’s a really good idea. I love it.
ohgodplsno 5y ago
Because the UX of having a non-native app is, and will always be dogshit.
joemasilotti 5y ago
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 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 https://jumpstartrails.com/ios
mamcx 5y ago
Because, specialy on android, is far slower…

amelius 5y ago

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

samwillis 5y ago
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.

The_rationalist 5y ago

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.

samwillis 5y ago
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.
sirwhinesalot 5y ago
> 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.

stragio 5y ago

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.

newlisp 5y ago

What's the difference between Ionic and Capacitor?

samwillis 5y ago
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.

jcelerier 5y ago

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

sirius87 5y ago

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/ https://kotlinlang.org/lp/mobile/

samwillis 5y ago
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.
- vanilla_nut 5y ago
  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.
jamil7 5y ago
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.

jamil7 5y ago

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

ramesh31 5y ago

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

zjyeung 5y ago
> 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.