enum Season: String, Decodable {
    case spring, summer, autumn
}

In order to compose things nicely, you put the seasons into a struct:

struct Seasons: Decodable {
    var available: [Season]
}

The following JSON comes from the server, it gets decoded, everything works well:

"available": ["spring", "summer", "autumn"]
// [__lldb_expr_12.Season.spring, __lldb_expr_12.Season.summer, __lldb_expr_12.Season.autumn]

The application gets released. Time passes, winter comes and the app gets updated available seasons from the backend:

"available": ["spring", "summer", "autumn", "winter"]

What happens now? Your functionality breaks.
Since the app can’t understand Season.winter, no seasons get decoded. You receive a lot of bug reports, and your users are not happy ☹️

If only there was something we could do to prevent this from happening..
This seems like a nice use case for property wrappers!

@propertyWrapper
struct IgnoreUnknown<Value: Decodable>: Decodable {
    var wrappedValue: [Value]

    private struct Empty: Decodable {}

    init(from decoder: Decoder) throws {
        var container = try decoder.unkeyedContainer()
        self.wrappedValue = []
        while !container.isAtEnd {
            do {
                wrappedValue.append(try container.decode(Value.self))
            } catch {
                _ = try? container.decode(Empty.self)
            }
        }
    }
}

This way, we simply add @IgnoreUnknown before our available seasons and voilà! After that, the available array simply skips the values it cannot understand 🚀

struct Seasons: Decodable {
    @IgnoreUnknown
    var available: [Season]
}

Property Wrappers come with a lot of other great use cases. Please see Properties in Apple documentation for more details 🙂

Hope this blogpost was helpful, thanks for reading!

struct FormData {
    let name: String
    let age: Int
    let password: String
}

One issue we are going to come about is that our model is strict, it needs all the values at once, whereas users will supply each value at a time. First they will type in their name, then their age, and so on. Wrapping up the fields in Optional, may loosen its strictness.

struct FormData {
    let name: String?
    let age: Int?
    let password: String?
}

Our flow code might look like:

func firstStepFinished(with name: String) -> FormData {
    return FormData(name: name, age: nil, password: nil)
}

func secondStepFinished(with age: Int, partialFormData: FormData) -> FormData {
    return FormData(name: partialFormData.name, age: age, password: nil)
}

func thirdStepFinished(with password: String, partialFormData: FormData) {
    let formData = FormData(name: partialFormData.name, age: partialFormData.age, password: password)
    
    api.performLogin(with: formData)
}

However, now we need to guard against any nil values if we want to use them (for example, to make a network request).

guard let name = formData.name,
      let age = formData.age,
      let password = formData.password {
    return // what should we do here???
}

// use data

From a domain perspective, that return doesn’t make any sense.

One could argue that it’s “safe” to force unwrap in this case, or that there is already a nice approach to this problem.

One may say, “we can raise an error to the user” or “we could track it and check if users are getting stuck somehow”. But, at the end of the day, this is not a good solution because you know that when the flow ends, you have all the values.

Our model is “lying” to us. That’s not loosen, it’s just flawed.

There are several approaches to make it better, like “one model per step”:

struct FirstStep {
    let name: String
}

struct SecondStep {
    let name: String
    let age: Int
    
    init(firstStep: FirstStep, age: Int) {
        self.name = firstStep.name
        self.age = age
    }
}

struct ThirdStep {
    let name: String
    let age: Int
    let password: String
    
    init(secondStep: SecondStep, password: String) {
        self.name = secondStep.name
        self.age = secondStep.age
        self.password = password
    }
}

That’s better! But there is also another way of doing things that doesn’t involve duplication nor partial data structs.

Instead of breaking down our data structure, why not to break down functions?

Our FormData initializer, when interpreted as a function, has this shape:

(String, Int, String) -> FormData

But we can break it down into plain old lambdas¹, and by applying it to the initializer for our data structure:

(String) -> (Int) -> (String) -> FormData

This technique is called currying. What it does is, it allow us to translate the evaluation of a function that takes multiple arguments into evaluating a sequence of functions, each with a single argument.

func curry<A, B, C, D>(
    _ f: @escaping (A, B, C) -> D
) -> (A) -> (B) -> (C) -> D {
    return { a in { b in { c in return f(a, b, c) } } }
}

The function above goes from a function that takes multiple arguments (A, B, C) and produces a D, to single functions, that take one argument each: (A) -> (B) -> (C) and produces a D, making it possible to partially apply each argument, one at the time, until it can evaluate and return the output value.

Using it in our flow, may look like the following:

typealias Name = String
typealias Age = Int
typealias Password = String

typealias FromFirstStep = (Age) -> (Password) -> FormData
typealias FromSecondStep = (Password) -> FormData

func firstStepFinished(with name: String) -> FromFirstStep {
    let curried = curry(FormData.init) // (Name) -> (Age) -> (Password) -> FormData
    return curried(name) // (Age) -> (Password) -> FormData
}

func secondStepFinished(with age: Int, partialData: FromFirstStep) -> FromSecondStep {
    return partialData(age) // (Password) -> FormData
}

func thirdStepFinished(with password: String, partialData: FromSecondStep) {
    let formData = partialData(password)
    
    api.performLogin(with: formData)
}

I’ve added a few type aliases just to make it more readable. Cleaning up them further, we’ll have:

typealias FromThirdStep = FormData // just to be explicit
typealias FromSecondStep = (Password) -> FromThirdStep
typealias FromFirstStep = (Age) -> FromSecondStep

If you ask me, this is much better because we didn’t have to write anything else, other than the curry² function itself, which can be used in other places.

And that’s it! Functions have saved the day :)

P.S: I want to thank Sean Olszewski, Gordon Fontenot, Peter Tomaselli, Henrique Morbin, Marcelo Gobetti and João Rutkoski for their awesome review.

struct Person: Codable {
    let name: String
    let email: String
    let age: Int
}

Once the structure conforms to Codable everything works out of the box. There’s a nice way to test those structures and make sure that everything gets the exact JSON format that we aligned with backend.

Let’s create the following protocol in the test bundle:

