Swift 3.0 String Index Changes

Swift 3.0 String Index Changes

Swift 3.0 makes fairly sweeping changes to Collection types (SE-0065 - A New Model for Collections and Indices) and you may not be expecting them to impact Strings... But if you are used to working with indexes of any of the different views of a string (for example UTF8 or UnicodeScalarView) and traversing individual characters from string with the String index... You will be impacted. 

Read More

Automatically create all your iOS 9 and OS X Icons

Automatically create all your iOS 9 and OS X Icons

When you create your new app on iOS app in XCode you will be faced with 20 empty boxes to fill in, and that's before you log in to iTunes Connect and are asked for just one more... Oh... and you probably want one for your web-site too that has the the right mask applied. Companion MacOS app? That's another 11. Wouldn't it be nice if a single script could create all of these for you? 

Read More

Using Swift GameplayKit to achieve rendering framework independence

Using Swift GameplayKit to achieve rendering framework independence

In the last article we looked at providing a better (and purely Swift) implementation of GameplayKit's Entity/Component architecture. By better I didn't mean "it's Swift so it's better"... I meant better at solving the stated objectives of GameplayKit: Rendering framework independence and composition. I focused on composition last time, this time I look at how the Swift GameplayKit implementation (and Swift itself) makes rendering framework independence easy. 

Read More

Making GameplayKit Swift-ier

I've posted before on the hot-mess that is GameplayKit. I've since been playing with it a lot, particularly with the entity/component system. I think there are some real problems with the implementation that I suspect may be part of trying to cater to Objective-C and Swift. In this article we'll take a look at those issues, and a Swift re-implementation of the GameplayKit API that solves these problems. 

Read More

Why I maybe don't want you as a reader

I'm sick of it. Just sick of it. Have you actually heard yourself? It's just shameful and embarrassing. I'm a middle aged, white, nerd blogger. All the toast, jam side up. I have had enough of whinging, spiteful, bitter, and stupid people who are harassing women/LGBT/muslims/whatever around the internet. I know that every time I tweet something positive about these people I lose followers.

Read More

Demolition Page 1 - Making Levels

Demolition Page 1 - Making Levels

iOS 9 and OS X El Capitan strengthen Apple's gaming line up with GameplayKit, which augments the graphics (and physics) engines with a game engine. Over the coming weeks I'm going to walk through the process of developing a "bomber man" style game using SpriteKit and GameplayKit.

The code will be supplied in a playground that will have a page for each blog entry. In general, I'll discuss concepts in the blog, and leave explanations of specific pieces of code in comments or Playground markup. There's going to be a lot to cover, so let's get started. 

Read More

Swift One Year On

With WWDC 2015 just a few weeks away, now seemed to be the perfect time to reflect on a year with Swift. When Apple’s Craig Federighi (SVP of Software Engineering) announced Swift there was an almost euphoric response from many parts of the Apple developer community. 

The sheer level of technical ambition was breath-taking. Apple had built a brand-new language that could be fully integrated with existing code, all of the Cocoa APIs, was easy to learn, encouraged crash resistant code and even delivered a performance boost. John Siracusa was lifted above the Ewokian throng and carried out of Moscone West on a throne. You get the idea. 

However, our response was ultimately tempered by the initial quality of the tools. This reality should not have surprised anyone. Apple had kept the language a secret even internally, and with little (not quite no) dog-fooding . Eager developers downloaded the first betas of XCode 6 and got started; many could see promise, the experience was painful. Playgounds (designed to make learning and experimenting in the language easy) were actually unstable and frustrating. Some of the language fundamentals were poor; copy semantics for arrays were confusing at best, and whilst the language came baked with arrays and dictionaries sets were nowhere to be seen. All of these problems paled into insignificance when compared to a truly explosive XCode. Not only did core parts of the build chain crash frequently with painful build times for even medium size projects  when they did work, but the interactive experience was just horrific

Where 'temporarily limited' means "get used to this, you'll be seeing it a lot for the next 8 months. 

Where 'temporarily limited' means "get used to this, you'll be seeing it a lot for the next 8 months. 

Iterate

With each new beta, the situation improved, some of the highlights included

Despite these developments, it was clear that by the time Apple threw the switch on iOS 8 and released it along with the first Swift apps to the world, that Swift was still a long way from finished. It would have been reasonable to assume that we would hear little else from Lattner and his team until WWDC 2015. Reasonable, but wrong. Swift has continue to develop with language updates (we are now at 1.2) as well performance and bug fixing. 

Swift 1.2 in particular seemed to signal more clearly than any of the other updates that Apple was serious about Swift, and serious about its claim that whilst binary compatibility would be maintained, the language itself was not done. 

What defines Swift?

Few areas of Swift are as distinctive (and sometimes as divisive) as optionals. Optionals force the developer to consider if it is possible for a pointer (a reference to an area of memory that stores an object in a program) to be nil. That is, point to nothing. C or C++ code would crash if you tried to use one of these nil pointers to call a method on that object (do something with it). In Swift you must declare that something can be nil by appending a ? to its type. When you use it, you must acknowledge the result of any method you call could be nil (?) too. Or force it to assume it’s not nil with the ! character. What this does it make it hard for the developer to hide from the fact that their code can’t assume a pointer points to a valid value. The initial release of Swift provided mechanisms for helping the developer work with these optionals. 

Some of the biggest changes in Swift 1.2 increased a developer’s ability to minimise the number of lines required to check to see if optionals had a valid value. 

Swift 1.0 [1]

//Check all my pointers are valid and a property is over 100
if let myObject = myObject
    if myOtherObject = myOtherObject
        if myObject.property > 100 {
            //Do something cool
        }
    }
}

Swift 1.2

//Check all my pointers are valid and a property is over 100
if let myObject = myObject, myOtherObject = myOtherObject where myObject.property > 100 {
    //Do something cool
}

It’s hard for a seasoned developer like myself to know if these things make it harder (?! Everywhere and lots of checking might increase the complexity to a beginners mind) OR they actually reduce the number of time a beginners program inexplicably [to them] crashes. What is clear is that in a rather intensive period of development with Swift 1.2 I was able to focus purely on the algorithms I was developing, and let Swift focus on potentially explosive nils. Every time you consider adding a ! to force the optional to be treated as a valid pointer… you feel dirty. You don’t do it. Your code doesn’t crash. Despite having a large number of beta-testers, we’ve only had functional defects, no crashes. None. I’m not an expert on all current languages, but for me optionals set Swift apart from every other language I have used, and certainly from other languages that are good candidates for developing on Apple platforms. They are unique and valuable.  

In Summary

Where are we now? The development process for Swift is now stable. Although the language has evolved and improved XCode has enabled early adopters of Swift to keep up with the changes as they happened. I’m not convinced Swift is an easy first language to learn. Were someone with another language under their belt to start now they would find themselves working with a mature language supported both online and in-print. For anyone wishing to start development for Apple platforms, they should start with Swift. For those of us with over a decade invested in Objective-C & Cocoa the decision is more personal. I believe Swift is ready for us, but exactly when you chose to jump is something that Apple has, for the time-being at least, left to each individual developer. 

However, I know that every time Swift reminds me that the variable is optional, I’ve just avoided a bug and saved time. Maybe just a minute, but maybe a few hours, and for any independent developer time is money. 

 

Footnotes

1. This could have been done more briefly of course, but I believe that the Swift 1.2 approach is as concise but more explicit. 

if myOtherObject!= nil && myObject != nil && myObject!.property > 100 {
    //Do something cool
}