Edit variables found in `AndroidManifest.xml` and `Info.plist` from a single file.

[7ammer]

Is your feature request related to a problem? Please describe. My client wants to be able to have multiple versions of the same app. One for production, a beta version for testFlight and an Ad Hoc version. I do not see an easy way to do this. It appears to currently involve manually editing multiple files which is error prone and messy.

Describe the solution you'd like I'd like to be able to edit the variables found in AndroidManifest.xml and Info.plist from a single file like nativescript.config.ts or package.json.

Things like: CFBundleName, CFBundleDisplayName, CFBundleShortVersionString and CFBundleVersion or versionCode, versionName, package.

If I could edit these values in nativescript.config.ts I could very easily write some code to change these values by adding something like NODE_ENV=testflight to the beginning of of a NS build command. This would then set the required variables depending on the environments I've setup.

Describe alternatives you've considered After asking around on slack I've found out that it's possible to add variables to app.gradle and build.xcconfig and use those in the files in question. However, I would like to be able to edit a single file.

If this feature does not exist I think it would help make nativescript more accessible for new users that want to do simple things like change the app name or version number. It would also help with more advanced things like I've mentioned above - swapping out the package name to build multiple versions of the same app.

If this feature already exist could you kindly explain how it can be achieved.

Many thanks

[xiromoreira]

Trying to do something similar I ended using hooks. I feel the use of hooks should be easier and could achieve this issue as well. Since we all are developers, a programmatic hook to make any changes on the project is flexible and powerful (not so clean, though).

But I feel these issues:

• Very few docs, and only on the CLI repo, should be linked or mentioned in webpage and/or here. When you search for nativescript hooks in google or in the issues list, you won't find anything relevant! Only a blog post talking about v6 migration.
• Document or simplify the API to know how to retrieve basic information (the inners of CLI can be hidden a bit only for those willing to risk versions breaking their hooks).
• hooks directory is usually ignored for repo and removed (by tools or by user), a place to put project persistent hooks would be great.

Should this be a separate issue?

[rigor789]

@xiromoreira i created a new issue in the CLI repo.

[7ammer]

Nativescript mentioned "workspaces" in their latest blog post which may help answer my question / anyone else with the question. (I've not actually tested this out yet).

https://blog.nativescript.org/nativescript-8-1-announcement/index.html#cli-updates

The CLI has been updated to officially support "workspace development". Over the years, several fantastic workspace style (monorepo) tools have become integral parts of scalable software development including but not limited to Lerna, Yarn Workspaces, Nrwl Nx and Microsoft Rush.

[sebj54]

This would be a very interesting feature!

Actually I need it in one of my project to be able to define variables from env. It would be very useful, especially for variables you don't want to commit in the repo (like tokens, secrets…)

Sometimes, I also have default values for those variables but they can be overridden (eg for dev environment).

I think workspaces can be a solution for that but I used to add custom hooks in my past projects. I found them not reliable (especially when NS7 has came out) so I don't use them any more.

I don't know how but it seems that there is something already supported because there are already injected variables in Info.plist (executable name, version…).

[insytes]

I actually made a plugin to do this very thing.

https://github.com/ontrackms/nativescript-dotenv

To make it work automatically, my nativescript.config.ts file reads the bundle ID from package.json

import { NativeScriptConfig } from '@nativescript/core';
import { readFileSync } from 'fs';

const { name } = JSON.parse(readFileSync('./package.json', 'utf-8'));

export default {
  name,
  id: name,
  appResourcesPath: 'App_Resources',
  android: {
    v8Flags: '--expose_gc',
    markingMode: 'none'
  },
  useLegacyWorkflow: true,
} as NativeScriptConfig;