I have, after many months of work, finally got my app updated for iOS4.
The first release was complied for iOS3.2 and has been in the AppStore for a while, I was very impressed to see it continued to work and be downloadable for iOS4 users all this time, even though my version failed to compile for iOS4.
However, now I've got the new version (complied for iOS4.2) waiting for review - I'm unsure what will happen to the existing app! If it is used overwritten, what will people with old versions of iOS see? Am I closing the door to anyone without iOS4.2+?
Many thanks
Ben.
p.s. apologies if this has been covered - I did look and failed to find :-)
When you specify the minimum OS required in the bundle, that filters what users will be notified of the upgrade. So users of your app that have yet to upgrade the underlying OS will not get pushed the update.
You can actually specify the target OS Level to an earlier version. The app will be allowed to install on that and any newer version. Generally, Apple is very good about forward-compatibility.
As Peter said, you probably don't want to compile it to only run on 4.2. If you added features that use newer versions of iOS, you can actually do a check prior to calling the method (I've done this with gesture recognizers) to ensure that the running OS version is capable. If you don't validate the OS, the app will simply crash on users with too-old operating systems, which could cause Apple to reject it.
Also, 4.3 is almost out, so you might as well wait a week :)
If your app only supports 4.2+, then only users with a device with 4.2+ iOS will be able to install and use your app. The version currently on the store will be overwritten. In short, yes you are "closing the door" to anyone with a lower version iOS.
Related
There is a situation that I am faced with which seems like it has no solution. Here it is:
I have an app on App Store. I didn't write any piece of code for this app keeping the upgrade scenario in mind. For all I could imagine, I never that I would be giving out more versions apart from the one I already have on app store. Now, the situation is that I am required to give an upgrade of my app and with in the new code, I am to identify if it is a new install of the latest version or if it is an upgrade from the older version. I don't know how to approach this as I have not coded my first version appropriately for upgrades? Anybody willing to enlighten me.
See previous thread here iPhone: How do I detect when an app is launched for the first time? I use this in just your scenario and it's fine to introduce it with the update - it copes with the previous version doing none of this.
Dear Scholars.
I have created a simple application using the latest SDK (4.2.1), Which runs smoothly and error free on all devices with iOS 4.x.x.
Lately I am getting some comments from users with older iOS version complaining the application is crashing on start, on Apple's crash log I see nothing at all.
Pushing my investigation forward, the only suspect I have at the moment is the use of EventKit class, which if memory serves, where introduced only after iOS4.
I am using it very lightly in one of my classes, and it works perfectly on iOS4.2.1
#import <EventKit/EventKit.h>
//some time later
[self setADateInCal: [MyTimeArray objectAtIndex:0] :formatterDate];
Thus my Questions:
Can this be the issue that crashes my application on iOS < 4 ?
How can I prevent it without dropping the feature for people with iOS4
In general, How can I test this? I have the latest official iOS on my device and SDK, the simulator is limited to how back it can go in regrading to iOS version... any magical way to do so?
1.) Yes. If it wasn't in the API in <4.0 than anyone not running >4.0 will crash.
2.) Test to see if the class is available using NSClassFromString (Google for examples) and respondsToSelector in correspondence to see if the method you want is available to use in the OS version the client is running. You will also probably need to weak link the EventKit framework (again Google for how to do this).
3.) The only real way to test this is to keep a device at the OS you want to test. Personally, I have an old iPhone that I never update running 3.1.3 for things just like this. Alternatively, you can keep old installs of xcode+iOSSDK on different partitions or something and use their simulator. (for future updates i guess since you obviously haven't done this for <4.0). But no, there is no magical way to do this. sorry.
edit for clarity on Number 2: Basically you will check to see if the class/method you want is available on the OS version you are currently running, if it is you can use it, if not you will have to find a work around (omit completely or do it another way that is compliant with older versions).
Yes it could be causing the crash. Issues with missing libraries do not report anything in the apple crash log.
To prevent it from happening you need to do two things,
Weak link the event kit library in xcode.
Check for its existence in your code with something like
,
if(!NSClassFromString(#"EKEventKit")){
//do stuff with event kit
}
The only way to test on the actual iOS version is to get hold of a physical device running ios < 4.
When releasing multiple versions of an iphone-app, there are problems:
you are running very old apps (still need to support them through server-api)
you have to live with bugs of a certain app, once released blocker-bugs are not fixable
Is there a way to mark an iphone-app as unsupported or enforce an online-update, i.e. when it starts up it will show an upgrade button?
So far I always read that you cannot enforce an upgrade of an iphone-app. Is this correct, can somebody give me official reference/link for that? I just cannot believe that once you released an iphone-app this is for eternity? An "unsupported" marker would be a very helpful app-store feature...
You can not enforce app upgrade, but you can add a mecanism in your app to display a message to say that the version is not compatible with server-api. Of course it should be provide on the first app version...
I've got an app that works in ios3 (3.0 - 3.1.3), but they've deprecated some of the code in ios4. The problem is, if I update to the ios4 code (3.2 -) it will no longer work in the older phones.
If I release an update that is for ios4, what happens to people who have the ios3 version? Does it say "sorry you can't have it"? Does it let them overwrite it anyway and then hit them with a "upgrade to 4.0 now" box? I'm worried that they'll be offered the update, download it, overwrite the old one, and now it won't work on their old phone.*
Thanks for the help.
(*I know the upgrade to ios4 is free and all that, but I'm pretty sure my demographic is more likely to be the "I like my phone the way it is thank you very much" type, annoyed to be forced into a new operating system just for my little app.)
I think it's your job to handle os 3 and os 4 in the same app (if you want, it's no an obligation).
You can check the OS and then do things depending on it.
When you need to use a framework which only exists in OS 4, you can set a weak dependency (Target "Project Name" Info => General Tab).
By the way, you can specify your app is only for > iOS 4.0 and then user will have to update his OS before updating your app. But I never had this kind of problem. I think it's handled in the AppStore when user want to install or update an application.
I want to update my app to make use of the multitasking functionality and local notifications available in OS4. My question is, if I update my app and make it only available for OS4 and above does this mean that if someone is running OS3 on their phone they won't get the update? or they will get a warning that they need to update their OS? What I don't want to happen is for them to update their app to find it no longer works? If the final situation is what will happen, how do I write the code to find out what OS is being used?
Thanks
If they try to update on the device, then they won't even see an update that doesn't run under their OS version.
However if a previous customer updates their apps using iTunes on their Mac or PC, then iTunes may show them any new update. If they download that, iTunes will blow away its copy that is compatible with their current device/OS combination. The new copy shouldn't overwrite the working one on their device. But if the user ever needs to do a restore, or deletes the app and wants to reinstall it, they're probably out of luck unless they have really good backups and know how to use them.
If you update your app to be 4.0 only, and also mark your app as 4.0-only in the Store, then people will not even see your update.
You can have the best of both worlds by designing the app to use 4.0-specific features only on 4.0 devices. Weakly link 4.0-only frameworks, and in your code use [object respondsToSelector:#selector(thisOnlyWorksInOS4:)] to test for 4.0 features before using them (or, in the case of multitasking, use the multitaskingSupported property of UIDevice, since not all 4.0 devices support multitasking). Alternatively, UIDevice also provides a systemVersion property.
This blog post explains these techniques fairly well, including weak-linking frameworks: http://blog.federicomestrone.com/2010/07/18/base-sdk-deployment-target-weak-linking-and-import/