Generating Core Data Swift

The Xcode generated NSManagedObject subclasses are annoying me. While they generate as a pair of files where you can add things to the main class and the @NSManaged variables are generated in an extension in a separate file so that they can be be overwritten and replaced as the model is updated without affecting the file where you make your changes unfortunately there is a big deficiency from my point of view in that the model type information does not get fully carried through to the Swift objects.

Insufficiently Typed

There are two generation options, with "Use scalar properties for primitive data types" you get usefully typed integers, floats, doubles and bools but lose the expression to express optionals/nil values. This is presumably due to the limitations of the Objective-C based API. It also expresses date types as NSTimeIntervals (Doubles) rather than NSDates.  The other option will generate with objects so you will get NSDates but for number values and Booleans you will get NSNumbers which lose information about whether it is a floating point type, integer or boolean.

Other Issues

Swift 2 (Xcode 7 GM at least) Generic support for @objc protocols

Just had a response to a radar (thanks Apple Swift team) that you can now implement Objective C protocols with generic Swift classes. This means that you can make typesafe and composable classes to do much of the work for many UI objects without ugly wrapping code and indirection.

This example shows a really basic example and should work in a playground.

In production code I would not initialise the table view cells in the closure but would make the closure but would probably take either the table view as an argument and directly dequeue cells from it or would take the cell as the argument and only configure it in the closure. Still this approach allows much of the boiler plate and common code to be abstracted. The next level may use a similar approach to make each section and an array of such structures could be used to make the whole table (or collection) view.

There is still work for the Swift team to do as I don't think that you can implement the Objective C protocol in an extension to a generic yet. I can't think of a reason why it wouldn't be possible and I'm confident it is coming.

Update: It should work in a protocol. I'm not sure if I'm currently doing something wrong or if it is Swift compiler bug yet:

Swift Performance - iOSDevUK

I presented today at iOSDevUK in Aberystwyth with some more material on Swift Performance and how to profile Swift. Also on wrapping classes in value types. Unfortunately much of the presentation was a demo and there is no video but I'm posting the materials here and will try to make a follow up post covering some more of the details in the next week or two (no promises).

Slides (note that slides a terrible communication mechanism and caveats and subtleties in the talk may be lost):

Unexpected Assertion Behaviour - Radar 21826180

Apologies for the lack of posts, full time work and family time among other things have been keeping me from finishing off Swift performance stuff. The new Swift 2.0 features look really good but again I haven't got stuck in yet. This is a quick post about an issue concerning me since I noticed it when reading Erica Sadun's post about assertions. I actually thought it couldn't be correct when I first read it so unexpected was it but when I checked the documentation it matched exactly what Erica said.

Assertions and Unchecked Builds

I use assertions for things that shouldn't happen but sometimes might. For example corrupt or unprocessable network data where I write code to safely handle the case but I also want to know instantly and start debugging the issue (whether it is in the app or the server). If you do the same and have assertions which could happen then you must not build in -Ounchecked (or in Swift 2.0 with Disable Safety Checks enabled) otherwise in the event of assertions not being true you will be in undefined behaviour.

How Swift is Swift?

Slides, video and links related to my Swift Summit talk on Swift performance. Video should be available later is now available and it might be worth watching Airspeed's talk that preceded mine before watching it when it is available I'm also expecting a blog post from him shortly on his static vs. compile time talk which is also highly relevant to optimisation.

The key point in Swift is that as the compiler gets better there is no need to choose between nice code and fast code. With a little thought and knowledge it is usually possible to get close to the speed of lowish level C code with nice abstractions. Some may say that C++ is there already but I enjoy writing Swift code much more and C++ is hampered by it's C legacy and choices made many years ago (for good reasons) from becoming a truly nice language in my view (non-Nullable by default would be hard to retrofit for example).

There were also many other excellent talks at Swift Summit, and all were at least good. I'm looking forward to watching several again.

Simple Library Free JSON Parsing in Swift

Parsing JSON in Swift without adding libraries could be tricky and annoying at least until nil coalescing was added and optional chaining was upgraded late in the original betas but that really isn't the case at least since Swift 1.0 was final. There are clearly a wide range of JSON libraries for Swift ranging from SwiftyJSON which just tidies up extractions from deep in nested structures to Argo which will feel comfortable for those coming from Haskell and look clever but be hard to read for those not familiar with the syntax.

