This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Some questions about Automatic Reference Counting in iOS5 SDK
Well, that's about it.
Does any one support automatic garbage collection? Which ones?
Which iOS versions let you develop without managing memory yourself? (i.e., only using Automated Garbage Collection)
It doesn't primarly depend on the version of iOS. It depends on the version of the compiler. ARC is supported in clang with LLVM version 3.0 and later.
Unfortunately enough, however, iOS 4.2 and earlier is missing symbols that are used by the compiler to generate ARC-enabled code, so these versions can't support ARC. This is not a strictly technical dependency though - if the clang compiler was written so that it doesn't require extra functions to generate ARC code, persumably all previous versions of iOS could run programs written using ARC.
Related
What is the min iOS which works well with Swift 5.1 or incoming Swift 5.2?
Are there any references to check this?
A similar question has been asked before, when Swift 4 came out. You can find the question and answer here.
Having that said, the swift.org site and the release notes only specify the compatibility with previous Swift versions, the operating systems and the toolchain (Xcode). So, a straight forward answer can't be given to this question.
Since Swift 5.1 is compatible with Swift 4, you can safely assume the code will run iOS 11 and probably iOS 10 as well. There are, however, some incompatibilities between Swift 5.1 and Swift 4, see for the details this link. I think you should also be aware of the fact that as of iOS 11 32 bit is not being supported anymore.
The next issue you will definitely run into are the deprecated functions in iOS. You have to build your code in the productive version of Xcode and that tool will throw errors and warnings for deprecated functions or variables being changed. For instance, the key "[UIImagePickerControllerOriginalImage" has been changed to "UIImagePickerController.InfoKey.originalImage". at the moment Xcode 11.3 doesn't let you specify below 12.1, so you will run into these problems when updating source code written in an older version.
I know Swift is not yet ABI stable, but does that only count for major versions of Swift?
Is there any guarantee that minor or patch versions (under semantic versioning) of Swift are ABI stable?
I'm guessing there is no guarantee here, but just wanted to double check if anyone has come across anything detailing ABI stability for different minor/patch versions of Swift.
Also, if I use a Swift binary framework compiled with a different version of Swift I get a compiler error usually. If I don't get a compiler error in my project does that mean it is safe, or could there still potentially be runtime issues with a slightly different (patch version) of Swift?
Update 3
We also have module stability, starting with Xcode 11, with the help of the newly introduced .swiftinterface files. One caveat, though, is that the code will have to be build with the -enable-library-evolution flag. More details here.
Update 2 Module stability is scheduled for Swift 6: https://swift.org/blog/abi-stability-and-more/#module-stability
This is an excerpt from the Swift evolution repo.
Update Swift 5 comes with some ABI stability:
The Swift 5 release will provide ABI stability for the Swift Standard Library.
Unfortunately, not yet. For Swift 4, they state this here: https://swift.org/blog/swift-4-1-release-process/.
Swift 4.1 is not binary compatible with 4.0. It contains a variety of under-the-hood changes that are part of the effort to stabilize the Swift ABI in Swift 5.
Hopefully we'll get ABI stability in Swift 5
I think we should know what is ABI stability firstly, After that your confusion has already been removed.
Today, the latest version of Swift is 3.1, so chances are if you ship an app tomorrow, your app bundle will contain the Swift dynamic libraries for 3.1, however, there are plenty of apps in the store right now which link 3.0, 2.3, and probably even some older apps that link 2.1 and earlier. Nothing is stopping me from downloading your app (on 3.1) and my app (on 2.3) and running them side-by-side on my iPhone with iOS 10.3, since both apps link against their own bundled version of Swift. It's exactly the same as you bundling Alamofire 4.4 and while I bundle 3.0.
When a language is ABI-stable (Application Binary Interface), that means it is packaged and linked with the operating system itself, in this case: iOS. The Swift code you compile on your computer has a binary interface into the operating system itself rather than any dynamic library you bundle with your application. Because of this, Apple has to be able to guarantee that my Swift code, when compiled to machine code (bitcode, LLVM-IR, yada-yada), will be able to interface properly with the rest of the operating system, and (probably more importantly) will not break between versions of iOS / Swift.
As it stands today, the Swift language specification and compiler are not in a state where the Swift team would feel comfortable making this promise of ABI-stability; changes to Swift are still too frequent and the roadmap is still too long. As soon as the Swift library is merged into iOS, it becomes much much harder to make big changes.
Why does it matter?
Yes, the bundle size of your application will decrease because you will no longer have to include the Swift standard library in your Frameworks folder, which is nice.
Language changes will be smaller / less frequent, so you won't have to worry about events like migration from Swift 2 -> 3 (I'm still scarred from that)
Developers will be able to create 3rd-party libraries written in Swift and distribute pre-compiled frameworks (binaries), because they no longer need to bundle the Swift standard library into their framework, and will instead be linking against the same version of Swift as your app (the one packaged with iOS).
This question already has answers here:
Swift compatibility between versions for a library
(2 answers)
Closed 6 years ago.
We are developing an iOS framework using Swift 2.2. This framework is intended for outside use, i.e., its built binary will be distributed to our clients, and they will use it to develop their applications.
Another update: Swift 3 will not have ABI compatibility. See here: https://www.infoq.com/news/2016/05/swift-3-no-stable-abi.
So if we author the framework in Swift, and the only way to guarantee our clients using different versions of Swift can consume it safely is to build multiple versions of the framework, and ask them to download the version that matches theirs, right?
From Apple's documentation.
Swift 2.3 and Swift 3 are not binary compatible so your app's entire
code base needs to pick one version of Swift.
Also here is a similar question that you may find helpful.
Here is my short assumption on that currently looking more on it.
Application with Swift code bundles Swift specific standard libs with Swift, Apple has changed how standard libraries are shipped. With Objective-C, all of the standard libraries, system frameworks, and the runtime itself, were shipped with the OS. But With Swift, Apple trying to ship a specific version of the standard library with your app.
Please share your thought on that.
Found Interesting - Compatibility Blog
According to that - In fact, you can target back to OS X Mavericks or iOS 7 with that same app. This is possible because Xcode embeds a small Swift runtime library within your app’s bundle. Because the library is embedded, your app uses a consistent version of Swift that runs on past, present, and future OS releases.
Any other discussion warm welcome!
I have to make apps for that work on both iOS 4 and iOS 5. The iOS 5.0 SDK has nice features like ARC, storyboard etc, which are not available in iOS 4.
My question is: In order to make an app optimized for iOS 4 and 5 what should do? Should I develop an app in a classic way without ARC, storyboard etc?
For instance, how can I switch off automatic garbage collection for iOS 4? If I do, of course iOS 5 will not benefit from having ARC. Also, if you mark reference as weak/string - that will not compile for iOS4, won't it?
As Andrey indicates in his comments, while automatic reference counting was introduced with the LLVM Compiler 3.0 that came with Xcode 4.2 and the iOS 5.0 SDK, you can use it in applications that target back to iOS 4.0. There's no good reason not to use it for applications that will run on iOS 4.0+. Also, it's different from garbage collection, as I explain in this answer.
__weak pointers are only available for applications that use ARC and target iOS 5.0 and greater. For iOS 4.0, you'll need to fall back to using __unsafe_unretained as a pointer type when you want to avoid retain cycles.
However, storyboarding is not available for applications targeting anything earlier than iOS 5.0. It's a nice convenience, but I don't personally use it for anything. Jonathan Wight has, and he has some complaints about its current implementation, so you might not be missing much if you gave that feature a pass.