Currently the projectName value that is passed into the platform template is set here:
https://github.com/NativeScript/nativescript-cli/blob/master/lib/project-data.ts#L101

this.projectName = this.$projectHelper.sanitizeName(path.basename(projectDir));

So if your NativeScript app is under ~/projects/my-project, the iOS project will end up being named myproject.xcodeproj, and the resulting app package will be named myproject.ipa. If you check this project into source control and a team member clones it into ~/git/project-app, when they build the project their iOS project will be named projectapp.xcodeproj, and the resulting app package will be named projectapp.ipa. Since the project name is always based on the directory containing the NativeScript app, there is no way to predict what the output file will be named, unless you put the root of your app in a subdirectory of your repository.

Why is this a problem? I have been trying to get continuous integration builds working with Bamboo within our enterprise. The way that Bamboo works is it has a unique certain key based on the project, plan, and job that it generates, and that is the name of the folder that it clones the project into during builds. Because of this, it is proving to be difficult to predict the name of the artifact that will be generated from the build. Actually I don't even get that far, since, it is difficult to predict the name of the XCode project I need to hand off to FastLane to do all of our enterprise build and deployment tasks.

Ideally, instead of using the name of the directory containing the NativeScript project, instead we could sanitize the name of the project as specified in package.json, or even a custom property in that file under nativescript (I noticed you already have an id field there to specify the bundle identifier). If such a field doesn't exist, you could fall back on using the directory name, but that would at least give a way to name your project and IPA file and have a predictable build artifact.