I have a general question as I found many frameworks are deprecated in iOS 9. Consider developing for iOS 7 and above with the latest Xcode and iOS SDK. I'm going to use UIAlertView which is deprecated in iOS 9 and replaced with UIAlertController. In my code when I want to show an alert, should I have to check for iOS version and provide a block of code using UIAlertView for iOS prior to 9, and another block of code for UIAlertController for iOS 9 and above?
The same goes for AddressBook and AddressBookUI frameworks which are replaced with Contacts and ContactsUI frameworks.
I know that many deprecated frameworks still work fine with new iOS SDK but sometime in future there will be a chance of not working fine.
What would be a good approach on this issue?
First off, UIAlertView was deprecated in iOS 8, not iOS 9.
Deprecated doesn't mean removed. It means obsolete.
As long as an API isn't deprecated in your Deployment Target, it should be safe to use. It's very rare for a deprecated API to actually stop working.
Like everything else, test to be sure everything works on each version of iOS your app supports.
When you drop support for iOS 7 in some future update of your app, you can replace all uses of UIAlertView with uses of UIAlertController.
Similar for AddressBook. Keep using it until your Deployment Target becomes iOS 9 then you can migrate to using the new Contacts framework.
Of course if a new API offers functionality that you wish to use on devices that support, feel free to do so. Just make sure you don't try to use newer APIs on devices with older versions of iOS.
Keep this in mind. There are apps that were written in iOS 2.0 seven years ago. Many of these apps still work under iOS 9.
Check iOS version first is a good way. Besides, you can use respondsToSelector method to check whether the new methods are supported on the (new) running devices.
Related
I've upgraded my Xcode project with Xcode 7. I'm using Objective-C.
When I'm targeting iOS 9.0 in deployment target, I've 36 warnings :
UIAlertView is deprecated, use UIAlertController.
ABAddressBookRef is deprecated, use CNContactStore ...
setStatusBarStyle:animated is deprecated, use [UIViewController preferredStatusBarStyle]
and some other...
Well, I would like to keep compatibility with iOS 9 and at least iOS 8.
Do I have to disregard these warnings for keeping compatibility with different OS ?
If I use UIAlertController iOS 8, is it working ?
What the best thing I've to do ? Using deprecated or replace with new code ?
If you are no longer targeting the older versions of iOS then its recommended to update deprecated code. You don't absolutely have to though, deprecated methods are still officially supported in Apple's SDKs, but one day Apple may remove those methods.
Here's what Apple says about deprecation:
From time to time, Apple adds deprecation macros to APIs to indicate
that those APIs should no longer be used in active development. When a
deprecation occurs, it is not an immediate end-of-life to the
specified API. Instead, it is the beginning of a grace period for
transitioning off that API and onto newer and more modern
replacements. Deprecated APIs typically remain present and usable in
the system for a reasonable amount of time past the release in which
they were deprecated. However, active development on them ceases and
the APIs receive only minor changes—to accommodate security patches or
to fix other critical bugs. Deprecated APIs may be removed entirely
from a future version of the operating system.
As a developer, it is important that you avoid using deprecated APIs
in your code as soon as possible. At a minimum, new code you write
should never use deprecated APIs. And if you have existing code that
uses deprecated APIs, update that code as soon as possible.
Fortunately, the compiler generates warnings whenever it spots the use
of a deprecated API in your code, and you can use those warnings to
track down and remove all references to those APIs.
https://developer.apple.com/library/ios/releasenotes/General/WhatsNewIniOS/Articles/iOS7.html
"Deprecated" means at least one of the following:
This API isn't gone yet, but it might be in the future, or on future platforms/technologies. For example, all API deprecated before iOS 8 is unavailable in Swift.
There's a better alternative to this API, and the old one might not keep doing everything you need as the platform changes. For example, AssetsLibrary is still around even though it's deprecated, but it doesn't provide access to iCloud Photos or Live Photos — for those you need its replacement the Photos framework.
Those are things to consider when targeting an OS version where the API are deprecated.
However, deprecation warnings are based on your project's minimum deployment target. If you tell Xcode that you want to build for iOS 7 and newer, you won't see warnings for APIs that are deprecated as of iOS 8 or iOS 9.
If you want to deploy back to an older minimum OS target, but use features from a newer OS, you need to put availability checks in your code that uses the newer features. See Apple's docs on compatibility/availability and weak linking in general, and/or Checking API Availability for Swift.
I've been searching through documentation for a while and I can't really find it. My question is very simple:
If I submit an app that works on iOS 8 only, will I be able to add a iOS 7 support with an update?
Thanks!
Yes, this is possible. You need to do the following:
Go to your project target's settings "General -> Deployment Info -> Deployment Target" to iOS 7.x.
Test your application on iOS 7.x device and make sure your application is not crashing and working as expected. If there are iOS
8.x only API's used in your code, you need to switch to API's for iOS 7.x at runtime.
Note: Since you are about to add the support for iOS 7.x, avoid using the deprecated API's. This will save your life later on when these deprecated API's are gone.
I had an app that worked with IOS7 now if I change the deployment target to IOS8 I get lot of Deprecated Methods, I want to edit the app in order to work for boht IOS versions, should I keep deployment target to IOS7 and change every deprecated method for IOS8?
Changing deployment target will not work.
Please keep deployment target to the lowest supported iOS version.
Also, Apple provides backward compatibility. So the deprecated methods will work.
For best result use respondsToSelector .
Try to replace deprecated methods but with caution. Keep your old methods as is. And conditionally give support for iOS 8 and above.
Hope i am helpful.
Thanks
If you intend support iOS 7. Set your Deployment Target to 7.0
Within your build settings, make sure that the Base SDK is at least 8.0 (the latest version you want to support) or typically most people will select Latest iOS which will list the latest version that the SDK would support. Currently iOS 8.1.
Deprecated Methods are referring to methods that are outdated BUT they still work because Apple provides backward compatibility. It is just a friendly warning. In the sense of, "Hey you don't need these older methods anymore since you're just supporting iOS 8. There's newer ways to do things in town."
In your case, change deployment target back to 7.0 and if you want to (optional), go ahead and update any remaining deprecated methods that are probably left from iOS 6, iOS 5, etc etc.
iSO 7 introduced a new API for popover
setPopoverContentSize: animated:
instead of
contentSizeForViewInPopover
which was used in iOS6 and previous. Since I am using iOS7 SDK shouldn't the first API redirect itself to use older version on iOS 6. why do I have to take care of replacing one call with if , else iOS detection everywhere in the code.
Is there a way to use one API for both the iOS version ?
Is there a way to use one API for both the iOS version ?
Yes. The only apparent change in iOS 7 is that contentSizeForViewInPopover is now deprecated. The other call, -setPopoverContentSize:animated:, and the corresponding popoverContentSize property have been available since iOS 3.2.
Given that, the right approach is to change your code to use popoverContentSize and -setPopoverContentSize:animated:. Your code will work fine in iOS 6, and you won't have to worry about going through your code at some point in the future to remove iOS 6-only code.
You can still use the older call, until such a time that you feel you only need to support iOS7.
There's no way for iOS6 to know what the newer call means, so it cannot re-direct.
The best way to handle this situation is by using the older API call, like everyone is mentioning here. If your deployment target is 6.x, your app will compile and build against that and you're good to go.
You don't need to worry about iOS 6 / 7 support if your target isn't iOS 7.
That being said, if, in the future, you do move to a target of iOS 7, it should be the developer's responsibility to handle backwards compatibility, and not the SDK's. The SDK cannot make assumptions about your code and redirect deprecated calls to the newer version.... It just doesn't work like that, and such a system would be asking for trouble.
Also, in this case, setPopoverContentSize:animated: isn't exclusive to iOS7 and is supported as far back as iOS3.2 so you're good to go.
This might help:
if (floor(NSFoundationVersionNumber) <= NSFoundationVersionNumber_iOS_6_1) {
//code for iOS 6
} else {
//code for iOS 7
}
Can be a pain, but this is the best we can do for now.
My app is getting an error message and crashes on the iOS 5.1 simulator because this iOS 5.1.1 doesn't support the "Social" framework.
Is there a way to solve this and use it on versions prior to iOS 6?
The Social Framework is an iOS 6 Only feature. It will NOT work on devices running iOS earlier than 6.0. You have two options. If your App is new you can require iOS 6 or greater.
If your App has been out there for a while and you need to support versions of iOS earlier than 6 you can test for the existence of the framework at run time with something like this:
if(NSClassFromString(#"SLComposeViewController") != nil) {
// The social Framework exists
else
// Social Framework does NOT exist.
NOTE IN RESPONSE TO YOUR COMMENT BELOW:
It is considered bad design to use the version number to check for the existence of a feature. The recommended approach is to check for the existence of the feature itself.
The code you mentioned in the comment is a perfect example of WHY you test for the feature and not the version. The floatValue of #"5.1.1" is 5.1 AND the floatValue of #"5.1.2" is also 5.1! If the feature your looking for is not in 5.1.1 but IS in 5.1.2 your code will NOT detect it and incorrectly assume the feature DOES NOT exist. Don't do this. Use the technique I outlined above.