Last updated: 2024-10-25
What are the general technology choices when building an app that should run on both mobile and web/desktop?
Let's list ...
For further actions, you may consider blocking this person and/or reporting abuse
Great breakdowns, thank you for all this. It's always helpful to enumerate an exciting space of great options. When possible to update a few inaccuracies regarding NativeScript would help to bring better understanding:
Inaccurate: * Uses a WebView.
Accurate: * Uses natural native platform view rendering
Inaccurate: "a major contributor"
Accurate: All the major contributors are involved on a daily basis and meet once a month on a growing Technical Steering Committee formalized with best practices from the OpenJS Foundation for healthy open source innovation.
One can find negative posts across all open source communities (everything on this list) and it's okay; anyone can voice their opinion anytime as it helps establish some understandings. I agree with a lot of sentiments in the ycombinator link mentioned. NativeScript was a bit ahead of its time with marketing in the beginning but it should not detract from what the technology is. It's a promising technology that is being led and cared for by a loving community and if you believe in bringing innovation to the JavaScript community, NativeScript offers a lot that others can be involved with in the spirit of open source to take it well beyond past complaints (that is why we all engage in open source to begin with).
I'm a fan of everything on this list.
Thanks for the feedback and corrections!
I meant you’d display your PWA in a WebView. Since it’s about crossplatform development (including web).
Is there another way to achieve that in NativeScript?
oh, so you mean all major contributors left?
Thank you for updating to clarify that point much appreciated. With web/mobile sharing NativeScript is just TypeScript driven so you can share as much as you’d like to achieve best result on the target platform. Since NativeScript is just JavaScript there’s an immense amount of code you can share to drive both web and mobile tailored UX. Don’t believe I’ve ever heard of anyone putting a PWA into a NativeScript app’s webview. I would also recommend combining NativeScript with Ionic Portals if one was going that route ({N} being inherently flexible works with everything on your list):
Hope that helps bring more understanding to a great breakdown.
Thank you for your insights!
If you want a cross-platform app that shares as much code as possible between iOS + Android + Web, how would you ideally go about it with NativeScript?
I updated the section on NativeScript with some options, as I see them, after doing a bit more research into it. It's still not entirely clear what the best cross-platform strategy with NativeScript would be. I think I'm still leaning towards a Web View, since it would allow running most of the same code on both native and web..
The degree of flexibility possible with iOS+Android+Web without compromises is the core reason I became interested in NativeScript many years ago (I personally didn't pay attention to the marketing of it -- what it was under the hood is what interested me the most).
Regarding cross-platform strategy with NativeScript + web development, the key part about this technology is it aims to be just natural JavaScript development, meaning all the same strategies you would use to share TypeScript/JavaScript code apply. This is a large topic with tons of options (and opinions) but the NativeScript TSC provides, as a starting base, some suggestions to frame a good fundamental understanding in terms of best practices:
docs.nativescript.org/code-sharing...
In short, any monorepo strategy is great for TypeScript driven "shared" (aka "code sharing") developments. Npm workspaces, yarn workspaces, Nrwl Nx, Turborepo, Microsoft Rush, the list goes on and on.
To expand on this with even more fine grain guidance, nStudio (professional software services), provides a whole set of tooling, simply called "xplat", aimed at enhancing Nrwl Nx specifically for diverse cross platform developments. It could also be adapted to work in any other monorepo tooling as well.
To answer your question, "not entirely clear what the best cross-platform strategy with NativeScript would be"... Here's some helpful information on xplat, which provide generators to get teams off the ground with a set of best practices for diverse "cross-platform" developments. This approach has been put to use successfully for several years and continues to be used to scale large TypeScript driven projects (enterprise and consumer facing):
There's quite a lot of work going on around NativeScript which continues to open up desirable workflows for TypeScript/JavaScript driven teams. On the inverse side, interestingly, some of the more recent work explores powerful workflows for purely native teams (Swift, Obj-C, Kotlin, Java) to work hand-in-hand with web teams to make use of diverse talent working better together without cornering teams into one style to bring ideas to life.
To conclude for me personally, the reason I'm attracted to NativeScript and enjoy working around it is it's ability to open up all the options on your list with angles to make them work together without cornering one out. I love technology and want to be working with all innovation at all times or, at a minimum, at least be able to, without inherent barriers from the get go; which is why I'm a fan of everything on your list -- I can work with it all by taking advantage of NativeScript.
I'd like to mention a new exciting option (for a crossplatform app) that I recently came across, that AngelRs github.com/angel-rs is working on:
11. Qwik (City) + React Native, using shared qwikified React components.
An especially promising alternative for those that care greatly about performance and SSR/SEO on Web.
Quote from AngelRs on 2022-09-23 from the #qwik-help-archive channel on the Builder.io Discord:
nice breakdown. thought id mention the link NativeWind + Solito + Next + Expo Monorepo example is no longer there
Thanks, it was the Tamagui link, and I updated it now.
This is the new link:
Tamagui + Solito + Next + Expo Monorepo
With the arrival of WASM GC, recently announced by Google, then Kotlin Multiplatform + Jetpack Compose has surfaced as a potential option for cross-platform apps. See more here:
youtu.be/RcHER-3gFXI?t=1010
—- Update 2024-10-25
I now recommend using the One JS full stack framework onestack.dev/ if you can, for your whole project, if you are just starting out. You can use it for web-only projects. But it is ALSO a full crossplatform solution integrating:
Hey! Nice post. Just a couple of things about NativeScript
it doesn't use a WebView at all. It allows you to use one if you want to display some web/local content, just like you can do natively. All views in NativeScript are 100% native (Button generates android.widget.Button and UIButton)
you seem to have stumbled on one of the only community dramas, sorry for that. I'll admit that that "major" contributor did some "contributions" back in the day (mostly plugins, few core contributions), but he's also the creator of proplugins (another one of your sources). He tried to split and cause drama in the community and quit when no one wanted to work with him anymore. All of his work had better open source alternatives by the time he quit.
Again, I'm sorry that you had to go through that inflammatory post. You can see in the post comments other people disagreeing with him. I don't think anyone in the entire community was sad he left. He had been absent for many months while one by one his plugins were being replaced by better (and free open source) alternatives and he decided to "quit" by writing an inflammatory post.
He's always been inflammatory, though (as can be seen by the proplugins "why" page), and the proplugins initiative only managed to cause doubt and distrust among the community. I've been using NativeScript since 2018 and never have I ever needed a plugin from that, which clearly means everything he says on the "why" page is a big lie from someone who desperately wanted to make money from open source.
I can guarantee you NativeScript is better now than ever, and you can give it a try straight up from StackBlitz front page: stackblitz.com/?starters=mobile
Thanks for the correction and insights!
If you want a cross-platform app that shares as much code as possible between iOS + Android + Web, how would you ideally go about it with NativeScript?
I updated the section on NativeScript with some options, as I see them, after doing a bit more research into it. It's still not entirely clear what the best cross-platform strategy with NativeScript would be. I think I'm still leaning towards a Web View, since it would allow running most of the same code on both native and web..
I also updated the section about the community controversy, to account for the fact that I don't precisely know how major the contributor was, and that there are more sides to the story (as I'm glad you detailed).
Unfortunately Eduardo has no clue what he is talking about. He wasn't involved, he wasn't even on the TSC at that point, lol... He also doesn't mention he is now on the TSC and also has a vested financial interest in seeing NS stay alive, I'm pretty sure his company is still the largest sub-contractor of nStudio for NS jobs... Of course he is going to try and disparage me and divert people from the actual facts I laid out based on REAL numbers. Anyone can go run the numbers, like I did... But lets just disparage Nathanael to cover up the facts...
To set the record straight:
I still have 3 of the 4 top plugins in the community by downloads (which it has been this way for many many years). And nothing that I'm aware of has been replaced by "better" plugins. The only community plugin that is actually "starting" to catch up to possibly replace one of my well battle tested plugins, has several bugs that can crash your app in it. And many of my other plugins that aren't used by as many apps are also still top in their categories with nothing else even remotely close in downloads. So what a joke of a statement. Really I have no issues if any of my plugins are replaced by others, that is the open source way -- but his statement is again trivially proven false by actually looking at the facts. ;-)
I did leave, but not disgruntled at NativeScript or because nobody wanted to work with me. I left quietly because I was hoping to give NS the best chance to survive, as I love the technology stack, it really is one of the best stacks if it could be maintained. Even though I don't trust Nathan Walker, he was a better TSC chairman that I would have been. So airing the drama to stay at nStudio in my opinion would have split the community and caused several of nStudios clients to leave, thus killing nStudio pretty quickly and thus killing NativeScript almost immediately. So I left quietly, hoping that nStudio could change NativeScript's trajectory. I still haven't aired any "drama" about what happened, just that basically a major disagreement occurred. ;-)
If he would bother to check the facts, he would realize I did maintain several of my plugins after I left nStudio, I just refused to do any business with Nathan Walker which meant I avoided doing anything to the core NS framework...
People have different takes on ProPlugins. Some people hate it, some love it... can't please everyone... ;-)
As for Stackblitz, still an awesome idea. But it now sucks more that the app harvests your email info before you can do anything with it. The old Preview was way better with no roadblocks to getting started, so one step forward, two back.
I personally don't see StackBlitz changing the core issue that NS only has a few developers for the plugins, and sees very few updates to actually fix bugs, I still have multiple bugs reports I posted back when working for nStudio that are still open...
So, yeah, Eduardo -- the Framework is thriving and I'm just disgruntled... ;-)
Honorable mention:
Hyperview - Lets you use Server-Driven UI Rendering of a native app, via rendering server-generated XML. Could be used with Rails, Django or any HTTP server on the back-end etc.
"Hyperview is our open-source project to bring the benefits of thin-client, HATEOAS development to native mobile apps. The project consists of two parts:
Hyperview XML (HXML) is an XML-based format to describe native mobile UIs. It supports common UI elements like headers, scroll views, lists, text field, and much more. It also supports styling and a behavior syntax for describing user interactions (touches, gestures, input interaction) without the need for scripting.
Hyperview Client is a cross-platform library for rendering HXML in mobile apps. Implemented in React Native, it can be embedded in existing apps, or you can use it to create a new app from scratch."
"
hyperview.org/docs/guide_introduction
Recent honorable mention:
Crux - "Cross-platform app development in Rust" - github.com/redbadger/crux
Why? - From the repo:
Another honorable mention:
Quasar for Vue.js. "One source code for all platforms simultaneously with all the latest and greatest best practices out of the box."
Another mention:
CodenameOne - "Cross-platform framework for building truly native mobile apps with Java or Kotlin. Write Once Run Anywhere support for iOS, Android, Desktop & Web."
hm.. but you said: "And you deploy your Flutter Web build to your domain's /app path."...?
Note: I'm not talking about a Web View here (for rendering a webapp on native). I'm talking about the opposite: rendering Flutter on the web, where Flutter Web internally uses a HTML Canvas element.
yes, such a monorepo is possible. But you'd still have to deploy the actual UI code (written in Flutter, presumably) to the web somehow. Flutter Web allows that. But is limited to a HTML canvas, as mentioned (i.e. no DOM, so no SEO).
Thanks for mentioning it! I'll add it to the list. :-)
Ok, and how does it connect to Flutter? You show the website/PWA in a Flutter Web View?
Thank you! That sounds interesting, do you have a link to a good resource to learn more about this approach?
but if you use Flutter Web, then you're rendering to a Canvas and effectively losing out on SSR/SEO, no?