NativeScript Professional, Scientific, and Technical Services Reviews & Insights

Score4.8 out of 10

18 Reviews and Ratings

Community insights

TrustRadius Insights for NativeScript are summaries of user sentiment data from TrustRadius reviews and, when necessary, third party data sources.

Pros

Extensive repository of plugins: Many users appreciate the extensive repository of plugins available in NativeScript, which allows them to enhance their development speed. This feature has been praised by numerous reviewers as it enables developers to quickly add functionality to their apps without having to build everything from scratch.

Flexibility of architectural choices: The flexibility of NativeScript's four architectural choices - JavaScript, TypeScript, Angular, and Vue - is highly valued by users. This flexibility has been mentioned by a significant number of reviewers who appreciate being able to choose the framework they are most comfortable with and easily transition from prototype to final product.

Native API access and performance: The fact that NativeScript offers 100-day zero Native API access is seen as a major advantage by many users. Multiple reviewers mention this feature as it allows them to leverage the full power of native UI and achieve better performance compared to other frameworks like Ionic or PhoneGap. This capability gives developers more flexibility and control over their app's performance.

Reviews

3 Reviews

Professional, Scientific, and Technical Services

The unknown beast - NativeScript

Rating: 8 out of 10

Incentivized

May 13, 2022

Use Cases and Deployment Scope

NativeScript (NS) is JavaScript that runs on a system-specific JSVM (V8 for Android, WebKit iOS). And everything would be sad if not for one thing - NS provides access to all system APIs. Moreover, NS has full support for the Angular framework. Mobile apps that we built with NS have full access to the platform APIs as if they were developed in XCode or Android Studio. Also with the help of NS we can also include third-party libraries from resources such as Cocoapods, Android Arsenal, Maven, and npm.js into applications without creating additional layers.

Pros

Access to the entire native API
Support for native iOS and Android libraries
Cross-platform declarative UI and source code
Powerful data visualization with native UI tools provided

Cons

The need to know the native Android and iOS APIs to access device hardware and other platform-specific functionality
Not all user interface components are available for free
NativeScript has no HTML and DOM, which requires some deep knowledge of different UI tools to be implemented instead

Likelihood to Recommend

NativeScript allows to easily integrate with native APIs by threading models. Moreover, the framework itself can be integrated with Angular, VueJS and JavaScript due to the fact that it was built on based on these frameworks. It allows you to easily maintain if you projects are based on these frameworks. Therefore, for the development of cross-platform applications it can be very handy!

Sabit Shaiholla

Head Research Assistant in Engineering at Nazarbayev University JSC (Research, 1001-5000 employees)

Vetted Review

1 year of experience

NativeScript -- Not Yet Ready for Large Development Efforts

Rating: 1 out of 10

Incentivized

April 29, 2020

Use Cases and Deployment Scope

In an effort to move from having separate projects for Angular web development and Android Studio for Andriod app development, I have been trying to replace the multiple projects with a single NativeScript project and add support for iOS devices. I have worked as a consultant for other organizations who also tried to use NativeScript for the exact same reason. One of the prior organizations was a large US government department, and another was a private organization who facilitates the trading of goods internationally.

Pros

Executes really fast compared to other alternatives
Compiles down to native code and runs as a native app
Provides a way to split custom content, including CSS styles, into separate files per target platform

Cons

