Inscrutable Swift/Xcode Errors

Ugh, what a horrible day of coding. I've been playing around with a small Swift app that's using Core Data and displaying the contents in a Table View.

There are plenty of tutorials on Swift + Core Data on the web but the majority were written before Apple released the 'final' version of the language with Beta 6 so any and all code samples you see online have to be audited as you use them. Today I discovered that you need to use that same auditing mentality when you're using Apple's boilerplate code as well.

Xcode will generate a lot of boilerplate code when you chose certain project templates when you begin a new project. It so happens that if you choose the Master-Detail Application template and choose "Use Core Data" you'll get a starting point for the very app I was wanting to build.

Since the purpose of this app was to learn all of the ins and outs of Core Data access using Swift I decided to use the boilerplate code as a reference but rewrite it all myself.

The problems started while overriding the controller:didChangeObject method. Using Xcode's autocomplete I wrote the following code:

    // MARK: FetchedResultsControllerDelegate
    func controller(controller: NSFetchedResultsController, didChangeObject anObject: AnyObject, atIndexPath indexPath: NSIndexPath?, forChangeType type: NSFetchedResultsChangeType, newIndexPath: NSIndexPath?) {
        switch type {
        case .Insert:
            tableView.insertRowsAtIndexPaths([newIndexPath], withRowAnimation: .Fade)

I was getting a weird error for tableView.insertRowsAtIndexPaths([newIndexPath], withRowAnimation: .Fade):

Could not find member 'Fade'


If I replaced .Fade with nil I then got:

'(UITableView, numberOfRowsInSection: Int) -> Int' does not have a member named 'insertRowsAtIndexPaths'


This is the code in the boilerplate I was working from:

    func controller(controller: NSFetchedResultsController, didChangeObject anObject: AnyObject, atIndexPath indexPath: NSIndexPath, forChangeType type: NSFetchedResultsChangeType, newIndexPath: NSIndexPath) {
        switch type {
            case .Insert:
                tableView.insertRowsAtIndexPaths([newIndexPath], withRowAnimation: .Fade)
            case .Delete:
                tableView.deleteRowsAtIndexPaths([indexPath], withRowAnimation: .Fade)
            case .Update:
                self.configureCell(tableView.cellForRowAtIndexPath(indexPath)!, atIndexPath: indexPath)
            case .Move:
                tableView.deleteRowsAtIndexPaths([indexPath], withRowAnimation: .Fade)
                tableView.insertRowsAtIndexPaths([newIndexPath], withRowAnimation: .Fade)

Notice the difference? It took me a couple of hours of debugging to see it.

It's the method signature, in the auto generated code newIndexPath and indexPath are optionals and in the boilerplate they aren't.

If this helps out one other person I will be happy.

Bug report time.

Words by brett ohland

Swift Multipeer Rewrite

The amount of code that ran the Multipeer Protype was small, so I decided to just rewrite the damn thing in Swift to get a feel for the new language.

I decided for the hell of it to write something up journal style. Very stream of though-y, not sure how easy it is to read or not.

I posted the journal here

I posted the code on GitHub

I really like Swift, it's amazing just how much extranious code just falls away when you start getting the hang out it. It really reminds me much more of writing in Javascript or Ruby.

I've got to hand it to Apple, they didn't make any of my Cocoa knowledge obsolete at all. It's writing the same calls against the same frameworks tha that's amazing.

Multipeer Swift Rewrite Journal

(This is a companion post to this one)

June 9, 2014


Created a new project in Xcode 6, created a single view application and choosing Swift as my language. Took a quick poke around, SO WEIRD to see .swift extensions and no .m/.h files.

Looked at the Storyboard and saw the new Adaptive UI stuff. Good thing I shotgunned the What's New in Cocoa Touch session last night.


Figured out the Adaptive UI stuff pretty quickly, was able to get it up and running with some Auto Layout Magic™ easily.


Testing layouts with a toddler on your lap is difficult.


Started writing my first bits of Swift. Got all of the IBOutlets and IBactions created just like I would for Objective-C.

Read the docs, got the view controller saying that it can be delegates for the various multipeer framework objects.

import UIKit  
import MultipeerConnectivity

class ViewController: UIViewController, MCNearbyServiceAdvertiserDelegate, MCSessionDelegate, MCNearbyServiceBrowserDelegate  {  
    @IBOutlet var myPeerIDLabel : UILabel
    @IBOutlet var theirPeerIDLabel : UILabel
    @IBOutlet var theirCounterLabel : UILabel
    @IBOutlet var counterButton : UIButton

    override func viewDidLoad() {
        // Do any additional setup after loading the view, typically from a nib.

    override func didReceiveMemoryWarning() {
        // Dispose of any resources that can be recreated.

    @IBAction func incrementCounterAndSend(sender : UIButton) {



I can't seem to get the autocomplete to help me out when it comes to implementing all of the required protocols for these various objects though. Still looking.


Yeah, looks like there's just weird issues with this version of Xcode 6. Once, and only once did I get the autocomplete to spit out

func advertiser(advertiser: MCNearbyServiceAdvertiser!, didReceiveInvitationFromPeer peerID: MCPeerID!, withContext context: NSData!, invitationHandler: ((Bool, MCSession!) -> Void)!) {}  

But I did manage to get the compiler to stop complaining 'ViewController' does not conform to protocol MCNearbyServiceAdvertiserDelegate.


It looks like it's something that's up with typing 'advertiser' that the autocomplete doesn't kick in. Bug report time.


Weird. Setting the class properties kept giving me an error ClassviewController' has no initializers`.

Setting them as optionals fixes it

    var session: MCSession?
    var advertiser: MCNearbyServiceAdvertiser?
    var browser: MCNearbyServiceBrowser?
    var localPeerID: MCPeerID?
    var connectedPeers = []

Ah, the docs make it clear:

Classes and structures must set all of their stored properties to an appropriate initial value by the time an instance of that class or structure is created. Stored properties cannot be left in an indeterminate state.

Properties of optional type are automatically initialized with a value of nil, indicating that the property is deliberately intended to have “no value yet” during initialization.

They need to be set as optionals since they have no initial state. Gotta remember to unwrap them.


Booleans are false and true. Whole lot of muscle memory is going to keep me writing YES and NO.


Using the optionals to initialize a local instance isn't making any sense. I think I need to watch more sessions


Okay, what was I smoking a few hours ago. It's pretty simple. I had declared optionals and for some reason I was attempting to unfold the values before assigning them:

browser! = MCNearbyServiceBrowser(peer: localPeerID!, serviceType: HotColdServiceType)  

It's that one "!" that's the issue. Of course I don't want to unwrap the value, I'm trying to set the value.

The rest of this should go much more smoothly


Almost rewritten. Not really taking advantage of many of the new Swift features but that can be forgiven considering this is the first bit of actual Swift code I'm writing in earnest.

Had my first run-in with the array literal syntax. I needed to create a class level property for storing MCPeerIDs, ended up having to declare it like so:

var connectedPeers: MCPeerID[] = []

It's kind of weird declaring what the array will store when you initialize it, but I could get used to it.


Grand Central Dispatch! I was hitting my head as to how to pass a block into the dispatch_async method when I realized that I just pass in a closure.

dispatch_async(dispatch_get_main_queue(), {  
    self.theirPeerIDLabel.text = peerID.displayName
    self.counterButton.enabled = true

Honestly, it couldn't be any more simple. Interesting that it explicitly yelled at me to call self within the closure, I was expecting that to just error out.


So, I guess Swift native strings can't be created from NSData. Kind of odd, using native strings everywhere and then having to write some good ol' NSString. I think this is something that will confuse new programmers when they start.

let message = NSString(data: data, encoding: NSUTF8StringEncoding)  


Must be getting the hang of this, just converted a string to NSData in one line:

let data = "\(buttonCounter) times".dataUsingEncoding(NSUTF8StringEncoding, allowLossyConversion: false)  


Started debugging and immediately started getting EXC_BAD_ACCESS errors on the MCSessionDelegate methods. Ugh. Done for the night.

June 10, 2014


Decided to look at my testing strategy. I was using an instance of the app in the simulator and an instance of my old Objective-C app. Instead, this morning I changed the deployment target to iOS 7 and ran it on my two testing devices.
Lo and behold, it started working.
The last thing I did was I rewrote all of the NSLog statements as println statements. I think that was the last bit of objective-c habits I need to purge.

All done