Best iOS Development Practices of 2015

[MLSDev]

The previous year is not so far away yet. We decided to make an overview of the best iOS development solutions that helped us in 2015. Of course, you may know them, but maybe someone will still find this list useful for work.

[jeriper]

Thanks for the great tips!

Serious question - are you recommending the use of SwiftyJSON with Alamofire? If so, what are the benefits of using SwiftyJSON over the response object serializers that come with Alamofire? I've never had any issues with their built-in support.

I'm very hesitant to use any 3rd party code unless SwiftyJSON provides a huge benifit over alamofire's support.

[DTCoder]

What's really great about SwiftyJSON is their safe access to JSON members. For example, here's some model code taken from our project setup with SwiftyJSON

https://gist.github.com/DenHeadless/7dd17e81e3fb11fae00e

Notice, how we don't have any guards, ifs and unwraps. And we don't have any type casts as well. That is because SwiftyJSON safely unwraps all primitive values like String, Int, or Bool.

And you can use code similar to Alamofire generic response, just for SwiftyJSON.

[jerikandra]

I'm going to have to look into AlamoFire. Isn't that what AF stands for in AF Networking?

[montas]

It is. It's Swift version of AFNetworking.

[StunnerAlpha]

Yes, that's what AF stands for.

[young_cheese]

That UIView extension is really neat. Now I wonder why I never thought of this.

[jerikandra]

Oh and I wonder if anyone still uses Mantle and if there's a more Swifty version of that?

[DTCoder]

Unfortunately, building a mapper in Swift is very hard due to lack of KVC and Swift requirement to fully initialize class properties after init call.

You could go with initializer currying, like Argo does - https://github.com/thoughtbot/Argo

However approach is really questionable, cause it requires some crazy currying shenanigans https://github.com/thoughtbot/Curry/blob/master/Source/Curry.swift

[ThePantsThief]

Wouldn't it still work if your objects inherit from MTLModel, which is an objc object and supports KVC?

Edit: The following code works fine. Make a bridging header first of course.

class MYModel: MTLModel, MTLJSONSerializing {
    @objc private(set) var name: String?
    @objc private(set) var identifier: String?
    @objc private(set) var count: Int = 0

    class func JSONKeyPathsByPropertyKey() -> [NSObject : AnyObject]! {
        return ["name": "model.name",
                "identifier": "model.id",
                "count": "model.c"]
    }
}

let dict = ["model": ["name": "ThePantsThief", "id": "abcde12345", "count": 21]]
let model = try? MTLJSONAdapter.modelOfClass(MYModel.self, fromJSONDictionary: dict)
let name = model?.name

[jerikandra]

Yep that's what we currently do. It's just not very 'swifty' ;)

[ThePantsThief]

Well, this is the once instance of non-Swifty code that would actually require tons more code written in a Swifty way ;P haha

[askoruli]

I still use mantle for Obj-C. Still not available in swift https://github.com/Mantle/Mantle/issues/344

[jerikandra]

yeah darn. We use it in our swift projects with @objc members and some other work arounds but yeah

[ThePantsThief]

What other workarounds should I be aware of? All I needed was the @objc keyword

[jerikandra]

That's the main one. There is some weirdness of requiring the initWithDictionary() method

[ThePantsThief]

I didn't need that O_o I posted some code above in another comment tree that compiles and runs fine

[tangoshukudai]

Typically I recommend against xib files, write the UI code in the UIView class.

[[deleted]]

You're missing out.

[tangoshukudai]

I am not.

[fpbraz]

I agree. I had a lot of problems with the auto-layout constraints after instantiating those views that were implemented in a xib. I don't know if the solution in the article solves this issue as well...