protocol JSONTestable {
    init?(_ json: String)
    func json() -> String?
}

After that we can immediately provide an extension which conforms to that protocol in the test bundle:

extension JSONTestable where Self: Codable {
    init?(_ json: String) {
        guard
            let data = json.data(using: .utf8),
            let decoded = try? JSONDecoder().decode(Self.self, from: data)
            else { return nil }
        self = decoded
    }

    func json() -> String? {
        guard let data = try? JSONEncoder().encode(self) else { return nil }
        return String(data: data, encoding: .utf8)
    }
}

Then there’s only one simple step which needs to be done in the test bundle in order to test the structure: PersonTests.swift:

extension Person: JSONTestable {}

That’s it! Now we can easily test the result of the serialization and deserialization :)

Example tests:

final class PersonTests: XCTestCase {
    func testJsonSerialization() {
        let person = Person(name: "John Appleased", email: "john@appleased.com", age: 30)
        XCTAssertEqual(personJson, person.json()) // ✅
    }
    
    func testJsonDeserialization() {
        let person = Person(name: "John Appleased", email: "john@appleased.com", age: 30)
        XCTAssertEqual(person, Person(personJson)) // ✅
    }
}

private let personJson = """
{"name":"John Appleased","email":"john@appleased.com","age":30}
"""

extension Person: JSONTestable, Equatable {}

What do you think about this method? Is there anything which could be improved in this implementation? Please let us know :)

This technique is very useful when you want to abstract away third-party code (think UserDefaults), but there are instances where this is not enough. That’s the case when working with the camera.

On iOS, to use the camera, one has to use the machinery that comes with AVFoundation.

Although you can use protocols to generalize the real objects, at some point, you are going to stumble upon a dilemma: the simulator doesn’t have a camera, and you can’t instantiate the framework classes making the tests (almost) impossible.

What are you talking about?

Let’s start with a very simple program that captures QR Code (I’m skipping lots of boilerplate but if you are looking for a more thorough example, here you have a great article).

enum CameraError: Error {
    case invalidMetadata
}

protocol CameraOutputDelegate: class {
    func qrCode(read code: String)
    func qrCode(failed error: CameraError)
}

final class Camera: NSObject {
    private let session: AVCaptureSession
    private let metadataOutput: AVCaptureMetadataOutput
    private weak var delegate: CameraOutputDelegate?

    public init(
        session: AVCaptureSession = AVCaptureSession(),
        metadataOutput: AVCaptureMetadataOutput = AVCaptureMetadataOutput(),
        delegate: CameraOutputDelegate?
    ) {
        self.session = session
        self.metadataOutput = metadataOutput

        super.init()

        self.metadataOutput.setMetadataObjectsDelegate(self, queue: .main)
    }
}

extension Camera: AVCaptureMetadataOutputObjectsDelegate {
    public func metadataOutput(
        _ output: AVCaptureMetadataOutput,
        didOutput metadataObjects: [AVMetadataObject],
        from connection: AVCaptureConnection
    ) {
        guard let object = metadataObjects.first as? AVMetadataMachineReadableCodeObject,
              let code = object.stringValue, object.type == .qr else {
                delegate?.qrCode(failed: .invalidMetadata)
                return
        }

        delegate?.qrCode(read: code)
    }
}

When the detection happens, you can compute from framework-provided values, by implementing the following method from AVCaptureMetadataOutputObjectsDelegate. Say we want to exercise our program in a way that we ensure that the CameraOutputDelegate methods are properly called, given what AVFoundation provides.

final class CameraOutputSpy: CameraOutputDelegate {
    var qrCodeReadCalled: Bool?
    var qrCodePassed: String?
    var qrCodeFailedCalled: Bool?
    var qrCodeErrorPassed: CameraError?

    func qrCode(read code: String) {
        qrCodeReadCalled = true
        qrCodePassed = code
    }
    func qrCode(failed error: CameraError) {
        qrCodeFailedCalled = true
        qrCodeErrorPassed = error
    }
}

let delegate = CameraOutputSpy()

let camera = Camera(
    session: AVCaptureSession(),
    metadataOutput: AVCaptureMetadataOutput(),
    delegate: delegate
)

camera.metadataOutput(
    AVCaptureMetadataOutput(),
    didOutput: [AVMetadataMachineReadableCodeObject()], // error: 'init()' is unavailable
    from: AVCaptureConnection() //error: 'init()' is unavailable
)

Waat!?

The problem here is that all of these classes are concrete, so we can’t abstract them into an interface. Also they are supposed to be created and populated at runtime, hence you can’t init them.

🍸 Swizzle to the rescue

One possible solution for this kind of scenario (since the framework it’s all Objective-C…for now at least), is to use the Objective-C runtime shenanigans to “fill this gap”.

This is only possible because in Objective-C the method to call when a message is sent to an object is resolved at runtime.

I’m not going to lay down the nitty-gritty details about how it works, but the main idea (for the sake of this example) is to, at runtime, copy the implementation of NSObject.init and exchange it with some new fake init we are going to create.

struct Swizzler {
    private let klass: AnyClass

    init(_ klass: AnyClass) {
        self.klass = klass
    }

    func injectNSObjectInit(into selector: Selector) {
        let original = [
            class_getInstanceMethod(klass, selector)
        ].compactMap { $0 }

        let swizzled = [
            class_getInstanceMethod(klass, #selector(NSObject.init))
        ].compactMap { $0 }

        zip(original, swizzled)
            .forEach {
                method_setImplementation($0.0, method_getImplementation($0.1))
        }
    }
}

With that in hand, now we can:

1. Create a private init that will hold the implemetation of NSObject.init.
2. Create our “designated initializer”, capturing the parameters our test needs.
3. Do the swizzle dance.

final class FakeMachineReadableCodeObject: AVMetadataMachineReadableCodeObject {
    var code: String?
    var dataType: AVMetadataObject.ObjectType = .qr

    override var stringValue: String? {
        return code
    }

    override var type: AVMetadataObject.ObjectType {
        return dataType
    }

