I`m developing an app that uses MKMapView, and I need it to run in iOS4, iOS5 and iOS6.
My question is, if I develop using the new iOS MapKit features, can someone using iOS4 see things like routing from sourceAddress to destinationAddress?
Yes and no.
If your write a maps app using iOS 6 features, it won't run on older versions of iOS, unless you check for the existence of those methods.
More generally speaking, the MapKit framework is smart enough to show the iOS 6 maps where appropriate, and to use Google Maps everywhere else. However, you need to avoid using the routing features where it's not supported. So, to abswer your question, users on iOS 4 and 5 will not see the new routing features.
So, if your app doesn't use new maps features, you're totally fine. If it does, you'll need to take steps, such as weak linking and method checking to ensure that your app doesn't try to run new API on older system versions. Running new code on iOS versions that don't support said code will crash, of course.
Please refer the answer given in this post.
Should I be worried about rumors that Apple will stop using Google Maps in iOS6?
It has descriptive answer of your question.
In the documentation, it states which OS versions specific functions work on. I don't have the documentation with me (on a PC currently) but if those methods were added in iOS6 they won't be available in earlier versions. What you can do to work around that is use #ifdef to check the OS version of the user and disable features as necessary.
Please note, that iOS6 is under NDA so questions about specific methods introduced in it should be kept in the Apple Developer Forums.
Edit: #ifdef is not the way to stop it from running. You just have to check for the version of the OS in your app and do something like:
if (os >= 6) sourceAddress stuff
else if ((os >= 5) && (os < 6) ignore sourceAddress stuff
Related
If a user was using my app on iOS 8 and my latest release supports iOS 9 only. The user update OS to iOS9.
Does he get al alert to update app when he opens my app?
Can the user still use my app without updating it?
What happens for the deprecated code? Will the app crash while trying to access such APIs?
No alerts. If user will not update iOS your application will not be updated. Your project should be updated that now it requires iOS 9, see deployment target in your project settings. If you don't change this setting than it will get updated and you can have a crash if new API is used on old iOS.
If you didn't change server side in such way that it breaks compatibility than old version should still work.
This should be investigated by you. It depends on many factors. If you have setup project "deployment target" properly than update will not be performed on older iOS versions. This may be tricky if your application should support older versions of iOS. Not updated application will continue to work on new iOS even if deprecated API is used. Apple will simply reject updates witch are using deprecated API but still maintains that API. Once I had a problem since UIAlertView was deprecated and old application had new bug where UIAlertView was not respecting application orientation. I had to do a tricky code which detected if UIAlertController (I prefer this approach instead detecting iOS version) is available than use it and if not than fallback to UIAlertView was used.
During application update the biggest problem you can create is setting compatibility or database comp compatibility. So you should be careful with that.
I have an application that was developed to support older versions of iOS as well, but I recently started on working on a Today extension in iOS8. Now my question is, what will happen to my app in the store? Will it ignore it and make it iOS8 exclusive? If not, I wonder what happens when a user runs it under iOS 7 for instance?
I have found absolutely no answer to this, has anyone been luckier than me on his research?
Thanks in advance,
Laszlo
Your extension functionality will not be available for lower versions(iOS7 and lower), However the app still run without any problem in lower versions.It has been explained in WWDC-14 session 217 Creating Extensions for iOS and OS X, Part 2.
I have an application whose minimum version has been set to iOS 7.0. This application also uses NSUserDefaults dictionary. This application is using UIAlertView and UIActionSheet extensively (not sure how much Apple non-disclosure covers). Now, with iOS 8.0, these two views have been deprecated and have been replaced by controller UIAlertController. Now, there are two ways that I can see which can help me in updating the app for iOS 8.
Raise the minimum version to iOS 8.0 for the update. This way, the users running iOS 7.0 won't be able to see the update. However, it leads to the following situation :-
However, there is one problematic case, and that comes from upgrades
performed from within iTunes or on a device with a higher version
number that is then synced to iTunes. When the user syncs the older
device with iTunes, iTunes will actually delete the application from
the device because it cannot run the new version currently within
iTunes. I had a couple of users with original iPod touches report this
when I upgraded one of my applications to only support 4.0.
The above comment is present under the accepted answer at the following url :-
Raising minimum iOS Deployment Target Version for App Update
Since, the application is using NSUserDefaults dictionary, the relevant entries in the dictionary would get erased when the application is deleted.
The other option is for me to detect in the code which version is being used and code accordingly using if-else statements. This would enable me to keep the iOS 7.0 as the minimum version and might also help me in deploying the update for iOS 8.0. However, this seems like a lot of work which can potentially lead to bugs.
So, I was wondering which option is better between the above 2 ways ? (This application would only be using Objective-C for now due to some constraints).
The best thing to do from the user's perspective is probably to code using UIAlertView and UIActionSheet even though they're deprecated. Keep your iOS 7 target the same as it's been. Xcode shouldn't give you warnings since you're using the older version as your base target. You won't need to change anything about your code and it should still work well enough.
Once you're ready to switch (perhaps when iOS 9 comes out), I would switch your base target to iOS 8 and update your code to use UIAlertController everywhere. To me, it doesn't make sense to spend time trying to support two different versions if it's just an API deprecation that still allows your code to work how you've written it for years. Saves resources and energy to just update it later.
But it's really up to you and how much you want to support iOS 7. I think it doesn't make sense to drop support until the next version comes out. I always try to support the current and last versions so there are no annoyed customers, but it depends on your own needs.
If you have analytics integrated, check out percentage of iOS 8 adoption once it's been released for the public. If not, it's a great opportunity to add it to find out how up to date your customers are!
This question already has answers here:
UIDevice uniqueIdentifier deprecated - What to do now?
(32 answers)
Closed 9 years ago.
After 1st May Apple is going to reject new apps and updates which are accessing to uniqueIdentifier. They introduced couple new methods in iOS 6.x which is good, but... what if I need my application run on older versions of SDK? So, my code would look like:
if ([UIDevice instancesRespondToSelector:#(identifierForVendor)]) {
deviceId = [UIDevice currentDevice] identifierForVendor];
} else {
// WHAT SHOULD BE HERE?
}
What should developers use if it is old SDK? Moreover, even if let's say I find something to use the value would be different once user upgrades his OS version, which is obviously bad - we would have two different ids for the same device.
What should developers use if it is old SDK?
Apple won't accept apps built with an SDK that's more than a few versions old, so you may not have the option of using the SDK that you're thinking of. You can still set the minimum supported iOS version to older versions, but you probably won't be able to use -uniqueIdentifier even when running on pre-6.0 devices.
-[UIDevice uniqueIdentifier] has been deprecated since iOS 5.0, so you've had nearly 2 years to deal with the fact that it's going away. It's too late at this point to try to sneak in another update that uses the UDID; depending on what you do with the UDID you may have a problem. There are several good solutions for replacing the UDID that are within the spirit of the new rules, but again, the window for switching to them seamlessly is more or less closed.
even if let's say I find something to use the value would be different
once user upgrades his OS version, which is obviously bad - we would
have two different ids for the same device.
Consider the reason that the UDID was deprecated: users don't want you to be able to track their devices without their permission, and Apple surely doesn't want to be seen as enabling you to do it. So, if you do find a solution that works for you and which doesn't use the UDID, you might still risk rejection if your scheme doesn't allow the user to opt out of whatever tracking you're doing.
I want to create a map based app but apple will no longer user google maps in ios 6.I dont want to upgrade to the developer beta yet as I am waiting for the final release. But I also want to get started as soon as possible. If I start my project now will it change or the code will differ when the ios 6 is available? In other words if I make a successful built in ios 5 will it be unsuccessful when i upgrade to ios6? Will I have to rewrite the entire thing or everything will be compatible resulting to an also successful built? thank you in advance..
Your code will work fine.
Almost nothing changes with iOS 6 and MKMapKit in terms of code.
The only thing which works different in iOS 6 is the way you call the native Map App from inside you app. (if you are using this functionality)
You don't need to wait to use beta versions of XCode, you place them in different locations on your hard drive and leave the current XCode in place.
Then you can test in the iOS 6 simulator just to make sure it works as well as on iOS 5.