Nativescript: Upgraded our OS to 14.2 and the enterprise app starts crashing, couldn't open it, install via MDM

Created on 1 Dec 2020  路  15Comments  路  Source: NativeScript/NativeScript

Environment
Provide version numbers for the following components (information can be retrieved by running tns info in your project folder or by inspecting the package.json of the project):

Describe the bug
The problem is similar to this:
https://developer.apple.com/forums/thread/666399,
OS: iOS 14.2, iOS 14.3 Beta 1, iOS 14.3 Beta 2
Hardware: Any arm64e cpu device (ex: iPad Pro 11" 1st/2nd gen, iPad Pro 12.9" 3rd/4th gen, iPad 8th gen, iPad Air 3rd/4th gen, iPhone 11, etc)
Deployment:
Deployed via any MDM and AppStore, install via MDM -> crash,install via AppStore -> works fine,
Ad-hoc .ipa deployment works fine even via MDM,
so via -> AppStore -> MDM -> crash

To Reproduce

Expected behavior

Sample project

Additional context

Does anyone have a similar problem? This is currently the same problem with Xamarin Apps.

backlog bug help wanted

Most helpful comment

@JamesRoome & @xuzhanqian - To set your expectation correctly, as much as we love to fix every issue reported -- unless it is something really simple that the logs point to -- this is very much likely not a issue that we will fix anytime soon as it will just consume too much time for the very tiny number of actual developers impacted. This issue is technically a "self-inflicted" corner case that doesn't affect the community at large.

Since this is a 100% open source project with currently a very very small amount of funding, our limited resources are so much better served dealing with the issues that affect the majority of the community rather than any corner cases that have such a small impact to the entire eco-system. We will gratefully accept any PR's to fix this...

Ways forward:

  • Your companies dedicate employees to research and create a PR to fix this. :+1:
  • One (or both) of your companies fund the time for us at nStudio to research and fix it.
  • One (or both) of your companies gets a enterprise support contract (which they are used to fund NS) and use one of your tickets on this issue.
  • Another enterprise company using MDM steps up and does one of the above...
  • Someone else from the community decides to fix it with a PR.

As such I'm marking this issue as a backlog issue... As we agree it is a real issue, and we would love to fix it, but it is not one we have the resources to fix at this point at time...

All 15 comments

This is the crash log.

    15:48:13.822149+0800        Cache loaded with 4644 pre-cached in CacheData and 54 items in CacheExtra.
    15:48:14.411175+0800        Initializing connection
    15:48:14.411348+0800        Removing all cached process handles
    15:48:14.411521+0800        Sending handshake request attempt #1 to server
    15:48:14.411655+0800        Creating connection to com.apple.runningboard
    15:48:14.414299+0800        Handshake succeeded
    15:48:14.414550+0800        Identity resolved as application<com.fonterra.ifonterra.prd>
    15:48:14.450736+0800        networkd_settings_read_from_file initialized networkd settings by reading plist directly
    15:48:14.451037+0800        networkd_settings_read_from_file initialized networkd settings by reading plist directly
    15:48:14.748261+0800        FBSWorkspace connecting to endpoint : <private>
    15:48:14.748394+0800        FBSWorkspace registering source: <private>
    15:48:14.749898+0800        FBSWorkspace connected to endpoint : <private>
    15:48:14.750005+0800        Added observer for process assertions expiration warning: <_RBSExpirationWarningClient: 0x282755760>
    15:48:14.765166+0800        Registering for test daemon availability notify post.
    15:48:14.765470+0800        notify_get_state check indicated test daemon not ready.
    15:48:14.804029+0800        NativeScript caught signal 10.
    15:48:14.804100+0800        Native Stack:
    15:48:14.807189+0800        1   0x101497018 sig_handler(int)
    15:48:14.807492+0800        2   0x1ca282290 <redacted>
    15:48:14.807591+0800        3   0x18381a540 <redacted>
    15:48:14.807737+0800        4   0x18381c5a8 <redacted>
    15:48:14.808058+0800        5   0x183822004 <redacted>
    15:48:14.808151+0800        6   0x182e79910 <redacted>
    15:48:14.808741+0800        7   0x1833e7404 _UIScenePerformActionsWithLifecycleActionMask
    15:48:14.808815+0800        8   0x182e7a4a8 <redacted>
    15:48:14.808953+0800        9   0x182e79f68 <redacted>
    15:48:14.809094+0800        10  0x182e7a2b8 <redacted>
    15:48:14.809294+0800        11  0x182e79af4 <redacted>
    15:48:14.809426+0800        12  0x182e82040 <redacted>
    15:48:14.809616+0800        13  0x1832f4030 <redacted>
    15:48:14.809871+0800        14  0x1833ffb2c _UISceneSettingsDiffActionPerformChangesWithTransitionContext
    15:48:14.809993+0800        15  0x182e81d38 <redacted>
    15:48:14.810117+0800        16  0x182ca9bb4 <redacted>
    15:48:14.810460+0800        17  0x182ca8528 <redacted>
    15:48:14.810528+0800        18  0x182ca97dc <redacted>
    15:48:14.810653+0800        19  0x1838201a4 <redacted>
    15:48:14.810897+0800        20  0x18331d85c <redacted>
    15:48:14.810982+0800        21  0x19017947c <redacted>
    15:48:14.811074+0800        22  0x1901a4dc4 <redacted>
    15:48:14.811125+0800        23  0x190188560 <redacted>
    15:48:14.811172+0800        24  0x1901a4a88 <redacted>
    15:48:14.811223+0800        25  0x180a64db0 <redacted>
    15:48:14.811348+0800        26  0x180a68738 <redacted>
    15:48:14.811425+0800        27  0x1901cd310 <redacted>
    15:48:14.811508+0800        28  0x1901ccfa0 <redacted>
    15:48:14.811606+0800        29  0x1901cd4f4 <redacted>
    15:48:14.811660+0800        30  0x180dec76c <redacted>
    15:48:14.811708+0800        31  0x180dec668 <redacted>
    15:48:14.811793+0800        JS Stack:
    15:48:14.811842+0800        UIApplicationMain([native code])