    // 1
    @objc private convenience init(fake: String) { fatalError() }

    private class func fake(fake: String, type: AVMetadataObject.ObjectType = .qr) -> FakeMachineReadableCodeObject? {
        let m = FakeMachineReadableCodeObject(fake: fake)
        m.code = fake
        m.dataType = type

        return m
    }

    // 2
    static func createFake(code: String, type: AVMetadataObject.ObjectType) -> FakeMachineReadableCodeObject? {
        // 3
        Swizzler(self).injectNSObjectInit(into: #selector(FakeMachineReadableCodeObject.init(fake:)))
        return fake(fake: code, type: type)
    }
}

Now, we can create a fake QR code payload in our tests and check if your implementation of AVCaptureMetadataOutputObjectsDelegate does what you expect it to.

let delegate = CameraOutputSpy()

let camera = Camera(
    session: AVCaptureSession(),
    metadataOutput: AVCaptureMetadataOutput(),
    delegate: delegate
)

camera.metadataOutput(
    QRMetadataOutputFake(), // plain ol' subclass, not really important
    didOutput: [
        FakeMachineReadableCodeObject.createFake(code: "interleaved2of5 value", type: . interleaved2of5)!
        FakeMachineReadableCodeObject.createFake(code: "QR code value", type: .qr)!
    ],
    from: AVCaptureConnection(
        inputPorts: [],
        output: AVCaptureOutput.createFake! // Another swizzle
  )
)

XCTAssertEqual(delegate.qrCodeReadCalled, true)
XCTAssertEqual(delegate.qrCodePassed, "QR code value")
XCTAssertNil(delegate.qrCodeFailedCalled)
XCTAssertNil(delegate.qrCodeErrorPassed)

As you can see, you can also check if your sut handles just QR code.

You can use this technique along side with other collaborators, like AVCaptureDevice, AVCaptureInput and AVCaptureOutput.

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.

Now, consider for a while the creation of an UIAlertView in iOS.

let alert = UIAlertView(title: "Question", message: "Do you like apples?", delegate: self, cancelButtonTitle: "I hate it!", otherButtonTitles: "Yes, I do!", "More of less")

This is a long method call, right? But really, that’s not the problem. The problem here is that our class has to conform to UIAlertViewDelegate in order to receive the alert result. Wouldn’t be nicer to have that logic encapsulated? Well, go back and read the definition for the builder pattern, it fits like a glove, am I right?

An idea on how to wrap the builder pattern around the UIAlertView class is as above:

class AlertBuilder: NSObject, UIAlertViewDelegate {

    typealias AlertBuilderCompletion = Int -> Void

    private var alertTitle: String = ""
    private var alertMessage: String = ""
    private var alertStyle: UIAlertViewStyle = .Default
    private var alertButtonTitles: [String] = []
    private var alertCompletion: AlertBuilderCompletion? = nil

    func title(title: String) -> AlertBuilder {
        alertTitle = title
        return self
    }

    func message(message: String) -> AlertBuilder {
        alertMessage = message
        return self
    }

    func style(style: UIAlertViewStyle) -> AlertBuilder {
        alertStyle = style
        return self
    }

    func buttonTitles(titles: String...) -> AlertBuilder {
        alertButtonTitles = alertButtonTitles + titles
        return self
    }

    func show(completion: AlertBuilderCompletion? = nil) {
        let alertView = UIAlertView()
        alertView.delegate = self
        alertView.title = alertTitle
        alertView.message = alertMessage
        alertView.alertViewStyle = alertStyle

        alertButtonTitles.forEach { title in
            alertView.addButtonWithTitle(title)
        }

        alertCompletion = completion
        alertView.show()
    }

    func alertView(alertView: UIAlertView, didDismissWithButtonIndex buttonIndex: Int) {
        alertCompletion?(buttonIndex)
    }
}

Now, all that is necessary to use create an alert is:

    alert.title("Question")
    .message("Do you like apples?")
    .buttonTitles("Yes, I do!","More of less", "I hate it!")
    .show { index in
        print(index)
    }

In the past, I would have used the first approach and lived with that. Of course, showing alerts to the user is a very tiny part of a real work application. But that’s preciselly where I was wrong. This kind of applicability of the builder (among all other design patterns) is what makes software components reusable. And there are some other places where you could apply the same principle, for example NSAttributedString or UIActionSheet.

I hope you find that useful. Builder to the rescue!

P.S: Yes, yes I know that Apple has released UIAlertController and deprecated both UIAlertView and UIActionSheet. However, the idea is pretty much the same, alothough what Apple did is Factory instead of a Builder.

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. Lets analyze those smart statements and put it into code so everyone can enjoy it:

func foo(@noescape code:(() -> String)) -> String
{
    return "foo \(bar(code))"
}

func bar(@noescape code:(() -> String)) -> String
{
    return code() 
}

print(foo() {"bar"})

It can be also captured in another @noescape closure:

func baz(@noescape code:(() -> String))
{
    qux {
        code()
    }
}
func qux(@noescape code:(() -> String)) {}

It’s important to point out, that closures (and functions) annotated with @noescape can only be passed as @noescape parameters. What this mean is:

• we cannot run it asynchronously:
• we can’t store it
• we can’t capture it in another non-@noescape closure

Last to mention, in the future releases this will be taken even further:

This enables control-flow-like functions to be more transparent about their behavior. In a future beta, the standard library will adopt this attribute in functions like autoreleasepool().

func autoreleasepool(@noescape code: () -> ()) {
    pushAutoreleasePool()
    code()
    popAutoreleasePool()
}

So dear developer the best is yet to come! ;]

void InitializeAudioSource(void *userAudioClass);
void PlayAudio();
void SetAudioGain(Float32 gain);

Will be converted into:

Void InitializeAudioSource(userAudioClass: UnsafeMutablePointer<Void>)
Void PlayAudio(Void)
Void SetAudioGain(gain:Float32)

And as far this is all pretty straightforward so now having our C CoreAudio implementation we can use it in our Swift project like that:

class KWSBackgroundStreamPlayer: NSObject {
    
