Relaxing the version check when app is ran from a simulator ?

[laurentperez]

Hello

This is more of a question than an issue. Our published apps have a version number of "3.3.xxx".

In our development pipelines, sometimes the next version number is not known -yet- at development time.

So our master and develop branches have a static magic number version of "1.99999999". We do not push them on testflight (we know the common issue number 3 about missing testflight api) but if we need to for beta testing, then of course we'll use a number newer than "3".

Now my "problem" is : when we developers run the app locally in a simulator, then Siren matches against the store version. Store version is newer, we use critical updates, so we can't bypass the forced update and our freshly simulated app can't be used.

How would you handle this use case ?

• locally modifying the package name as in "com.foo.this.is.a.developer.run" ?
• locally modifying the version string to one that's older than the store ; if so, do Apple HTTP APIs provide this version check ? (we'd rather not jump into the whole Fastlane thing, our publishing pipeline is a custom in-house one)
• relaxing the version check based on a "development" flag set at run or buld time within the xcode simulator ; if so how would you do it ?

thanks

[ArtSabintsev]

Option 1 or 3 work! I've done both in the past.

[ArtSabintsev]

For option 1 m, I should add, you'll need to use a separate QA target, which can be doubly useful when working with staging or non-prod APIs.

[laurentperez]

Could you elaborate on option 1 "separate QA target", did you mean something like a package name of "com.foo.myapp.THIS.IS.QA.FOR.API.XXX" ?

[ArtSabintsev]

Exactly - separate target in an Xcode workspace with a separate bundle ID (which is how one differentiates targets from what I recall)