I uploaded the app in App Store, and now it in "Pending Developer Release" status. But I want give it to testers before release. I have no troubles with internal testers, I gave them access to application without problems. But I have trouble with external testers with the same binary. There is an error:
CFBundleShortVersionString in info.plist must be higher than 1.0
What should I do, if I don't want to reload binary, because I can lose the "Pending Developer Release" status?
When you release a new version using Apple's distribution system (i.e. App Store or TestFlight) the version number needs to be higher than the previous release.
If the app is still in testing, it shouldn't have even reached 1.0 yet. Start with 0.1 and increment up to 0.999 as development milestones are reached. Once it's tested and ready for release, make it 1.0. This is my thinking on the issue anyway; the actual value is not important, however some users may query why a newly-released app has a version number of 1.452, for example.
Note that the number is not a floating point; instead it's major.minor and major does not increment when minor goes above 9; instead the version becomes 1.10 until you rework it sufficiently that the major becomes 2 and the minor resets to 0, and so on.
So to answer your question, change CFBundleShortVersionString to 1.1.
As for CFBundleVersion, that should be an integer that increments from 1 whenever a build is performed and source files have changed (again, in my opinion), which can be managed with a script as posted in this answer.
Related
As iTunesConnect has introduced the new feature to expire the build which eventually remove the build from iTunesConnect. After doing that i wanted to upload the new build with same App version and Build version but getting below error
ERROR ITMS-4238: "Redundant Binary Upload. There already exists a binary upload with build version '1.2.8' for train '1.2.0'" at SoftwareAssets/PreReleaseSoftwareAsset
Is it possible with new iTunesConnect?
This is not possible. Suppose you already have version number 1.0 in App Store then new version must be greater than 1.0.
Refer following link for more details: https://developer.apple.com/library/content/technotes/tn2420/_index.html
Version number and build number checklist
Here are some things you can check when submitting a new build to the App Store. Making sure you have your version number and build number set properly will help you by avoiding having your app automatically rejected for having them improperly configured.
For each new version of your app, you need to invent a new version number. This number should be a greater value than the last Version Number that you used. Though you may provide many builds for any particular release of your App, you only need to use one new Version Number for each new release of your App.
You cannot re-use version numbers.
You cannot re-use version numbers.
For every new build you submit, you will need to invent a new build number whose value is greater than the last build number you used (for that same version). For iOS apps, you may re-use build numbers when submitting different versions. For macOS apps, you must chose a new build number for every submission that is unique and has never been used before in any submission you have provided to the App Store (including build numbers used in previous versions of your app).
For iOS apps you can re-use build numbers in different release trains, but you cannot re-use build numbers within the same release train. For macOS apps, you cannot re-use build numbers in any release train.
I have client with an app in the app store that was at version 4.05 and they accidentally submitted a new build as version 5.06 when they meant to submit it as 4.06. They aren't ready yet for a full version number increase. Long story.
Is it possible to submit the next version as 4.06 to get it back on track? Or is not allowed to upload a lower version to iTunes Connect?
Yes. The version numbers only need be distinct.
From the Developer Guide:
A Version Number The unique version
number of the app. Keep the following
in mind:
Use typical software versioning conventions (for example, “1.0 or
1.0.1 or
1.1”).
Do not include words such as “build” , “version” or “beta” in your version
number. This will appear next to your
application icon on the app product
page.
Perviously the client uploaded same app on iTunes connect and rejected for some reason.
After some modifications I need to upload the binary again.
The previous binary details are,
Now, here are the current info.plist details,
I am using Xcode 4.0
When I tried to validate product from Xcode I got this error,
I tried different different CFBundleVersion in the Info.plist. but still error occurs.
I cleaned project, deleted build, also re-installed Xcode and retried but no use.
Please help me.
So it looks like this needs to be an ever-increasing version number and can't reset when the marketing version number changes. It seems like you could use your VCS revision number here; in my app I display the marketing version number and if the user "clicks" on it it adds the build number (CFBundleVersion) on the end. The primary purpose of this is to keep the version number clean and simple, but also allow QA and beta testers to determine the exact version of the product they're testing. The Subversion revision number would certainly help us track down the build being used, but in this case that'll be a strange version number jump for me (6 -> ~74000).
basically i had to change 1.1f to 1.11 in both itunes connect and in xcode. the f had to be removed from the version number. no alphas allowed !
Reference: Can't Update App with New Version Number
I am planning to release version 1.0 of my app now. I plan to release 1.1 in the next 2-3 months.
What are the things I need to take care of now for the initial release?
Also what should I select as SKU Number and Bundle ID in iTunes Connect for submitting 1.0?
Version numbers in software are completely arbitrary. Usually, you have a major version and a minor version. Consider the version "1.2". It's version one of the software and there have been two minor updates since the original release. (Note that this is subjective because it could technically be version 3 - where each release is a version change.)
You should not release a second version just for the sake of pushing an update. Generally, an update contains a bug fix or a feature enhancement. (For example, I made a game called "Nippon". I'm updating it to have a new user interface on the iPad as well as fixing bugs. In contrast to this, consider another update I made to another app, which I just changed the icon. See the difference?)
As far as when to release your app, that is totally up to you. You don't need all of the features right away, but make sure that those that you do put out are completely implemented. Don't rush to put out something with features that are incomplete. Users will hate you for it. Instead, choose a core group of features that are your app. Make those work really well and then work on other things for the next version.
Here's a related excerpt from the Apple Developer Resources "submission tips" section (requires login):
The two most common reasons for application rejection are issues with core functionality and crashing. Core functionality encompasses the belief that customers rightfully expect all the features described in the marketing text and release notes to work as described, and likewise that all the buttons and menu items within the application will be fully functional (i.e., no grayed out buttons or notifications that a feature will be implemented later). Before you submit your app for approval, make sure that every aspect of your application is fully functional and that the marketing text and release notes correspond to the end user experience.
Also, make sure you thoroughly test your application on iPhone and iPod touch in addition to the iPhone Simulator. A large percentage of applications are rejected due to various types of crashes, including crashes on launch, which would have been found and dealt with if they'd been tested on an actual device. Don't skip that step in the development process.
Make sure that your app works and works as advertised. That should be your goal for version 1.
As far as SKU and bundle ID:
SKU is supposed to be a four letter code, representing your app. In the old iTunes connect, you would see your SKU represent your downloads. I just checked and it seems that they print out the entire name of your app. However, just to illustrate, a valid SKU for Nippon would be NPPN. (I actually use that one.)
Your Bundle ID should be a reversed domain name. For example, com.mosheberman.myapp could be a bundle ID for my app. You don't have to actually own the domain name, by the way. For Nippon, I used com.yetanotheriphoneapp.nippon.
Hope this helps.
Some time ago we released an app to the AppStore on a client's account. The client preferred a simple version number scheme, so the apps first version number was 1.0. Since it's release, however, there seems to be an unexpected need for minor changes to the content of the app on a regular basis, so a more precise versioning scheme, reflecting content revisions, would be more feasible now.
Is it possible to "refine" the numbering scheme in the course of an update to the app? Instead of upgrading from 1.0 to 1.1, I'd like to go to 1.0.1 now.
Would it be sufficient to just change the version number according to the new needs or will the AppStore accept only new releases if they follow the original scheme?
Thanks!!
You definitely can, especially if you haven't submitted the 1.1 version yet. 1.0.1 > 1.0 so it's ok.
Taken from "Developer Guide" (https://itunesconnect.apple.com/docs/iTunesConnect_DeveloperGuide.pdf)
Version Number:
The version number of the app you are adding. Numbering
should follow typical software versioning conventions (for
example, 1.0 or 1.0.1 or 1.1).