Category Archives: Uncategorized

NativeScript 5.40 Released

NativeScript 5.40 only offers a smaller number of fixes and features than usual; but is still well worth upgrading to. It will probably be the last major 5.x release. NativeScript 6.00 is on the horizon...

The most interesting update (for me) is actually the Android V8 engine has been upgraded yet again. Android engine is now on v8 v 7.4 - which offers even faster JavaScript parsing (in some cases up to 10% faster) In addition to the engine speed ups; v8 now has better memory management and much better deadcode elimination.

So just upgrading the runtimes to 5.4 should again give you a faster android app... So it is worth it just for this alone. Nothing changed on the iOS side here...

In addition the v8 v7.4 now offers support for Private class variables; an ESNext feature that is finally shipping in v8. If you are unfamiliar with this feature, this feature is needed for keeping private variables private. 😀

class CoolClass {
  iAmPublic = 1;          // .iAmPublic is public variable
  #iAmPrivate = 2;        // .#iAmPrivate is private variable

  getIAmPrivate() {

const m = new CoolClass();
console.log("I am private now equals:", m.getIAmPrivate()); // runs OK
m.#iAmPrivate = 0;  // TOTALLY FAILS!   

Unfortunately, JavaScriptCore does NOT support this feature yet and the code will fail to even parse on JSC, so don't use it in any shared code. This is an Android only feature. TypeScript will soon be adding this feature, so this should become a common way of making class fields private...

Important Depreciation Notice

In version 5.2 short imports have been depreciated; I do not know when they will no longer actually work; but basically things like require("http") are no long valid; you need to do require("tns-core-modules/http"). The primary reason for this is that webpacking requires the full path; and it has problems with short imports. Please note this now becomes more critical that you handle this; NativeScript 6.00 will be 100% webpack only; meaning that if you don't fix your code it might fail to build until you do so in NativeScript 6.

Core Modules

The core modules offers the following enhancements and fixes...

Multiple iOS components have crashing issues fixed
FormattedText crashing issue fixed


Upgrade to V8 7.4.288 - which offers
- Private Class Fields
- Faster JS Parsing
- Better Dead Code Elimination
Static Binding Generator fixes and enhancements
Gradle 3.40 support.
Several memory leaks fixed
v8 Symbols exportable (for native v8 extensions)
Elevation Shadow Support


Allows compiling Swift code as part of app_resources
Minor leak fixed
Unicode crash fix
Some Metadata generation fixes


HMR is now the default app type
TNS Create Plugin fixes
Better handling of CTRL-C
CocoaPod handling improved

Updating NativeScript

To get updated; you first need to do:
npm i -g nativescript@latest

That will get you the latest version of NativeScript CLI; once you have it; do a "tns --version" and verify it prints out "5.4.x".  Then do a "tns doctor" to verify your environment is up to date and has all the newest support tools you need for a successful build.  

To update a project; you need to do the following:

Latest Runtimes:
tns platform remove android && tns platform add android@latest
tns platform remove ios && tns platform add ios@latest

Latest Core modules:
npm r tns-core-modules --save
npm i tns-core-modules@latest --save

To install Webpack & HMR support:
npm i nativescript-dev-webpack@latest --save-dev
Note: you need to have nativescript-dev-webpack as a development dependency for HMR to work.  

To install latest NativeScript Angular plugin
npm i nativescript-angular@latest --save
You will then need to install the actual angular bits; which as of this post v6 is currently supported.

The addition of all the additional analytics/tracking to the CLI reminded me; you can disable it permanently; if you value your privacy by doing:
tns usage-reporting disable && tns error-reporting disable

Known issues

NativeScript 5.1.1 Released

Even more fixes have come down the pike. Based on some of the bugs that have been squashed it appears that if you are using v5.1.0 you want to upgrade to v5.1.1 as it should make your life a little easier.

Core ModulesT

Technically they released 5.1.1 of the core modules last month; as it was a quick release that fixed several issues with 5.1.0.

v5.1.1 several android issues; and added a new ios model system, they moved context into an options hash that you now pass in its place; in addition several other parameters that used to be separate parameters are now part of the context. This cleanup allows new features to be added in the future. The old showModal function is still supported, but marked as depreciated.

5.1.2 was released with the rest of the updates this week; this version fixes the Android crash in Listview switching templates.


Nothing done which needed a new Android runtime version...


Debug logs show in Chrome again


Debugging on iOS when using HMR is now fixed, many issues resolved
Many Yarn support issues fixed
Sidekick and Preview app fixes
A couple CLI crashes fixed when running/debugging.

Updating NativeScript

To get updated; you first need to do:
npm i -g nativescript@latest

That will get you the latest version of NativeScript CLI; once you have it; do a "tns --version" and verify it prints out "5.1.x".  Then do a "tns doctor" to verify your environment is up to date and has all the newest support tools you need for a successful build.  

To update a project; you need to do the following:

Latest Runtimes:
tns platform remove android && tns platform add android@latest
tns platform remove ios && tns platform add ios@latest

Latest Core modules:
npm r tns-core-modules --save
npm i tns-core-modules@latest --save

To install Webpack & HMR support:
npm i nativescript-dev-webpack@latest --save-dev
Note: you need to have nativescript-dev-webpack as a development dependency for HMR to work.  

To install latest NativeScript Angular plugin
npm i nativescript-angular@latest --save
You will then need to install the actual angular bits; which as of this post v6 is currently supported.

The addition of all the additional analytics/tracking to the CLI reminded me; you can disable it permanently; if you value your privacy by doing:
tns usage-reporting disable && tns error-reporting disable

Known issues

Australian AABill

If you look at my blog; I do believe this is the first article I've ever written about something political.  I tend to be anti-political because I feel like it just divides us and tends to be just complaining with no one actually doing anything meaningful about it.

However two days ago I noticed in the news that the AABill was about to be passed.  I had read about it before, but since I'm not Australian (and I don't work in Australia) it really doesn't affect me "personally" right this minute.   However, the reality hit me later, that it does affect my friends; and it has a very high chance of affecting all of us in the future.  What the Australian government gets away with now; the rest of the "civilized" countries will also attempt to implement someday.    

Our own (USA) FBI has been hankering for this power for years; and so far they have been thwarted; the Canadians have thwarted similar issues in their country.   Europe; has caved to a lot.   So much of what Australia did; they took from Europe.  They just went a lot farther.  The more nations that cave; the easier it is for the other nations to do the same thing and go farther.   

This bill is BAD!    So bad, if it was meat it would have to be launched into the sun to actually eliminate the deadly bacteria.   If it was a meteor we would all be wiped out instantly.   

In a nutshell the bill gives the Australian government the right to require people and/or companies to implement back doors into any systems (web, phones, your apps, banks, encryption, etc).   

