Swift: problems and prospects

On June 2, 2014, in the Apple world, something happened that nobody expected. Apple introduced a new object-oriented programming language - Swift.

What can Swift attract?
Unlike Objective-C, in which for each class you need to create * .h and * .m files with an interface and implementation, respectively, in Swift you need to create only one * .swift file, which contains both the interface and the implementation. This means that the source files in the project will be 2 times smaller, which is a plus. However, the question arises - how to divide class properties and methods into public and private? In Objective-C, we are used to “hide” private properties and methods in * .m files. To do this in Swift at the moment is impossible.


')
According to Apple, such a mechanism will still appear:



Source: https://devforums.apple.com/thread/227288 (requires a developer account).
Swift has an excellent switch-case statement. Unlike Objective-C, in Swift you can perform a listing in rows and with conditions:

let vegetable = "red pepper" switch vegetable { case "celery": let vegetableComment = "Add some raisins and make ants on a log." case "cucumber", "watercress": let vegetableComment = "That would make a good tea sandwich." case let x where x.hasSuffix("pepper"): let vegetableComment = "Is it a spicy \(x)?" default: let vegetableComment = "Everything tastes good in soup." } 

Swift and Objective-C can be used in the same project, i.e. It is possible to smoothly transfer to Swift; it is not necessary to rewrite old libraries and classes.
Swift modules are available immediately in the entire project, while in Objective-C you need to include interface files (* .h) in order to use them.
Now let's try to check whether Swift really works faster. To do this, create 2 identical applications in Objective-C and Swift. The functionality of the application is to load the controller (UIViewController) and in its main view (UIView) place and display a picture (UIImageView). We will note the time from the moment the application is fully loaded until the first controller is displayed. Repeat the test 10 times (chart below).



As it is easy to see, an Objective-C application loads a controller faster than a Swift application, and the Objective-C load time is more stable.
So, our application on Objective-C on average loads the controller in 0.02556 seconds, and the application on Swift - in 0.03404 seconds. Why so? Because, most likely, Apple did not rewrite frameworks, including UIKit, which is responsible for creating controllers and views on Swift. Instead, so-called “wrappers” were made. Simply put, Swift methods for creating controllers, views, etc. just call in turn methods on Objective-C and return the result. Most likely, in the future the situation will change, Apple will carefully work on optimization and in the future applications on Swift will work faster. But not now.
Now let's try to rename our class. Click on the class name with the right mouse button, Refactor / Rename and ...:



Of course, this problem will definitely be resolved, most likely by the fall, when the final version of Xcode 6 will be released. But all this hints at Swift again.
Still experienced iOS developers, who are used to Objective-C, will be confused by the fact that when using Blocks and closures similar to them in Swift, there are differences in the braces tabulation.
This is how a simple block of animation in Objective-C looks like:



And so in Swift:



For some reason in Swift it is customary for the closing brace to be on the same level with the body of the block. It would be quite logical to do this like this (focus on curly brackets {}):



Another very annoying Swift problem is related to increment. The increment is used mainly in cycles, as a counter.

 let startDate = NSDate() var j:Int64 = 0 for var i:Int64 = 0; i<=1000000000; i = i+1 { j = i j = j+1 } println("\(NSDate().timeIntervalSinceDate(startDate))") 

The execution time of this code: 4.44419801235199 seconds.

But if i = i + 1 and j = j + 1 are replaced by ++ i and j ++, respectively (and this is a more general case):

 let startDate = NSDate() var j:Int64 = 0 for var i:Int64 = 0; i<=1000000000; i++ { j = i j++ } println("\(NSDate().timeIntervalSinceDate(startDate))") 

That runtime increases dramatically to 624.784721970558 seconds (more than 10 minutes!).

Accordingly, Objective-C:

 NSDate *startDate = [NSDate date]; int64_t j = 0; for (int64_t i = 0; i<= 1000000000; i = i + 1) { j = i; j = j + 1 } NSLog(@"%f", [[NSDate date] timeIntervalSinceDate:startDate]); 

Time: 2.842506 seconds.

 NSDate *startDate = [NSDate date]; int64_t j = 0; for (int64_t i = 0; i<= 1000000000; i++) { j = i; j++; } NSLog(@"%f", [[NSDate date] timeIntervalSinceDate:startDate]); 

Time: 2.833201 seconds.

For the purity of the experiment, we only pay attention to the differences between using i ++ and i = i + 1 in Swift and Objective-C and separately. And we will not compare them with each other, because int64_t in Objective-C is a simple type, but Int64 in Swift is a structure and, of course, will work slower, although Swift does not provide any other way out.
In addition, Xcode currently has very weak support, poor autocompletion of the code, and still does not fully support, perhaps, the main framework for creating iOS applications - UIKit. What can we say about the rest ...
Thus, we can conclude that Swift was presented to us so that we would learn it while it was being finalized. Most likely, all of these problems will be fixed over time, but currently, using Swift to create commercial applications is strongly discouraged. Now it is only for training. Swift will definitely take its place, but Objective-C will still be used as the primary language for another year 2.