The ABSOLUTE WORST documentation I have ever seen for an environment which advertises direct involvement with Google and other vendors. Their website content appears to be written once as a version comes out, and then is never updated again as follow-on versions with significant changes are released.
Examples provided are often written from an expert's view, making far too many assumptions, and containing too much outdated content, to be useful to any developer who is just learning the environment.
Some areas of considerable interest, such as the development of composite plugins (draw on the use of existing components as opposed to new native components), are void of ANY useful support.
Support is left up to the use of stackoverflow.com questions and answers, and several of those who respond frequently, do so with language which comes across in an arrogant manner, and only serves to help in a specific instance, not in a global manner which would be useful to all.
The description of the environment is misleading. One is often led to believe that use of NativeScript will significantly reduce development effort and time. I would venture to guess that in most cases, this is untrue. A lot of effort is spent trying to keep the web app and the mobile apps at the same level of development, because the NativeScript components DO NOT support web pages. The user interface of a web app is still almost entirely new development.
The appearance of an Android mobile app is only like that of an iOS mobile app about 90% of the time. You cannot develop an app in NativeScript for an Android device, and expect it to look the same for iOS apps. Organizations who read about NativeScript, are misled into believing that the will be able to reduce staff by eliminating all Android developers or all iOS developers. To do so, is unwise, and in most cases, I believe that organizations will find it easier to develop for one mobile platform and then have the other mobile platform follow one version behind.
NativeScript advertises that it provides great support for Angular and other environments. While I cannot speak directly to those other environments, I can say that the integration between NativeScript and Angular is CLUNKY and PROBLEMATIC! What is easily accomplished in Angular, is a headache in NativeScript, and ends up degrading the quality of use within Angular. For example, Angular allows for developers to very easily develop components which reduce code duplication. Developing a NativeScript UI plugin (aka composite plugin) is made so difficult through the abundance of BAD information on the NativeScript website and manual operations to get it to work within Angular, that it defeats the purpose of building them. I see developers spending more time trying to fix the integration of a UI plugin than they spend in actually using the plugin.

Likelihood to Recommend

NativeScript by itself, appears to be a reasonable environment for the development of simple apps between a web app and mobile apps. Do not read their white papers and accomplishments of their development team members, but rather what external developers are saying.

If you are looking to add the use of NativeScript to an existing environment, give your developers several months to work through several significant scenarios individually in full-fledged (not stubbed) proofs-of-concept. Impress upon those developers, the need to delve deep into the construction of NativeScript UI plugins which require interaction with other areas of functionality within the environment. Even if you believe that the out-of-the-box functionality of NativeScript appears sufficient, ask each of your developers to attempt the development of a couple of NativeScript plugins which interact with the native functionality of both Android and iOS.

Once your development has had ample (or excessive) time to provide you with working proofs-of-concept, please listen intently to all of the concerns posed by those developers. Do not accept a summary report of their efforts. I cannot stress this last one enough, because this is often when large development teams fail, and/or end up going way over budget.

Eric Bewley

CEO in Information Technology at Bewley Software Productions, Inc. (Information Technology & Services, 1-10 employees)

Vetted Review

2 years of experience

View profile

Mobile apps delivered by leveraging our existing skillset with NativeScript

Rating: 10 out of 10

Incentivized

April 30, 2018

Use Cases and Deployment Scope

We are using NativeScript on a single mobile project at the moment. It is the framework which supports development of this entire project for our client. In particular, we are using NativeScript with Angular 5, to leverage the current skills of our front-end development team. We also have an internal app to track our knowledge sharing events that we are developing with NativeScript.

Pros

NativeScript allows our front-end developers to build actually native mobile apps with the javascript we already know well.
It is very quick to get started using NativeScript. We can generally onboard a new developer into the project in just a day or two.
The open source community surrounding NativeScript allows our team to find solutions to open issues quickly, as well as give back by fixing some issues ourselves. Work can progress quicker with the plugins other developers have already built.

Cons

The frequency of updates can make it hard to stay fixed to a common version. I found that there were so many improvements happening that it was worth bumping versions and adjusting the code at least every 3 months. This added extra development time, which also added stress. The benefit is worth it, but it's important to keep in mind that sometimes even a bugfix version bump will require some code changes.
We also found the fractured dependencies hard to keep up with at times. The nativesript-cli, tns-android, tns-ios and nativescript-angular dependencies all have their own release cycles that are close together, but not tied together, and that has downsides when prioritising upgrades during a release cycle. Again, the benefit to upgrading is worth it, but staggered releases do add additional complications.
Documentation is good, but could be better. Over the past year, this has been greatly improved, but there is still a delay between the adding or refactoring of features and the updates to the documentation.
The plugin ecosystem is open source, which is good, but as with your own project, the authors of these plugins also have to keep up to date with the changes in the repos, and that isn't always done in a timely fashion.

