Category Archives: Tips

NativeScript and Console logging on iOS (including XCode 9)

Been a while since I posted; and most this info was going to be presented at the NativeScript Developer days speech that we ran out of time in our cool session.     So I'm going to present it here, because I think this will help a lot of people.

First of all, NativeScript has an issue (at least on my machine) where the logging is incomplete and missing important things, like crash reports (and now on XCode 9, non-existent).

Well, when I ran into the two first issues using XCode 8.2 & 8.3.   I figured out a work around, because I hate my tools not working.    🙂

There is a really awesome set of utilities called libimobiledevice this set of utilities lets you do all sorts of things with a real iphone when it is connected to your computer including reading the logs.

 

Real Devices (any version of iOS)

So I typically do idevicesyslog | grep CONSOLE and it will then show me all my logs for the device and it basically fixes any issues other than some exception reporting.   Most the time my app doesn't crash so that command above I use probably 99% of the time.    However in the cases I need to see the NativeScript actual crash logs.   I use the above command and it will spit out the PID of your app next to the CONSOLE word.  I then cancel it, and do a idevicesyslog | grep <PIDID> and this gives me the full log including anything the NativeScript runtimes print.

Please note this only works for real devices.

Simulators (iOS 10 and before)

UPDATE for iOS 11 simulators, please see below!

Now for simulators; the process is very similar.

You run xcrun simctl list | grep Booted and it will give you a line like this:
iPhone X (4701B6F6-0EE4-423F-B5E2-DE1B5A8C32AC) (Booted)

Do you see that big old long uuid; you need that.

tail -f ~/Library/Logs/CoreSimulator/4701B6F6-0EE4-423F-B5E2-DE1B5A8C32AC/system.log | grep CONSOLE

This allows you to grep the log from that specific simulator.   Again, using the grep CONSOLE filter you can limit it to any console logs.   And you can also use grep <PIDID> to filter it to any application if you need the filtered down to, if you are needing the specific NativeScript application level logging or crash reports too.

 

Simulators (iOS 11)

iOS 11, changed the logging for the Simulator drastically.  Technically iOS 10 changes the NSLog drastically, but 11 enforced some new rules.   So iOS 11 broke the NativeScript internal logging; but it broke the cool tail trick above.    Everything now is now running through the new os_log facility.  The easiest way to get logging from your simulator is this single line:

log stream --level debug --predicate 'senderImagePath contains "NativeScript"'
--style syslog

Please note this is case sensitive, if you don't case the senderImagePath and NativeScript you won't have your filtered logging (or any logging at all if you type it wrong).   This part of it filters it down to just any NativeScript logging from all emulators running.

I created a simple bash script called /usr/bin/local/tnslog and dropped the above line it in and then chmod +x /usr/local/bin/tnslog 'd it.  So I can easily just start tns, and then open another terminal tab; and type tnslog and have all my logging again.

 

Installation

The simulator you need no extra tools.   For real devices you need the libimobiledevice toolset, which you can easily install via brew with the following two commands:

brew install --HEAD usbmuxd

and

brew install --HEAD libimobiledevice

It is really important that you install from head, the changes in Xcode 9 and iOS 11 have made a couple changes to both those libraries require some updates and the normal brew packages are out of date and doesn't have it.  So you need the latest and greatest.

 

Final Thoughts

I have been lazy, and just documented the steps.   If someone has some spare time and wants to create a quick bash script to automate the grabbing of the simulator id, and starting the older logging; against that simulator that would be cool to add to our tools.  But since I'm using primarily iOS 11 emulators now; my tnslog script handles all logging until the NativeScript team can fix their tool's issues.

 

NativeScript: @Next- should I use it?

Short version: Nope...   😉

Long Version:

I see this pop up frequently in the bug tracker and slack where someone is complaining about a issue; then we all find out it is a issue in the @next version.    Unfortunately Telerik really did everyone a huge disservice when they named it @next.

This is not actually the next version of that specific repo/codebase.     What, you say???  But it is named next.   Yes, I'm sorry to say it is totally a mis-named tag.   None of the repos have an actualNEXT branch.

The @next tag is actually tied to the MASTER branch.    And Master is not a RELEASE branch in NativeScript.    Master is used for testing, and validating things.  Once they have been validated and the feature(s), or fixes approved;  then that single item will be tracked and eventually moved into the Release branch before the real next upgrade release.

