NativeScript limitations
Asked Answered
F

6

10

I´m evaluating differents mobile frameworks, and I think that nativescript is a good option. But I don't know if exists limitations on the development process. For example I had limitations on the styling (and that's not so important), but I want to know if in the future I can have a limitation and can´t use some native feature or external library. Thanks!

Falgoust answered 24/10, 2016 at 18:7 Comment(0)
U
15

I have been using NativeScript since v0.90. I have written multiple apps and over 40 plugins for NativeScript, so I am very familiar with the ins and outs of the platforms.

This post is features as of v6.50.

I can think of only a couple limitations;

  • Tooling sometimes leaves a lot to be desired, however using the IDE's supported make this better than the Native CLI in a lot of cases.
  • Sometimes errors aren't always propagated back from the app to the screen/ide -- so you have to do things like "adb logcat" to see the full error log to see the error that got filtered out by the CLI.
  • Native Services (i.e. background services) --- This is much better written as native code. The NS runtimes take memory while running; so a service you typically want as small of a memory footprint as possible -- I would not use anything but Java/ObjC for a background service.
  • OpenGL on android needs to run in a separate thread, NS by default switches you back to the main thread when returning from any native calls; this basically kills direct NS opengl calls. However, it is actually better to create any OpenGL stuff in Java or Kotlin anyways; and then have NS call into your native code that handles all the rendering, so this is more of a minor annoyance.

Beyond that I can't think of any "real" limitations; you have full access to the native platform and can actually style any control as long as you know how to do it via native calls; if for some reason the control doesn't support the normal css styling. I & others have used many Android and iOS libraries in our apps. You can easily reuse native android/ios components you have full access to anything out there that is available to a native iOS or Android app.

You can look at https://plugins.nativescript.rocks for a list of all the plugins in the NativeScript community.

Uboat answered 24/10, 2016 at 18:30 Comment(4)
FWIW, debugging with VS Code is pretty good. Using what is included with the CLI is really bad from what I've seen.Yucca
iOS debugging is far better than Android; vsCode also does a decent job. However, when you consider the tools in Android/ObjC, or any other major language the debugging in NS is a serious limitation...Uboat
Livesync on android is being improved on and we should see a great improvement in the next version. For now IOS Livesync is super fast.Radiograph
@Radiograph - LiveSync has weird issues on both platforms in v3.0, it just isn't that reliable in a lot of cases. I frequently have to nuke the app off the device and do a full rebuild to get everything working again. So be prepared to sometimes do full rebuilds. However, I expect they will fix these issues in the future. 3.x had a lot of breaking changes that haven't been totally stabilized yet. In addition the new debugging stuff on Android is far better now than what I discussed last year. So give and take.Uboat
L
4

I have been developing with Nativescript for some time now, and while finished product (application) is more than decent, the process of development is really painful. The primary reason for that are frequent bugs in Nativescript platform itself, and it's official plugin for VSCode.

I am currently working on Nativescript 2.0.0 and have been trying to update to newer versions since they came out, but there were always some errors, ether with Node, or with Gradle for Android, and that is just one of many problem examples I face with the platform. I wish they improve it in the near future.

Lavaliere answered 16/2, 2017 at 12:45 Comment(0)
F
2

For now native apis are fully accessible from JS but if you want you can do some library in native languages and call them from JS code too, about external libraries it depends if you mean native libraries or JS ones, but there quite many options/plugins done in JS code using some native libraries but in case not as JS plugin you can do it yourself with native libraries

Fredenburg answered 24/10, 2016 at 18:21 Comment(0)
K
1

Community support is low compared to other frameworks available in the market. This should improve as people adopt the framework. I see that as a limitation for now.

And Yes, Debugging is indeed a limitation.

Kropotkin answered 4/11, 2016 at 14:45 Comment(0)
I
1

Nativescript is the best cross-platform solution in my opinion, but like the others stated there can be limitations. Besides background services, accessing the hardware CAN be a bit tricky. I have been using it to work with BLE devices though, and once you understand how to interact with native APIs, it isn't so bad.

Ildaile answered 30/9, 2017 at 15:21 Comment(0)
F
1

I've written one NS app (core).

Some of the cons are:

  • performance - loading and also run-time. I'm replacing an Android native app with a NS app (because it's cross platform) and few customers have complained that the new app is slower and jerky...I agree.

  • bugs in NS core. I think that they've spreading themselves too thin. They need to get their core product stable and improve it (i.e. make it faster).

  • plug-ins varying quality with minimal support. Here NS could curate a few important plug-ins and make people pay for it.

Yes it's free - but that's not a huge issue for me - I'd prefer to pay for a more polished product.

At the end of the day - the product works - have my app in the app-store and look forward to future improvements.

Futch answered 30/9, 2017 at 15:58 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.