2.5.1 iOS incremental build generates inconsistent binary

[toddanglin]

There appears to be an issue with 2.5.1 that is corrupting all incremental iOS builds targeting the simulator. The issue is captured and well described here:

https://discourse.nativescript.org/t/ns-2-5-1-ios-incremental-build-generates-inconsistent-binary/591

Steps to reproduce:

• Build and deploy an app to the iOS simulator using CLI 2.5.1
• Trigger an incremental/LiveSync build
• After successful build/sync, the app will crash on simulator
• App cannot be re-opened or run until a fresh build is forced (using tns build or tns deploy)

This problem did not exist in 2.5.0.

[dtopuzov]

@toddanglin
Can you reproduce the issue with hello-world templates?
Can you post your package.json?

I can not reproduce with:

npm uninstall -g nativescript
npm install -g nativescript@2.5.1
tns create TestApp && cd TestApp
code app (open app folder in VSCode)
tns run ios

Make whatever changes (in css, js, xml, break the app on purpose with invalid changes and then fix it)
Result: No issues.

Same with release branch of https://github.com/NativeScript/sample-Groceries -> No issues.

[toddanglin]

Let me try to create a project that reproduces the issue. Clearly, as per the forum thread, I'm not the only one encountering this error...but it's also clear that it's not impacting every project.

I have a hunch that it could be related to plugins, most like i18n since it does the most during the build process. Let me test and report back...

[toddanglin]

Still struggling to get a new project to recreate the error. Here is the series of log messages that occurs when a LiveSync happens on my existing app (run with tns run ios --emulator):

Executing before-prepare hook from myapp/hooks/before-prepare/nativescript-dev-typescript.js
Executing before-prepare hook from myapp/hooks/before-prepare/nativescript-i18n.js
Preparing project...
Project successfully prepared (ios)
Executing after-prepare hook from myapp/hooks/after-prepare/nativescript-i18n.js
Transferring project files...
Successfully transferred myView.xml.
Refreshing application...
Successfully synced application com.htmlui.MyApp on device [UUID].

NativeScript debugger attached.
CONSOLE LOG file:///app/tns_modules/tns-core-modules/trace/trace.js:151:28: Debug: TabView._onSelectedIndexPropertyChangedSetNativeValue(1)
CONSOLE LOG file:///app/views/tabs/devicesView.ts:76:16: OLD INDEX undefined
Skipping prepare.
Transferring project files...
Successfully transferred InfoPlist.strings.
Successfully transferred Localizable.strings.
Refreshing application...
Feb 21 17:12:30 Mac-Pro com.apple.CoreSimulator.SimDevice.[UUID].launchd_sim[427] (UIKitApplication:com.htmlui.MyApp[0xd35f][5579]): Service exited due to signal: Terminated: 15
Unable to sync files. Error is: Command xcrun with arguments simctl launch [UUID] com.htmlui.MyApp failed with exit code 3. Error output:
 An error was encountered processing the command (domain=NSPOSIXErrorDomain, code=3):
Failed to lookup the process ID of com.htmlui.MyApp after successful launch.  Perhaps it crashed after launch.
No such process

Everything looks fine...the sync happens the app is refreshed...but then the process keeps going and seemingly attempts to build and refresh a 2nd time. Not sure if this will help trigger any ideas about what could be happening. Will keep trying to create a local, isolated problem reproduction.

[toddanglin]

Okay. Got it. This simple hello-world project reproduces the error:
https://github.com/toddanglin/ns-build-error

The steps to recreate the project:

• Create a new hello world project with CLI 2.5.1, with or without TypeScript template (tns create demo --tsc)
• Add the iOS platform (tns platform add ios)
• Add the i18n plugin (tns plugin add nativescript-i18n)
• Create the folder/file for i18n strings: app > i18n > en > strings.xml
• Add some string keys to the strings.xml file like:

<resources>
    <string name="btnText">Next</string>
</resources>

• Run the project on the iOS simulator (tns run ios --emulator)
• Project should build and load correctly
• Make a change to the app source and save, triggering a LiveSync
• Watch the build process get stuck in a loop of rebuilding and redeploying the native app

Let me know if you are unable to reproduce the problem using this project. Seems to be definitely related to the i18n plugin. To trigger, you must have the plugin installed and a strings.xml file in the project.

[toddanglin]

All of this is likely also related to this Issue in the nativescript-i18n repo:
EddyVerbruggen/nativescript-i18n#37

And this issue from 2.5.0:
#2482

Not sure if this is a regression or if the problem that those threads suggest was fixed did not cover all the scenarios. But definitely looks like same problem, only more severe in 2.5.1.

[Plamen5kov]

Thank you @toddanglin,
We'll investigate.

[toddanglin]

FWIW, I've downgraded to 2.5.0 for now. Seems to be the only way to continue working with the i18n plugin until this build issue is resolved.

[rosen-vladimirov]

Hey @toddanglin ,
It looks like the nativescript-i18n plugin has before-prepare hook that modifies Info.plist in app/App_Resources/iOS directory: https://github.com/rborn/nativescript-i18n/blob/master/lib/before-prepare.js#L52 . All changes in App_Resources required rebuiliding the application. That's why CLI starts a new build when you apply any change. Plugin's hook always modifies the Info.plist file, no matter which file has been changed. CLI 2.5.0 has issues with checking files (it relies on the mtime of a file, not the ctime, which is incorrect), that's why you do not see the error with it - it just does not understand there's a change in App_Resources.
I'm not sure what is the best way to handle this. I have some ideas, for example:

1. In CLI we may check the shasum of the modified files during watch and we may not transfer them to device (platforms dir in the project) in case the file there is the same. This way when you modify any other file, nativescript-i18n hook will overwrite app/App_Resources/Info.plist file, but its content will be the same and CLI will disregard this modification.
2. Another option is to add new hook in which CLI will notify the plugins which are the modified files during watch. In this case, the plugin itself will see that the modified file is not any of the files that concerns its behavior and will not regenerate Info.plist.
3. Third option is to add a new file at the top of the project, which will define the directories that should be watch. We may support minimatch syntax, so in case you will not modify App_Resources, you'll be able to exclude the directory from watched dirs. This will also allow watching of specific directories from node_modules and trigger livesync in case any file inside these plugins is modified.

What do you think? Ping @hshristov , @Plamen5kov as well.

[toddanglin]

Personally, I like both Option 2 and 3.

• Option 2 gives plugin authors power to make better plugins
• Option 3 gives developers power to override default plugin behavior and explicitly opt-out folder from the watch process

Thinking of the CLI behavior before 2.5.0...the reason none of these problems existed was because LiveSync wouldn't attempt to do a native rebuild. The nativescript-i18n plugin would warn you that you'd need to manually trigger a full rebuild if you changed the strings definitions. And life was good. :)

I'm wondering if another option to consider is a flag (or config option) for tns run that lets developers disable native rebuilds during a LiveSync watch session. There are pros and cons to this approach, but it is this key change from 2.4 that is causing a lot of these problems now.

Adding @rborn since his plugin is one of the more popular impacted here.

[Plamen5kov]

I'm for option 2. Power to the people!

I'm wondering if another option to consider is a flag (or config option) for tns run that lets developers disable native rebuilds during a LiveSync watch session.

@toddanglin I'm not so optimistic about the flag and here's why:

• misuse (it has happened already with other flags of the sort --watch --no-watch)
• might not resolve all variations of problems (not a general solution)
• confusion about yet another flag
• late adoption