  • No real  over sight   "Trust us; we won't abuse it..."   (I bet they  have a bridge to sell us too.)
  • Massive mandatory punishments for speaking about the request; to anybody -- even if it is to defend your reputation or job when the back door is found..
  • Severe Anti-whistle-blower rules to eliminate anyone attempting to do the right thing, when the government is doing the wrong thing.   Trust us we won't abuse it...
  • The improbability that the person served with the "backdoor" order can actually bypass the security of any company that is multinational is... well, rather ludicrous.  More than like instead it will cause their own termination and potential black balling of the poor developer in the industry since he can't defend himself nor mention why he tried to subvert the software.
  • Trying to backdoor anything, is a criminal paradise.    We all know that no bad guys ever fine issues in any thing, never happens...
  • Backdoored encryption, what a joke.   
  • What Australian developer (or company) can I now trust with my code, data or hosting?
  • Beware of that bridge for sale...

I can go on an on about the terrible things in this bill...   Suffice to say; this is a very bad bill and that it has world wide implications.

I posted on twitter that I thought that maybe the internet community should route all the Australian government IP's to a banned page saying that until the bill is repealed they are being segregated to limit any more damage they can generate.

Several people posted they thought that was a good idea.   And it dawned on me, all I was doing was still just complaining and offering ideas that nobody would probably do.   In all reality I wasn't really doing anything at all.

So I got off my butt; and actually did something.   I purchased the domain name; I then proceeded to setup a simple site.  Figured out several blocks of Australian government IP's to be routed to the banned page.    Figured out how to make the routing work in both Apache 2.4 and Nginx, and published the site.

I have attempted to start something here; and I cannot do it alone.   

If you are a internet provider or you have control over a website.  I urge you to check out the site and become involved.  The more sites that blackhole all the Australian Government IP's; the more likely they will be forced to actually repeal the law if they want to be able participate on the internet.   

