Project parameters

The parameters element contains general information about the project:

  • mainclassname: name of the application’s entry point.
  • applicationname: name that will be displayed in the mobile device menu
  • packagename: name of the application’s root package
  • vendor: name of the the application’s vendor
  • description: application’s description
  • version: version number (3 numbers from 0 to 99, separated by dots)
  • versionCode: version code number (positive integer)
  • srcpath: relative path to the source files directory
  • outputpath: relative path to the directory where binaries will be generated - if this doesn’t exist, it will be created by NeoMAD

All this information is required except the description parameter.

Binary name

The binaryname element defines how the output binaries will be named and stored.

   suboutputpath="$TARGET" />

List of attributes:

  • filename: Allows binary files (.apk, .xap, ipa, .zip) to be renamed. The value of attributes is parsed and replaced by automatized strings:
    • $MAINCLASSNAME: replaced by content of <applicationname> from section parameters (of the URS)
    • $TARGET: replaced by the final name of the target (ie. after renaming if specified)
    • $LANGUAGE: replaced by the name of language (first line of the csv file of strings) or by all language names appended if multilanguage is used, each separated by the multilanguageseparator attribute from <binaryname> (default is ‘_’).
    • $VERSION: replaced by version from <version> in section parameters
    • $MAJORVERSION, $SUBVERSION, $MINORVERSION: replaced by the parsing of the <version> in section parameters (with ‘.’ as separator). e.g. $MAJORVERSION.$SUBVERSION.$MINORVERSION
  • multilanguageseparator: Optional string that will be used in $LANGUAGE for filename attributes
  • suboutputpath: Optional path to describe the path where binary files will be generated. Suboutputpath takes its root from the <outputpath> value in section parameters and is parsed with constants from file. For more information about using constants in the URS file, refer to the chapter Use of constants in the URS file.



will generate binaries in the MyOperator/ANDROID if contains:

public static String OPERATOR="MyOperator";

and the target specified in the command line is ANDROID.

Version Code

The versionCode element is a positive integer used as an internal version number.
This number is used only to determine whether one version is more recent than another, higher numbers indicating more recent versions.
This is not the version number shown to users: that number is set by the version element.

It has a maximum value in each platform:

  • iOS: < 1 000 000 000 000 000 000
  • Android: < 2 100 000 001
  • Windows: < 65 536
  • Windows Phone: < 10 000

How to use it ?

In the urs file:

  • Use the <versionCode> tag in your urs file and write the version number manually

When building you app:

  • Declare a constant in the file.
  • Use ${VERSION_CODE} in the tag <versionCode> in your urs file.
  • Build your app with -d VERSION_CODE= and write your version number. The value of the attribute is parsed and replaced automatically.

You can use the build number of your continuous integration server as your version code.

What happens when versionCode is not set ? (Default behavior)

The versionCode is automatically generated by NeoMAD depending on the version attribute with different behaviors on each platform:

  • Android: if version = “1.2.3” then versionCode = “10203”
  • iOS: if version = “1.2.3” then versionCode = “0”
  • Windows: if version = “1.2.3” then versionCode = “0”
  • Windows Phone: if version = “1.2.3” then versionCode = “0”

The Android system uses the versionCode value to protect against downgrades by preventing users from installing an APK with a lower versionCode than the version currently installed on their device. Consequently NeoMAD have to generate a unique and higher integer each time to respect Android guidelines.


If you start using <versionCode> in your project you have to use it during all project lifetime else the version number will replace it in Android. This can generate conflict when publishing to the store, for the reasons explained before.

Switching to manual versionCode for a new application ?

For a new application, you would release the first version of your app with versionCode set to 1.
The versionCode have to be unique and atomic. It must be increased for each version (regardless to the version).


  • On Android versionCode value does not necessarily have a strong resemblance to the application release version that is visible to the user (version attribute). It is this integer that determined the uniqueness of the application.
  • On iOS, WindowsPhone and Windows this is the association of the version and the versionCode which determine the uniqueness of the application.

Switching to manual versionCode for an existing application ?

Considering the default behavior explained above, if your version is 1.2.3, you have to start with a versionCode upper than 10203 to be able to publish an update on stores.