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.
Related
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 9 years ago.
Improve this question
Do they use some algorithm such as the ones used in GDIFF program?
Do they ship the intermediate code to the user instead of iOS binary?
Why is it not possible do do a Delta update while updating iOS on Windows?
A delta update is defined as 'an update that only requires the user to download the code that has changed, not the whole program.'
iOS does, in fact, perform delta updates, and contradictory to Ralph's comment, we know exactly how it works.
Applications
For iOS applications, delta updates are used to minimize the download size of new versions, to save internet traffic. Usually, the things that give a program most of its size are the static images and other media. During a simple update such as a bug fix, usually these static images stay the same, and there is no reason to send them over the network again. The only thing that is sent is the actual Mach-O binary containing the code that is buggy, along with whatever files have been changed.
So, delta updates most likely run by checksumming. When you submit an app update, Apple checks the checksum of all files submitted using some algorithm (most likley SHA1 or MD5) to scan for changes. If the executable has changed, but a certain image or other file has not, the image isn't packed with the update, as users have already downloaded it, and don't need to download it again. While this method may not pertain exactly to the definition of a delta update, as it includes executables along with other types of files, it has very similar concepts.
OTA Updates
Apple uses delta updates in over-the-air updates for iOS as well. This is visible on any jailbroken iOS device. Updates are downloaded to /var/MobileSofwareUpdate/softwareupdate.xxxx, where xxxx presumbably is the build/release number. Each software update contains an image of the root filesystem, but not the entire version of iOS is included. Only the files that have changed from the version the user is currently on need to be replaced, and so only those files are included in the update package. The method for finding these changes is likley to be the same as with iOS apps, where checksumming finds changes in the files.
Algorithm
Basically, to answer your question, Apple's algorithm doesn't send the differences between two individual files (similar to what you see in a git commit), but sends the entire updated file. Their 'algorithm' just looks for any change at all between the last version, and doesn't look for the actual change itself. This is proven by the fact that in OTA update packages, the complete files are available, and not just a log of the changes.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 6 years ago.
Improve this question
The guidelines for iOS and the Mac App Store state that demo versions of apps are not allowed.
As far as I can tell, a lite version is (most of the time) just a demo with an IAP for the full version (so as to retain progress)
A "demo" app is traditionally a fully functional app that only runs for a limited time or doesn't let you save anything, or is crippled in some way to make it useless beyond being a demo.
A "lite" app is fully functional in its own right. If a user never upgrades to the full version, the lite app must still do something useful, even if it is fairly limited. One critical thing Apple will look at is no part of the UI must be disabled in a lite app. If a bit of functionality doesn't work in the lite version, then it must not be part of the UI at all.
In a lite app you may have a button or other UI element that lets the user upgrade. If the user reaches some limit imposed by the lite version, you may inform the user that they can upgrade if they wish. But never prompt the user out of the blue to upgrade.
A lite app does not require IAP. You can create a pair of apps (lite/paid) instead if you wish.
If you decide to use a single app with IAP to upgrade, don't call the app "Lite". Don't put "lite" in the icon. Because if you do, your customers will hate you once they upgrade the app and it still says "lite" anywhere.
Provided you're not putting any sort of time limit on your application, or removing functionality from the game - it'll pass as a lite version.
The "removing functionality" limitation is one of those ambiguous statements. You wouldn't get away with removing the "Save" function from a text editor, though you would get away with not having a different model of car in a racing game, or by having it as an IAP.
It's all rather subjective
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 7 years ago.
Improve this question
NB: This question has been extensively edited to make it more relevant, for completeness the original question maintained at the end.
What version(s) of iOS should my App support?
When building a new iOS app what a strategies should one use to determine what versions of the operating system to support? What practical considerations are there in supporting legacy OS version. Are there any reliable statistics to support the business case of dropping legacy support?
Original Question
If I build a new iOS application, should I support iOS versions prior to 5.0, or is that not necessary anymore? Is there any reliable and up to date data on iOS 5.0 adoption rates?
iOS Support Matrix v3.0.1
This version is updated and includes iOS 7.1 and new iPads.
Link: http://www.iossupportmatrix.com
According to this article: http://thenextweb.com/apple/2012/03/06/why-do-developers-prefer-ios-over-android-try-75-adoption-of-ios-5-while-ics-is-stuck-at-1/
the adoption rate of iOS5 has been very fast, at least when compared to Android ICS. You will always have users that are very slow to upgrade, however they seem to be the minority on iOS. If the numbers from the article are correct, you should be fine using iOS 5 for you app.
Look at statistics and judge for yourself if it is worth the effort.
For example:
http://www.14oranges.com/2012/03/ios-version-statistics-march-14th-2012/
http://pxldot.com/post/18754186750/ios-ebb-and-flow
from which I can read that < 11% are still using iOS 4.3
Or just search for e.g. "ios version stats", and try to find a web site that matches the target audience for your app.
This depends a lot on your app. But I would recommend supporting only iOS 5.0 and later because:
The new Xcode creates iOS 5.1 projects by default.
The new Xcode doesn't include iOS 4.3 simulator by default.
Apple has some iOS 5.0 only apps (like iTunes U).
So I guess, Apple is somehow pushing developers to support only the newer versions of the iOS.
Here is a good article that has some recent stats about iOS 5 adoption rates and good arguments on why to support only iOS 5 for new apps.
Here is another good article that discusses the question. Its conclusion is:
I think that both positions (support old, or support only new) are valid.
So it really depends on your special case. But personally, I'll currently support iOS 5.0 or later, unless there are solid reasons for a particular app.
I asked the same question some time ago and did not get any good answer with respect to a reliable up-to-date source of statistic data. In the end it comes down to your target market.
People who do not update their os recently are not likely to buy apps in high volumes. So even if these devices exist, the fraction of potential customers amongst their owners is most likely much smaller. That makes it hard to justify the extra effort in providing iOS 5.0+ functionaltiy and same functionality for smaller iOS.
On the other hand it may be suitable for you just to omit some functions for older iOS. That of course depends on the nature of the 5.0+ function that you want to use. Testing the curent os version and then deciding wether to call a function/method or not ist not that much of an effort. It needs to be tested though.
On the other hand there may be an interesting part of the user community that does consume apps but did not yet afford a brand new device. There is a number of devices around which cannot be migrated to iOS 5.x. And I personally would be interested in a) how many of these divices exist and b) how many of these are still in use.
If it is a new app then adressing older devices may not be justifyable. Unless of course you address some very special interest group and now for sure that the amount of oder devices is of a significant value.
Just some thoughts. Sorry that I did not have the statistics handy that you were looking for.
In my opinion it depends on which features of iOS 5.0 you need...
As example: in an application I need support for forward geocoding, available only in iOS 5.0 so I decided that the number of unsupported devices "cost" less then the effort to find a non apple library for forward geocoding ..
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"
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.