Why you should NOT use NativeScript

- It's multi-framework (Vue, Angular, React or Svelte); easy to pick up for web devs

- The per-framework implementations are fairly similar to the web-variants (except it uses NS component tags vs HTML tags)

- UI abstraction layer that maps the NS components to real native UI components for iOS/Android (instead of Flutter's gimmicky pixel-by-pixel OS element duplication ala Adobe Flex)

- Use of native UI elements lead to performant UI elements (recyclerviews, tabs etc). React Native plugin devs had to tediously re-create elements like the recyclerview with custom logic (see 'RecyclerListView'). The core team adds new UI elements fairly quickly after OS releases, as they only have to create the bridging code

- Out-of-the-box code bridging; access native methods/variables on iOS/Android from JS. E.g. accessing the Android notch API can be done with a few lines of JS

- Recognizable CSS elements for styling (margin, borders, gradients, box-shadow)

- Performant; fairly quick cold-boot and no iOS shader-cache jank like with Flutter. OP likely has a web-dev background and used too many nested views leading to jank (as it would with a native app).

The struggles:

- Inconsistent maintenance of (semi-)official plugins like background uploading and toasts. Hard agree with OP.

- Overuse of outdated, third-party Cocoapods/Gradle plugins for their plugins. Some Cocaopods they use don't even have iCloud support.

- Large backlog of Core issues/bugs

- No more Sidekick (The 'Expo' equivalent for NS), as it wasn't part of the acquisition. This tool was really handy for low-barrier deployments/boilerplate code rollout

But the real problem is adaptation. No large adaptation = no big sponsors = no full-time development. Earlier it was in hands of Progress which had a highly talented team from Bulgaria working on it full-time. Progress tried to use NativeScript as an on-boarding strategy to get people to use Kinvey. When Progress pulled the plug, a small development agency took over development and is struggling to find the manpower to maintain this colossal project. I hope they will manage to make it work as NativeScript does have unique qualities.

Then they proceed adding platform dependent code for their vanity projects like Fuchsia along side their other platform dependent code for not vanity projects like ChromeOS and Android.

IMO Dart is only alive because of Flutter, outside of it, it's dead.

NativeScript was born after forking Appcelerator Titanium’s Hyperloop project, which was meant to create direct bridge between native APIs and the JavaScript runtime.

At the time the fork happened just when Appcelerator made Hyperloop development private since it was facing more or less the same anger from the community that we see in this article and could not keep the promises that hyperloop was meant to fulfull. (This reminds me a lot the current situation with React Suspense)

The idea in the community was more or less “those bullies from telerik think they can fork it and finish it before us, they will never complete it” and indeed they faced a lot of the problems that was delaying the release of hyperloop itself.

At the end of the day the embraced Angular as a React Native killer (React Native more or less killed the competition for bridged native app frameworks IMHO) but never reached the quality required… wait for it… for a commoditizied framework. That’s the problem: no one will ever pay for a framework which competes with free (if proprietary and not compatible) native frameworks.

(Fun enough, Titanium SDK is actually incredibly solid right now, still following every native SDK release with only some weeks of delay)