To create a development environment Staging environment, I want to distribute the same version with different environment variables. ( I am using the same bundle without dividing it. )
For Android, I could deploy the same version, but for iOS, the second deployment overwrites the app on first deployment.
https://firebase.google.com/docs/reference/app-distribution/rest/v1/UploadReleaseResult
Android always had "RELEASE_CREATED" results, but iOS had "RELEASE_CREATED" results, and iOS had "RELEASE_UPDATED" results.
I confirmed that it can be distributed in the same version. But I don't know when the existing app will be overwritten.
How can I distribute the same version on iOS?
I received an answer about the reason for creating a new release.
This is a great question and one we get regularly. There are some subtle differences between iOS and Android in what is considered a new release. For Android the logic is pretty simple but for iOS it's more complicated.
If your goal is to have a new release created each time for iOS the easiest way to do it is to make sure you're also changing the version or build number.
If you really want to hold onto the same version or build number, here's how we determine whether or not to create a new release for you:
Android: If the CRC32 checksums in the APK (or AAB) don't change, we don't create a new release. If any single bit (of the uncompressed binary) is different, then a new release is created - even if versions and build numbers are identical.
iOS: We only use the UUIDs for the executable(s) (a.k.a. CFBundleExecutable) inside the IPAs to determine something we call the "instance identifier". If two uploads have the same "instance identifier", version, and build number, then no new release is created and the newly uploaded binary replaces the existing binary
Related
Traditionally, I used to manage build and version numbers with Apple's agvtool and/or build scripts. However, when uploading an archive to App Store Connect, I noticed that there is now a new option:
Manage Version and Build Number
Archive's build number does not meet App Store Connect requirements. This will change the version and build number of all content in your app to 1.0 (2).
I was expecting this to automatically update my target's Version and Build numbers. Instead, I see that it doesn't update version numbers at all; and, although it updates the build number, it only does so in the archive, so my Xcode project shows a stale value.
How do I get this new feature to update my target's Version and Build numbers?
For reference, this is what a new project in Xcode 14 (SwiftUI Interface) looks like...
The Info.plist is no longer auto-created. Instead, the target's Info tab shows Bundle version string (short) (CFBundleShortVersionString) and Bundle version (CFBundleVersion) hard-coded to the values ${MARKETING_VERSION} and ${CURRENT_PROJECT_VERSION}, respectively:
I say "hard-coded" because no matter what I try (deleting them, updating them, or redefining a value like CFBundleShortVersionString in an Info.plist) the two settings are reset to look like the screenshot above, upon navigating back to the Info tab.
Also note that MARKETING_VERSION defaults to 1.0 (which is odd since the CFBundleShortVersionString documentation clearly states it must be 3 integers); while CURRENT_PROJECT_VERSION defaults to 1.
Attempting to change the bundle values in the General tab simply changes the backing property's value (e.g. MARKETING_VERSION for "Version").
Unless someone has a better answer, this is what I've been able to glean/guess so far...
The "Distribute apps in Xcode with cloud signing" WWDC 2021 video mentions it only increments build numbers in the archive:
New in Xcode 13, if Xcode detects I am distributing with a build number that has already been used on App Store Connect, or that is not incrementing, it will offer to increment the build number in the archive to one that is valid. [emphasis added]
This answer quotes the following from the Xcode release notes, which again suggests it only increments build numbers, and only updates the archive:
When uploading an app to App Store Connect, the distribution assistant in Xcode detects whether your app has a valid build number (CFBundleVersion). If your app has an invalid number (like one that was used previously, or precedes your current build number), the distribution assistant provides an option to automatically increment it to a valid number. In addition, the distribution assistant ensures that the build numbers of all embedded content in your app (such as app extensions, App Clips, or watchOS apps) are in sync with your app. Note that this doesn’t modify your source code or your archive; Xcode updates the build number in a staged copy of your app before packaging and uploading it to App Store Connect. (59826409) [emphasis added]
The "Manage Version and Build Number" feature is poorly named. While Build Numbers are incremented, Version Numbers are only updated in embedded frameworks, to keep them in sync with the main app. This is often undesirable, and probably why people are looking to permanently disable it.
In summary:
If you don't have embedded frameworks, then using this feature to increment build numbers is fine. Keep in mind that your target's build numbers won't be updated though.
Whenever you need to increment the version number, you need to manually increment it.
I have a problem with fastlane when I publish on TestFlight a new bundle that uses the usual version (ex: 1.0.2):
Error This bundle is invalid. the value for key
CFBundleShortVersionString (1.0.2) in the Info.plist file must contain
a higher version than that of the previously approved version [1.0.2]
It seems like I need to publish a new version, but I want to publish a new build instead, keeping the same version ... how is that possible?
Edit Response:
ok, I understand ... although unlike Android, I don't see the usefulness of blocking a new build if there is the same approved version ... but thank you all!
There is no way to upload new build of the previously approved version. So in this situation you should have to create new version in iTunes Connect and then and then you can able to upload new build in Testflight.
Few cases arise:
If you want to keep same version, remove current app from app store and publish your current version.
Now there is already app with same version so you cannot allow to do this, either increase the version or go with point 1, how ever be careful with this point. You need to analyse cases, because it is already on appstore.
You can upload the same version to TestFlight with increased build number. Eg: 1.0.2(1) and 1.0.2(2) Simply increase the build version from Project settings.
If I get an email regarding a rejected build e.g. Missing Purpose String in Info.plist File.
Then once I resolve the issue, is it mandatory to increment the build number? Or can I remove or invalidate the previous build so I can reuse the build number used for the rejected build?
Context:
I am building a react native app and would like to keep the build number (for iOS) and version code (for Android) be the same
To upload app on the app store the pair(version,buildNumber) should be unique.
so if your particular build is rejected by app store and you want to use the same version then you can increase the build number and upload the new build again.
These the important point to remember:
If current pair(version,build) is (2.2,1) then you can upload the build by updating the pair as (2.2,2)....
Version (CFBundleShortVersionString) must be in ascending sequential order.
Build number (CFBundleVersion) must be in ascending sequential order.
To read more about Version and build number in iOS
You should always consider to update your build number for new uploads, as only your version stays the same and this way you can track the correct build.
e.g. your app is at 1.0.0 and you upload build 1.
Now this build gets rejected for any reason and you need to fix the issue and upload another build.
This new build should have build number 2 otherwise you can't tell for sure it is the updated one.
In comparison, you do not have to update the version number at this point (at least if you are using semantic versioning) as you didn't release anything yet.
I have an iOS app that uses semantic versioning to tag shipped builds. I'm also using Apple's TestFlight to push internal builds to the team for testing/QA.
Pushing an internal build requires uploading a build to iTunes Connect. There's no distinction between a test build and release build to iTunes Connect, and iTunes Connect does not allow overwriting previously uploaded versions. So every time I want to push a new build for internal testing, I have to bump the version number (well, the patch (X.X.X) number).
This works fine, except to our users it looks like our version numbers jump around a lot in between updates. For instance, if this is our build history:
v1.0.0
v1.0.1 (bug was found in testing)
v1.0.2
v1.1.0 (bug was found in testing)
v1.1.1 (bug was found in testing)
v1.1.2
...then the users are only seeing the bold releases, and our release history looks odd:
v1.0.0
v1.0.2
v1.1.2
I thought a good way to avoid this is to use beta versions, like v1.1.0-beta for the test builds, but iTunes Connect rejects any version strings that aren't X.X.X.
Is there a way to continue using TestFlight for internal testing/QA and avoid the appearance of a gap-filled version history to users?
I use an internal 4th number in the build version, I believe iTunes still accepts this.
e.g. it might be version 1.0.0 but the build could be 1.0.0.87 indicating 87th internal build to test. You can choose to lop off the last number when displaying it in the App, but people do not usually care.
I have found this easy to understand and accepted in most places.
Build number as compared to version number is not given enough credit.
Use the build number.
Simply sequentially increase the build number.
We just use a simple integer 523, 524, etc.
Don't change the version number for test flight because...
If you change the actual version number, you will pointlessly trigger another automated test delay for that upload! Simply increase the build number.
Basically the versioning has below rules.For example if existing version is v1.0.0 then the next release will be:
v1.0.1 For bug fixes & minor changes.
v1.1.0 For major changes but the App is still compatible with
older versions. The user can still run the old version of app.
v2.0.0 For major changes but the App is NOT compatible with
older versions. The user cannot run the old version of app.
v1.0.0.1(beta) For internal testing
I have an iPad application that during beta testing may need a small code update here and there, but has a large number of graphics assets (300MB+).
Is there a way of creating a partial .ipa file that just has the changes instead of re-installing the whole application along with graphics files each time?
Short answer: NO!
Explanation:
Apple gives you no means to do so !!!
The .ipa is just a .zip file. So it seems on the first look, that you can do it.
But there are 2 problems
You need direct access to the iOs Devices. You normally don't have it for your Beta-Tester.
You will need to sign your code again. This you can only do on your local machine, because you need your private key for the task
No, what you are thinking of would be considered a "patch". Apple forces you to update the entire app bundle. Take the Tomtom app for example. The app is right around 1.5GB's so for small minor changes they would need to reupload the entire 1.5GB bundle.
For the App Store builds, things have changed since iOS6 and iOS 7.1:
Starting with iOS 6, the app store will automatically produce an update package for all new versions of apps submitted to the store. When generating the update package, the app store compares one or more prior versions of your app to the new version and creates an optimized package for each that contains only the content that has changed between versions of your app, excluding any content that did not change. This comparison looks at everything in the application bundle, including the application executable, nibs, localizations, image files, video files, audio files, text files, and files containing data in a custom format.
For devices running iOS 6.x and iOS 7.0, the update package will include any file, in its entirety, that has changed in the new version of the app. For example, if you have a 10 MB file in your app and only change 1 KB of content within that file in the new version of the app, the update package for that new version will contain the full 10 MB file.
For devices running iOS 7.1 and later, the update package may include only the differences between the old and new versions of a changed file instead of the full file. This may significantly reduce the size of the update package in the case where only a small part of a large file changes, but will increase the update's installation time on the device. For this reason, the two tips above are still important even for updates on iOS 7.1 and later. Minimizing changed content and localizing it to many smaller files instead of one larger monolithic file will reduce the download size in all cases and will speed up installation on devices running iOS 7.1 and later.
Source:
https://developer.apple.com/library/archive/qa/qa1779/_index.html