In the meantime if you decide to try @next, you will have many features/bugs that are still in testing or transition that might not even be 100% complete or working properly.     Now the Telerik devs have been trying really hard to keep the Master branch in a usable state (Kudos for the guys putting "DO NOT MERGE" on really major pull requests that are still being developed).   But even with them being careful; Master is still a DEVELOPMENT branch, so just like my own DEVELOPMENT branches, thing will slip through.   Or a design change will occur; where we decide to refactor something and then the current "master" is broken in some weird way that we didn't anticipate.   In addition there will be many features/bugs that are present on Master that will never be in Release in that form.    So, @next != release or really even release quality.

Please if you don't need to upgrade to @next; don't do it.  Not only will you stay saner; you won't be wasting peoples time with issues that are frequently meaningless.   @Next is really so that you can test if a bug is fixed; but be very leary of using it for ANY other reason, the rest of the non-release changes in @next will probably bite you...

However I would ask that if a bug you reported is fixed on @next; please upgrade temporarily to verify the bug is fixed, and report back to the team.   This is helpful for them to know they squashed your bug as you see it.   But once you are done,testing; I would highly recommend you go back to the @latest tag.   😉

To upgrade you do npm i tns-core-modules@next  (Example sake; we are assuming it is the core you are upgrading, but all the repos have a @next).   Then a tns platform clean android or ios.  Then re-build and run the app.    When you are done testing, change the @next to @latest, and you will get the latest RELEASE version available for that repo.

 

NativeScript: Android application upgrade issues

Updated Information: A RELATED ISSUE CAN also effect ALL normal android applications that are just a simple upgrade in that your newly upgraded app WON'T be upgraded properly on the device.  The client running your app, will revert to the prior version and/or prior data.

This doesn't normally crash the app, like the original issue (discussed below)-- but your client will be wondering why your upgrade didn't change anything...   So my recommendation is to apply the application backup disabling fix listed below so you don't run into either of these issues.

This new issue effects:

  1. Android 6 and up devices.
  2. Any application upgrade/update.
  3. Does not affect a brand new installs on a device that has never had your application. Will affect devices that deletes your app and later re-installs.  So this is doesn't affect a new customer, but will effect any exist customers.

The issue described below has been patched in v3.01 of the Android Runtimes, technically it should be fixed.  However as I suspected and we have confirmed recently; the root issue actually can cause other related issues, and it is unpatched and with no eta for its solution, hence this updated blog post with a work around...


For those who don't want to read the hows; the information you need is:

  1. This is an Android only issue; iOS doesn't have this issues.
  2. This is an Android 6.0 and higher issue.
  3. Fresh new installs will not have this issue, only devices that have had a old version on it.
  4. The main issue only occurs when you are upgrading from 2.x to 3.0 application.  (See update info above, related issue is different)    So new apps that started as 3.0 won't have this issue; and apps that stay 2.x won't have issues.  Only apps upgrading from 2.x to 3.x will have this issue on clients that are upgrading.
  5. This is a conflict between a file (in 2.5) that was changed into a folder (in 3.0).
  6. This is in the cases I've seen are caused by Google Auto-Backup auto restoring files/settings on the application installation.

If your app is a upgrade from 2.x to 3.x and you are wanting to release it to the Amazon or Google play store; don't do it -- for you and your customers sanity.  The app will crash on startup and you will be left scratching your head as to why it works (new customers) sometimes and why it doesn't (existing customers).

Progress is aware of the issue and how critical it is; so I would guess we should see a patch shortly (released in 3.01 ), however if you are under the gun and must release today; I have a fix that should also work, see end of blog post.   😉


The longer story; Brad Martin pinged me late last week because he ran into this issue.   He is one of the awesome members of the nStudio team, along with myself and Nathan Walker.  So I stopped what I was doing and began to help him out.    By the time we finished a couple hours of debugging (it was LATE Friday night) we had determined a number of things, but not the underlying issue.

We figured out that on what appeared to be a fully clean device it would still crash.

