
In early May, on the Internet, language developers announced that they are beginning preparations for the release of the 3.0 version of the language. Development 3.0 goes to the master branch, by releases, it can be understood that the 3rd of May was the release of Swift 2.2.1. Then they began to infuse changes regarding the 3rd version of the language. On May 9th, the first developer release from the same wizard has already appeared, which can be rolled onto the latest xcode through the installer from
swift.org/download/#snapshots , which is enabled via Preferences -> Components -> Toolchains.
Some general information about a future release.
Around the first dev release of Swift 3.0, the developers stated that, unfortunately, they do not have time to implement ABI compatibility in version 3.0. Let's understand what it all means, for the first time I saw these three letters together.
')
ABI is an application binary interface, roughly speaking, compatibility of binaries of different versions with each other, you can draw an analogy with the API compatibility we are used to when API 1.0 is compatible with 2.0, but changes made in 3.0 will be incompatible with the first version, so when using the API 3.0 it will be necessary to edit the code (in the case of ABI, not to edit the code, but to reassemble the binary).
In fact, as it turned out to be a discovery for me, Swift has never had ABI compatibility. This suggests that the lib compiled in Swift 2.0 will no longer be resolved with the 2.2 version of the language. Colleagues from stable languages:

So it turns out and live. But the
sweaters to the spivters are lucky in this regard, because the dependency managers (cocoapods, carthage) always pull the source of the projects, not the binaries, so there are no problems with ABI compatibility as such. But, apparently, it is worthwhile to refrain from writing proprietary libs on a sphivt and upload them to the public in the form of binaries. Yes, ABI promise to add only to Swift 4.0.
Look at the changes in the API

Even the didFinishLaunching method is highlighted by varning, since its signature has changed, it has now become
/// swift 3 func application(_ application: UIApplication, didFinishLaunchingWithOptions launchOptions: [NSObject : AnyObject]? = [:]) -> Bool {} /// swift 2 func application(application: UIApplication, didFinishLaunchingWithOptions launchOptions: [NSObject: AnyObject]?) -> Bool {}
Warnings should be easily fixed for migration to Swift 3.0 in Xcode in the future.
Look at the changes in the standard library Swift and Foundation
ErrorType changed to
ErrorProtocol /// swift 3 enum MyError: ErrorProtocol { case Success case Fail(ErrorProtocol) } /// swift 2 enum MyError: ErrorType { case Success case Fail(ErrorType) }
Changes to
Array /// swift 3 sort() // sorted() // /// swift 2 sortInPlace() // sort() //
that is, the
sort method became mutable, removed
sortInPlace and added
sorted .
/// swift 3 reversed() append(contentsOf: [T]) insert(T, at: Int) joined(separator: String) /// swift 2 reverse() appendContentsOf([T]) insert(T, atIndex: Int) joinWithSeparator(String)
Also, many designers have removed and renamed other methods.
String Changes
/// swift 3 "3.0".components(separatedBy: ".") "3.0".substring(to: 1) "3.0".substring(from: 1) "".data(using: NSUTF8StringEncoding) "2.0".replacingOccurrences(of: "2", with: "3") "".uppercased() "".lowercased() "3.0".contains(".") "3.".appending("0") ("dir1" as NSString).appendingPathComponent("dir2") " 3.0 ".trimmingCharacters(in: .whitespaces()) "".write(toFile: "/..", atomically: true, encoding: NSUTF8StringEncoding) /// swift 2 "3.0".componentsSeparatedByString(".") "3.0".substringToIndex(1) "3.0".substringFromIndex(1) "3.0".dataUsingEncoding(NSUTF8StringEncoding) "2.0".stringByReplacingOccurrencesOfString("2", withString: "3") "".uppercaseString "".lowercaseString "3.0".containsString(".") "3.0".appendContentsOf(".release") ("dir1" as NSString).stringByAppendingPathComponent("dir2") "3.0".stringByTrimmingCharactersInSet(.whitespaceCharacterSet()) "3.0".writeToFile("/..", atomically: true, encoding: NSUTF8StringEncoding)
Cases for
enum are now in lover case
/// swift 3 UIInterfaceOrientation.portrait Optional.some("") Optional.none /// swift 2 UIInterfaceOrientation.Portrait Optional.Some("") Optional.None
UIKit changes
/// swift 3 let vc = UIViewController() vc.present(some, animated: true, completion: nil) vc.dismiss(animated: true, completion: nil) vc.prepare(for: segue sender: button) UIColor.white() UIColor.blue() let path = UIBezierPath() path.move(to: CGPoint(x: 0, y: 0)) path.addLine(to: CGPoint(x: 100, y: 100)) // _ + , - func tableView(_ tableView: UITableView, numberOfSections section: Int) -> Int { return 0 } func tableView(_ tableView: UITableView, cellForRowAt indexPath: NSIndexPath) -> UITableViewCell { return UITableViewCell() } func tableView(_ tableView: UITableView, didSelectRowAt indexPath: NSIndexPath) { } /// swift 2 let vc = UIViewController() vc.presentViewController(some, animated: true, completion: nil) vc.dismissViewControllerAnimated(true, completion: nil) vc.prepareForSegue(segue, sender: button) UIColor.whiteColor() UIColor.blueColor() let path = UIBezierPath() path.moveToPoint(CGPoint(x: 0, y: 0)) path.addLineToPoint(CGPoint(x: 100, y: 100)) func tableView(tableView: UITableView, numberOfRowsInSection section: Int) -> Int { return 0 } func tableView(tableView: UITableView, cellForRowAtIndexPath indexPath: NSIndexPath) -> UITableViewCell { return UITableViewCell() } func tableView(tableView: UITableView, didSelectRowAtIndexPath indexPath: NSIndexPath) { }
More changes
/// swift 3 NSData(contentsOf: "") UIApplication.shared() NSUserDefaults.standard().set("value", forKey: "key") NSFileManager.default().fileExists(atPath: "/...") NSBundle.main() /// swift 2 NSData(contentsOfURL: "/") UIApplication.sharedApplication() NSUserDefaults.standardUserDefaults().setObject("value", forKey: "key") NSFileManager.defaultManager().fileExistsAtPath("/") NSBundle.mainBundle()
This is how the swiftification was conducted, in general, the whole api suffered, and not just the standard library. But you have to admit, readability really got better. Release Swift 3.0 is scheduled for autumn. ABI compatibility is scheduled for 4.0. Something new in Swift should not be expected at WWDC 2016.
The question arises, so what is to choose for a new project? I vote for Swift, with it the development is much faster and safer due to the very strict typing and custom-made ruffles and syntax closures / lambda. Generally:

Useful links:
https://swift.org/blog/https://www.hackingwithswift.com/swift3https://github.com/apple/swift-evolutionhttp://www.bensnider.com/abi-compatibility-whoopdty-do-what-does-it-all-mean.htmlupdate
It is worth adding that the Swift developers shoveled the entire API to make it as it was intended from the first days of the language, just support for compatibility with Objective-C did its job and broke the original API design. Swift is planned to work on many platforms, including FreeBSD, Raspberry Pi, Android, Windows. Apparently, it was in version 3.0 that we decided to make a complete processing of the API, to give it a more swift style.