I want to show people that there is really nothing very tricky or ugly about parsing JSON data in Swift even without libraries to help.

This post was trigger by seeing Jameson Quave's new lightweight Luma library and the syntax in the project readme (at the time of writing) would work without a added library on the result of parsing with Cocoa's included NSJSONSerialization class. Please note that there is nothing wrong with the Luma library or anything I have seen written about it but I wanted to make clear how lightweight it is and how easy these things are to do without using a library at all.

I confirmed that the syntax was available in the Playground without using the library and there is no problem just using exactly the same syntax on the dictionary you get back from NSJSONSerialization as in the Luma example. The only difference in the presentation of printing the parsed structures.

Overcoming Swift Resistance Explored

This post is a response to David Owens' Swift Resistance Explored post.

First I want to acknowledge that Swift Debug builds are hideously slow. This isn't news to me or anyone who has seen my talk on Swift optimisation. To be clear this is a problem which Apple have said that they are working on but I still don't think it is an absolute block on any real development because there are fairly simple workarounds.

If you want to see the code under discussion it is all in my repository here with a log of my development. The first commit is the Zipfile that David made available in his blog post, the rest is my testing and development of the Swift version.

These are my performance figures (for 100 runs so it isn't directly comparable to David's):




0.077 (1.8)

0.042 (1)


0.38 (9.1)

13.7939 (327)

The Importance of Being `final`

[UPDATE - Swift 1.2 from Xcode 6.3 Beta 2 brings performance benefits to non-final properties and methods making final unnecessary for performance from that time - see my initial reaction to Beta 2. I still recommend final where possible as it avoids need to consider effects of an object being subclassed and methods overwritten that change the behaviour.]

This post is intended to quantify, explain and show the performance hit that you take from not adding the word final to your classes (or their properties and methods). The post was triggered by a blog post complaining about Swift performance and showing some performance figures where Swift was significantly slower than Objective-C. In the optimised builds that gap could be closed just by adding a single final keyword. I'm grateful to David Owens for showing the code he was having trouble and giving me a base to demonstrate the difference final can make without it being me cherry picking any code of my choosing.

As with most performance issues this doesn't matter most of the time. Most code is waiting on user input, network responses or other slow things and it really doesn't matter that much if the code is being accessed a few times a second. However when you have got performance critical code and in particular that inner loop that is being executed hundreds of thousands of times a second it can make a huge difference.

What does final do

Beyond if let

I've given my Beyond if let talk based on my How I Handle Optionals blog post about handling optionals in Swift twice this week. I was probably a more dynamic speaker in the NSLondon talk but the content is pretty similar. I may have been a bit slower and more methodical at the Swift London one though. Let me know if anything isn't clear in either of them or if you have any tips or suggestions (speaking  or Swift).

Vimeo of talk at NSLondon. Questions from 13:30. [Updated to replace Livestream feed with this.]

You Really Don't Need Protected Members

When Swift's access controls were introduced I wrote about how they worked like C's with good use of internal and external headers. I've recently been asked about how to do access private properties when subclassing and thought it would be worth sharing the conversation.

If you are new to Swift's access controls I suggest you look at the previous post (same link as above) first as this is the refinement and conclusion (in my mind) of an issue that I an open question when I wrote that. If you are new to programming then this post is probably one to skip as it is more about comparing how things can be done in Swift that people are used to doing a certain way in Java than something meant as an introduction to the concepts.

I’ve a question in context of open/closed principle (Software entitles should be open for extension but closed for modification.), coming from Java, AS3 background highly influenced by the Design Patterns book by the Gang of Four, the way I see protected is so that work can be extended by other people. 

How can I fully extend a class in it’s entirety without access to it’s private members, surely I can override methods but that won’t be enough.

The only way I could think is to approach this by declaring everything public or have a getter setter for each but then I’m violating “Encapsulation” principle
The short version is I would design the system in such a way to avoid requiring any inheritance apart from the specifically designed to inherit from system classes (NSObject, UIView, UIViewController etc.).