We are contemplating changing the version number in the next release of an iOS app from using the traditional Major.Minor.Patch version number scheme to instead use a date based scheme such as 2012.month.patch to better reflect to our users the currency of the app.
Apple's only version number guidance in iTunes Connect is as follows:
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).
My question - do they enforce this traditional scheme?
Is there any downside to using a date based scheme?
Are there any gotchas that might emerge from changing schemes on an app that has already been widely deployed?
Update: To explain a bit more of the justification for going to a date-based versioning scheme... The apps in question are updated primarily to reflect new datasets being added a few times a year. It is useful for a user to know that version 2012.2 has current data - version 2.6 does not convey that.
The apple scheme is generally enforced, seeing as your bundle is checked twice for the proper version number (once at validation, once at upload). And if not by apple, by general accepted tradition. Besides, why would you need to go beyond the recommended decimal places if you could just use the build number field for that?
Anyways, there is but one gotcha. Sometimes, iTunes Connect has trouble with double digit numbers in decimal places. What I mean, it that V1.1 and V1.10 sometimes show up as the same version (because the zero is ignored). But, V1.11 is fine.
As per your suggestion, it would seem slightly outlandish, but I would go ahead and try it. The app store does not prominently display version numbers (except during software updates, and even then, it's a subtitle), so I'll bet it could just slip right by. If you need to, just amend the name of the app to reflect the year.
In my experience they do not enforce it except that the first version is not less than 1.0 and you cannot release a lower numbered version.
The upside to the traditional scheme is it focuses on features which may be updated at your pace instead of the date which is always ticking away and changing much too fast. It is easy to tell where the release fits in relation to the other releases and shorter using dates.
Why would you want to? If you submit 2012.02.08 to the app store but it is not approved until the 15th of February then immediately there is a disparity. The app store lists the date the app was last updated, your users can go read that or your website.
If you regularly update it, and they download the updates, then I'm sure they'll get the message that your app is being updated frequently. I certainly notice when apps are updated. Other than actually seeing the version number while downloading it or within the app, changing the version number to dates doesn't help them know it is updated frequently.
After doing some research to submit my first build I am writing this.
First upload of the App can not be less than 1.0 ( no beta version ideas allowed)
Every subsequent upload should be incremented by one at the least
Maximum sub-version format allowed is X.X.X (where X can only be numbers)
No alphabets
Make sure only one version number is followed in all the version related parameters in Info.plist file before archiving to upload to the app store
I wanted to comment on this to say that using a year.month.day versioning scheme is fine.
I checked my phone to see who's doing something similar and here's what I found:
ideviceinstaller -l | grep 2020
com.bestbuy.buyphone, "202003261603", "Best Buy"
com.google.Docs, "1.2020.10202", "Docs"
com.huang.speedtest, "2020043002", "Oka Speed Test"
com.alibaba.iAliexpress, "8.7.1.2020031010", "AliExpress"
com.wayfair.WayfairApp, "20200326.72595", "Wayfair"
com.nguyenvh.holeio, "202003271450", "Hole.io"
com.adobe.Adobe-Reader, "20200326.133802", "Acrobat"
com.clearchannel.iheartradio, "2020022503", "iHeartRadio"
com.google.Sheets, "1.2020.12203", "Sheets"
com.google.Classroom, "2.2020.12205", "Classroom"
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
I know how to change the version number but I wish to know what conditions we change the version number? How it differs from build number?
Do we change version for every minor editing in the code, for example, fixed a small bug? or We change it for major revisions?
Version number for customers,build number for developer.
In my opinion,before every push to Git, let the build number +1.
I don't change the version number unless I decide to upload my app to iTunes connect.
And how to change the version number depends on how many features I added or improved since my last build version on iTunes. If I fixed a critical bug that may cause the app crash, let the third number of version +1 and upload it to iTunes as quick as possible.If I just fixed a small bug, I won't upload it and just let build version +1.Too many version updates may cause users annoyed and ignore it.
If there is a new feature added or lots of small bugs fixed, let the second number of version +1 and upload it.
If there are some new features added and some small bugs fixed, it's a brand-new version and I'll let the first version number +1.
The version number is some "encoding" you are going to use to represent where your application is in regards to maturity. Note that I'm trying not to use the word version here in the "definition", so I'm using maturity to represent the state of development your application is in. So a version like 1.0.0 (or 1.0) would in theory represent your first release. As you add features (i.e. application is getting more mature) your version number would change.
How you encode it is up to you, but you commonly see something like:
x.y.z
Where:
x - Major version
y - Minor version
z - Hotfix version
What constitutes major, minor, and hotfix are up to you.
For example, a major version change may be that you completely re-written part of the application to use a newer database. A minor change may be that you added AirPrint support. A hotfix change may be just some bug fixes, but no new added functionality. In general, major and minor will represent feature change(s) or some underlying architecture change(s) whereas hotfixes are more just bug fixes.
Some people don't like to use x.y.z and just use x.y. This is really a matter of preference.
The build version is used during App Store submission to represent your submission attempts.
As stated in the Apple documentation (https://developer.apple.com/library/ios/technotes/tn2420/_index.html)
The Version Number and the Build Number values work together to
uniquely identify the build and release for a particular App Store
submission. For each new version of your App, you will provide a new
unique Version Number and you may provide one or more builds (or
submissions) each with a different and unique Build Number together
with that same Version Number. All Version Numbers used in an App must
be unique. You cannot re-use version numbers. Also, as you create new
releases, new Version Numbers must be added in ascending sequential
order.
Build Numbers provide a way to name each of the submissions you
provide for a particular release. As described in the definitions
above, the collection of all of the builds that you provide for a
particular version of your App is called that version's 'release
train'. Build Numbers must be unique within each release train, but
they do not need to be unique across different release trains. That is
to say, you can use the same Build Numbers again in different release
trains if you want to. And, as you create and submit new builds for a
release, the Build Numbers you assign to them must be in ascending
sequential order.
It is normal to use the same Version Number many times over and over
again with different Build Numbers when uploading submissions for a
particular release of your app.
We have an iOS App which has millions of users in the US and needs to be Internationalized and made available in 11 different countries (many with a different language). Have worked out all technical details for exposing hiding features as applicable to a particular country, and also the different currencies etc. We have also implemented a way for the app to get location (if it is switched on, otherwise request user for it) and based on that, to self-configure for the country/language.
We'd like to do this off one Code Base. Suppose this is currently at version 1 say. Suppose we start with adding 5 countries - i.e. US, plus Korea, Japan, France, Canada and Mexico. Say this is now version 2.
We will then deploy this (a single app with one bundle id) to the App store and set availability for this version (2) to USA, Korea, Japan, France, Canada and Mexico app stores.
Suppose in the next month we add a new feature and that becomes Version 3. We test this thoroughly for USA, but our QA team does not have time to test this for the other 5 countries. So we want to release this V3 only for the USA and set availability for the new version for just the USA.
From what I understand, with the way app store settings work, since we have the same bundle id, we cannot restrict the new V3 to the US alone. It will automatically get published to the app stores in Korea, Japan, France, Canada and Mexico as well.
Is there a way around this?
(the other approach I know is to use the same code base, but build separate targets with separate bundle ids for each country, and I would rather have everything based of one target)
iTunes does not support enabling new version availability only for a particular region and while letting the old version be available in the rest of the regions. And they do this for a good reason too.
Suppose you support English and Japanese. What you are saying is, as you were able to test only the English localisations of the new version, you decide to launch it in all regions but Japan.
But what if a user who works in the US with English as the device language goes back home to Japan for a few days on a holiday. His son who uses this guy's phone to play some game changes the device language to Japanese. Now when your App is executed, will the end user be exposed to an untested version of your App?
Even if you don't localise according to the settings of the OS and have a separate option in the settings panel of your App, the user can always switch to a possibly untested version resulting in bad user experience.
So the only options which I think you have are either:-
1. Testing you App for all languages before release.
2. If the features in the App vary vastly according to the regions, group similar regions and create 3-4 different Apps (XYZApp-US, XYZApp-Europe etc). This option would make sense only if your features vary largely across different regions (lots features need to be hidden/modified according to language). This approach would not only help in timing your releases according to QA coverage but also help in segregating code as only relevant App would have the relevant feature code.
Option 1 though looks the easier one.
Currently I have a live iPhone app. I need to convert it to a paid one with territory limitations. That means I need to make my app paid for some territories and free for the rest.
Will apple allow this?
Can I upload 2 separate apps with same features, one is free and other is paid but their no feature changes. Only territory limitations.
First thing is you can not change price of the same Application for different territory. Apple will not allow to do so. In fact there is no such option to set different price for different territory.
So for the second you mentioned i say YES. To do so you to keep few things in mind.
Let say you have created 2 different applications with same features for 2 different countries with different price tags
Make sure the version which you uploaded for Country-A should be only visible to Country-A. And same for Country-B.
Keep Description & keywords localized language.
Make sure there is something different in both app versions. Otherwise Apple team will feel its a similar concept & they might reject the application.
Hope it will guide you.
I have an iOS app in the AppStore, built with Xcode a while ago, but I am thinking of rewriting it from scratch to iron out some bad decisions and this time use some cross-platform framework such as Appcelerator Titanium or Rhodes to add Android support also.
Is it possible for my current iOS users to seamlessly upgrade to the new version, retaining their userdata (of course a migrator is required in the new app). I think I have to retain some app identifier or other data in the new version.
Or should I create it as totally new app and let the users migrate their data (possibly using the Open in... scheme).
The downside of this is that current users must re-purchase the app, which might drive some of them away.
Is it possible for my current iOS users to seamlessly upgrade to the new version, retaining their userdata (of course a migrator is required in the new app). I think I have to retain some app identifier or other data in the new version.
In principle, it is possible. The fact that you are moving to a different development platform will not affect your ability to access data already stored by the user. In the end, it greatly depends on how you stored that data: if it is through NSUserDefaults, it will be pretty much transparent; if it is in XML/JSON files, you will need to add some XML/JSON parser to you new app (provided Appcelerator Titanium or Rhodes do not already provide one); if it is through sqlite, I know that, e.g., Titanium supports it; if it is through Core Data, maybe you will need to write some kind of converter for the existing data. But, in the end, it is definitely possible.
Or should I create it as totally new app and let the users migrate their data (possibly using the Open in... scheme). The downside of this is that current users must re-purchase the app, which might drive some of them away.
What you should take into account here is how much the new app will differ from the old one. If there is a risk of disappointing your customer base, maybe you can go for a separate version. It is clear that doing so will bother some users that will have paid for the old version. One scheme that has been applied in at least one case I know of is offering the app for free during an initial period. But whether this is sensible or not depends entirely on the prospects of your apps.
Maybe the best approach is striving for a largely improved new version, so that disappointed customers will be the least possible number, and keep the same bundle id for a seamless update.
I would suggest refactoring your current iOS codebase as opposed to rewriting it from scratch. Rewriting from scratch is almost always the wrong decision when you can refactor and clean up code as you go. It will always be harder than you expect, take longer than you expect, and often won't end up providing the benefit you expected it to. Refactoring is cheaper, faster, and safer.
In my opinion you would be doing your users a disservice by rewriting the app using cross-platform framework after they are used to a fully native app written in Objective-C. You would be doing yourself a disservice by throwing away code. Bad code can be fixed, no matter how ugly it is now.
I would suggest writing your Android app using Java and refactor your iOS app once the Android app is finished. You can provide the best experience for both platforms this way. The reason to add Android support first is because you already have a working iOS app in the store, so you're 1/2 way there already without touching a cross-platform framework. Writing the Android app should also allow you to flesh out ideas of how to refactor the iOS app.
As far as upgrading your current users, you need to keep the bundle ID the same in order for users to be able to seamlessly upgrade via the app store. Upgrading their data is also possible, but you need to provide more details on how that data is stored within your current app. If at all possible, the automatic upgrade is preferable to an Open In... scheme that requires the user to manually load their settings.
How do you handle a bug in a specific SDK version in a released application? Say for example I've reported and received notification that a bug is known in a specific version of an SDK. Say the SDK engineers fix the problem in the next release. Do I then need to check if the user is running the buggy release and display an error message that they can't use a specific feature with a bug in it because it will crash their hardware? Is there a more graceful way? Do you display an alert and tell them to upgrade to the latest SDK? Do you completely remove the feature? Advice would be appreciated.
This is phrased to be agnostic as possible, but I am asking for the purposes of iPhone application development at this time. General answers for other platforms would be nice as well.
It depends on the nature of the bug and on the nature of the platform. With the iPhone, for example, you cannot just tell the user to upgrade his or her phone. If your goal is to support iPhone version X.Y, then you will need to support the corresponding SDK; whereas, targeting browser X version Y.Z or Java version X.Y, it may sometimes be acceptable to tell users to upgrade.* Giving the impression that your application can do something only to give an error message saying that it cannot support it for that version of the platform does not make for a good user experience. If possible, try to work around the deficiency in the platform (by possibly reimplementing code that supposedly works in the SDK) and provide the feature to the user. If that isn't possible, then disable it when running on the deficient version of the platform, but be sure to remove all traces of that feature from the application (so that users don't click on a button only for it to tell them that the button is completely useless). I should add that conditionally enabling/disabling features is only sensible in the case where the feature is not essential to application; if a feature is a core aspect of the application, then you'd better find a workaround or raise the minimum requirements as it would not be appropriate to ship a deficient application to your users.
*An example where telling users to upgrade is not reasonable would be business applications, since business sys admins tend to be unusually lazy and users have no power to upgrade by themselves.