    func setGain(gain : Float32) {
        
        SetAudioGain(gain)
    }
    
    func play() {
    
        PlayAudio()
    }
    
    func pause() {
    
        PauseAudio()
    }

    func close() {
    
        if self.trackClosed == true {
        
            return
        }
        
        self.trackClosed = true
       
        CloseAudio()
    }
    
    deinit {
        
        self.close()
    }
    
}

But because Swift is very strict when it comes to type checks we are no more able to pass our class to InitializeAudioSource function, if you try to do so:

InitializeAudioSource( &self )

You will end up with this error:

And this is were the bad hacks come in. Unfotunately we need to get a “true” raw pointer to be able to pass it back to C code and to so we need this piece of code:

//convert self to unmanaged object
let anUnmanaged = Unmanaged<KWSBackgroundStreamPlayer>.passUnretained(self)
//get raw data pointer
let opaque: COpaquePointer = anUnmanaged.toOpaque()
//convert to Mutable to match Swift safe type check
let voidSelf = UnsafeMutablePointer<Void>(opaque)
            
InitializeAudioSource( voidSelf )

And that’s how you pass Swift classes and objects to C code, and you will need to do it every time you need a void or any other fancy pointer on C side.

What happens here is that we first take an Unmanaged version of our class object this tells compiler that we are now responsible for memory management, and stops doing retain release magic under the hood for us. But still this is not enough, now we need a raw memory pointer from that unmanaged object and thats where toOpaque() comes in. This will return an raw C pointer of our class object. This is the true void * pointer. COpaquePointer is memory representation of something that cannot be represented in Swift so you should be very careful when playing with this kind of pointers. Now we just need to make it a proper type in this case UnsafeMutablePointer with <Void> class type. Every UnsafePointer have constructor that takes COpaquePointer so you have to be sure you are choosing proper type when creating it as there is no type check at this point!

Hopefully on C side it’s easy to convert void pointer to proper class type, you just need to use bridge to do so:

void InitializeAudioSource(void *userAudioClass)
{
	//bridge it back to our class 
    KWSBackgroundStreamPlayer *backgroundPlayer = (__bridge KWSBackgroundStreamPlayer*)userAudioClass;

    //get some properties
    NSString *path = backgroundPlayer.filePath;
    repeatSong = backgroundPlayer.repeatSong;
      
    //...    
   
    //we can even pass it as parameter with proper pointer type
    OSStatus result = AudioQueueNewOutput(&dataFormat, BufferCallback, (__bridge void *)(backgroundPlayer), nil, nil, 0, &queue);
   
    //... 
}

I hope this will help people understand a bit more about how danger may be playing with C in Swift and vice versa. Using Unmanaged and COpaquePointer may lead to crashes and memory leaks, as in some cases you are again responsible for manual memory managment, you are able to get raw pointers with no type that can be casted to whatever you want and so on.

Overall this is a powerful magic you can do in Swift but as someone said: “With Great Power Comes Great Responsibility” ;)

Example usage available on github

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. It can be used in any kind of game! Strategy, board, rpg, race. I built§ a small demo project to show this in details but now let’s focus on basics:

Pros:

1. It’s simple!
2. Works with any device
3. No need to pair, login etc. Just come near other phone

Cons:

1. Bandwith (approx 30bytes of data per packet which todays is nothing)
2. Limited distance (work well in approx 20m range)

We have our interface class that will be used to extend functionality on both server and client logic (we use central and peripheral mode of our phone)

enum KWSPacketType : Int8 {
    
    case HearBeat
    case Connect
    case Disconnect
    case MoveUp
    case MoveDown
    case Jump
    case Attack
    case DefenseUp
    case DefenseDown
    case Restart
    case GameEnd
}

protocol KWSBlueToothLEDelegate: class {

    func interfaceDidUpdate(interface interface: KWSBluetoothLEInterface, command: KWSPacketType, data: NSData?)
}

class KWSBluetoothLEInterface: NSObject {
    
    weak var delegate : KWSBlueToothLEDelegate?
    weak var ownerViewController : UIViewController?

    var interfaceConnected : Bool = false

    init(ownerController : UIViewController, delegate: KWSBlueToothLEDelegate) {
        
        self.ownerViewController = ownerController
        self.delegate = delegate
        super.init()
    }
    
    func sendCommand(command command: KWSPacketType, data: NSData?) {
        
        self.doesNotRecognizeSelector(Selector(__FUNCTION__))
    }
}

As you can see, it’s very simple - one send and one receive method as delegate. As both recive and send arguments, we can get the command used in your game to recognize packet type and data which will come along with this command.

Now we need to implement our server and client logic, i don’t want to describe in details how to setup BluetoothLE on iPhone so insted I will highlight only important methods like receiving and sending packet on both client and server side.

KWSBluetoothLEClient

class KWSBluetoothLEClient: KWSBluetoothLEInterface, CBPeripheralManagerDelegate  {
  
 	override func sendCommand(command command: KWSPacketType, data: NSData?) {
    
        if !interfaceConnected {
        
            return
        }
        
        var header : Int8 = command.rawValue
        let dataToSend : NSMutableData = NSMutableData(bytes: &header, length: sizeof(Int8))
        
        if let data = data {
        
            dataToSend.appendData(data)
        }
        
        if dataToSend.length > kKWSMaxPacketSize {
            
            print("Error data packet to long!")
            
            return
        }
        
        self.peripheralManager.updateValue( dataToSend,
                         forCharacteristic: self.readCharacteristic,
                      onSubscribedCentrals: nil)
        
  }

 	func peripheralManager(peripheral: CBPeripheralManager, didReceiveWriteRequests requests: [CBATTRequest]) {
        
        if requests.count == 0 {
            
            return;
        }
        
        for req in requests as [CBATTRequest] {
        
            let data : NSData = req.value!
            let header : NSData = data.subdataWithRange(NSMakeRange(0, sizeof(Int8)))
            
            let remainingVal = data.length - sizeof(Int8)
            
            var body : NSData? = nil
            
            if remainingVal > 0 {
            
                body = data.subdataWithRange(NSMakeRange(sizeof(Int8), remainingVal))
            }
            
            let actionValue : UnsafePointer<Int8> = UnsafePointer<Int8>(header.bytes)
            let action : KWSPacketType = KWSPacketType(rawValue: actionValue.memory)!
            
            self.delegate?.interfaceDidUpdate(interface: self, command: action, data: body)
            
            self.peripheralManager.respondToRequest(req, withResult: CBATTError.Success)
        }
  }
}