at run(file:///app/vendor.js:92762:26)
at file:///app/vendor.js:87008:26
at file:///app/vendor.js:86909:38
at file:///app/vendor.js:86889:26
at ./main.ts(file:///app/bundle.js:1409:117)
at __webpack_require__(file:///app/runtime.js:75:34)
at checkDeferredModules(file:///app/runtime.js:44:42)
at webpackJsonpCallback(file:///app/runtime.js:31:39)
at anonymous(file:///app/bundle.js:2:61)
at evaluate([native code])
at moduleEvaluation
at 
at asyncFunctionResume
at 
at promiseReactionJob

You would need to check your vendor.js file at line 92762, 87008, 86909, 86889 and see what it is doing to have an idea why it is crashing... You might also double check your bundle.js:1409:117 to see what it called.

We are also seeing this crash issue. App works just fine on iOS 14.1 and below (deployed using MDM). It crashes with iOS 14.2 when deployed using an MDM tool (works fine with normal deployment).

Our MDM provider sent us this link for troubleshooting: https://developer.apple.com/forums/thread/666399

The Xamarin team have a fix, but it is very Xamarin specific (https://github.com/xamarin/xamarin-macios/issues/10086#issuecomment-738237870). Looking for a NativeScript fix.

I'll be getting my development tablet setup with an MDM today, so will hopefully be able to followup with the vendor.js info.

at run(file:///app/vendor.js:92762:26)

This is code at vendor.js:92762.
This method leads to Crash, but it does nothing.

if (!iosApp.nativeApp) {
UIApplicationMain(0, null, null, iosApp && iosApp.delegate ? NSStringFromClass(iosApp.delegate) : NSStringFromClass(Responder));
}

This line of code is actually the bootstrap that iOS uses to bootstrap the app, it actually goes into Apple's Code at that moment, that explains why their is mostly native code in the crash log . See:
https://developer.apple.com/documentation/uikit/1622933-uiapplicationmain?language=objc

This really does look like something between the MDM and the Apples changes to IOS 14.2 -- Can you find out from your MDM provider if they have see the SIGBUS (Signal 10) error in other apps? Are they possibly twiddling the application delegates on startup?

NativeScript caught signal 10.

  • Which MDM provider?
  • In addition have you tried the NS7 engine with your app on iOS 14.2 and your MDM code, it is a completely different engine..
  • Can you also pull the full crash log from the actual Apple device so we can see any other relevant information.

This line of code is actually the bootstrap that iOS uses to bootstrap the app, it actually goes into Apple's Code at that moment, that explains why their is mostly native code in the crash log . See:
https://developer.apple.com/documentation/uikit/1622933-uiapplicationmain?language=objc

This really does look like something between the MDM and the Apples changes to IOS 14.2 -- Can you find out from your MDM provider if they throw the SIGBUS (Signal 10) at any point?

I believe the notify_get_state is from your MDM provider, I don't recall seeing that before...

notify_get_state check indicated test daemon not ready.
NativeScript caught signal 10.

And then we are seeing this SIGBUS signal, and catching it. So it might be something we need to ignore, but this part of the code has not changed; so this is something either Apple or your MDM (probably the MDM) provider is throwing...

  • In addition have you tried the NS7 engine with your app on iOS 14.2 and your MDM code..
  • Can you also pull the full crash log from the actual Apple device so we can see any other information.

Thank you. I have released a demo of N7, which has been approved by Apple. I hope N7 will not have MDM problems. If N7 still has MDM issues, I will update the latest Crashlog.

@xuzhanqian Please report if that fix works or not.

Thanks for your investigations.

After the N7 demo was approved by Apple, it was installed on 14.2 devices through MDM, but it still crashed. This is the latest Crashlog, it seems that the problem still exists
notify_get_state check indicated test daemon not ready.

09:37:35.248048+0800        networkd_settings_read_from_file initialized networkd settings by reading plist directly
09:37:35.248117+0800        networkd_settings_read_from_file initialized networkd settings by reading plist directly
09:37:35.253038+0800        nw_path_evaluator_start [679A41C0-F7D6-467D-9AB2-6B5A787F9560 <NULL> generic, indefinite]
path: satisfied (Path is satisfied), interface: en0, ipv4, dns
09:37:35.510298+0800        Cache loaded with 4644 pre-cached in CacheData and 53 items in CacheExtra.
09:37:35.576811+0800        Initializing connection
09:37:35.576863+0800        Removing all cached process handles
09:37:35.576941+0800        Sending handshake request attempt #1 to server
09:37:35.577043+0800        Creating connection to com.apple.runningboard
09:37:35.578388+0800        Handshake succeeded
09:37:35.578423+0800        Identity resolved as application<com.xxxxx.xxx>
09:37:35.950232+0800        [FBSDisplaySource 1-1] silently connecting <FBSDisplayConfiguration: 0x283c08fc0; Main; mode: "414x896@2x 60Hz p3 SDR">
09:37:35.950294+0800        [FBSDisplaySource 1-1] initialized <FBSDisplayConfiguration: 0x283c08fc0; Main; mode: "414x896@2x 60Hz p3 SDR">
09:37:35.953552+0800        FBSWorkspace connecting to endpoint : <private>
09:37:35.953583+0800        FBSWorkspace registering source: <private>
09:37:35.953788+0800        FBSWorkspace connected to endpoint : <private>
09:37:35.953834+0800        Added observer for process assertions expiration warning: <_RBSExpirationWarningClient: 0x28052db40>
09:37:35.955166+0800        Registering for test daemon availability notify post.
09:37:35.955877+0800        notify_get_state check indicated test daemon not ready.

Is it possible to solve this problem with NativeScript Framwork? Or is it apple's problem?

@xuzhanqian From all the research that I have done, while the issue has indeed be caused by a change between iOS 14.1 and 14.2, it seems like there is a change frameworks like NativeScript can make that will fix this issue.

This is a huge issue for us, we have a customer with 40+ iPads at different sites across the country, and all I can tell them is to send them all into the corporate office so they can be downgraded to 14.1

It is a Apple created issue; but sounds unlikely they will fix it as they made Microsoft make horrible changes to Xamarin which I'm sure the Xamarin team are not happy about to make it work in MDM. If you can provide which MDM provider you use and the crash logs from the device we _might_ be able to figure out some weird work around for MDM usage.

@JamesRoome & @xuzhanqian - To set your expectation correctly, as much as we love to fix every issue reported -- unless it is something really simple that the logs point to -- this is very much likely not a issue that we will fix anytime soon as it will just consume too much time for the very tiny number of actual developers impacted. This issue is technically a "self-inflicted" corner case that doesn't affect the community at large.

Since this is a 100% open source project with currently a very very small amount of funding, our limited resources are so much better served dealing with the issues that affect the majority of the community rather than any corner cases that have such a small impact to the entire eco-system. We will gratefully accept any PR's to fix this...

Ways forward:

  • Your companies dedicate employees to research and create a PR to fix this. :+1:
  • One (or both) of your companies fund the time for us at nStudio to research and fix it.
  • One (or both) of your companies gets a enterprise support contract (which they are used to fund NS) and use one of your tickets on this issue.
  • Another enterprise company using MDM steps up and does one of the above...
  • Someone else from the community decides to fix it with a PR.

As such I'm marking this issue as a backlog issue... As we agree it is a real issue, and we would love to fix it, but it is not one we have the resources to fix at this point at time...

Just bumped into this issue we have stopped MDM updating to iOS to 14.2 can we some how come together to resolve this issue? Keen to get this resolved as we have hospital applications which are critical, love to chat more on NativeScript slack.

Not N related. Xamarin is facing the same issue https://github.com/xamarin/xamarin-macios/issues/10086. Apparently Apple is about to release a fix https://github.com/xamarin/xamarin-macios/issues/10086#issuecomment-743395597

  • One (or both) of your companies fund the time for us at nStudio to research and fix it.

This is definitely a possibility. How can I get an estimate of cost to investigate and the timing for doing so?

Getting this resolved is becoming increasingly critical to my company and customers.

@tmedora - You can send a email to us at [email protected] it will go into our support queue and one of us at nStudio will respond. ;-)

Was this page helpful?
0 / 5 - 0 ratings

Related issues

hshristov picture hshristov  路  3Comments

nirsalon picture nirsalon  路  3Comments

kn9ts picture kn9ts  路  3Comments

rLoka picture rLoka  路  3Comments

dhanalakshmitawwa picture dhanalakshmitawwa  路  3Comments