What we knew

  1. It didn't matter if it was Android @ release  or Android @ next runtimes.  (Wasn't runtime dependent.  Included cleaning this multiple times)
  2. We knew his tns-core-modules was 100% correct and it wasn't related to 3.00 or 3.01
  3. We knew his his tns-core-modules & widgets matched 100% a clean version on another machine (no npm corruption)
  4. We knew the .APK generated worked on all the emulators fine.
  5. We were pretty sure LiveSync couldn't be causing the problem (we nuked it several times and installed via a couple different methods)
  6. The platforms / src did NOT have that file in it, so no way the built APK could even get it.

Alexander Vakrilov (from the NS team) noticed the call stack was pointing to the old 2.5 style.js file.    I knew the 2.5 style.js file couldn't be coming from the freshly built apk and it wasn't in the LiveSync folder; so I actually thought that maybe there must be two different ways this error could appear, one of them would be someone upgrading and having the extra style.js in the node_modules/tns-core-modules, the other would be what Brad was running into.

Then Brad confirmed today that the style.js file was present in his stack trace.   That actually confused me quite a bit, because with the data we had above, that didn't make any real sense.  We had a fully clean APK without that file in it.  How was the device getting it?     We had manually deleted the livesync folder and even verified it was empty before we ran the app.    But the app would still crash with that call stack.    Color me confused...

So I took some time to scan the NativeScript android runtime source code for its livesync stuff.  I had seen the code before, but I wanted to make sure nothing major changed in 3.0.    I couldn't find anything other than what I expected to see.  No "other" LiveSync folders, so I was still confused...

So how is the device getting this file on it???

So I thought for a few minutes; in my best Sherlock Holmes voice; "When you have eliminated all which is impossible, then whatever remains, however improbable, must be the truth"

  1. Appears to be primarily happening on Real Android devices.
  2. Clear Data, works if done after the install.
  3. Doesn't matter how the app is installed.
  4. LiveSync doesn't appear to be responsible
  5. The generated APK is 100% correct.