KWSBluetoothLEServer

class KWSBluetoothLEServer: KWSBluetoothLEInterface, CBCentralManagerDelegate, CBPeripheralDelegate {

    override func sendCommand(command command: KWSPacketType, data: NSData?){
        
        if !interfaceConnected {
            
            return
        }

        var header : Int8 = command.rawValue
        let dataToSend : NSMutableData = NSMutableData(bytes: &header, length: sizeof(Int8))
        
        if let data = data {
            
            dataToSend.appendData(data)
        }
        
        if dataToSend.length > kKWSMaxPacketSize {
            
            print("Error data packet to long!")
            
            return
        }
        
        if let discoveredPeripheral = self.discoveredPeripheral {
        
            discoveredPeripheral.writeValue( dataToSend,
                          forCharacteristic: self.writeCharacteristic,
                                       type: .WithResponse)
        }
    }
  
    func peripheral(peripheral: CBPeripheral, didUpdateValueForCharacteristic characteristic: CBCharacteristic, error: NSError?) {
        
        if let error = error {
            print("didUpdateValueForCharacteristic error: \(error.localizedDescription)")
            return
        }
        
        let data : NSData = characteristic.value!
        let header : NSData = data.subdataWithRange(NSMakeRange(0, sizeof(Int8)))
        
        let remainingVal = data.length - sizeof(Int8)
        var body : NSData? = nil
        
        if remainingVal > 0 {
            
            body = data.subdataWithRange(NSMakeRange(sizeof(Int8), remainingVal))
        }

        let actionValue : UnsafePointer<Int8> = UnsafePointer<Int8>(header.bytes)
        let action : KWSPacketType = KWSPacketType(rawValue: actionValue.memory)!
        
        self.delegate?.interfaceDidUpdate(interface: self, command: action, data: body)
    }
}

In both cases sending and reciving is the same:

Sending:

1. Take raw value of the command
2. Save into NSData
3. Append using additional data that comes with the command
4. Send to peripheral/central

Receive:

1. Take NSData from central / peripheral (update request status if needed)
2. Get first byte to recognize command type
3. Take subset of Data by removing 1st byte and store it as value coming along with command
4. Take value of header byte and cast it to our PacketType
5. Send it to delegate

Thanks to that we can build our game logic like this:

Setup:

func setupGameLogic(becomeServer:Bool) {
    
        self.isServer = becomeServer
        
        if self.isServer {
            
            self.communicationInterface = KWSBluetoothLEServer(ownerController: self, delegate: self)
        }
        else {
            
            self.communicationInterface = KWSBluetoothLEClient(ownerController: self, delegate: self)
        }
   
}

Sending data to other player:

//player is dead notify other player
self.communicationInterface!.sendCommand(command: .GameEnd, data: nil)

//send some basic data about your player state (life, position)

let currentPlayer = self.gameScene.selectedPlayer
        
    var packet = syncPacket()
        packet.healt = currentPlayer!.healt
        packet.posx = Float16CompressorCompress(Float32(currentPlayer!.position.x))
        
    let packetData = NSData(bytes: &packet, length: sizeof(syncPacket))
    self.communicationInterface!.sendCommand(command: .HearBeat, data: packetData)

//send some other info 

let directionData = NSData(bytes: &currentPlayer!.movingLeft, length: sizeof(Bool))
self.communicationInterface!.sendCommand(command: .MoveDown, data: directionData)

Reciving data:

func interfaceDidUpdate(interface interface: KWSBluetoothLEInterface, command: KWSPacketType, data: NSData?)
{

	switch( command ) {
  
	case .HearBeat:
	if let data = data {
                
		let subData : NSData = data.subdataWithRange(NSMakeRange(0, sizeof(syncPacket)))
		let packetMemory = UnsafePointer<syncPacket>(subData.bytes)
		let packet = packetMemory.memory
                
		self.gameScene.otherPlayer!.healt = packet.healt
		self.gameScene.otherPlayer!.applyDamage(0)
                
		let decoded = Float16CompressorDecompress(packet.posx)
		let realPos = self.gameScene.otherPlayer!.position
		let position = CGPointMake(CGFloat(decoded), CGFloat(realPos.y))
                
		self.gameScene.otherPlayer!.position = position
	}

	case .Jump:
		self.gameScene.otherPlayer!.playerJump()

	case .Restart:
		self.unlockControls()
            
	case .GameEnd:
		self.lockControls()
        
	}
}

And i get some pretty promising results:

Game works smoothly, there are no lags in connection and you can play almost instantly! And of course it allows you to integrate mutliplayer in your game in few minutes.

If you are starting your journey with gamedev or iOS and plan to build simple SpriteKit game with some basic multiplayer support it may be worth considering this option.

Demo project used to present the mechanics is available as always on github

Game require at least two iPhone 5 to test and play. To start simply open game, one of the players choose server, other one client mode and bring your phone next to each another. Once you do that you should be notified about successfull connection by tone sound.

For those who have some experience with this integration knows that casting plays an important role. So, todays hint will dig into an poor documented protocol called _ObjectiveCBridgeable.

The documentation, which is only founded in header files says:

A Swift Array or Dictionary of types conforming to _ObjectiveCBridgeable can be passed to Objective-C as an NSArray or NSDictionary, respectively. The elements of the resulting NSArray or NSDictionary will be the result of calling _bridgeToObjectiveC on each element of the source container.

Ok, but there is something else you can do with that, which is very handy.

Suppose that you have this class in Objective-C:

@interface OPerson: NSObject

- (instancetype)initWithName:(NSString *)name surname:(NSString *)surname;

@property (nonatomic, copy) (NSString *)name;
@property (nonatomic, copy) (NSString *)surname;

