Some examples: In swift 2 we had NSData and NSUrl; in swift 3 we have Data and URL. If you alt click on Data it says available from iOS 10 and above.
Please can someone explain the following: if the Apple docs say something is only available from iOS 10 and above, does that mean I can only use it on an app that's target is iOS 10 and above?
I have read that Swift 3 is compatible with iOS 8, but these changes (NSData to Data, for example) were part of the move from Swift 2 to 3. So if Data is only available in iOS 10 and above, what does it mean to say Swift 3 is compatible with iOS 8?
I guess, in essence, I am confused about the difference between API availability and Swift 3 compatibility.
Your help is much appreciated.
if the Apple docs say something is only available from iOS 10 and above, does that mean I can only use it on an app that's target is iOS 10 and above?
No. The availability part of Apple's docs may show two different kinds of info -- the SDK availability and the target OS availability.
In the case of Data, the Standard Library code of Data is compatible for all iOS's 8 and later, but the Standard Library including Data (Swift 3 Standard Library) is included only in iOS SDK 10 or later, the availability part of the Apple's doc is representing the "availability" in that meaning.
This thread in the Apple's dev forums would be some help. Generally, you can rely on the availability checking feature of Xcode/Swift. When you marked your project's minimum target to iOS 8.0 and you get no warnings about availability, all the features used in the project should work on iOS 8.0 devices.
You can send a bug report about this as a documentation error.
Related
Recently I have read a few articles about Swift 5 being ABI Stable (which basically means you won't need to pack app's own version of the Swift Dynamic Library within the App bundle) and here is the confusing part:
because Swift will be embedded within the iOS Operating System.
Now that sounds like Swift Dynamic Library would now go directly into iOS. Would that mean that Apps compiled Swift 5 will be able to run only on specific iOS versions?
You're on the right track, but the point is that the app would only run on a specific iOS version or later. The whole goal of ABI stability is to allow a Swift binary (i.e. an app) that was compiled with one version of Swift to be able to interoperate with a binary (i.e. a framework) that was compiled with a different version of Swift.
But yes, to make use of ABI stability, your app would only be able to run on iOS 13 (or whatever version it turns out to be), or later.
This is how things work in ObjC (and C and C++ and most languages). I can build my Objective-C app on iOS 10 and expect that it will link with Foundation and UIKit on iOS 11 without trouble. You can't do that with a Swift library today.
For example, in swift 3 there is a new type and property: Calendar.current, does it support for iOS 8?
The document said the SDK is iOS 10+, but I can run a app using this type property on iOS 8 device. This is very strange.
I want to know is there any place to check the minimum iOS version support for a type, property and function?
Or may be just the document is not updated? I use Xcode 8 GM version.
The Swift Syntax that is available is dependant on the development environment (The version of Xcode), not the iOS platform that Xcode is building for. Therefore swift 3.0 syntax will be valid for any project for any iOS version that is built using Xcode 8+ (assuming you have not enabled the setting to use legacy swift, which uses the older syntax)
As #Eric Aya said, just because it's new for Swift 3 doesn't mean that it won't work on earlier versions of iOS.
This is (somewhat) equivalent to the change of CGRectMake() to CGRect(). You can't use CGRectMake() in Swift 3, but its replacement will work for pre iOS 10 (how else would you do it?).
Swift 3 will work for any project being made in Xcode 8 (unless you specifically choose Swift 2). It does not take into account which version of iOS or which device.
You can read more at the official Swift 3 migration guide.
So Swift 2.0 is coming up with Xcode 7, what is the minimum iOS / OS X system version required to use Swift 2.0?
An Apple staffer had this to say:
iOS 7 / OS X 10.9, same as Swift 1.0.
Update: I'm guessing this is because the runtime is packaged into the built app / library / framework / whatever the same as with Swift 1.x.
I've tested it as far a iOS 7, no clue on anything lower however you probably shouldn't be supporting iOS 6 anymore.
I couldn't find an official response anywhere, but they implied that Swift 2.0 will deploy back to iOS 7 in a couple of WWDC 2015 presentations.
Session 403: Improving Your Existing Apps with Swift (http://asciiwwdc.com/2015/sessions/403), where they mention the availability feature in Swift 2.0:
Because they all want you to support these old versions, iOS 7, 8, and now 9 is probably going to be on slate for this fall for many of you.
So to do that, we have this new availability feature introduced in Swift 2.0.
So as long as you are writing some code in Swift 2.0, we have a great way to check to see what SDK you are on and if you can actually use this feature or not.
Session 411: Swift in Practice (http://asciiwwdc.com/2015/sessions/411), where they talk about the Swift 2.0 availability feature:
But if I slide all the way back to deploying to iOS 7, the compiler can see, just as we can read on this slide, that it's unsafe to use this method, request when in use authorization. And the compiler will tell you that this is just unsafe code. And it's an error. It will literally prevent you from building this code. And it will give you a nice safety check.
Currently, I'm in the middle of adapting my app for iOS 7.1 to support iOS 8.
During this process, it dawned more and more on me that I may have seen the relationship between SDKs and OS versions wrong all the time.
I'll tell you with a concrete example:
The UIViewControllerContextTransitioning protocol gained some more methods for iOS8. So in order to support the new OS, I started implementing the new methods in my ContainerViewController.
When I came across the - (UIView *)viewForKey:(NSString *)key method, I naturally checked the key against the UITransitionContextFromViewKey constant.
This constant has the NS_AVAILABLE_IOS(8_0) suffix. So I assumed the constant is only available when running on iOS8 and above.
When I set the deployment target in Xcode from 8.0 to 7.1 and hit 'Build & Run', to my surprise there was no error at all and the app ran on my iOS7.1 device without any problem. - Even while the code contained the constant that should only be available at >= iOS8.
So here are the questions that came to my mind at this point:
The NS_AVAILABLE_IOS(8_0) suffix in the header files does not determine the iOS version, but rather the SDK version from which on the marked API is available. - is that correct?
Does this mean we are able to use APIs added in the iOS8 SDK in apps that are compiled for iOS7.1, as long as we use the new SDK to build the app?
I'm particularly curious about the second question, because that would mean we can use cool new stuff like the UIVisualEffectView for apps that run on iOS < 8. Also, this would mean much less headache for example when maintaining CoreLocation functionality while following all the changes made to it (kCLAuthorizationStatusAuthorized -> kCLAuthorizationStatusAuthorizedWhenInUse, etc.), because we can simply maintain a single code base and do not have to #ifdef a lot.
Please tell me if my assumptions are correct and if not, please correct them in your answer.
Thank you!
It's important to realize that linking against the iOS 8 SDK with a deployment target of iOS 7 allows you to create an application that will run on both, but there will be differences in API availability.
When the application is run on iOS 7, iOS 8 APIs will be unavailable. At runtime, acccessing an iOS 8 API can cause a crash or other undesirable behavior. The recommended way to handle this is when using classes, methods, or constants that are marked as available only on iOS 8 or later, you must query for their availability at runtime.
In the case of new UIViewControllerContextTransitioning methods, you would query for the presence of those iOS 8 methods at runtime:
if ([transitioner respondsToSelector:#selector(viewForKey:)]){
// It's available, you're set to call it
} else {
// The method is not available, you will have to work around it.
}
Obviously, this can complicate things significantly for some applications. The application DeployMate can be very useful for finding API disparities in your code base. It will scan your project and tell you where you are using a method that is iOS 8 only.
Guidance for supporting different SDK and OS versions and capabilities is explained in more detail in the iOS 7 Tech Talk Architecting Modern Apps, Part 2. While the examples are for supporting iOS 6 and 7, the guidance here applies to supporting more than one OS or SDK, no matter what the version.
As Swift supports the mix-match with objective c , then can we use it for building the applications having deployment target less than iOS 7.
from Swift Prerelease Documentation Under the Basic Setup Section what i read is :
Swift is designed to provide seamless compatibility with Cocoa and Objective-C. You can use Objective-C APIs
(ranging from system frameworksto your own custom code) in Swift, and you can use Swift APIsin Objective-C.
This compatibility makes Swift an easy, convenient, and powerful tool to integrate into your Cocoa app
development workflow.
This guide covers three important aspects of this compatibility that you can use to your advantage when
developing Cocoa apps:
● Interoperability lets you interface between Swift and Objective-C code, allowing you to use Swift classes
in Objective-C and to take advantage of familiar Cocoa classes, patterns, and practices when writing Swift
code.
● Mix and match allows you to create mixed-language apps containing both Swift and Objective-C files that
can communicate with each other.
● Migration from existing Objective-C code to Swift is made easy with interoperability and mix and match,
making it possible to replace parts of your Objective-C apps with the latest Swift features.
So after reading this the questions arrises in my mind are
Can we use swift for the applications we are currently working
on.
If the answer is no then it will be contradict to the above
explanation.
Update - As per Xcode 6 Beta 4
iOS 7 and OS X 10.9 minimum deployment target
The Swift compiler and Xcode now enforce a minimum deployment target of iOS 7 or OS X
Mavericks. Setting an earlier deployment target results in a build failure.
From Xcode 6 release note
So my previous answer(Shown below) will not be applicable to any further swift development. Swift will no longer available for iOS6 and below
Yes you can . I have tested a simple app written completely in Swift in my iOS6 device, it works perfectly fine. As apple says Swift code is binary compatible to ObjectiveC code. It uses the same compiler and runtime to create the binary.
So if you are not using any new APIs added as part of the iOS8 SDK or some swift specific api's (corresponding api is not available for ObjectiveC) your app will seamlessly work on iOS6+(Tested and working) even iOS5(not tested). Most of the APIs in the swift are just the replacement of the existing ObjectiveC api's. In fact they are same in binary.
I am not sure but YES swift support lower version of ios in to Xcode Beta if you are check in to Project-->Target-->General-->Deplyment Info for select deployment target there is drop-down with 6.0,6.1,7.0,7.1 and 8.0
So i think yes swift support lower version.
I just test the demo that created in Xcode6 with swift language select. then i open this project in to Xcode5 with deployment target 6 and that runs it means that working with lower version too.
Here it is a screenshot of swift project runs in xcode5 with ios6.1 simulator:
HERE IT IS DEMO AS WELL http://www.filedropper.com/demo_5
Yes you can . I have tested a simple app written completely in Swift in my iOS6 device, it works perfectly fine. As apple says Swift code is binary compatible to ObjectiveC code. It uses the same compiler and runtime to create the binary.
So if you are not using any new APIs added as part of the iOS8 SDK or some swift specific api's (corresponding api is not available for ObjectiveC) your app will seamlessly work on iOS6+(Tested and working) even iOS5(not tested). Most of the APIs in the swift are just the replacement of the existing ObjectiveC api's. In fact they are same in binary.
No, only iOS 7+ and OS X 10.9+.
You can import and run swift code from Objective-C like this:
#import “ProductModuleName-Swift.h”
MySwiftClass *swiftObject = [[MySwiftClass alloc] init];
[swiftObject swiftMethod];
You can check the iOS version number with this gist and only run the swift code if the version is >= 7.0.
Yes, the minimum deployment target for Xcode 6 with Swift language is iOS 6.0
Yes you can. Its not important in which language you are writing the code. Finally what matters is compiler and architecture. So, you should definitely able to deploy them to OS version less than 7.0