Likelihood to Recommend

As with any mobile app, the most important decision to make first is whether you really need a mobile app at all. If you are just building a web app with some user data persistence, then perhaps a progressive web app is all you need. Where NativeScript shines is in building apps that use more than the standard web APIs, and really provide value to your users in how they interact with the device APIs.

Additionally, consider what javascript framework your team is most comfortable using before starting your NativeScript project. There are flavours available for standard JS, Angular, and Vue. Angular is often the best documented, and both JS and Angular are quite stable. NativeScript + Vue is new, and there are still many bugs, but for simple apps, you can accomplish a lot without trouble. The best thing is to choose based on what your team already knows, and this will speed up your development process.

Evan Payne

Senior Front-end Software Engineer in Information Technology at Netcentric, A Cognizant Digital Business (Information Technology and Services, 201-500 employees)

Vetted Review

1 year of experience

View profile

Loading Reviews List....

NativeScript -- Not Yet Ready for Large Development Efforts

Rating: 1 out of 10

Incentivized

April 29, 2020

Use Cases and Deployment Scope

Pros

Executes really fast compared to other alternatives
Compiles down to native code and runs as a native app
Provides a way to split custom content, including CSS styles, into separate files per target platform

Cons

The ABSOLUTE WORST documentation I have ever seen for an environment which advertises direct involvement with Google and other vendors. Their website content appears to be written once as a version comes out, and then is never updated again as follow-on versions with significant changes are released.
Examples provided are often written from an expert's view, making far too many assumptions, and containing too much outdated content, to be useful to any developer who is just learning the environment.
Some areas of considerable interest, such as the development of composite plugins (draw on the use of existing components as opposed to new native components), are void of ANY useful support.
Support is left up to the use of stackoverflow.com questions and answers, and several of those who respond frequently, do so with language which comes across in an arrogant manner, and only serves to help in a specific instance, not in a global manner which would be useful to all.
The description of the environment is misleading. One is often led to believe that use of NativeScript will significantly reduce development effort and time. I would venture to guess that in most cases, this is untrue. A lot of effort is spent trying to keep the web app and the mobile apps at the same level of development, because the NativeScript components DO NOT support web pages. The user interface of a web app is still almost entirely new development.
The appearance of an Android mobile app is only like that of an iOS mobile app about 90% of the time. You cannot develop an app in NativeScript for an Android device, and expect it to look the same for iOS apps. Organizations who read about NativeScript, are misled into believing that the will be able to reduce staff by eliminating all Android developers or all iOS developers. To do so, is unwise, and in most cases, I believe that organizations will find it easier to develop for one mobile platform and then have the other mobile platform follow one version behind.
NativeScript advertises that it provides great support for Angular and other environments. While I cannot speak directly to those other environments, I can say that the integration between NativeScript and Angular is CLUNKY and PROBLEMATIC! What is easily accomplished in Angular, is a headache in NativeScript, and ends up degrading the quality of use within Angular. For example, Angular allows for developers to very easily develop components which reduce code duplication. Developing a NativeScript UI plugin (aka composite plugin) is made so difficult through the abundance of BAD information on the NativeScript website and manual operations to get it to work within Angular, that it defeats the purpose of building them. I see developers spending more time trying to fix the integration of a UI plugin than they spend in actually using the plugin.

Likelihood to Recommend

Eric Bewley

CEO in Information Technology at Bewley Software Productions, Inc. (Information Technology & Services, 1-10 employees)

Vetted Review

2 years of experience

View profile