This allows non-simulator builds on CI servers without setting up team-id/provisioning-profile/etc.
It also allows signing using a different method, if desired.
Co-Authored-By: mcagabe19@users.noreply.github.com
Code intelligence should always use the newest hxml content, so the fallback mode where the hxml content is generated, instead of loaded from an existing .hxml file, should be used when the project file is newer.
For instance, if the user changes any file/dir paths in their project file, continuing to use the existing .hxml file could lead to confusing error messages that still reference the old/cached file paths. It should always use the latest paths or other values from the project file. It should be considered a bug to use the old cached paths.
Previously, as a workaround, the user would need to clean or build their project again to get updated .hxml files. It might also require restarting their editor/IDE too. Bad developer experience when we can detect this case automatically.
This value doesn't actually contain default values, but instead helps
verify that the correct fields are present and have the correct types.
It also doesn't need to show up in code completion.
There's no need to have three separate files containing a single static
variable each. Ideally, the `Data` types should include the variable,
which can be accomplished using abstracts.
`from Dynamic` is required in Haxe 3 and simplifies things in Haxe 4.
By setting `<meta build-number=".build" />`, you can force Lime not
to calculate a build number from git or svn, but instead use the
default option of getting it from the .build file.
Since setting this value would previously have produced useless
build numbers, it's unlikely that this affects any existing builds.
