We're in a pre-release stages of our mobile game, and it's been mostly tested on android devices. As we get closer, we started to run tests on iOS devices and noticed that the same versioning that works great on Android is not working for iOS.
Our version is automatically increased and looks like this: Major.Minor.Commit
We've noticed, that in TestFlight a version 1.0.9 would be higher in the hierarchy than 1.0.10.
In Apple Documentation it is pointed that a version - is a string that consists of up to 3 integers separated by a dot. If it is an integer, how come 9 is higher than 10? I assume that AppStore treat this number as a decimal, but this is not what the documentation suggesting.
The solution we found so far is to use only Major and Minor versions in the version string, and assign an incremented build number, but it's not ideal, as we would like to have similar version strings in both Android and iOS versions of the game.
So far I haven't found a proper explanation to this, and it could be that this is only a display bug in the developer dashboard.
Related
EDIT: My answer is provided below
I was developing an educational app which I was targeting specifically for iPad-1 devices, because I think schools can take advantage on these 'old' devices.
However I'm afraid that nowadays it is not possible to upload apps which support iPad-1 (which is stuck with iOS 5.1).
What happens when I try using Xcode 6.4 to submit, is one of the two:
If I include the standard architectures (both 32 and 64 bits), I'm getting an error saying that apps with 64-bits can't set their target to iOS 5.1.
If I remove the 64-bits support, I'm getting an error saying that Apple do not allow apps without 64-bits binary.
I was trying to search the internet but didn't find much info. Any idea please?
EDIT
I was trying to use the standalone app loader but it didn't change anything because the validate is done by the remote server. For the second option above, I was getting this:
ERROR ITMS-90086: "Missing 64-bit support. Beginning on February 1,
2015 new iOS apps submitted to the App Store must include 64-bit
support and be built with the iOS 8 SDK. Beginning June 1, 2015 app
updates will also need to follow the same requirements. To enable
64-bit in your project, we recommend using the default Xcode build
setting of “Standard architectures” to build a single binary with both
32-bit and 64-bit code."
ANSWER
I got an answer at the developer forums of Apple, so copying here:
Although not in the drop-down box of the deployment targets of Xcode, we need to set the deployment target to be 5.1.1 in order to allow installation on iPad-1 devices.
This is because 5.1.1 is compatible with iPad-1, and is capable of reading dual-architecture binaries.
One thing to consider is that it will not be possible to use TestFlight for testing on these devices, because TestFlight is only compatible with iOS 8 and up. But testing can be taken in other means, like direct-install from Xcode.
We have a couple test iPhones in the office. The one I use for development hasn't been updated in the last couple months, the one used by our QA team has been recently updated, however. I'm also still using Xcode version 6.3, and my compilations run fine in the simulator or the dev iPhone.
However, now that the QA iPhone has been updated, my Xcode refuses to build for it, claiming that the verison of iOS on it (8.4) is not supported. This is a common occurrence and I've just been dealing with it. While I'm waiting for my Xcode to finish updating (which is taking its sweet time), I'm realizing that this limitation is arbitrary (or at least it seems that way). I've already compiled my app for the QA phone earlier this month, that version obviously wasn't built for 8.4, yet it runs fine on it. Likewise, other apps on the phone don't need to be redownloaded after each update, nor does the app store require recompilation for each iOS update. Clearly the newer version of iOS can support the app built by older version of Xcode, then why does Xcode refuse to deploy to a device that has been updated? Is there a checkbox I'm missing somewhere in build settings that says "deploy even if you don't recognize the iOS version"?
I can build and debug on an iOS 9 iPhone with Xcode 6.4
Also you need to understand (but I'm not an expert either) that when there's an OS update, to really support debugging Xcode needs to be familiar with that OS' debugging symbols (which may change at every software update). This is why, when you plug in an older version of iOS (or any version it is encountering for the first time) Xcode will take a few seconds to load and process the device's symbols. That's my understanding of it.
This question already has answers here:
Which iOS app version/build number(s) MUST be incremented upon App Store release?
(10 answers)
Closed 8 years ago.
I have an iOS app with version number 2.0.0 and build number 2.0.0. I found there is a bug in version 2.0.0 and I want to patch this and do a quick update. I do not want to increment the version number if possible because it is a small fix.
I have been working on Android for a while. Android allows keeping the versionName (a.k.a. version number on iOS) and just incrementing the versionCode (similar to build number on iOS)
Is it possible to release an iOS build with the same version number?
Would just incrementing the build number in the info.plist help me achieve what I wanted?
If it is a small fix, then your version number can be something like 2.0.1 There is not a way which you could release the same version number and for many good reasons. Lets say you have 2.0.0 in the store and it has a small bug, so you release 2.0.0 again to patch it. About a week later, you are getting reports of the app crashing in version 2.0.0. Which code base do you look at?
If it is a very small bug and not that important to fix, maybe it makes more sense to bundle it with a larger update later on instead of releasing a new update.
I have a legacy application distributed Ad-Hoc that runs on older iPod Touches (running iOS 3.1.3) with a custom connection to rather expensive 3rd party hardware. Unfortunately my annual renewal of the provisioning profile (which also involved rebuilding with the most recent version of XCode that will compile armv6 (4.5) and the corresponding SDK) seems to have broken the app.
I know that you can set the target platform earlier (and I've done that). But my problem seems to be specifically related to the SDK. The hardware these devices interface with is several hundred miles from me so testing is very difficult.
My first set of problems were related to deprecation of the TouchID APIs, but I've worked around that problem. Unforatunately, I still have crashes and they are proving very elusive to debug.
The simplest solution for me would be to just rebuild against the older SDK (4.x). Is this possible? To make matters worse my Mac is running 10.8.4--so there's a limit to how far back I can get XCode working on it.
I was able to get this to work by renaming my current version of XCode to something else, downloading and installing XCode 4.4 something from the developer site. Then I downloaded an earlier version yet and used the techniques described in this post:
Adding Older iOS SDKs to Xcode 4.1 in Lion
To extract the older SDKs. I was then able to copy these SDKs into XCode 4.4 (as described in the post). Now I was able to build using older versions of the SDK.
I have an app that I build using XCode 3.2.6, Base SDK 4.3, Deployment target iOS 4.0.
I decided that I should test it with the latest iOS5 beta, to make sure that my app doesn't break, and submit any bug reports to Apple if I find something.
What I found is that if I build the app using XCode 4.2, Base SDK 5.0, Deployment target iOS 4.0, the size of the text in my UILabels and UITextViews renders smaller (by maybe 3 points or so). But that's not really what's important.
I have two test devices, one has iOS 4.3 installed on it and the other has iOS5b3 installed on it. What confuses me is that the shrunken text behavior occurs on BOTH devices.
If I build the app (like I normally do) using XCode 3.2.6, Base SDK 4.3, Deployment target iOS 4.0 the shrunken text behavior goes away on BOTH devices.
My understanding was that the UIKit libraries were linked at runtime on the actual device, and as long as I use APIs that are supported by both Base SDK versions it shouldn't matter which Base SDK I choose.
It wouldn't be so surprising to me if I observed different behaviors on devices running different versions of the OS. But as far as my understanding goes, choosing a different Base SDK shouldn't change any behaviors on a given OS as long as (of course) the Deployment Target setting is low enough to include the OS version and I'm using APIs that are supported.
So what gives? I'm obviously missing something.
I really appreciate you taking the time to help me understand this.
Thanks!