If finally hit me; some sort of external force is causing the issue.   I was so focused on NativeScript; I didn't think about the other items on a REAL DEVICE.  It hit me like a 2x4... What is one thing that Real devices typically have over emulators???    A Google account is normally setup and syncing...    So I told Brad...

  1. De-install app (again)
  2. Nuke the LiveSync Folder (just to make sure)
  3. Turn on Airplane Mode (What a trouper he is, didn't even ask me why!)
  4. do a TNS run

App worked!    I'm like AWESOME, Brad is like WTF!     I don't blame him, I didn't tell him what the test was for, and so he had no idea what I was testing for.  And the poor guy has been not only doing my tests, but he had also put in a lot of time himself testing things...   He just had the surprising fact that it actually worked on his phone when in Airplane mode.    Me, I'm like I know what it is...

Android 6.0 Introduced a cool features called Auto-Backup; this nice feature backs up your data and files from your app.   Well unfortunately for us NativeScript users; NativeScript stores its .JS files in the /files/app folder.   Guess what one of the folders that is AUTO BACKED UP?   /files folder...

What is happening is there is a cool setting with your device, that will Automatically restore application settings when you re-install a application.

When you install app; it detects the name is the same, it restores the /files/ folder (adding any MISSING files) which then puts the old 2.5 styles.js file into the folder.    And then NativeScript attempts to load this file, and crashes...


My fix:

  1. Open your app/App_Resources/Android/AndroidManifest.xml file change or set/add the key allowBackup in your <Application> tag to "false" and the tools:replace.  So it should look like:

&lt;application
   android:name="com.tns.NativeScriptApplication"
   android:icon="@drawable/icon"
   android:label="@string/app_name"
   android:theme="@style/AppTheme"

   android:allowBackup="false"
   tools:replace="android:allowBackup"
&gt;

Then in the Manifest section you need to add the xmlns:tools namespace entry:
&lt;manifest xmlns:android="http://schemas.android.com/apk/res/android"
 xmlns:tools="http://schemas.android.com/tools"
 package="__PACKAGE__"
 android:versionCode="1"
 android:versionName="1.0"&gt;

By disabled the backup; you also disable the auto-restore of just this app's setting and files...  (Thanks Brad for confirming this works!)

 

NativeScript: Downgrading to 2.5

If you are needing to use a plugin that hasn't been upgraded to support 3.0 you basically have three choices, and guess what I can help with each of them...

  1. Wait for it to be updated; you can check my site http://plugins.nativescript.rocks; then select the "3.0" plugins list, now you can easily see when a plugin has 3.0 compatibility.
  2. Update it your self; or since I'm a contractor; you pay me; I will upgrade the plugin for you.
  3. Downgrade to NativeScript 2.5; I suspect most of you are the most interested in this since you are here...

The good news is that several of the 3.0 parts are backwards compatible.  You can be running the 3.0 NativeScript command line and build 2.5 apps.  You can also be using the 3.0 release runtimes with the core 2.5. modules.  So here is the way to downgrade a 3.0 app into a 2.5 app.

 

To downgrade PAN (Plain Awesome NativeScript) apps:

npm install tns-core-modules@2.5.2 --save
npm remove nativescript-dev-android-snapshot --save-dev
tns platform clean ios
tns platform clean android

If you are using TypeScript in your apps you need to do:

npm install typescript@2.1.6 --save-dev
npm install nativescript-dev-typescript@0.3.7 --save-dev

To Downgrade NAN (NativeScript ANgular) apps:

npm install --save @angular/animations@~4.0.0
npm install --save @angular/common@~4.0.0
npm install --save @angular/compiler@~4.0.0
npm install --save @angular/core@~4.0.0
npm install --save @angular/forms@~4.0.0
npm install --save @angular/http@~4.0.0
npm install --save @angular/platform-browser@~4.0.0
npm install --save @angular/platform-browser-dynamic@~4.0.0
npm install --save @angular/router@~4.0.0
npm install --save nativescript-angular@~1.5.0
npm install --save reflect-metadata@^0.1.8
npm install --save rxjs@~5.2.0
npm install --save zone.js@~0.8.4
npm install --save tns-core-modules@2.5.2

npm install --save-dev @angular/compiler-cli@~4.0.0
npm install --save-dev babel-traverse@6.15.0
npm install --save-dev babel-types@6.15.0
npm install --save-dev babylon@6.11.2
npm install --save-dev htmlparser2@^3.9.2
npm install --save-dev Lazy@1.0.11
npm install --save-dev typescript@2.1.6
npm install --save-dev nativescript-dev-typescript@0.3.7
npm remove --save-dev nativescript-dev-android-snapshot

tns platform clean ios
tns platform clean android


One note that seems to confuse some people; you can continue to use the NativeScript 3.0 CLI with NativeScript 2.5 applications.  You can also use the 3.0 Runtimes (highly recommended actually) with your 2.5 Core modules applications.

Any of my 2.5 applications are now (This setup is fully 2.5 plugin compatible):
- 3.0 CLI
- 3.0 Runtimes
- 2.5 TNS Core Modules (if NAN, then you need the old Angular stuff as listed above)

And my 3.0 applications are (This is the standard 3.0 setup)
- 3.0 CLI
- 3.0 Runtimes
- 3.0 TNS Core Modules  (if NAN, then you need the new 3.0 compatible Angular Stuff)

 

NativeScript Android Snapshots

For those who haven't deployed any apps in v2.4 of NativeScript; one of the new features that is turned on by default is SnapShots.    Now most the time this is a AWESOME thing, however occasionally this can cause issues.   For example I have one app of mine that this crashes at startup when using SnapShots.

Now the docs do list how to disable snapshots; but it is a lot easier for me to find the notes on my own site than trying to figure out which doc has the info.

The environmental variable you need to adjust is: <strong>TNS_ANDROID_SNAPSHOT</strong>

  • 0 = Force Snapshots off always
  • 1 = Force snapshots on (including in debug mode)
  • Unset = Snapshots only in Release mode

Allowing TypeScript to understand NativeScripts ~/ home path

I know a wide number of you use TypeScript; well one of the irritations I've had with TypeScript -- I just figured out how to solve.   Finally did some research and tests to figure out how to make TypeScript support using ~/ as a normal path for building and determining editor intellisense since this is a special path in NativeScript meaning the home app path.   Using this path in a import / require statement means you can do something like this.

/app/views/login/login.ts ->

import * as animation from '~/support/animation'
and it will load in the file at   /app/support/animation

You can use relative paths, but I find absolute path's a lot easier to read and understand exactly which file is being loaded.   In addition things like my NativeScript-Updater can't use relative path's (do to some low level issues in the iOS runtimes) and determine if a file has been updated.

Ok, so the solution: open your tsconfig.json file and add the following:

"baseUrl": ".",
"paths": {
   "~/*": [
     "./*"
   ]
  }

To the "compilerOptions" key in the json file.

MySQL SSL required connection Ubuntu solutions

I went to implement MySQL replication for a client this evening and ran into some interesting issues that I haven't ran into before. Guess it has been a while since I had to set it up from a client.   So this post is for notes for me or someone else who might need to do this in the future. The normal installation replication installation works great but if you are going to enable ssl connections this is where the things can get a bit more complex.

The first thing to find out is if you have your SSL setup correct, try doing:
And verify the SSL is enabled and build in, in my case everything looked good:

mysql> SHOW VARIABLES LIKE '%ssl%';

have_openssl  = YES
have_ssl      = YES
ssl_ca        = /etc/mysql/certs/ca-cert.pem
ssl_capath    =
ssl_cert      = /etc/mysql/certs/server-cert.pem
ssl_cipher    =
ssl_crl       =
ssl_crlpath   =
ssl_key       = /etc/mysql/certs/server-key.pem\";

This looks correct, so the next thing to figure out is where the error log file is located;
mysql> SHOW VARIABLES LIKE '%error_log%';

log_error     =  ./mysql-bin.err
or something like
log_error     = /var/log/mysql/error.log

Now that you know where the error log is at you can see why it is failing.

In my case the error was this:

2016-12-06 23:21:33 32695 [Warning] Failed to setup SSL
2016-12-06 23:21:33 32695 [Warning] SSL error: SSL_CTX_set_default_verify_paths failed

I love that it is a "Warning".   It is totally broken, but we will list it as a Warning...

Well, this can be caused by several things:

  1. No permissions to the files in the folder, use chmod/chown to give perms.
  2. SELinux blocking it, disable selinux or grant permissions via SELinux
  3. AppArmor blocking it.  (this was my case)

Edit the /etc/apparmor.d/usr.sbin.mysqld file.

You'll see something like this in the file:

/etc/mysql/*.pem r,
/etc/mysql/conf.d/ r,
/etc/mysql/conf.d/* r,
/etc/mysql/*.cnf r,
---> /etc/mysql/certs/*.pem r,  <---
/usr/lib/mysql/plugin/ r,

Add the ---> line <---, make sure it matches your path to where you are storing the certs.  Then restart mysql. After restarting the server, I then got this error: SSL error: Unable to get private key from '/etc/mysql/certs/server-key.pem' 2016-12-06 23:53:32 21728 [Warning] Failed to setup SSL 2016-12-06 23:53:32 21728 [Warning] SSL error: Unable to get private key Ok, this one threw me for a while.  The files are fully readable by MySQL.  The issue ends up being incompatibilities between SSL libraries in use.  OpenSSL 1.0x vs yaSSL The key file will start like this:
-----BEGIN PRIVATE KEY-----
If you used OpenSSL to generate the keys;  OpenSSL creates keys in PKCS#8 with a SHA256 digest.  Of course yaSSL which is (normally) used by MySQL doesn't support either, and want PKCS#1.  So despite having the files fully readable, MySQL is telling you it can't figure out how to "get the private key" out of the file.  Once you know the issue, it has a simple solution:
openssl rsa -in server-key.pem -out server-key.pem
when you are done with this command the beginning of the file should look like this:
-----BEGIN RSA PRIVATE KEY-----
Again, the internal format is different, so don't try and just change the text and insert the "RSA" into it -- it will look like it works until something try's to connect using SSL. Once you have this done, restart mysql again and you should be good to go.

NativeScript 2.4.0 - New Features

ns-version240Some of you might have seen the all New version 2.4.0 has been released today.   This has been a release that has taken a bit of time to get right, but it is finally out!  Wooo Hoooo!!!

Some of the new features

  • NativeScript Workers
  • Per-Side borders
  • Flexbox layout
  • Android Snapshots on Release build (faster app start time)
  • Added "import" to point to the JS file
  • More pseudo selectors: button now supports: pressed, active and highlighted, and views descendants support disabled.
  • Segmented Bar now has a new css property:  selected-background-color
  • TabView now has new CSS properies: tabTextColor, tabBackgroundColor, selectedTabTextColor, and androidSelectedTabHighlightedColor
  • Some CSS properties now support % sizes:  height, width, margin-left, margin-top, margin-right, margin-bottom, margin.
  • Image Capture allows rotation.
  • Camera module now a plugin (Removes a permission)
  • Brand new Theme!
  • Reduce the size of the Android App
  • Much nicer Android crash screen
  • Faster tns prepare
  • Android has ~ 97% support for pure ES6 code.
  • Can create TypeScript typings automagically on android platform using --androidTypings command line.

Lots and lots of bug fixing in all the repo's.

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

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.4.x

Common Issues:

  • iOS failing to build, older projects:  v2.4 requires you to have the Info.plist file in the app_resources/ios folder.    The simplist way to fix this is to create a new project and then replace your app_resources with the new app_resources folder.  If you have any resources you have manually added or any changes to any files make sure you copy them out before you delete the old app_resources folder.  I would highly recommend you do NOT merge them as you might get some weird behavior from the old resources in the old format vs the new resources in the newer layout.
  • iOS requires CocoaPods v1.0 or later.   This is not a NativeScript issue so much as the Cocoapod infrastructure no longer allows anything older than 1.0..
  • Android failing to build with some plugins (like NativeScript-Telerik-Ui). with the error Multiple dex files define Landroid/support/v4/accessibility
  • Android failing with snapshot error, install the nativescript snapshot support via
    npm install nativescript-dev-android-snapshot@latest --save-dev
  • TNS no longer building your TypeScript files or livesync'ing any of your TS files.

 

NativeScript - Professional post series

I've been doing NativeScript for a while; and since I'm a contractor/freelancer; and no specific company pays my salary -- I've decided to start putting some of my cool learned tips into the paid category.   Most of these will only qualify if they took me multiple hours to figure out.  Unfortunately nobody pays me for fixing things when they break...  So, if I can use my hard earned knowledge to save you a vast amount of time, what is it worth to you?
All this knowledge is time tested and can save you a vast amount of diagnostic time on why something doesn't work.   So if you think saving you time is worth it; please feel free to sign up and support me; and I will provide the information you need when you need it...
The different series are going to be available on my Patreon site: https://www.patreon.com/NathanaelA
The first series is; NativeScript Platform Differences


You might get an app running perfectly on one platform, and then wonder why it isn't working on the other.   I have started out with a cool post on several issues you might have between iOS and Android using HTTP/HTTPS.

The second series is: Troubleshooting your NativeScript
I have started this series out on dealing with Upgrading from NativeScript  to 2.4 and issues you might face.
The first post in this series deals with a specific iOS upgrading issue.
The second post in this series deal with a specific Android upgrading issue (Error starts with: Multiple dex files), when using several plugins...
The third series is: Ready to Distribute my app...  What now?
The first post in this series deals with a specific iOS Build issues...
The second post in this series deals with a specific iOS Build configuration information.
Some of these posts will be showing up in the next couple day as I have time to finish them off...
And yes; I will continue to post free useful stuff...   😉

NativeScript: iOS and xCode 8 the wonderful world of breaking changes

native8xcodeFor those who have upgraded to the all new xCode 8, you may have noticed some of the plugins breaking...     The biggest breaking change in NativeScript and xCode 8 is now things deep down in the ObjC runtime that used to be a function call are now a property.

So, for example let say you needed to access UIScreen.mainScreen.

 

 

In xCode 7 this was

var mainScreen = UIScreen.mainScreen();

in xCode 8 this is now:
var mainScreen = UIScreen.mainScreen;

Notice, it is no longer a FUNCTION call.  It is a PROPERTY.   Now how do you make this compatible so your code can run with both xCode 7 and xCode 8.

If you are developing an app; I recommend you use the helper function that Telerik added to NativeScript which they use throughout the core modules.

var utils = require('utils/utils');
var mainScreen = utils.ios.getter(UIScreen, UIScreen.mainScreen);

If you have your own plugin, then I'm going to recommend you embed my code into your own plugin...  The code is basically the same as Teleriks, but you eliminate the require call.
function iosProperty(theClass, theProperty) {
    if (typeof theProperty === "function") {
        // xCode 7 and below
        return theProperty.call(theClass);
    } else {
        // xCode 8+
        return theProperty;
    }
}

Then you use it the exact same way;
var mainScreen = iosProperty(UIScreen, UIScreen.mainScreen);

Happy NativeScripting, and hopefully you can easily get all your plugins updated shortly to support both xCode 7 & 8!