Add support for fetching App Store build number

[ApoorvKhatreja]

Right now, there's a fastlane action app_store_build_number that can be used to fetch the build number that is live in the App Store, and there's a get_app_store_version_number action in this plugin to fetch the version number. It seems unnecessary to have to call two different methods for what is essentially related information. I'd love if I could reduce this to one call in my Fastfile instead of two.

[xotahal]

Why would you get the build number from the app store? Isn't called build number because it is a reference to your build system? So you can track back where was actually built the release?

I just wrote a plugin which I believe supports this versioning plugin. The plugin can retrieve the next release version by analyzing GIT history so you don't have to think about the version at all.

I also wrote an article about the plugin and I mention there how we get the build number. But that's not a big deal - we just get it from CircleCI env variable (if it runs on CI) or from CircleCI API if it runs on a local machine (or outside of CI).

[ApoorvKhatreja]

@xotahal I have a lane in Fastlane that "announces a new release" to the rest of the team in a Slack channel when it gets approved and moves to the "Ready for Sale" status on the App Store. When this happens, I've usually moved on to working on a newer release, so the build number from my own system almost certainly won't match what is on the App Store. The build number is essential information for other teams (QA, Product, Marketing, Backend) to know and make decisions based on that.

[xotahal]

Why isn't the version essential for them? The version should provide information about changes in the product. Why is it build number? I think that build number should be autoincremented always when you run the build.

[ApoorvKhatreja]

@xotahal The version number and build number are both essential. Here's what a sample Slack message looks like.

The build number is essential for tying external things such as crash logs to a specific version of the code, and with auto-incrementing behaviors it is really hard to do that. In the Apple/mobile world, this is often the way people use build number (contrary to the web). Anyway, the need for build number is a matter of personal development setup, I don't really see any harm in the plugin exposing this for people interested in using it.

[xotahal]

Yeah sure, I am not saying that build number is not important. Here's what I would think about a version change:

v4.6.7/280 -> New version. Let's try it.
v4.6.8/290 -> Ok. Someone fix a bug in the version 4.6
v4.7.0/294 -> Boom. A new feature available. What's there?
v4.7.0/295 -> Someone run the build. But why, when there is nothing changed in the code?

I still don't understand those external things. If something crashes you'll see the version of the app, right? Not a build number. So if you see that the version 4.7.0 crashes, why would you need to know the build number?

Sorry, our conversation probably went to different direction, but I am just curious 😃🙈

[ApoorvKhatreja]

@xotahal Version number and build number combinations are not unique. Internally, when planning a new release, the version number is finalized first. Lets say for example we decide the next release will have the version number 5.0.0. Build number right now is 200. Work starts and can sometime take several months.

Over the course of several months, all internal development/debug builds, QA builds, external TestFlight alphas, betas, will all have the same version number (5.0.0), but will have different build numbers. It is not uncommon to see a crash on v5.0.0/202 when you are actively working on v5.0.0/325. It is important to have the ability to checkout the code for build number 202 and go back to it to debug the crash. Hope it makes things clearer?

[xotahal]

Well, understand now how you work with the version and why you need the build number. But don't understand why you work like that. You make version absolutelly useless. All tools work with version but you see v5.0.0 all 7 months long (while you working on the new version).

I can see the conversations:

Hey what version do you have on your phone?
John: "I have 5.0"
Jim: "I have 5.0"
Matt: "I have 5.0"

Jim, your version 5.0 crashes right? But your version 5.0 is ok Matt, right? Ok noticed!

That would be hell for me 😃 Anyway man, good luck 😉 And thank you for having time to explain me your problem 🙏

[ApoorvKhatreja]

@xotahal I wish I could take credit for this versioning system, but this is all Apple 😃 All iOS apps distributed via the App Store and TestFlight work this way.

• Every time you upload a build with a new version number, it must go through review before being distributed to external testers.
• If you are merely iterating/fixing issues in a release, Apple expects you to keep the same version number, and increase the build number.
• Only the first build for a version number goes through Apple's review process.
• Apple also does not accept builds with the same version number/build number combo more than once.
• Apple also does not accept builds with a build number lower than the previous build uploaded for that version number.

[xotahal]

That's probably not what would have apple introduced. It is just a way how to skip the apple review. But I think that the test flight review is not as long as a review for the app store. And you can still use internal testing (that's I think without the review) or services as HockeyApp, etc.