Yesterday I was watching a talk from Nikita Lutsenko about Swift and Objective-C Interoperability. At some point he states:
What Objective-C protocols are in Swift is very special. There is so much that was added specifically for it. It’s also weaker and not Swift-y, even though you can use optional. So, optional is not supported on Swift protocols, unless they are exported into Objective-C, because that time, they become Objective-C protocols.
There is also no ability to talk to extensions of these protocols. Either they are concrete extensions, with no way you can talk to a protocol and build things like protocol extensions, which we all love and use in Swift. So they’re very limited altogether.
If you actually are writing Swift code, please don’t use these, they make everyone’s life bad as well as they could not be used, say, in a Linux environment, where you don’t have Objective-C runtime.
He’s right! When you annotate a protocol with @objc, LLVM will generate a bunch of extra things: an isa pointer, runtime sections like: __objc_imageinfo, __objc_classref, etc. It seems that it’s casting the protocol into a NSObject, and maybe it will have a performance penalty. Also @objc protocols can not be used with struct and enums, just class types.
So, let’s think this thoroughly, shall we?
optional means that a function may or may not exist.
In Objective-C, before passing a message, we have to check for respondsToSelector, otherwise it will crash at runtime.
In Swift, we just call the function, followed by a ?, all safe, no crashes.
But I think that there’s a more Swifty way of doing that, by using protocol extensions, take a look:
Now, if someone calls optionalMethodOne(), nothing happens, due to it’s empty implementation. We also mitigate the risk of someone, accidentally, forcing unwrap an optional functional. Not to mention the fact that, now, it’s not constraint to a specific type!
The way I was introduced to the Design Patterns lead me to think that those clever and neat solutions were meant to be used just in big softwares solutions. I never considered using them into the small pieces of software. What do I mean by that? Please, read on.
The Builder Pattern if defined as follows:
Separate the construction of a complex object from its representation so that the same construction process can create different representations.
Swift 1.2 introduced us with @noescape attribute. It’s a very important feature, when we want to make our code more cleaner and stricter. Using it properly at 3am will prevent many unwanted retain cycles.
While digging into release notes we can see a bunch of clever words:
A new @noescape attribute may be used on closure parameters to functions. This indicates that the parameter is only ever called (or passed as an @noescape parameter in a call), which means that it cannot outlive the lifetime of the call. This enables some minor performance optimizations, but more importantly disables the self. requirement in closure arguments.
Swift like objC allow us to mix it with other languages, unfotunately when it comes to Swift we can only choose between our good old friend objC or ANIS C, as there is still lack of C++ support. Basically using function pointers allows us to call C functions inside Swift. Swift will automatically convert methods included in Bridge Header into Swift equivalents:
Today Bluetooth Low Energy can be found in many cool applications, it can be used from simple data exchange to payment terminals and the more popular usage with iBeacons. But what if we want to build something funny with it? Like some simple game not even realtime, it may be even turn based game. Imagine you do not need to go through this long setup, waiting for server players to be ready etc.
Everyone knows that building good multiplayer game is hard, multiplayer itself is hard… But here I want to show you my small proof of concept of working bluetooth low enery multiplayer game.
Swift is out there for about a year and it’s a great programming language. I think that almost every iOS/OSX developer out there has already written couple of things in Swift (if you haven’t, go ahead and try, you won’t regret it, I promise). Although, we have many years of libs and frameworks built using Objective-C and sooner or later a project may have both Swift and Objective-C working together.
Gone are the days where there was just one iPhone for developers as a target. Now we have to support multiple devices with different screen sizes. Fortunately, we have autolayout, which solves a part of this design equation, the other part is solved with UITraitCollection. Trait collection object has two size classes: horizontal and vertical. Each of these classes has three possible values: compact, regular or any. The current device+orientation can be described as a combination of the sizes.
Having an application running at 60 FPS is every programmers dream, and users delight.
The worst users experience ever is a frozen and unresponsive screen. It’s a dreadful crime in mobile world nowadays. Users try to interact at any moment and according to Murphy’s law they will find all your mistakes. So, you better keep the main thread slim.
UIMotionEffects was first introduced in iOS 7. The WWDC session which presented this, amongst other cool things, is named Implementing Engaging UI on iOS. Nevertheless, UIMotionEffects is still overlooked. But not today, let’s make something cool with it.
Motion effects is an easy way to react to external variations on the device’s orientation. To say, UIKit performs UI changes whenever the user tilts the device, vertically or horizontally.
Let’s use UIInterpolatingMotionEffect a subclass of UIMotionEffects, with MapKit. Notice how appealing it is.