Swift: challenges and prospects

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

What can attract Swift?
Unlike Objective-C, in which for each class it is necessary 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 separate class properties and methods into public and private? In Objective-C, we are used to hiding private properties and methods in * .m files. It is currently impossible to do this in Swift.



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 enumerate line by line 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 one project, i.e. You can make the transition to Swift smoothly; you don’t need to rewrite old libraries and classes.
Swift modules are available immediately throughout the project, while in Objective-C you need to include interface files (* .h) in order to use them.
Now let's try to check if Swift really works faster. To do this, create 2 identical applications on Objective-C and on Swift. The functionality of the application is to load the controller (UIViewController) and in its main view (UIView) place and display the picture (UIImageView). We will detect the time from the moment the application is fully loaded until the first controller is displayed. Repeat the test 10 times (chart below).



As you can see, an Objective-C application loads the controller faster than a Swift application, and the load time on Objective-C is more stable.
So, our Objective-C application loads the controller on average in 0.02556 seconds, and the Swift application in 0.03404 seconds. Why so? Because, most likely, Apple did not rewrite the 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. they simply call the methods on Objective-C and return the result. Most likely, the situation will change in the future, Apple will carefully work on optimization and in the future applications on Swift will work faster. But not now.
Now let's try renaming our class. We right-click on the class name, Refactor / Rename and ...:



Of course, this problem will be unambiguously resolved, most likely, by the fall, when the final version of Xcode 6 is released. But all this once again hints at Swift's "dampness".
Still experienced iOS developers who are accustomed to Objective-C will be confused by the fact that when using Blocks and similar Closures in Swift, there are differences in the tab braces.
This is how a simple animation block looks in Objective-C:



And here it is in Swift:



For some reason, in Swift it is customary for the closing curly bracket to be at the same level as the block body. It would be quite logical to do like this (attention to curly braces {}):



Another very annoying Swift issue is related to increment. 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))")

Execution time of this code: 4.44419801235199 seconds.

But if we replace i = i + 1 and j = j + 1 with ++ 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 rises sharply 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 pay attention only to the differences between the use of 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 more slowly, although Swift does not provide another way out.
In addition, Xcode currently has very poor support, poor code autocompletion, and does not yet 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 introduced to us so that we would learn it while it was being finalized. Most likely, all of these problems will be resolved over time, but at the moment, using Swift to create commercial applications is strongly discouraged. Now it is only suitable for training. Swift will certainly take its place, but Objective-C will still be used as the main language for another 2 years.