@end

Now you want to easily cast this class into a Swift struct. Yes, we can! All you have to do is conform to _ObjectiveCBridgeable, like so:

struct Person {
        let name: String
        let surname: String
}

extension Person: _ObjectiveCBridgeable {

    typealias _ObjectiveCType = OPerson

    static func _isBridgedToObjectiveC() -> Bool {
            return type
    }

    static func _getObjectiveCType() -> Any.Type {
            return ObjectiveCType.self
    }

    func _bridgeToObjectiveC() -> _ObjectiveCType {
            return OPerson(name: name, surname: surname)
    }

    static func _forceBridgeFromObjectiveC(source: _ObjectiveCType, inout result: Person?) {
            result = Person(name: source.name, surname: source.name)
    }

    static func _conditionallyBridgeFRomObjectiveC(source: _ObjectiveCType, inout result: Person?) -> Bool {
            _forceBridgeFromObjectiveC(source, result: &result)
            return true
    }
}

And voilá!

let objcPerson = OPerson(name: "John", surname: "Doe")

if let swiftPerson = objcPerson as? Person {
	//will work
}

let swiftPerson = objcPerson as Person //this too!

let swiftPerson2 = Person(name: "Jack", surname:"Doe")
let objcPerson = swiftPerson2 as OPerson //and that

let person: OPerson = Person(name: "Alfred", surname: "Doe") //hooray

Oh, that’s so beautiful, don’t you think? :]

The best thing is that storyboards and nib files support these size classes. We can make layout changes directly onto them. Every view or auto-layout constraint can exist in one or several other size classes. So it is possible to support multiple devices and orientations without any code. Nevertheless there is a case, which is not covered at all. Imagine that you support only portrait mode and the designer wishes to make a difference between iPhone 5 and iPhone 6+ screen. In this case, size classes are not much helpful. However, we can leverage them in an unusual way.

UITraitEnvironment is a protocol which provides access to trait collection. Its conformed by most of the objects in view hierarchy: UIScreen, UIWindow, UIViewController, UIView. Every child inherits the trait collection object from its parent. The trick is to override the trait collection in UIWindow and return a custom value for iPhone 6+ device. Take a look:

@objc public class Window: UIWindow {

    override public var traitCollection: UITraitCollection {

        if DeviceType.isIPhone6P {

            var collections = [UITraitCollection(horizontalSizeClass: .Compact),
                UITraitCollection(verticalSizeClass: .Compact)]

            return UITraitCollection(traitsFromCollections: collections)
        }

        return super.traitCollection
    }
}

We override trait collection in UIWindow just for iPhone 6+ model. Now we can make layout changes in storyboard directly for this model by changing size class selectors at the bottom of Interface Builder pane. Trait collection with horizontal compact class and vertical compact class is reserved for iPhone 6+.

We can install additional views and change layout constraints only for iPhone 6+.

Tell your designer about that cool hint and you will probably get some treats. The project shown above can be found on GitHub.

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. To keep things smoothly in the users interface, every single operation that’s schedule to run into the main thread can take longer than 16 milliseconds, and there’s a handy solution to get you covered. It’s a little library called Watchdog.

Watchdog is a very simple and straightforward library that logs excessive blocking on the main thread. Let’s take a look at how to use it:

let watchdog = Watchdog(0.2)

Just instantiate it with a number of seconds that you want for Watchdog to consider that the main thread blocked. Also don’t forget to retain Watchdog somewhere or it will get released when it goes out of scope. Whenever the main thread is blocked for more than the value previously defined, it will print out logs, just like this:

👮 Main thread was blocked for 1.25s 👮

Pretty nice debugging tool!

Every time a new translation comes, it’s necessary to run the application and check for broken layouts. Take this quite simple UI.

Simple, huh?

All right, here’s what you have to do to get covered with future translations, and avoid autolayout nightmares.

Add -NSDoubleLocalizedStrings YES to Arguments Passed On Launch to the Run section at your Project Schemes.

This argument will duplicate all strings loaded using NSLocalizedString.

What’s better then that? What about finding out unlocalized strings?

So, -NSShowNonLocalizedStrings YES comes to rescue!

Great! Now you go and get yourself a cup of coffee while the translation team does their job :)

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.

Sweet, right?

Achieving it, is easier than you think. Just a few lines of code and you’re good to go:

var horizontalMotionEffect = UIInterpolatingMotionEffect(keyPath: "center.x", type: .TiltAlongHorizontalAxis)
horizontalMotionEffect.minimumRelativeValue = -100
horizontalMotionEffect.maximumRelativeValue = 100

mapView.addMotionEffect(horizontalMotionEffect)

Think of minimumRelativeValue and maximumRelativeValue as leading and tralling constraints, respectivily, to its superview.

That’s why you have to create the UIView, MKMapView in this case, outside its superviews bounds. Like so:

As the user tilts the device, UIInterpolatingMotionEffect translates the fixed offset values returned by the system to the range of specified values, then UIKit applies the translated values to any target views.

Don’t forget about this! Details matters and it’s what users love in mobile apps!

Unable to simultaneously satisfy constraints.
Probably at least one of the constraints in the following list is one you don't want.
Try this:

(1) look at each constraint and try to figure out which you don't expect;
(2) find the code that added the unwanted constraint or constraints and fix it.
(Note: If you're seeing NSAutoresizingMaskLayoutConstraints that you don't understand, refer to the documentation for the UIView property translatesAutoresizingMaskIntoConstraints)

(...........)


Make a symbolic breakpoint at UIViewAlertForUnsatisfiableConstraints to catch this in the debugger.
The methods in the UIConstraintBasedLayoutDebugging category on UIView listed in <UIKit/UIView.h> may also be helpful.

That’s a huge log! And I cut off the NSLayoutConstraint part. Yet, the second last line is giving a clue in which direction to go to fix this issue. Symbolic breakpoint at UIViewAlertForUnsatisfiableConstraints.

All right, here’s what Xcode want’s you to do:

Honestly, that won’t help much, because basically it’ll just stop the execution and leave you up with LLDB, alone in the dark.

