As you publish single source applications written in Delphi on the Apple App Store and the Google Play Store, you easily bump into an issue: each store uses a different version numbering rule. This is my direct experience with the "My Minifigures" app I wrote with my son and published on both stores (see the links above).
On both stores, you have the concept of a version number (like 1.1) and a release number (like 14). In Delphi, you can enter those easily, doing manual increments or letting the system increase the release number at every build.
The way these version numbers are used, however, is totally different. On the Play Store, what matters is the internal, progressive release number. Each following release must have a higher release number (15, 16, 17 and so on -- but you can skip some). Rather simple. This implies that the version number is an additional information you can show to users, but nothing relevant for the store. Internally, the APK version is just a number:
This is the corresponding project options pane:
On the App Store the situation is exactly the opposite. While you can use build numbers as you wish, you need to use a "two elements" versions number, like 1.1, which have to be increased at each release in logical sequence (like 1.2, 1.3, 2.0, 2.1, etc). This is how the version is reported in iTunesConnect:
This is the specific project options pane:
So, how can you handle a common course with synchronous releases? basically by merging the two mechanisms and keeping them in parallel. As an example, if you have a release version 1.1.14 the next one could be 1.2.15. That is, version 15 for Android and version 1.2 on iOS. Actually if you see the Delphi project settings and the corresponding versions in the stores in the four images above, you can see the numbering schema I'm using for this app.