 If you don't own any websites; please pass this blog and/or the site around.  If you do copy editing, graphics works or technical work; the site is open source and could use more work prettying it up and making it more appealing to the masses and the press.   It was built quickly to try and spread the word because the tech world is starting to understand just how bad this law is.

If we can get the law repealed in Australia; then that will make all the other nations have second thoughts about trying it in their nation.   Maybe we the people of the internet can actually get our government to listen to us and follow our lead...

Security with Apps on iOS and Android.

Recently a person on twitter asked about a statement that Max made in a blog article which he did on the official ionic blog.  For those who know me; I actually am pretty heavily into security; and I happen to have used many mobile technologies  Cordova/Phonegap/ionic, Flutter, Titanium, React Native, Java, NativeScript, ObjC, Swift, etc -- so this article is right up my alley.   So lets start with the quote that started the tweet...

Some toolkits, like NativeScript, take the approach of exposing every Native SDK API to JavaScript. We think the security implications of that are undesirable, and it doesn’t remove your need to learn platform-specific APIs. We don’t think you should have to learn those APIs if you don’t want to, and we don’t think you should expose all Native APIs to JavaScript for security reasons.

(Quoted from Max's blog post linked above)

Initially I saw this tweet and was well saddened that Max feels he had to bad mouth his competitors to make his product potentially look good.   Unfortunately the statement Max made is 100% pure marketing FUD (Fear, Uncertainty, & Doubt).  He is just try and make a competing framework look bad with the hot button topic called security.    All it does in my opinion is make him, and his product look bad, and it is on the official ionic blog.   Compete on what you do great; not on trying to make the competition look bad (especially with FUD).

The real truth of this matter is that no matter the framework the same security surface exists.  Unfortunately for Max, this includes ionic!

So lets say I'm a evil person and I want to take over the world with my evil ionic app.   What do I do?

[I]...wrap a Native SDK and expose it as a reusable component that can be easily consumed in JavaScript ... Native Views provide a structure for wrapping and consuming a Native SDK so that it can be easily and safely exposed to JS...

(Quoted: from the same blog post linked above)

Oops; I guess I safely exposed some very bad methods  and succeeded in doing the exact same thing in ionic.  The only thing is I had to add the exact same code in a different place and expose it so it is easily consumed  using my exposed call "doBadThing()" in the JavaScript side of ionic when I need it to do my evil bidding.      Does that mean ionic shouldn't be trusted since I can easily and safely do very bad things in ionic?   See the problem, for me to do GOOD things in ionic; that gives me the same power to do BAD things in it.  

The reality is this means that just like I can do bad things in 100%  pure Java app, Kotlin, C/C++, NativeScript, React Native, ObjC, and Swift (name the framework); I can do it just as easily in Ionic.  None of them are immune!     This doesn't mean any specific platform is worse or better; they all have the ability in one way or another to access the exact same api's which can be used for evil purposes.   The bad code in all of them is literally the same; just the location in the app calling it is different.   

Now not to get into a more technical discussing; there are some areas where the frameworks do have some differences that may allow certain things to be easier to miss.  For example; using proguard can hide method calls in native Java code.  However overall this does not change the relative security of each of the frameworks.   You name the framework; and I know a way to make it hard for you to detect my evil code..   They all have pretty close to the same level of security surface.  

Now that I've explained the FUD and debunked Max's unfortunate dig at his competitor; I would like to explain where I see the real security issues with Android and iOS.

The real security vulnerabilities is our trust model.   We are now seeing it play out more and more where a developer creates a decent app.  It gets a decent reputation and then it gets sold to another developer.   The "other" developer is sadly not your friend.  Unfortunately; they add "bad" code; upload it as a minor fix to the app; and bam your Android or iPhone now is doing stuff you would rather it not be.   This has happened on ALL platforms, ALL types of code bases and so far none are immune.   Eventually they are caught (at least we hope) and the app is removed from the stores and you see a article about how 20 apps by XYZ dev had malicious code in them...

But the root problem is trust was built; and then outside of our control and knowledge; the app transferred to a different vendor who hasn't proved himself.  This is a hard issue to solve.     Do we say when you sell your app; it no longer can be auto-updated and has to be manually updated the next time so a notice will appear?    Or can we make the stores possibly notify us on the next upgrade with a re-install dialog announcing that the app has changed hands?    What has the best chance to be detected by the community and looked into?

I think that either of those ideas would be a good first step; but it won't solve this issue.  Bad actor then waits several months and then posts his "bad" changes.   Likely hood of being caught went drastically down, as we all get busy and our trust level goes up...  But at least the community is aware of the change of ownership and so some of them might still be diligent...

My next suggestion, is something unfortunately neither Google nor Apple will ever implement because our personal information is their bread and butter...   

I believe the real solution is that our devices should have two additional features: 
1. Built in firewall added to the OS.  The firewall is allowed to block all traffic for a specific application.   Easily enabled and disabled per application.   
2. Lying Data Module - This is a little harder to explain and a bit more advanced but basically you can tell the OS to lie to the app.  The app asks for your location and you have pre-configured the OS to always say you are at the north pole.   The app asks for the temperature; and again you pre-configured the OS that the temperature is 200 degrees.   It asks for your phone number and it returns 555-555-1212.   For the apps that need the real data (like maps, needs your location) you tell OS to tells the truth about GPS location.  But otherwise the same dummy data is passed by DEFAULT to every app.   If your map app asks about your phone number, it gets the same 555-555-1212.   This eliminates the app (& companies) from actually gathering any valuable data, and effectively the database will be poisoned making it virtually worthless to the company trying to collect the data.

With those two items; you could take control of your digital lives on your android or ios devices.  Yes, it requires more setup as when an app starts you have to tell it what you want to allow it to have access to data wise.  (or maybe when it requests something).

If anyone has an idea how to actually get Google or Apple to implement this in their Operating systems; I would love to hear feedback as I feel this could drastically improve our digital lives.    (and yes I know if you have a rooted android phone -- both are available to use right now.)     

Disclaimer: I have written books, blog posts, and plugins for NativeScript; so I currently do have a preference towards NativeScript.  However, anyone in the community that knows me; knows I'm the first person to call a spade a spade and argue about how this feature is horrible in NativeScript and awesome it is in framework X.  I can tell you several things I think that NativeScript is doing wrong or poorly.  (Just look on github)    I have written apps and/or thoroughly investigated the security and software stacks of each of the frameworks I've mentioned in this article.    I am not employed by Progress, nor is this blog sponsored by them -- all posts are strictly my own opinions.     

NativeScript 5.0 Released

It has been a long road getting to this point; but I'm happy to see that the NativeScript team released The final piece of the 5.0.  The CLI tool which was the final piece was finally released on Nov 2nd; the rest of the pieces have been released for a couple days.

5.0 adds a whole lot of new awesome features; however since several pieces have changed; I would highly recommend before uploading a 5.0 app to the app stores you do another full test of your application; testing everything as several low level framework items changed for both iOS and Android.

The quick list of some of the new features in 5.0

CLI Prompts

The cli now will prompt you for input; so when you type "tns create ProjectName" you will see something like this:

You can use the arrow keys to select an option, in this screen shot; the "Plain JavaScript" is chosen and so it is highlighted.

HMR - Hot Module Replacement

This is the feature most NativeScript developers have been waiting for; this is awesome.  You know the silly change a file app restarts; change another file app restarts livesync?    Now you can do this:  tns run --hmr

HMR, allows the page and JavaScript code to be updated dynamically (no more full app restarts) ; if you change a class the class may have to be re-instantiated (like in this example), but if you change other things, like functions, the state is preserved and the new function will be what is called the next time that function is needed.   All in all, this is very HOT!   (You do need to have the nativescript-dev-webpack as a developer dependency of your project for HMR support)

NativeScript Preview

QR Code

Preview allows you to preview the application without having xcode or android tools installed and building it.  It uses the already built playground preview application to preview the app so that you can see the app on your mobile phone.   It has the same limitations as the playground site; but for most developers getting started it is a quick and easy way to start playing around with programming application.    When you type:
tns preview

you will then see the qr code in your console.  Point the playground app's qr scanner at it and then your app will start running on your phone.   Please note the entire application is uploaded to the cloud; which then your phone links to.  So if this is an issue with your company  don't use this feature.

Internal Changes

Android Core modules is now descended from the Google Support libraries; this opens up many more visual plugins and makes the app a lot more modern and compatible.   One word of caution this did require them to do a bit of reworking of several parts of the base code for android.  Their is the likely potential for new bugs to appears in areas that were bug free before.  So heavily test your app before releasing it to the stores.

iOS Core modules now have a new way to do the safe areas; this also has required a lot of reworking and so the same warning applies.  Test your app thoroughly to make sure that something in this area won't cause you any issues.  

Other android specific changes:

  • now using the v8 engine, v6.9.427.23.
  • before-plugins.gradle support
  • SBG will fail if their is a JSParser issue
  • JSParser fix for Decorators
  • Runtime issue fix with support > 26 on devices < 23.
  • Gradle is now using 3.2
  • Building is even faster now

Other iOS specific changes:

  • Typing generation improvements
  • Webkit is now using 11.4
  • Several marshalling to native from JS issues fixed.

Other specific changes:

  • Many bugs fixed
  • Webpack Vue  bundling support
  • Angular memory leak fixed
  • Styling changes to support dynamic theming
  • tslib helpers now global
  • appSettings now supports allKeys method
  • Touch event pass through now supported

Updating NativeScript

To get updated; you first need to do:
npm i -g nativescript@latest

That will get you the latest version of NativeScript CLI; once you have it; do a "tns --version" and verify it prints out "5.x.x".  Then do a "tns doctor" to verify your environment is up to date and has all the newest support tools you need for a successful build.  

To update a project; you need to do the following:

Latest Runtimes:
tns platform remove android && tns platform add android@latest
tns platform remove ios && tns platform add ios@latest

Latest Core modules:
npm r tns-core-modules --save
npm i tns-core-modules@latest --save

To install Webpack & HMR support:
npm i nativescript-dev-webpack@latest --save-dev
Note: you need to have nativescript-dev-webpack as a development dependency for HMR to work.  

To install latest NativeScript Angular plugin
npm i nativescript-angular@latest --save
You will then need to install the actual angular bits; which as of this post v6 is currently supported.

Known issues

Tech support & Open Source bug fixes

I get more than one message a week requesting help with one of my many open source plugins or projects.   I would really love to help you; but this is not something that is sustainable and completely unfair to my family.

Not only did you get the plugin and/or project for free; you already have the source code, documentation, and probably even a full demo that shows most -- if not all the functionality of the project.   You should have everything you need to find the answer to the question yourself.

Pretty much all my income generated is currently from my doing contract development or consulting related work.   So any "free" support work that interrupts paid work; really is a bad thing for my family.   If you are being paid to build your app; than you can see how this  even more of an issue.

If you really you think you found a bug; then by all means report it to the proper repo ( and the support will be appropriately dolled out.   I do take bugs seriously; but again open source plugins are never as high of a priority as paid work.    The bugs will eventually get fixed; but it might take several weeks to find the time to work on it.   In the meantime I do accept pull requests.  I am also much more likely to accept your PR fairly quickly and fix anything that I find broken in it; than reject it.  😀

Finally, I am not opposed to supporting you; so If you really want my support; I do offer paid support

Now back to the regularly scheduled technical blog posts.  😉

NativeScript: 2.5 and 3.0 upgrade learning moments

Well, my son has been learning Web and NativeScript for a while and was continuing to work on NativeScript project today (Lots of cool things like GridLayouts, ListViews, Sliders).

So he finally got to see first hand the wonderful world of fun that the new NativeScript 3.0 upgrade has caused.

One of his requirements for his application was ability to include a picture with each data item.  So he used my site to find the plugins and then did a simple tns plugin add nativescript-imagepicker -- then a tns run android and got the error cannot require the nativescript-imagepicker file in the Android crash dialog.   So I had him do a full rebuild, then as it still doesn't work (and of course he is telling me the plugin shows in the node_modules folder on his local machine).   So, next I have him open his packages.json file.   Its not present.... Hmm, so I ask him try to do a tns plugin add nativescript-imagepicker again.  This time he saw the error about the current project does not supported 3.00 runtimes.

I'm like welcome to the wonderful world of 3.0 incompatibilities, high five time!    You have reached the pinnacle of achievement; welcome to my world!   😉

So then I explained why he was now seeing this issue; and that 3.0 is not compatible with 2.5 in several ways and all the ins and outs of why and then I said you have two choices...

  1. Upgrade to 3.0, and upgrade your plugins to 3.0 -- No guarantee all of them are 3.0 compatible, so he would need to look into that.  Even some of my plugins I haven't had time to test on 3.0 and some aren't 3.0 compatible yet.     This is something that should have been handled better by Progress, do to the number of breaking changes and sometimes missing documentation.   But as the community has time, and large number of the issues are fixed by Progess; 3.x will eventually turn into a good solid release, and this will all be a bad memory...
  2. Stay with 2.5 and grab a older version of the plugin.

He decided to go the safer and easier route so I showed him how to use the npm info naitvescript-imagepicker command to find the older version of the plugin.  In most cases the last version before 3.0 is the version you want...   In this case 2.5.2 was the last version before 3.0.

npm r nativescript-imagepicker to make sure to delete the 3.0 version that is in his node-modules folder.  Then we used tns plugin add nativescript-imagepicker@2.5.2 and we do a tns platform remove then tns platform <strong>a</strong>dd again to make sure nothing was left over from the prior failed attempts.

Of course, it wasn't as simple as that -- the developers of the imagepicker plugin has a really stupid issue that were causing building issues that I had to fix for him.  But that is a story for another day...  😉

But none the less it turned into a great teaching moment to improve his skill set on both CLI, NPM and NativeScript...  And so off he goes...  So proud, of this guy...  Can't wait to show off some of his stuff...


NativeScript: Android & Crashing issues

This is more of an informational post; there are a couple issues that I am aware of that will kill your application deader than a door nail.    As a community service I want to inform you on how to deal with them.

The first issue is fairly simple to duplicate; open your app in Android 7, and then open it in split screen mode.  At this moment there is a issue in the android runtimes that causes your app to crash and burn.   Assuming you do not want to see  your customers complain about application crashes, Nick came up with a good workaround until they can fix the issue.

To fix the issue you need to open your /app/App_Resources/Android/AndroidManifest.xml file and navigate to following key to the Activity section of the file.     It should look like this:

You want to add android:resizableActivity="false" to the Activity section as shown in this image.

This will disable the ability for the application to be resized; which will eliminate the crash.   The NativeScript team is investigating how to fix it; so eventually you won't need to do this; but in the meantime, I would recommend you add this to all your apps to eliminate at least one place your app can easily crash on Android 7.


The second issue is one that I have been dealing with for month; my remote error logging shows this log frequently:

Error (native) com.tns.NativeScriptException: No weak reference found. Attempt to use cleared object reference id=-xxxxxx

This of course crashes the application.    Well Peter (on the NativeScript Android team) has managed to duplicate and fix at least one of the ways this can occur.    So, we will be seeing this fix in the the new 3.0.0 runtimes.   WooHoo, less customer crashing is AWSOME news...

Now I know what a lot of you are thinking, I've got a NativeScript 2.5 application; I don't want to upgrade to 3.0 yet; it will break all my plugins...  Guess what this intrepid developer has tried and confirms works properly.   You can run the 2.5 TNS core modules and the 2.5 widgets with the Android 3.0.0 android runtimes.    This is not going to be guaranteed to work for any future releases past 3.0,  but for the first couple versions, you should be very safe running the Android 3.0 runtimes with 2.5 NS Core Modules and 2.5 NS Core Widgets.    One word of warning you MUST use 2.5 core-modules with the 2.5 widgets; DO NOT try to mix these up these versions.

Now 3.0 is not yet out of RC status; so I wouldn't deploy this right this minute.  But once 3.0 is out; I plan on updating my apps to use the 3.0 engine to eliminate this nasty issue that randomly crashes my applications...

To update you just do:

tns platform remove android
and then
tns platform add android@3.0.0

Please note; you will also want to disable the snapshot feature.  It is tied to the core modules and runtime engine.  At this moment there is no version of the snapshot for v2.5 core on a 3.0 android engine.   To disable the snapshot ability; the easiest way is to do:

npm remove --save-dev nativescript-dev-android-snapshot

This will remove all the snapshot code from your project so it won't run and mess anything up...




NativeScript 2.5.0 - Released

Some of you might have seen the all New version 2.5.0 has been released today.  For the first time that I can recall; Telerik has actually beat me to the release news.   You can read the official blog post here.

Some of the new features

  • Better Debugging using Chrome Developer tools
  • Working Webpack 2.0
  • Flexbox layout fixes
  • Updated Android Runtime Engine (even more ES6 support)
  • More css support for ActionBar
  • Lots of bug fixes

Upgrading (Core):

First of all to upgrade is done is a couple steps:
> npm install -g nativescript@latest
> npm install tns-core-modules@latest --save

Next try the new update command
> tns update

For Android:
> tns platform remove android
> tns platform add android

For iOS
> tns platform remove ios
> tns platform add ios

Then you can type tns info and verify that everything says v2.5.x

Some Changes

  1. tns run does not work the same way anymore; it is now equal to tns livesync --watch
  2. To actually "rebuild" the app; use tns run android --clean

Common Issues:

  1. In some cases when doing a tns platfrom add android, the package.json file gets a entry in the dependencies section for "tns-android": "^2.5.0" which will cause any following builds to fail with the error code: the plugin tns-android is already installed.   Fix: Delete it out the package.json.
  2. ActionBar items -- backgroundColor do not use color names; only use Hex values.  Using color names can cause the app to crash.
  3. Android --release apps and error about can't find package "nativescript-snapshot@x.y.z" or "nativescript-angular-snapshot@x.y.z" in the registry.     A couple things can be causing this; first make sure you have updated everything.   Second, occasionally the hooks folder gets out of sync, you might have to delete your hooks & node_modules folder and do a npm i to reinstall everything.


Amazon Tablets - Jailbreaking / Rooting

Amazon sales some decent little tablets called the Amazon Fire 7", add one of there decent kids cases and the tablet is great for letting the kids use for a ereader, comics, games, notes, Zork, and many other tasks that a normal Android compatible touch screen devices can do. All for the grand total of $50 for the android device, and $20 for the case.   So around $70 you have unit that is perfect for kids.

Now with this unit there is a couple of small gotcha; by default it comes with a silly advertising screen saver and it is tied completely to the Amazon eco-system.   For those who aren't interested in Advertising there is two options; one you can pay Amazon $15 to eliminate the advertising, or you can remove it yourself.   Now many of you know me; So I'm sure you can guess which way I did it. 🙂

The second issue is that it only has a 3 month warranty; they DO sell a "kids" version for $99 that comes with the case, removal of the ads and a two year warranty.   So the cost difference between the two is negligible if you want a two year warranty, this is your better bet and you don't have to do anything to eliminate the ads as it comes already without ads.

This device is not a bad little tablet; and my kids fight sometimes over who gets which one of the them that we have.

Now on to why most of you are probably viewing this blog post; I prefer to have full control over any device that enters my house.   So guess what my choice was.  Yep, I eliminated the ads and "root"ed the device.   If that sounds scary; it really isn't.   You just do a couple steps; install some software and boom your done and have a fully open Android tablet.  Please note this can void your warranty and you have a chance you can mess up your device.   No warranty is provided and I don't provide free tech support.  😉 Please note this only works on Amazon Kindle fire 5.3.1 and lower, if you are running 5.3.2; you need to downgrade to 5.3.1 before doing this. There are videos to help you do this.

Please note; by doing this you might eliminate the ability for Amazon's Alexa, freeplace, prime videos, kindle free books from working.   I do have a prime account; but I don't have anything on Amazon I want the kids to have "easy" access too; so I honestly haven't tried any of the prime services on my fire's.   I'm pretty sure the Kindle e-reader app continues to work fine; but no guarantees.    I don't believe my fire's are babysitters, so no video access is given to them.  If they want to be entertained they can read a book.  😉

First things first; you need the tools.  You need to download the link on here:

The file is currently called and it is around 152MB's

After you download it and extract it to a folder; you need to install the ADB drivers; the best tutorial I've seen if you like video's is the author of this tool; "Root Junky" video tutorials which you can watch on

If you prefer text and pictures

Now I'm not going to repeat those tutorials; The things I did to make everything work was option 1. ADB Driver Install, then 2. Install Google Play and remove ads from Lock Screen, then 7. Root your Amazon Fire fifth gen, and finally 8. Replace Amazon Fire Launcher with Nova Laucher.
1. ADB Driver Install -- This is required so that the software on your computer can talk to the Amazon Fire, so this has to be done FIRST, and must be working, for everything else to work.  This can be tricky depending on the OS; if you are using Windows 8 or 10; you have to disable driver signing; which you can see how to do in the Text and pictures link.

2. Install Google Play / Remove ads -- well I don't like ads, and I want Google play to be able to install other things, that I mention below.

7. Root your amazon fire; this is if you want to be able to control things; I happen to like putting a firewall on my devices.  This allows me to block all applications from connecting to the internet and dialing home and/or pulling down ads inside of them.    This is not needed; but I personally prefer it.  The firewall I use is called "AFWall+" and can be got for free on the Google Play store. (But you must be rooted to use it).   There are a couple other tools I use on my devices that require root; but I'm a developer so they probably won't interest you.  😉

8. Replace the Amazon Fire launcher with Nova Launcher.  Nova Launcher is a pretty good default launcher; if you like the Amazon launcher; then no need to do this.  But I don't and I find it very limiting and it is very much tied to the Amazon eco-system.  So I install Nova Launcher; then I installed another app called "Kids Place" this allows you to setup a simple to use Launcher for the kids; where I can pick the apps they can run, when they are allowed to be ran and other "kid" friendly items. This "Kids" place runs in its own sandbox and limits the kids to pretty much only the apps you allow it. It has some "holes" that my crafty kids have discovered, but the holes are pretty minor and don't cause any real issues since the firewall blocks access from any app that I've decided doesn't need internet access.

I tend to disable the internet on the tablet, pre-install a ton of books, apps, comics and other items. I have also purchased a License for Moon Reader (My favorite e-reader app), and Aldiko Premium. And so I install these along with FBReader on all my Fire's so that the kids can choose which e-reader they like.  In addition I typically install a couple learning games (for the non-readers), drawing, and even a comic book reader; as everyone loves comics.

If you want to allow your kids access to the internet from the device; I would install the Brave browser as it has built in ability to eliminate ads and tracking which is what you want for your kids. The other thing you might consider is changing the DNS to use a family/kid friendly provider. You can do it on the device; or if you have a smart router; you can tell your router to server a kid friendly dns to a specific device. OpenDNS & Norton both provide free kid friendly dns servers.

None of this is totally bulletproof and you still have to be a parent; but it does make my life a lot easier and I have no concerns about any of the kids taking any of the fires in their rooms and using them.