But there’s a little trick you can do to enhance the preceding symbolic breakpoint. Adding po [[UIWindow keyWindow] _autolayoutTrace] to it (for Obj-C projects) or expr -l objc++ -O -- [[UIWindow keyWindow] _autolayoutTrace] (for Swift projects).

Now, on console, you’ll see all the UIView hierarchy and exactly where it has ambiguity.

UIWindow:0x7f9481c93360
|   •UIView:0x7f9481c9d680
|   |   *UIView:0x7f9481c9d990- AMBIGUOUS LAYOUT for UIView:0x7f9481c9d990.minX{id: 13}, UIView:0x7f9481c9d990.minY{id: 16}
|   |   *_UILayoutGuide:0x7f9481c9e160- AMBIGUOUS LAYOUT for _UILayoutGuide:0x7f9481c9e160.minY{id: 17}
|   |   *_UILayoutGuide:0x7f9481c9ebb0- AMBIGUOUS LAYOUT for _UILayoutGuide:0x7f9481c9ebb0.minY{id: 27}

Note that as you hit continue it’ll stop at every ambiguous layout you may have. And if that’s not enough for you to find out your autolayout issue, try changing the view’s color, who knows?

(lldb) expr ((UIView *)0x7f9ea3d43410).backgroundColor = [UIColor redColor]
(UICachedDeviceRGBColor *) $1 = 0x00007f9ea3d43410

Fear no more young Padawan, make symbolic breakpoints and LLDB work for you!

I would like to thank Porter Hoskins for pointing out the correct LLDB command for Swift.

Besides of helpfull UserInfo object keys which give us comprehensive text information about progress of our tasks in proper language, NSProgress was supposed to provide us way of compositioning objects into trees. However, first version of class allowed this in an implicit way which does not look very clear first time you learn it. I will try to present it to you in a short way:

let parentProgress = NSProgress()
parentProgress.totalUnitCount = 2
parentProgress.becomeCurrentWithPendingUnitCount(1)

let childProgress = NSProgress(totalUnitCount:1)
parentProgress.resignCurrent()

When applying this approach you have to create child progress using totalUnitCount convenience constructor immediately. You also should document that you support implicit composition in a clear way.

OSX 10.11 and iOS 9.0 provides more explicit way for creating tree structure of NSProgress objects. Things are simple now:

let parentProgress = NSProgress()
let childProgress = NSProgress()
parentProgress.addChild(childProgress, withPendingUnitCount:1)

There is also one more thing useful thing in process of forwarding progress through our app architecture. When any of your classes is free to attend in NSProgress family tree, simply implement following protocol:

protocol NSProgressReporting : NSObjectProtocol {
    var progress: NSProgress { get }
}

This way we are able to easily track progress of tree structure of tasks and get our overall progress in an easy, object oriented way.

You can use sql database function strftime to get UNIX time from e.g.: ISO8061 date string.

Here is the magic function:

+ (NSArray *)parseDatesUsingStringArray:(NSArray *)stringsArray
{
    sqlite3 *db = NULL;
    sqlite3_open(":memory:", &db);
    
    sqlite3_stmt *statement = NULL;
    sqlite3_prepare_v2(db, "SELECT strftime('%s', ?);", -1, &statement, NULL);
    
    NSMutableArray *datesArray = [NSMutableArray array];
    
    for (NSInteger i = 0; i < stringsArray.count; i++)
    {
        NSString *dateString = stringsArray[i];
        
        sqlite3_bind_text(statement, 1, [dateString UTF8String], -1, SQLITE_STATIC);
        sqlite3_step(statement);
        
        kTimeStamp value = sqlite3_column_int64(statement, 0);
        NSDate *date = [NSDate dateWithTimeIntervalSince1970:value];
        
        [datesArray addObject:date];
        
        sqlite3_clear_bindings(statement);
        sqlite3_reset(statement);
    }
    
    sqlite3_close(db);
    
    return datesArray;
}

We will use it to replace standard parsing method like this:

var datesFromNSDateFormatter:[NSDate] = []

for string in stringsArray {              
	datesFromNSDateFormatter.append(NSDateFormatter.dateFromISOString(string))
}

I did some measurements using iPhone 5S with iOS8.2 in release configuration running exactly same amount of data (One Milion strings with ISO8601 date)

And here are the results:

Time elapsed for NSDateFromatter parsing: 73.7988719940186 s
Time elapsed for SQLDateFormatter parsing: 8.51147103309631 s

So using SQL to format string into date is pretty fast but acutally slower than objC version (But still at least 10time faster than regular method) So what about Swift?. Nothing really changed, overall results show faster computation but I’m using better CPU so NSDateFormatter is still very very slow… If you like it, sample source code is available on Github

let sharedApplication = UIApplication.sharedApplication()
let delegate = sharedApplication.delegate
if let delegate = delegate as? AppDelegate {
    delegate.doSomething()
}

There are too many temporary objects, and presumably, there’s no reason why this class should know about AppDelegate casting and so on.

Using the Decorator pattern, is a way to wrap up this logic and decouple stuff.

extension UIApplication {
    class func myDelegate() -> AppDelegate {
        return (self.sharedApplication().delegate as! AppDelegate)
    }
    class func doSomething() {
        myDelegate().doSomething()
    }
}

extension AppDelegate {
    class func doSomething() {
        UIApplication.doSomething()
    }
}

Now the class would just call UIApplication.doSomething() or AppDelegate.doSomething().

Another situation that’s a claimer for LoD is when you have chained ‘get’ statements, for example:

let myDesire = Metallica().gimmeFuel().gimmeFire().gimmeThatWhichIDesire()

In such a case, the Metallica class should be refactored and provide it with a mean of calling Metallica().gimmeThatWhichIDesire(), for example:

class Metallica {
    func fuelSetOnFire(fuel: Fuel) -> Fire {
    	return Fire.setFuelOnFire(fuel)
    }
    
    func gimmeThatWhichIDesire() -> Desire {
        return Desire.fromFire(fuelSetOnFire(metallicasFuel))
    }
}

