Monday, February 29, 2016

Swift or Objective C - another 5 points to note

1. Swift is faster : 
Swift is nearly on par with C++ for both the FFT and Mandelbrot algorithms. According to Primate Labs, the GEMM algorithm performance suggests the Swift compiler cannot vectorize code the C++ compiler can -- an easy performance gain that could be achieved in the next version of Swift. According to Primate Labs, makers of the popular GeekBench performance tool, Swift was approaching the performance characteristics of C++ for compute-bound tasks in December 2014 using the Mandelbrot algorithm.In February 2015, Primate Labs discovered that the Xcode 6.3 Beta improved Swift’s performance of the GEMM algorithm -- a memory-bound algorithm with sequential access of large arrays -- by a factor of 1.4

Dropping legacy C conventions has greatly improved Swift under the hood. Benchmarks for Swift code performance continue to point to Apple’s dedication to improving the speed at which Swift can run app logic.

2. Fewer name collisions with open source projects 
One issue that has plagued Objective-C code is its lack of formal support for namespaces, which was C++’s solution to code filename collisions. When this name collision happens in Objective-C, it is a linker error, and the app can’t run. Swift provides implicit namespaces that allow the same code file to exist across multiple projects without causing a build failure and requiring names like NSString (Next Step -- Steve Jobs’ company after being fired from Apple) or CGPoint (Core Graphics). 

3. Swift support dynamic libraries 
Dynamic libraries have never been supported on iOS until the launch of Swift and iOS 8, even though dynamic libraries have been supported on Mac for a very long time. Dynamic libraries are external to the app executable, but are included within the app bundle downloaded from the App Store. It reduces the initial size of an app as it is loaded into memory, since the external code is linked only when used.

The ability to defer loading in a mobile app or an embedded app on Apple Watch will improve the perceived performance to the user. This is one of the distinctions that make the iOS ecosystem feel more responsive. Apple has been focused on loading only assets, resources, and now compiled and linked code on the fly. The on-the-fly loading reduces initial wait times until a resource is actually needed to display on the screen.

Dynamic libraries are executable chunks of code that can be linked to an app. This feature allows current Swift apps to link against newer versions of the Swift language as it evolves over time.

4. Swift Playgroups encourage interactive coding 
Apple has added inline code execution to Playgrounds to help programmers create a chunk of code or write an algorithm while getting feedback along the way. This feedback loop can improve the speed at which code can be written because the mental model that a traditional programmer needs can be replaced with data visualizations in Playgrounds. Programming is an iterative process, and any strain that can be reduced or used to complement the creative process will make programmers more productive and free them to solve bigger problems, rather than focusing on boring details that traditional compilers have imposed on programmers.

5. Swift is future that can influence


Swift provides the development community a direct way to influence a language that will be used to create apps, embedded systems (if Apple ever licenses an embedded framework and chip for third parties), and devices like the Apple Watch.

References:
http://www.infoworld.com/article/2920333/mobile-development/swift-vs-objective-c-10-reasons-the-future-favors-swift.html?page=2

No comments:

Post a Comment