Wrapping up method calls, separating concerns and decoupling classes are the spine of LoD. Some can say that objects become more complex, but one thing is for sure, your software components will be more testable, and that is a big win!

Now go ahead and follow the rule!

To keep this blog post short, I’ve created a simple script that checks which build configurations were used:

echo "note: Starting script phase.”
echo "warning: testing for Debug target"

if [ "Debug"= "${CONFIGURATION}" ];
then
    echo "error: please run this script on Release target"
else
    echo "warning: running on Debug target"
fi

Please, take a look in every echo at note:, warning: and error: prefixes. When XCode recognizes any of these tags, the proper indicator will show up in Report Navigator and of course at the top bar:

Pay attention to the colon at the end of each tag. Tags can be placed anywhere in the message.

override func collectionView(collectionView: UICollectionView, 
    moveItemAtIndexPath sourceIndexPath: NSIndexPath, 
    toIndexPath destinationIndexPath: NSIndexPath) {
    // move your data order
}

The collection view infers that items can be moved because moveItemAtIndexPath is overrired.

Things go complicated when we want to use a simple UIViewController with collection view. We also need to implement UICollectionViewDataSource methods mentioned above, but we need to rewrite installsStandardGestureForInteractiveMovement. No worries, it’s also easily supported.UILongPressGestureRecognizer is a continuous gesture recognizer and fully supports panning.

override func viewDidLoad() {
    super.viewDidLoad()

            longPressGesture = UILongPressGestureRecognizer(target: self, action: "handleLongGesture:")
        self.collectionView.addGestureRecognizer(longPressGesture)
}

    func handleLongGesture(gesture: UILongPressGestureRecognizer) {
        
        switch(gesture.state) {
            
        case UIGestureRecognizerState.Began:
            guard let selectedIndexPath = self.collectionView.indexPathForItemAtPoint(gesture.locationInView(self.collectionView)) else {
                break
            }
            collectionView.beginInteractiveMovementForItemAtIndexPath(selectedIndexPath)
        case UIGestureRecognizerState.Changed:
            collectionView.updateInteractiveMovementTargetPosition(gesture.locationInView(gesture.view!))
        case UIGestureRecognizerState.Ended:
            collectionView.endInteractiveMovement()
        default:
            collectionView.cancelInteractiveMovement()
        }
    }

We stored selected index path obtained in long press gesture handler and depending on wether it has any value we allow to pan gesture to kick in. Then, we call some new collection view methods accordingly to the gesture state:

• beginInteractiveMovementForItemAtIndexPath(indexPath: NSIndexPath) which starts interactive movement for cell at specific index path
• updateInteractiveMovementTargetPosition(targetPosition: CGPoint) which updates interactive movement target position during gesture
• endInteractiveMovement() which ends interactive movement after you finish pan gesture
• cancelInteractiveMovement() which cancels interactive movement

And this makes handling pan gesture obvious.

The behavior is the same as with standard UICollectionViewController. Really cool, but what makes it even cooler is that we can apply reordering to collection view with our custom collection view layout. Check interactive movement with simple waterfall layout.

Uhm, looks cool, but what if we don’t want to change cell size during movement? Selected cell size during interactive movement should remain the same. This is possible. UICollectionViewLayout also gets additional methods to handle reordering.

func invalidationContextForInteractivelyMovingItems(targetIndexPaths: [NSIndexPath], 
    withTargetPosition targetPosition: CGPoint, 
    previousIndexPaths: [NSIndexPath], 
    previousPosition: CGPoint) -> UICollectionViewLayoutInvalidationContext

func invalidationContextForEndingInteractiveMovementOfItemsToFinalIndexPaths(indexPaths: [NSIndexPath], 
    previousIndexPaths: [NSIndexPath], 
    movementCancelled: Bool) -> UICollectionViewLayoutInvalidationContext

The former is called during the cells interactive movement with target and previous cell’s indexPaths. The next one is similar, but it’s called just after interactive movement ends. With this knowledge we can achieve our requirement using one little trick.

internal override func invalidationContextForInteractivelyMovingItems(targetIndexPaths: [NSIndexPath],
    withTargetPosition targetPosition: CGPoint, 
    previousIndexPaths: [NSIndexPath], 
    previousPosition: CGPoint) -> UICollectionViewLayoutInvalidationContext {

    var context = super.invalidationContextForInteractivelyMovingItems(targetIndexPaths, 
        withTargetPosition: targetPosition, previousIndexPaths: previousIndexPaths, 
        previousPosition: previousPosition)

    self.delegate?.collectionView!(self.collectionView!, moveItemAtIndexPath: previousIndexPaths[0], 
        toIndexPath: targetIndexPaths[0])

    return context
}

Solution is straightforward. Grab previous and target index paths of currently moving cell. Then call UICollectionViewDataSource method to move this items around.

Without a doubt, a collection view reordering is a fantastic addition. UIKit engineers made awesome job! :)

P.S: I would like to thanks Douglas Hill for hinting out some improvements in our code. Thanks Douglas, keep up the good work!

iOS has some gotchas regarding multithread, things that if you don’t respect, may cause your application to crash or hang the users interface, for example:

• Animations outside the main thread, may crash the application.
  
• Performing network requests on the main thread, will hang the users interface.
  

We can solve those situations by using the so called Symbolic Breakpoints and share those breakpoints with your team. Thereby, every developer can take advantage of that, and get notified, when they occur.

To help you out, we created a bunch of shared breakpoints and integrate them into your project is very easy:

• Go to your .xcodeproj or .xcworkspace file, right click on it, and choose Show Package Contents.
  
• Open the folder xcshareddata, then xcdebugger (create them if not exists).
  
• Breakpoints are saved into Breakpoints_v2.xcbkptlist.
  
• Now you just have to paste the following content into the <Breakpoints> node.

(We could also add those by using LLDB commands, but those won’t show up on the Breakpoints navigator)

Our list of useful breakpoints is available here

Now, whenever the breakpoint conditions are satisfied, you’ll be notified and will have a chance to quickly fix your code, before it crashes into the users hand!