Unfortunately, that read led to this post as I disagree strongly with a number of the laws he has laid down.

Since I know people are going to be asking me about this post (I am still getting asked about Simmons’ post from a VERY long time ago), better to get my thoughts out now.

1. Do not use Core Data as if it were a database

No disagreement; Core Data is your object model and it can persist to a database but that is not its biggest strength.

2. Do not use Core Data as if it were a SQLite wrapper

This is re-iterating #1. Core Data is your object model, not a thin wrapper around a database.

3. Your NSManagedObjectContext is your “stack”

Here is where we start to disagree. The NSManagedObjectContext is not your stack. It is a scratchpad. It is where you stage changes to the data objects and decide to persist them or not.

I have advocated putting an object around it for convenience and Apple added the NSPersistentContainer which is designed to be subclassed. That wrapper is a great place to handle migrations, importing, exporting, convenience methods for accessing data; the list goes on.

All of the internal workings of your Core Data stack, your persistence and data model absolutely should be stored in the persistent container and that container should be injected through your controllers in your application.

4. Never ever ever ever ever use an NSManagedObject outside its context’s queue

No disagreement. Core Data is designed to work in a threaded environment but most of the objects are NOT designed to work on multiple threads/queues. As with ANY object, assume it is thread locked unless you can demonstrably confirm that it is safe to use across threads.

5. Do not use NSManagedObject as if it were an NSObject

An NSManagedObject is an NSObject that has additional functionality added. It should absolutely be treated as if it is an NSObject because it is an NSObject. NSManagedObject instances are your data objects and should be treated as such. Creating Plain Old Objects on top of NSManagedObject instances is asking for pain and data corruption.

6. You usually don’t need parent-child contexts

If you are not accessing the network, exporting data, importing data or interacting with the outside world in any way, shape or form then this is correct.

If your app talks to anything else then you will want to use parent-child contexts.

The parent context should be on the user interface thread (the main thread) and when you need to do asynchronous work with your data objects (importing or exporting) then you want to do that on another thread and that work should be done in a child context.

A child context simplifies the transfer of notifications of data changes and greatly simplifies using Core Data in a multi-threaded environment.

7. Keep your main queue context read-only

The main queue is also known as the user interface queue. The context that is associated with that queue should be for the user. That context reads and writes data when the user is interacting with the application.

Should it be read-only? Absolutely not.

Should it be user-only? Absolutely.

Any non-user work (importing and exporting) should be done on a child context on a background thread (see response to #6 above).

8. Use an abstraction layer

Please do not do this. You are going to make the next developer curse your name in a very unpleasant manner.

Use Core Data in your user interface. Do not create dummy data objects on top of Core Data. That leads to a maintenance nightmare.

Your user interface can use Core Data without really knowing that it is using Core Data. Your user interface treats the NSManagedObject instances as if they were data objects because they are data objects.

Your user interface does not need to know any more about Core Data than it does for any other model structure. Your user interface should talk to your persistent container subclass and ask for the data it needs. The response to that request might be instances of NSManagedObject or might be an NSFetchedResultsController which then serves up the data objects in a consistent and reliable way.

9. Use Core Data as a local cache

I agree with the wording of this rule but I suspect the meaning is different. Core Data, like any local persistence, is a local cache of what is on the server. This is not specific to Core Data because that is what any local persistence does when you have data on a server.

Core Data is more than just a local cache.

Core Data is not complicated

Core Data is as complicated as you make it. Most of the time you do not need or want the advanced features of Core Data and can just grab an instance of NSPersistentContainer and be happy.

When you need to deal with more complicated or interesting situations there is a fair chance that Core Data has an advanced feature to handle that situation. For the 80%, you can ignore those advanced features and relax in the comfort knowing they are there for if/when you need them.

The harder your code is to write the harder it is going to be to maintain and debug.

Don’t make it harder on yourself. Keep it simple.

No, not a MacBook Pro 13 or 15. I purchased the 12 inch MacBook. The small laptop that people say over and over again cannot be used for development.

This is a living review of that MacBook as used by a macOS/iOS developer.

How I Work

Whether I am coding or writing, I try and conserve motion as much as possible. My laptop is not doing 1000 different things at once. Nor am I continually compiling code or publishing my writing. Those actions are infrequent at best. Most of the time I am reading, studying, thinking and then, eventually, typing.

I sit and stare at the screen a lot.

Therefore, I am less concerned with the overall speed of the processor in my laptop than a gamer or video producer would be.

I do need memory though. Development tools are notoriously terrible about memory management and when you add in simulators, etc. to that mix, 4 or 8 GB of memory just isn’t sufficient.

I also need hard drive space. Projects get big with audio, video, and images fairly quickly. While I can make my projects fit onto the smallest drive, I would rather have breathing room if possible. I would rather NOT carry around external drives.

Therefore I settled on the MacBook with an I5 processor, 16GB of ram and a 512GB SSD drive. Not the absolute top end machine but pretty close.

I would have selected the I3 with 16GB and a 512GB drive, but it was not an option that was available.

Where I Work

I like having a “rig” that can work anywhere. That means having a rig that can work in the worst situation.

For me, at 6’0″ and broad-shouldered, a middle seat in coach on an international flight is probably the worst situation I will find myself in.

Therefore my rig needs to be able to work in a very small environment with no expectation of power.

I frequently will work from home, that being my home office or the couch. My home office has an external monitor and lots of room for devices (my primary work is on mobile devices).

With that, I have an upper and lower requirement.

This is the smallest laptop in terms of footprint which means it will do well on a flight. I will report back on that one after my next flight.

USB-C, while not as great as Thunderbolt 3, is a very flexible port. With the docks that are available or even with Apple’s HDMI connector, I can set this machine up at my desk with a monitor, keyboard, trackpad and external drives. Those drives are limited to USB 3 speeds but that is plenty for development, back-ups, and repositories.

While I have not purchased a dock yet, I may in the near future and update.

With a monitor, Bluetooth trackpad and keyboard, this machine is a decent desktop unit. It drives an external display without issue.

What’s in the Bag?

My rig needs to be very transportable but fully usable in the field. The field might be a bus, a plane, a client’s office; sometimes even a racetrack. I am expected to ship code in all of those environments.

I want to keep the gear to a minimum. The less I bring, the less likely I am going to lose or forget something.

Current kit:

• MacBook 12
• iPad Pro 9.7
• Power for MacBook
• HDMI Adapter for MacBook (also a USB-A Adapter)
• USB-C to USB mini
• USB-C to USB micro
• USB-C to Lightning
• USB-A to Lightning

All of this fits easily into a proper waterproof bag that works well whether I am on a motorcycle or an airplane.

Wireless Development

This is the part where the current state of iOS development is awesome. The fact that I can develop against my phone, tablet and watch without a cable is a fantastic advancement; I absolutely love it.

I do carry sufficient cables with me just in case wireless stops working (happens occasionally) or if I am not on a wireless network that is strong enough to support it; most of the time I code without wires.

When you combine wireless development with the crazy battery life of the MacBook, I can easily get in a full day’s worth of work (more than 8 hours) without needing to plug in a thing.

Battery Life

I am a few weeks into using this machine and so far the battery life has been shocking.

I pretty much plug in the machine at the end of the day. It easily lasts me all day doing wireless development. All day is more than 8 hours a day.

But read above. That includes a lot of staring at the screen, thinking, planning, walking away, etc. I am not hitting build every 2 seconds or intentionally trying to get it to burn its battery. Normal daily usage for me without caring whether I am on battery or not.

I intentionally plug it in when I am doing wired development and I suspect that wired development off the battery will have the laptop feeding power to the mobile device. I suspect I will find out on my next international flight.

The battery on this machine has really changed how I develop. Not watching the battery power through the day is surprisingly liberating.

Speed of Development

It is common for developers to look at pure clock speed when selecting a new laptop. In that department, the MacBook is definitely way behind the curve. If you look at just the numbers, you wonder if the MacBook can even run FaceBook in a browser or not.

In reality, the MacBook works extremely well. iOS, macOS, server and even Android development works just fine. Using both Xcode and Android Studio simultaneously offers no problem for the MacBook.

I suspect the upgrade to 16GB of ram really did the trick.

Storyboards

With the type of development that I am normally involved in, I do not work with storyboards often. Most of my work is at the persistence and networking layers, and therefore storyboards are rarely loaded on my machine.

However, storyboards do feel sluggish. Opening and working with a large storyboard is a test of patience but definitely doable. Given that storyboards are sluggish on my iMac as well, I am going to chock that up to storyboards/Xcode more than a deficiency in this particular laptop. If you are a heavy storyboard developer that item might give you pause. I suggest taking Xcode and a project on a drive to an Apple store and play. That one item could be a deciding factor for you.

My Home Desk

With this laptop, I work from literally anywhere in the house. This time of year I am spending a lot of time in the family room and the kitchen.

Needless to say, the laptop doesn’t get a lot of use while I am cooking, spending time with my family or gaming :)

But, I do have a home office as well. My home desk is minimal as that is the way that I prefer to work.

The iPad is for documentation lookup, taking notes, drawing layouts, watching a movie while I work, etc. Sometimes it is my music player with my Groove external DAC! :)

The monitor is a simple Samsung 1080p HDMI which connects to the Apple HDMI adapter. I might upgrade it next year to a 4K.

I have a powered 7 port USB 3 hub also connected to the Apple adapter which allows me to connect as many devices as I need while at my home desk.

I have a small USB-C extension cable that connects to a left side port to the laptop and lets me store the OMG Dongle behind the monitor to reduce the clutter on my desk.

This configuration gives me a ton of screen to work with and I certainly do not feel constrained.

OMG Dongles!!!

This argument crops up every few years, and it is just repeating drama.

When the floppy drive was dropped; people lost their minds.

When the serial port was dropped; people lost their minds.

When the optical drive was dropped; people lost their minds.

When ADP was dropped…

When DVI was dropped…

There are more I am forgetting. Same drama, over and over again.

Look at the list above: I carry exactly ONE dongle with me.

I upgraded a few cables, switched out USB-A cables with USB-C cables so that I can connect to external drives and devices. Total cost was less than $50.00 (not including the dongle).

My external drives still work.

I can access every device that I could access before.

A few years from now people will be making jokes about how people used to carry so many different cables.

Connectors change; life goes on.

Worth It?

Being able to carry a full rig that is light enough that I forget I am carrying it is fantastic.

So far there are no regrets about the purchase and no hindrance to development. If anything, I am getting more done now because I am able to take this laptop with me everywhere without it being a burden.

Would I rebuild an OS on it? Not if I can help it.

But as a highly portable machine, it does great for development.

For my own purposes I have resisted this slippery slope as often as possible. However I still preferred the way NSURLConnection worked and how it integrated nicely with NSOperation subclasses. My attempts at using the NSURLSession were cumbersome and didn’t feel “right”.

Fortunately, I have recently worked on a design that I have been quite pleased with. In this design I am happily using NSOperation subclasses again and I am using the NSURLSession API.

Changes to NSOperaton implementation

One of the reasons that it took me so long to discover this pattern was due to forgetting about a way to implement NSOperation subclasses and taking control of the life-cycle of the NSOperation. This was not a feature I used very often and therefore did not think about using it with the NSURLSession API.

After various experiments and research I re-discovered this option and the following update to my network operation design was born.

The most complicated change (and probably a change that someone will suggest a better solution to) has to do with the finished property on the NSOperation. This property is defined as readonly which is a bit more enforced in Swift than it was in Objective-C. In Objective-C it was a simple matter of creating a setter accessor and manipulating the underlying ivar that the property generates. However, in Swift, I have not found a way to do that exactly the same. Therefore I ended up overriding the property completely:

var junk: Bool = false
override var finished: Bool {
    get {
        return junk
    }
    set (newAnswer) {
        willChangeValueForKey("isFinished")
        junk = newAnswer
        didChangeValueForKey("isFinished")
    }
}

Note that I am triggering a KVO notification on isFinished as opposed to finished which is what the property name is. This seems to be a Swift-ism as the NSOperation get accessor is called isFinished instead of getFinished and I suspect that is part of why I need to tickle the accessor name instead of the property name.

Since I am building a base class to extend my actual network operations from, there are a couple of other variables that I added:

let incomingData = NSMutableData()
var sessionTask: NSURLSessionTask?
var localURLSession: NSURLSession {
    return NSURLSession(configuration: localConfig, delegate: self, delegateQueue: nil)
}
var localConfig: NSURLSessionConfiguration {
    return NSURLSessionConfiguration.defaultSessionConfiguration()
}

The incomingData property will hold the data coming back from the network operation. This property can be used in a few ways.

The sessionTask will hold a reference to the task that will be created so that we have access to it even when it is not responding back to its delegate. Speaking of delegates, this subclass of NSOperation also implements the NSURLSessionDataDelegate as is hinted at in the localURLSession property.

Both the localURLSession property and the localConfig property can be overridden by a subclass. This is intentional as using a non-default configuration or session is usual for me but I want to leave the option open.

start()

With these variables made available, the start function is fairly straight-forward.

override func start() {
    if cancelled {
        finished = true
        return
    }

    guard let url = NSURL(string: “aURL”) else { fatalError("Failed to build URL") }

    let request = NSMutableURLRequest(URL: url)

    sessionTask = localURLSession.dataTaskWithRequest(request)
    sessionTask!.resume()
}

Because I am now completely in control of the life-cycle of this NSOperation it is prudent to check isCancelled immediately upon entry into this function. It is entirely possible that the operation has been flagged as cancelled before it began. Therefore I will immediately set the finished flag to true if the operation has been cancelled.

I could have built the url property without the guard and just unwrapped it but I prefer the guard syntax for that so that when I do have a problem I get a human readable error message. Personal preference.

The start() function merely kicks off the task and completes.

Because we have overridden the start() function and specifically not called super.start() the NSOperation will continue to reside in the queue, “running”, as far as the NSOperationQueue is concerned until I set the finished property to true.

From here I needed to implement a minimum of three functions to complete the delegate implementation.

didReceiveResponse:

func URLSession(session: NSURLSession, 
    dataTask: NSURLSessionDataTask, 
    didReceiveResponse response: NSURLResponse, 
    completionHandler: (NSURLSessionResponseDisposition) -> Void) {
    if cancelled {
        finished = true
        sessionTask?.cancel()
        return
    }
    //Check the response code and react appropriately
    completionHandler(.Allow)
}

This is another opportunity to watch for the cancellation of the operation and to abort if the flag has been set to true. If it hasn’t then the next step (left as only a comment for brevity) is to check the status of the response and make a decision how to proceed.

The normal procedure here is to execute the completionHandler and pass it the value of .Allow to tell the NSURLSession to continue with the task.

didReceiveData:

func URLSession(session: NSURLSession, 
    dataTask: NSURLSessionDataTask, 
    didReceiveData data: NSData) {
    if cancelled {
        finished = true
        sessionTask?.cancel()
        return
    }
    incomingData.appendData(data)
}

This delegate method is expected to be called numerous times during the life-cycle of this NSOperation. Each time it is called it adds a bit more data to what has been received. Once we have confirmed that the operation has not been cancelled, the next step is to add the packet that was received to the incomingData property.

didCompleteWithError:

func URLSession(session: NSURLSession, 
    task: NSURLSessionTask, 
    didCompleteWithError error: NSError?) {
    if cancelled {
        finished = true
        sessionTask?.cancel()
        return
    }
    if NSThread.isMainThread() { log("Main Thread!") }
    if error != nil {
        log("Failed to receive response: \(error)")
        finished = true
        return
    }
    processData()
    finished = true
}

This is the final of the delegate methods we need to implement. There are others that we can implement if we need to deal with authentication or redirects.

In this function, after confirming that it is not cancelled, we need to check to see if there was an error. If there is an error we effectively abort the operation, throw away the data and change the finished flag. Depending on your application and your expectations, you may want to fire a NSNotification or handle some other kind of behavior to notify the application that the network operation failed.

When the operation doesn’t fail I then call processData() which does nothing in the base class. The expectation is that the subclass of this base class will implement the processData() function and handle its specific processing of that data.

Wrap Up

With this implementation I am able to build network operations that are small discrete units of work that I can easily test with a unit test. I can expand upon this by passing in a NSManagedObjectContext and have my processData() function create a private child of that passed in context and consume the data received from the server.

I can also attach a completion block to the NSOperation and get bandwidth information from the operation if I want and make adjustments to the assumptions of the application based on the current bandwidth.

By using NSOperation subclasses I can now prioritize my network calls (posting to twitter is a higher priority than receiving avatars from twitter for example), cancel operations that are no longer needed (avatars or images that are no longer on screen) and in general be a much better citizen by only keeping the radios on for as long as I need them and not any longer.

Further, I can now watch for application life-cycle events in my NetworkController and terminate operations when my application goes into the background, further improving my citizenship status. I can also look for operations that need to finish when the application goes into the background and request additional background time.

I hope that you find this article helpful and if you have any questions about this design, please feel free to contact me at marcus@cimgf.com.

tl;dr;

You can download the code and playground for this post from github.

What Are Type Constrained Extensions

One of Swift’s most expressive and powerful features is type constrained extensions. If you’re new to Swift coming from Objective-C, think of it as a category in Objective-C yet with the ability to specify type criteria so that your category (extension) only applies to the class if it conforms to a certain type. For example, if you have an array of your own custom objects, you can create functions that are specific to an array of your objects. Here’s a quick snippet similar to one that I posted to Twitter a while back:

class Thing {
    var name:String
    init(name:String) {
        self.name = name
    }
}

extension Array where Element : Thing {
    func whereNamed(name:String) -> [Element] {
        return self.filter( { $0.name == name } )
    }
}

let thing1 = Thing(name: "Thing 1")
let thing2 = Thing(name: "Thing 2")
let thing3 = Thing(name: "Thing 3")

let things = [thing1, thing2, thing3]

let found = things.whereNamed("Thing 2")

After the code runs in a playground the found variable contains an array of Things with the name “Thing 2”. Obviously, you could just run filter on the Things array and achieve the same result, but the code demonstrates the capability succinctly. This is a very cool feature of the Swift language. You can create any function you want that is specific to arrays of your Thing objects.

Yes, you can, in essence, do the same in Objective-C using a category on NSArray, but there is no type safety. It would look something like this:

@interface NSArray (Additions)
- (NSArray*)whereNamed:(NSString*)name;
@end

@implementation NSArray (Additions)

- (NSArray*)whereNamed:(NSString*)name
{
    return [self filteredArrayUsingPredicate:[NSPredicate predicateWithFormat:@"name = %@", name]];
}
@end

You can call whereNamed: on any NSArray and it will work fine as long as the object inside your array has a property named name.

Adding App Specific Functionality

Let’s talk about type constrained extensions by way of an example. If you’ve written code for mobile apps for any significant amount of time, the one thing you can do in your sleep is fetch JSON from a URL, parse it, and display it in your UI. Recently while prototyping I decided that instead of creating an object hierarchy I would just use the arrays of dictionaries as parsed by the NSJSONSerialization class. But then I got to thinking about it and realized that if I use type constraints, I can add some properties to my dictionaries that are specific to the data in the JSON feed. Here’s what I mean.

Let’s start with downloading JSON from iTunes. If you go to this URL: https://itunes.apple.com/us/rss/topmovies/limit=50/json it will download the JSON for the top 50 movies currently in the store. The output currently looks like this in a browser (well, assuming you have a JSON parser plugin).

.

So given this url, let’s download it (in a view controller just for discussion purposes).

let url = NSURL(string: "https://itunes.apple.com/us/rss/topmovies/limit=50/json")

var movies = [[String:AnyObject]]()

override func viewDidLoad() {
    super.viewDidLoad()

    self.downloadData()
}

func downloadData() {
    
    let task = NSURLSession.sharedSession().dataTaskWithURL(self.url!) { [weak self] (data, response, error) -> Void in
        do {
            if let records = try NSJSONSerialization.JSONObjectWithData(data!, options: []) as? [String:AnyObject] {
                self?.movies = records.movieEntries
                dispatch_async(dispatch_get_main_queue(), { () -> Void in
                    self?.tableView.reloadData()
                })
            }
        } catch {
            
        }
    }
    
    task.resume()
}

In this code you can see we’ve created an array-of-dictionaries, String to AnyObject, variable called movies to hold our downloaded/parsed data and then we have a function to perform the download from our iTunes URL. The download gets spun off in the background using an NSURLSession in viewDidLoad. When the download completes, using an NSURLSessionDataTask, the data is now in memory and we can parse it using the NSJSONSerialization class. After parsing completes, we set our movies class variable to the parsed result and then we reload the table view causing it to display the data. Now look closely, though. See how the records variable is type casted as an optional [String:AnyObject] dictionary, yet it has a property on it called moveEntries. Where did that come from? How does a dictionary know anything about movieEntries? Take a look at this extension.

extension Dictionary where Key : StringLiteralConvertible, Value : AnyObject {
    var movieEntries : [[String:AnyObject]] {
        if let feed = self["feed"] as? [String:AnyObject] {
            return feed["entry"] as! [[String:AnyObject]]
        }
        return []
    }
}

This extension is constrained to a String (well, StringLiteralConverrible technically) key and an AnyObject value which matches the type of our dictionary. Once you’ve implemented this extension even code completion now knows about it and will happily suggest movieEntries to you when you type a dot after you type records in the download task completion handler.

You Can, But Should You?

I alluded to this notion earlier, but what I have just demonstrated is really cool and interesting, but you should think about whether it is something you should do in a shipping app. A number of thoughts come to mind. Say, for example, that you grab an object embedded deeper in your JSON/dictionary hierarchy. You would need to create some properties specific to that object as well and the intention of your code may lose clarity. The movieEntries property I demonstrated grabs the “feed” dictionary, and then grabs the “entry” array of dictionaries (refer to the feed JSON again if this is unclear). The “entry” array contains the movie entries themselves in an array. So, say you want to grab a property of a specific movie entry. Now your extension looks like this for the movieName property.

extension Dictionary where Key : StringLiteralConvertible, Value : AnyObject {
    var movieName : String {
        if let nameObj = self["im:name"] as? [String:AnyObject] {
            return nameObj["label"] as! String
        }
        return ""
    }
    
    var movieEntries : [[String:AnyObject]] {
        if let feed = self["feed"] as? [String:AnyObject] {
            return feed["entry"] as! [[String:AnyObject]]
        }
        return []
    }
}

Now, presumably, you’ll know by the context of the code when you want to access a property and when you don’t, however, as I mentioned, this reduces the code clarity making it more difficult to understand what’s going on. Read this code in a couple months after not having touched it in a while and you’ll see what I mean. While writing obscure code might be (arguably) great for your job security, it’s not a best practice. However, you have to admit that this capability is really cool! I really love the expressiveness it demonstrates.

So in spite of my warnings, let’s keep going. When my extension was finished, it looked like this:

extension Dictionary where Key : StringLiteralConvertible, Value : AnyObject {
    
    var movieName : String {
        if let nameObj = self["im:name"] as? [String:AnyObject] {
            return nameObj["label"] as! String
        }
        return ""
    }

    var movieSummary : String {
        if let summary = self["summary"] as? [String:AnyObject] {
            return summary["label"] as! String
        }
        return ""
    }
    
    var movieThumnailURL : NSURL? {
        if let imageItems = self["im:image"] as? [[String:AnyObject]] {
            let firstOne = imageItems[0]["label"] as! String
            return NSURL(string: firstOne)
        }
        return nil
    }
    
    var movieEntries : [[String:AnyObject]] {
        if let feed = self["feed"] as? [String:AnyObject] {
            return feed["entry"] as! [[String:AnyObject]]
        }
        return []
    }
}

I access the the movie object specific properties in my cellForRowAtIndexPath: in this next snippet. Notice I’ve grabbed the image URL to download the movie thumbnail (The download code is quick and dirty in the view controller. Don’t do this in a real shipping app).

var images = [NSIndexPath:UIImage]()

override func tableView(tableView: UITableView, cellForRowAtIndexPath indexPath: NSIndexPath) -> UITableViewCell {
    let cell = tableView.dequeueReusableCellWithIdentifier("Cell", forIndexPath: indexPath)

    let object = self.movies[indexPath.row]           // Grab a movie object from our parsed array
    
    cell.textLabel!.text = object.movieName           // Movie name property
    cell.detailTextLabel!.text = object.movieSummary  // Movie summary property

    
    if let image = self.images[indexPath] {          // Use the cached image if it exists
        cell.imageView?.image = image
    } else {                                         // Otherwise download it
        if let url = object.movieThumnailURL {       // Movie thumbnail URL property
            let task = NSURLSession.sharedSession().dataTaskWithURL(url) { [weak self] (data, response, error) -> Void in
                if let data = data {
                    if let image = UIImage(data: data) {
                        self?.images[indexPath] = image  // Cache the image so it doesn't get re-requested
                        dispatch_async(dispatch_get_main_queue(), { () -> Void in
                            self?.tableView.reloadRowsAtIndexPaths([indexPath], withRowAnimation: .Automatic)
                        })
                    }
                    
                }
            }
            task.resume()           
        }
    }
    
    return cell
}

(The download and caching code here is immaterial to the goals of this post except to point out that I grabbed the URL using the same typed constrained dictionary. How you implement an image cache will likely vary depending on your app’s requirements.)

Primitives Need Not Apply, Well Sorta

At this point you’ve probably already thought of some cool ways you could leverage this capability (if not, you will), but as with everything else there are limitations that require you to think about your problem before attempting to solve it. Let me provide an example. When working with paths, CGPathRef or UIBezierPath, you don’t typically want to initialize your paths and pass them around, but instead you’ll keep around an array of CGPoints and only convert the points to a path when you’re ready to render it. Wouldn’t it be cool if an array of CGPoints had a calculated property called path that would return the CGPathRef you need to render it? Enter type constrained extensions.

extension Array where Element : CGPoint {
    var path : CGPathRef {
        let bezier = UIBezierPath()

        if self.count > 0 {
            bezier.moveToPoint(point)
        }

        for i in 1..< self.count {
            let point = self[i]
            bezier.addLineToPoint(point.point)
        }

        return bezier.CGPath
    }
}

(This is a simplistic example and likely wouldn't suit every need for building out a path, however, the point is again about the convenience that type constrained extensions provide)

And voila! Your array of elements now has a variable called path.

var points = [CGPoint]()
// .. add some points
let path = points.path

Except it doesn't work! Sorry. I know. You were all excited. Well fear not. We will make this work, but first you have to realize that type constraining is looking for objects. CGPoint is a primitive (struct). I know what you're thinking. Let's just wrap a CGPoint in a class and away we go. Well, you could do. How about this instead, though? Let's create a protocol that CGPoint can conform to and constrain it to that instead.

protocol Pointable {
    var point : CGPoint { get }
}

extension CGPoint : Pointable {
    var point : CGPoint {
        return self
    }
}

So now our type constrained array looks like this:

extension Array where Element : Pointable {
    var path : CGPathRef {
        let bezier = UIBezierPath()

        if self.count > 0 {
            bezier.moveToPoint(self[0].point)
        }

        for i in 1..< self.count {
            let point = self[i]
            bezier.addLineToPoint(point.point)
        }

        return bezier.CGPath
    }
}

Now, with a minor addition of a protocol and making CGPoint conform to it, our path variable on the array of Pointables works as expected.

Conclusion

I will conclude with one more practical example. If you've ever needed to manage the items in your navigation bar, you've probably wondered if there is a simpler way to do so other than managing the items array. Well, there really isn't, however, by using a type constrained array extension, you can add functionality that makes managing the items more intuitive. Here's what I mean. For an app I'm working on, I needed to remove one of the nav bar items in a form view controller when I loaded data for editing, but needed it to be available when creating a new object from the form data. Here's what I did:

extension Array where Element : UIBarButtonItem {
    mutating func removeItemWithTitle(title:String) {
        for item in self {
            if item.title == title {
                self.removeObject(item)
            }
        }
    }
}

Notice my function is marked with the mutating keyword to indicate that the function can make changes to the internal array. So now when I load my view controller, I just check to see if my object instance variable is non-nil indicating that we're editing and just remove the navigation item like this if we are:

self.navigationItem.rightBarButtonItems?.removeItemWithTitle("Search")

It's pretty powerful to be able to work this way. I'm finding this functionality to come in handy in a lot of situations. As I said at the beginning, I wasn't exactly enamored with Swift when I first started using it, but the improvements and features we've seen get added to the language in the more recent versions make it a language that is interesting, fun, and expressive to use. You can can call me a believer. I'm really starting to love using Swift. Until next time.

Now that I am working independently again, I am being exposed to a large number of interesting code bases.

It came as quite a surprise to me that view controllers are considered bad by many developers and that they have been coming up with some rather intersting solutions to make them more “manageable”.

To me, this is an indication that many developers have lost the perspective on what should and what should not be in a view controller. For some reason there is a misconception going around that everything belongs in the view controller.

Madness!

Lets break it down.

Network Code

I have spoken about this at length at conferences around the world.

Putting network code in the view controller is beyond a code smell, it is just wrong.

Where does it go?

All of the network code belongs in NSOperation subclasses. Ideally one NSOperation subclass for each network request. That NSOperation is responsible for creating the network request, receiving the data, parsing it into JSON and storing it in the persistence layer (ideally Core Data).

This creates small, discrete, units of work that are easy to maintain. If a network operation fails, we can isolate the code and find the problem. Further, we can put each call into a unit test very easily and run it in isolation until it is perfect.

But where do we fire these operatons from? I strongly recommend creating a top level data controller that is responsible for maintaining a reference to the persistence engine (again, ideally Core Data). This top level data controller is normally instantiated in the application’s delegate and is passed down to the view controllers via dependency injection.

Using a singleton for this is bad; another code smell. Why is a subject for another discussion.

What does this look like?

The data controller starts out very simply:

import UIKit
import CoreData

class DataController: NSObject {
    var managedObjectContext: NSManagedObjectContext
    let networkQueue = NSOperationQueue()

    init(completionClosure: () -> ()) {
        //initialize persistence.  NOT LAZY
    }

    func refreshRequest() {
    let op = OperationSubclass()
    op.dataController = self
    op.url = ... //Pass in what is needed
    self.networkQueue.addOperation(op)
    }
}

With this class being passed into the view controller the view controller can react to refresh requests by simply calling:

self.dataController.refreshRequest()    

One line of code that can be wired directly from the button’s action directly to the data controller.

Consolidating the networking code into a central location also adds additional benefits beyond just code isolation. Real time reaction to bandwidth changes, resumability, cancellability, and many other features become trivial to implement. When the network code is in the view controllers the same features are nearly impossible to implement.

How does the view know when the data is ready?

There are a few answers depending on on what kind of view we are dealing with.

The UITableViewController

This is the easiest type of view controller to work with. When we are using Core Data as our persistence engine the view controller practically writes itself.

By putting a NSFetchedResultsController between the data controller and the table view controller, we have extremely brief method implementations.

But what about the table view cells?

Each table view cell should be designed in the storyboard and then populated via a UITableViewCell subclass. No fuss no muss.

With this simple design the population from the view controller can be as easy as:

override func tableView(tableView: UITableView, cellForRowAtIndexPath indexPath: NSIndexPath) -> UITableViewCell {
    let cell = tableView.dequeueReusableCellWithIdentifier("cellIdentifier", forIndexPath: indexPath) as! CustomTableViewCell
    let object = self.fetchedResultsController.objectAtIndexPath(indexPath) as! NSManagedObject

    cell.populateCellFromObject(object)
    return cell
}

Let the view subclass handle populating the labels, images, whatever else is needed to draw the cell.

By keeping the network code out of the view controller and letting the views draw themselves, the view controller becomes very simple. All it really ends up doing is managing the life cycle of the view, exactly what the view controller is meant to do.

Why add more complexity?

Plain View Controllers

Plain view controllers can be a little harder, but generally do not need to be.

The previous view controller is usually responsible for injecting the needed data objects into the view controller. If you aren’t using dependency injection here you are probably doing it wrong.

With the data being injected the view controller just needs to pass that data to the view subclass.

Let the view populate itself from the data!

Let the view controller manage life cycle events.

Build the view in the storyboard.

Use either KVO or core data change notifications to refresh the view. The view controller does not need to handle the data refresh if the data objects do not change.

Use Dependency Injection. The UIKit framework was designed for it. When you avoid it you are fighting the frameworks and just making everything harder on yourself.

Duplicating data

A few of the interesting design patterns that I have seen recently involve duplicating the data in memory. Sometimes there are two copies of the data, one in the cache (aka persistence layer) and another for the views.

This defeats some of the most amazing pieces of Cocoa!

When our UI has a single copy of a data object we can observe changes on that data object.

We can use KVO (Key Value Observing) or we can use notifications from Core Data to detect changes to the data to react and refresh.

Why is this important?

We do not need to write code to watch the cache!

Our network layer simply updates the cache and the view will update itself. We completely avoid tight coupling between the network layer and the view layer.

Our code base gets smaller.

Our code base gets more maintainable.

Our code base gets faster.

When we duplicate the data and/or try to introduce other design patterns into UIKit based applications we are adding unnecessary complexity.

Why subclass the view?

The UIView class is meant to be subclassed. The documentation on this class is well defined and subclasses of UIView integrate extremely well into the UIKit framework.

When the UIView is subclassed and the data is injected into the view, the view can be reused. This is the core of the concept of code reuse. If a piece of data is going to be displayed in multiple places then it makes sense that there should be a view to be reused.

What about data validation?

When we subclass the view and the view is aware of the data, guess where the data validation goes?

In the view subclass!

Why? So that the view can respond to the validation failures!

This is a big difference between OS X and iOS. In OS X, Cocoa Bindings allow the view elements to query the data directly and confirm validation. This is a very cool feature that makes validation borderline magic.

But Cocoa Bindings do not exist on iOS. Therefore we must validate the data as close to the editing view as possible. This allows us a very short path back to the user to notify the user that the data is invalid.

What better place than in the view itself?

If we do this at the persistence layer, it is too late. At best it will cause a tight coupling between the persistence layer and the view layer. A very bad thing. At worst the user will be in a bad state. Unable to save their data and forced to go find the edit view again that is probably off screen, deallocated, gone. A terrible user experience.

When we design our user inteface to have data validation feedback it then becomes trivial to validate the data upon entry and give the user immediate feedback.

What about business logic?

What is business logic?

Business logic is code that is not part of putting data on the screen and is not part of receiving data from the network (generally).

If the business logic is about posting something to a server, then it belongs in the network layer!

If the business logic is about controlling a device, then it belongs in a manager for that device.

Define what your business logic is and then determine where it goes. Very rarely does it belong in the view controller.

Doesn’t this make the views heavy?

No.

The code to populate the view must live somewhere. If we put it in the view controller then the view controller gets too big.

If we create an object to sit between the view and the view controller then we are creating unnecessary additional objects.

The view is already holding onto references to the elements contained in the view that are provided from the storyboard, it makes perfect sense to put the population code with the references to what is being populated.

This does not make our code any heavier than any other design. The code is arguably a class lighter per view.

What is left over

When we remove the view population and the data code from the view controller; the view controller is trimmed down dramatically. Now the view controller is back down to doing its job, view lifecycle events.

Even the view lifecycle events have been dramatically reduced over the past few years with the introduction of storyboards.

Wrap up

We must never forget the K.I.S.S. principal. It absolutely applies to iOS and OS X development. When we introduce multiple layers of indirection, multiple copies of the data, we are adding completely unnecessary complexity to the application.

That complexity will cost us. It will cost us CPU, Battery Life, Memory, and maintainability.

Why do it the hard way?

About the Author

Marcus S. Zarra is best known for his expertise with Core Data, persistence and networking. He has been developing Cocoa applications since 2004 and has been developing software for most of his life.

There are very few developers who have worked in more environments, on more projects or with more teams than Marcus has.

Marcus is currently available for short to medium term development contracts, code reviews and workshops.

If your team is struggling with code structure, networking, or persistence please contact him. He would love to help your team produce the best application possible.

Marcus can be reached via email at marcus@cimgf.com.

It is time to move on to the next chapter.

What is Next?

Long term I have some ideas that will take a bit of time to put into place. In the short time I am eager to help as many teams as possible through short term contracting, consulting and workshops. I really do enjoy helping teams get the most out of their persistence and networking layers.

Therefore…

Effective immediately, I am available for short term and possibly long term contract work.

While I can assist with any form of iOS or OS X development, my area of expertise is in networking and persistence; specifically Core Data.

If you are not familiar with my experience, here are a few highlights:

• Wrote “The Book” on Core Data.
• Taught at universities around the United States
• Spoken at nearly every Apple related tech conference around the world
• Provided workshops on persistence, Core Data and Networking at many conferences and large corporations in and around the United States.
• Developed some of the most complex applications ever conceived for the iOS platform

What are the options?

I am looking for short term projects unless it is truly amazing, cutting edge, and never done before. I am looking to help your team provide a better experience for your users.

We can accomplish this either through a monthly, weekly, daily contract or through a workshop. The details of which we can discuss in detail. I am available to travel and can work on site for short periods of time.

Are you struggling with your persistence or networking layer?

Are you having performance issues that you are unable to isolate?

Would you like a fresh set of eyes on your project to get an idea of where things are?

Contact me; we can discuss the options.

You’ve heard it said before and sometimes in a scolding tone, “CORE DATA IS NOT A DATABASE. IT’S AN OBJECT GRAPH!”. What normally follows is a discussion about what that means, if you’re lucky. Otherwise, you’re just on your own to go figure it out. In my mind, though, it’s not necessarily wrong to think of it as a database as they have enough things in common to make it a reasonable thing to do and at the end of the day Core Data is backed by a SQLite database. I think that if it helps you understand what is going on behind the scenes better, then go for it. You do have to remember some key differences that can bite you like the need to fetch before updating or deleting, for example. Though with recent additions–last year with iOS 8’s NSBatchUpdateRequest (link to iOS 8 API diff since it’s not currently documented) which allows you to perform a batch update similar to a SQL update query or this year with iOS 9’s NSBatchDeleteRequest (See WWDC 2015 session 220 for more info) which allows for batch deletes based on whatever predicate you give it, the lines seem to be blurring more and more.

tl;dr; Get the source code here: Core Data and Aggregate Fetches Code on Github. The project and source were created with Xcode 7 beta and Swift 2.0 but they’ve now been updated to Xcode 8 and Swift 3.

When it comes to aggregating data, or in more simple database-y terms, data you want to group by, it’s not immediately obvious in Core Data how to go about what you need using a fetch–to the point where some have wondered if it was even possible. It would be nice if there were some mechanism or even syntactic sugar around it that would make it a little more database-y since that makes it easier to grasp, but I think that if we start from a database SQL query and work our way back to a Core Data fetch that uses NSExpression and NSExpressionDescription, it will make a whole lot more sense. Let’s get started by considering some data:

I’ve seen this kind of data many times. It’s a report that you might get from a company who wants to display sales reports for reps or customers. You can see that this data is flattened. It’s not normalized. Instead of using multiple tables you have a single table that has a way to represent a parent entity. In the case of the data above, this is represented by the column called “ProductLine”. In SQL, if we wanted to get a report of the total sum of all of the items grouped by product line, it would go something like this:

SELECT ProductLine, SUM(Sold) as SoldCount FROM Products GROUP BY ProductLine

And the results would looks something like this:

ProductLine  SoldCount 
-----------  ----------
Bowler       48        
Stetson      142       
Top Hat      50  

So the question is, how do we translate this query into a Core Data fetch?

The Basics of Aggregate Fetching

The concept behind the SQL query is simple and easy to understand, but until you see how each component part of the query translates to a Core Data NSExpression or NSExpressionDescription it can be a little confusing getting the results you want in Core Data. Here are a few basic points that will clarify things a little as we head into writing our Core Data query code.

• When you fetch the records, you are going to be requesting that Core Data returns you an array of dictionaries. This makes sense if you think about it. You won’t get back a list of managed objects because the data doesn’t represent a single record and therefore entity. Instead, it represents rows in your data model that have been manipulated to provide an aggregate dataset–a sum of all rows grouped by product line in our case.
• Just as in the SQL query, you need a name for your aggregate “column”. When you run the query directly in SQLite, you don’t have to use the “as” keyword and provide a label–it will provide one for you. However, in your Core Data Query, you’re going to need to name your aggregate column.
• Just as in the SQL query, you need to list the columns you want to group by. This will be the same column names you listed in your select minus the aggregate columns.

Our final aggregate query that we’re going to build is going to also include a sum of the returned counts. It looks like this:

SELECT ProductLine, SUM(Sold) as SoldCount, SUM(Returned) as ReturnedCount FROM Products GROUP BY ProductLine

And the output of this query using the SQLite CLI looks like this:

ProductLine  SoldCount   ReturnedCount
-----------  ----------  -------------
Bowler       48          4            
Stetson      142         27           
Top Hat      50          6  

Fetching Some Aggregate Data

When a fetch request is handed to your managed object context to fetch your data it needs to have a list of columns you want to use for your fetch specified by a list of either NSExpressionDescription objects or Strings. Here’s how to determine which one you should use. Look again at our query:

SELECT ProductLine, SUM(Sold) as SoldCount, SUM(Returned) as ReturnedCount FROM Products GROUP BY ProductLine

We have three items we want returned. “ProductLine” is an actual column in our table–for that we should use a String, while SoldCount and ReturnedCount are new columns we are creating for our query result. They need to be added as NSExpressionDescription objects.

NOTE: The data we’ve been using in the discussion up until now is contrived other than having been placed into a Numbers spreadsheet and, from there (as CSV), imported into a SQLite database just to run the command line queries–the results of which you’ve seen above. Here, however, we depart from that data and will reference similar fields, but ones that we are actually using in the demo project. The differences are subtle, “ProductLine” vs “productLine”, etc. however, it seems important to mention since the following will seem inconsistent unless we explain. Carry on.

If you look at the signature for the property propertiesToFetch on NSFetchRequest you see it takes an array of Any:

@available(iOS 3.0, *)
open var propertiesToFetch: [Any]?

So when your fetch request is ready to execute, you just give it an array containing Strings and NSExpressionDescriptions. Here is how I begin my code to build up these expressions.

var expressionDescriptions = [AnyObject]()
expressionDescriptions.append("productLine" as AnyObject)

As a first step I go ahead and append the Strings I need as you can see above. Next, I go ahead and build up the expression description objects. Let’s take the first one, SoldCount, and see how it is setup in code:

// Create an expression description for our SoldCount column
var expressionDescription = NSExpressionDescription()
// Name the column
expressionDescription.name = "SoldCount"
// Use an expression to specify what aggregate action we want to take and
// on which column. In this case sum on the sold column
expressionDescription.expression = NSExpression(format: "@sum.sold")
// Specify the return type we expect
expressionDescription.expressionResultType = .integer32AttributeType

Now that it this one is built out, add it to our AnyObject array:

// Append the description to our array
expressionDescriptions.append(expressionDescription)

Now let’s do the same for our ReturnedCount column:

// Create an expression description for our ReturnedCount column
expressionDescription = NSExpressionDescription()
// Name the column
expressionDescription.name = "ReturnedCount"
// Use an expression to specify what aggregate action we want to take and
// on which column. In this case sum on the returned column
expressionDescription.expression = NSExpression(format: "@sum.returned")
// Specify the return type we expect
expressionDescription.expressionResultType = .integer32AttributeType

And add it to the array as well:

// Append the description to our array
expressionDescriptions.append(expressionDescription)

All that’s left now is to build up our fetch request.

Put It All Together

When we create our fetch request the two fields that are most pertinent are the propertiesToGroupBy, and propertiesToFetch. In the propertiesToGroupBy we provide an array containing just the one field, “productLine”. In the propertiesToFetch we specify our AnyObject array that contains Strings and NSExpressionDescription objects. Here is the code to build up the fetch request.

// Build out our fetch request the usual way
let request = NSFetchRequest(entityName: self.entityName)
// This is the column we are grouping by. Notice this is the only non aggregate column.
request.propertiesToGroupBy = ["productLine"]
// Specify we want dictionaries to be returned
request.resultType = .dictionaryResultType
// Hand off our expression descriptions to the propertiesToFetch field. Expressed as strings
// these are ["productLine", "SoldCount", "ReturnedCount"] where productLine is the value
// we are grouping by.
request.propertiesToFetch = expressionDescriptions

You can set other fields on the fetch request as usual, like adding an array of NSSortDescriptors, for example:

// Go ahead and specify a sorter
request.sortDescriptors = [NSSortDescriptor(key: "productLine", ascending: true)]

Finally, here is what the code looks like altogether as a class function on our NSManagedObject subclass:

class func aggregateProductsInContext(context:NSManagedObjectContext) -> [[String:AnyObject]]? {

    // Create an array of AnyObject since it needs to contain multiple types--strings and
    // NSExpressionDescriptions
    var expressionDescriptions = [AnyObject]()
    
    // We want productLine to be one of the columns returned, so just add it as a string
    expressionDescriptions.append("productLine" as AnyObject)
    
    // Create an expression description for our SoldCount column
    var expressionDescription = NSExpressionDescription()
    // Name the column
    expressionDescription.name = "SoldCount"
    // Use an expression to specify what aggregate action we want to take and
    // on which column. In this case sum on the sold column
    expressionDescription.expression = NSExpression(format: "@sum.sold")
    // Specify the return type we expect
    expressionDescription.expressionResultType = .integer32AttributeType
    // Append the description to our array
    expressionDescriptions.append(expressionDescription)
    
    // Create an expression description for our ReturnedCount column
    expressionDescription = NSExpressionDescription()
    // Name the column
    expressionDescription.name = "ReturnedCount"
    // Use an expression to specify what aggregate action we want to take and
    // on which column. In this case sum on the returned column
    expressionDescription.expression = NSExpression(format: "@sum.returned")
    // Specify the return type we expect
    expressionDescription.expressionResultType = .integer32AttributeType
    // Append the description to our array
    expressionDescriptions.append(expressionDescription)
    
    // Build out our fetch request the usual way
    let request = NSFetchRequest(entityName: self.entityName)
    // This is the column we are grouping by. Notice this is the only non aggregate column.
    request.propertiesToGroupBy = ["productLine"]
    // Specify we want dictionaries to be returned
    request.resultType = .dictionaryResultType
    // Go ahead and specify a sorter
    request.sortDescriptors = [NSSortDescriptor(key: "productLine", ascending: true)]
    // Hand off our expression descriptions to the propertiesToFetch field. Expressed as strings
    // these are ["productLine", "SoldCount", "ReturnedCount"] where productLine is the value
    // we are grouping by.
    request.propertiesToFetch = expressionDescriptions
    
    // Our result is going to be an array of dictionaries.
    var results:[[String:AnyObject]]?
    
    // Perform the fetch. This is using Swfit 2, so we need a do/try/catch
    do {
        results = try context.fetch(request) as? [[String:AnyObject]]
    } catch _ {
        // If it fails, ensure the array is nil
        results = nil
    }
    
    return results
}

When this function returns, we get a nice tidy little array of dictionaries that looks something like this:

[
    ["SoldCount": 48, "productLine": Bowler, "ReturnedCount": 4], 
    ["SoldCount": 142, "productLine": Stetson, "ReturnedCount": 27], 
    ["SoldCount": 50, "productLine": Top Hat, "ReturnedCount": 6]
]

Which is exactly what we want. We can then just use this array directly as our data for our UITableView data source on the master side of our split view controller. Here is what our app looks like with the data fully populated (click to enlarge):

You can see that we’ve built out the detail side of the split view controller to also display a table view that contains a list of all of the products for the selected product line. Take a look at the source project on GitHub and build the source yourself to see how it all comes together. This post and the source code for it have now been updated to Swift 3 and Xcode 8.

Conclusion

For me the impetus of mastering the aggregate fetch was poor performance doing it another way. Yes, you can achieve the results you want by performing aggregate functions on arrays of data manually, but I noticed in places where I was doing this in an app I work on the performance was growing steadily worse the more data the customer added to the table in question. Experience with RDBMSs (in some other lifetime) reminded me that performing the right query could be far more efficient and so the search was on to find an appropriate optimization. In the mean time I had resorted to doing a background fetch (on a background context) and calculation that loaded an activity spinner to let the user know that the fetch/calculation was occurring, but I hated doing that to my users–and I guarantee they hated that experience. Once I found a way to properly do an aggregate fetch (as demonstrated in this post), I didn’t even have to perform it in the background. What was taking up to 30 seconds before, was now taking milliseconds. That is a nice optimization that makes for happier users. Until next time.

Server encountered an error with Apple Developer.

Please try again later. If the problem persists, contact Apple Developer Technical Support for help.

It could be a red herring. There’s a support note here: https://support.apple.com/en-us/HT203853 that states the issue has to do with making sure you login as an Agent or Admin. That’s probably a valid scenario, but it may not be as in my case. I got this error message simply because an updated program license agreement needed to be accepted on the web portal. Once that was done, I was able to add the server to the team and could continue on.

(Yes, I know it’s April first, but this is not a joke)

Shortly after my acceptance I had heard that there was some controversy surrounding the conference about a comment made by one of the organizers who had attended another conference. After reading up on the controversy I figured; “oh well, how bad can it be?”

The short answer? It was amazing. I absolutely loved every minute of the conference.

The Venue

The conference proper was held at the Palace of Culture and Science in the center of Warsaw. The first floor of the palace has been converted into a movie theater. What this meant to me as a speaker is that I would be speaking to an audience in an amphitheater environment.

A little known secret.

A lot of speakers are introverts. Introverts spend energy to be in a group or crowd. When you are on stage you can feed off the audience’s energy to give a better performance. You feed off that energy by seeing the faces of the audience and their reactions to your talk.

In an amphitheater the speaker feeds off the entire audience, not just the front row or two.

The energy in the talks was amazing. It was almost palpable. After watching some of the talks on the first day I was excited to do my talk. I couldn’t wait to be the focus of that energy.

The people

I always learn a tremendous amount about other cultures when I travel outside of the USA to give a talk. When I arrive at a new venue the first thing I do is walk the city and just explore. Take in the vibe of the city and of the culture that I am being exposed to.

It is amazing what you can learn just walking around, visiting the shops, looking at the restaurants, etc. It is a fantastic way to learn about a place you have never been to before.

At the conference, the vibe was great. People were excited to be there. I was not recognized very much at this conference which worked to my benefit. I got to walk around, engage in conversations and just listen. Listen to the other speakers, listen to the attendees. Listen to the conversations instead of being the center of the conversation. I really learned a lot about how others go about being a developer or designer.

There were an incredible number of cultures represented at this conference. I dare say, more cultures than any other conference I have been to. I can’t say why it seemed so diverse but it was just a wealth of knowledge and experience to learn from.

My Talk

First talk of the year.

Completely new venue.

A technical talk without a single line of code.

What is there to be nervous about?

I approached the stage both excited and nervous. I have learned how to deal with the normal “I am on stage” nervousness (ask me over a drink sometime how I did that), this was another level. Everything could go wrong.

My talk already went through a last minute change just before I went on stage so I was past that.

I already rearranged how the stage worked so I got past that.

But still, new audience, new material.

For me; the talk was fantastic. The audience was incredible. From my first slide I felt the harmony and energy. As I clicked to the second slide I knew this talk was going to be great.

Others can judge the content of my talk.

Others can judge my presentation.

The audience and venue were so incredible that I was disappointed when I ran out of time. I wanted to feel that energy forever. I could have stayed up there forever.

It is the high I feel when I am racing motorcycles.

It is a high that no drug can give you.

As soon as it is over you want it again.

See you again soon

I hope to have another opportunity to speak at MCE. It was a fantastic experience for me.

And the controversy? As with most drama; completely overblown nonsense. A cultural mistranslation at best.

We offer our deepest condolences, thoughts, and prayers for all those affected by the tragic loss of such a great friend to this community, Jordan Breeding. He lost his fight with cancer this morning and we grieve deeply along with the rest of you. Jordan will be sorely missed.

Sincerely and with heavy hearts,

• Marcus, Matt, and the rest of the CIMGF family.

Beginning iOS Application Development with Swift from Skye Road Systems on Vimeo.

tl;dr; Download the Value For Key Path Playground

I was incredibly disappointed in Swift when I started to look into how key value coding might be preserved in the transition from Objective-C. Of course, Apple would preserve that, right? And I don’t mean by resorting to using Foundation classes–you know all type-casty and everything (yeah, type-casty). Are we progressing forward or looking to the past, after all? I shouldn’t have to rely on NSArray like this:

var values = (items as NSArray).valueForKeyPath("value")

Right? Who wants to do that? What’s the proper Swift way?

Well, my early assumption from what I was seeing in Swift was that valueForKeyPath: was gone and no longer did we have a convenient way to grab only the fields we needed from a collection of objects. It appeared that it couldn’t be done–at least not in any idiomatic elegant way. Then I downloaded some sample code from the Apple developer site and noticed they were doing what I needed, but using map to do it. The answer was map. Here’s an example:

var lastNames = items.map({$0["last"]! as String})

Now the lastNames variable contains a list of strings with just the last name property of my items array. Given an array of dictionaries like this, you can see how that is providing pretty much what we used to get from valueForKeyPath:

var items = [
    ["first" : "Billy", "last" : "Bogart", "address" : ["street" : "111 Main Street"]],
    ["first" : "Gary", "last" : "Gollum", "address" : ["street" : "2277 AB Street"]],
    ["first" : "David", "last" : "Dangerly", "address" : ["street" : "22311 Place Ave."]],
    ["first" : "Johnny", "last" : "Jones", "address" : ["street" : "10 Orange Rd."]]
]

lastNames now contains:

["Bogart", "Gollum", "Dangerly", "Jones"]

Notice we also have an address property that points to a dictionary. If want to get the street property inside of address, we can drill down the same way:

var streetAddresses = items.map({ $0["address"]!["street"] as String})

Now, you can see we had to force-unwrap the address property in order to access the street property. This works perfectly and is a fine replacement for valueForKeyPath: of old. When the call succeeds we now have all of the street addresses in the streetAddresses array:

["111 Main Street", "2277 AB Street", "22311 Place Ave.", "10 Orange Rd."]

Take a look at the Value For Key Path Playground if you want to see it in action.

What About Safety?

In Objective-C, if you message nil, it’s a no-op. In Swift, however, if we unwrap an optional that is nil, we will crash. So, on this line:

var streetAddresses = items.map({ $0["address"]!["street"] as String})

when we unwrap using the bang ! operator, if that value doesn’t exist, we’re in trouble. Say our data was changed to this:

var items = [
    ["first" : "Billy", "last" : "Bogart", "addr" : ["street" : "111 Main Street"]],
    ["first" : "Gary", "last" : "Gollum", "addr" : ["street" : "2277 AB Street"]],
    ["first" : "David", "last" : "Dangerly", "addr" : ["street" : "22311 Place Ave."]],
    ["first" : "Johnny", "last" : "Jones", "addr" : ["street" : "10 Orange Rd."]]
]

Notice the address field has been changed to addr. This causes a crash.

Meanwhile, with the old Foundation way, we do this:

var oldStreetAddresses = (items as NSArray).valueForKeyPath("address.street") as NSArray

but look what the output is. NSNull!

[NSNull, NSNull, NSNull, NSNull]

No crash. So which is better?

Well, if your data can be unpredictable, which really shouldn’t happen, then the Foundation outcome is “safer” from a crash perspective. However, your data should be nailed down, so a crash would actually tell you what’s wrong with your data pretty quickly.

What, though, is the safe Swift way of handling this? We can coerce our objects to optionals and use optional chaining instead:

var streetAddresses = items.map({ $0["address"]?["street"] as? String})

So our first optional operator says to return the object or nil and the second operator says that is should be an optional of type String. This call returns an array of optionals that has this output in our playground:

[nil, nil, {Some "22311 Place Ave."}, {Some "10 Orange Rd."}]

Assuming the following data:

var items = [
    ["first" : "Billy", "last" : "Bogart", "addr" : ["street" : "111 Main Street"]],
    ["first" : "Gary", "last" : "Gollum", "addr" : ["street" : "2277 AB Street"]],
    ["first" : "David", "last" : "Dangerly", "address" : ["street" : "22311 Place Ave."]],
    ["first" : "Johnny", "last" : "Jones", "address" : ["street" : "10 Orange Rd."]]
]

Notice the first two use the bad addr field and the last two use the correct address field.

For my applications, I think I would prefer to see a crash so I know my data is bad. It’s the server developer’s problem. Am I right? ;-)

Taking Map() Farther

The map() function really goes far beyond this trivial little valueForKeyPath: replacement example. You can really massage your data into any form you want with it. Say for example you wanted to create an transformed array of dictionaries from your array of dictionaries that had some of the same data, but organized differently. For example:

var fullNames = items.map({ ["full_name" : ($0["first"] as? String)! + " " + ($0["last"] as? String)!] })

This returns an array of dictionaries that contain a single key value pair with a key called full_name and value of the first name and last name of each item in the original array concatenated together. The output looks like this in our playground:

[["full_name": "Billy Bogart"], ["full_name": "Gary Gollum"], ["full_name": "David Dangerly"], ["full_name": "Johnny Jones"]]

As you can see, there really are a lot of possibilities for massaging your data structures using map. The tough part is imagining how it might be used and often that just comes from experience. The more you use it, the more obvious the solutions will become.

Swift Is Not So Bad

There are certain complaints about Swift I still have, however, I am finding that it is growing on me. I am starting to have much more success making my code pure Swift–pulling back from my old habits and considering how problems should be solved in this brave new Swift world. It’s getting better and some of the language aspects are actually better than Objective-C. I couldn’t see that forest for the trees just a couple short months ago. Until next time.

Recently while using this language feature writing Swift code, I ran into a few snags and learned from the process. I figured I would document it in this screencast. It walks you all the way through from project creation, so it’s about 35 minutes.

Here’s what you will learn:

• How to setup CoreData entities in the data model
• How to add a run script action to build your managed object classes using mogenerator
• How to create a protocol in Xcode 6
• How to implement a protocol in the various managed object classes
• How to preload your CoreData store with test objects in code
• How to load each object type generically into a table view controller

And if you want to just cut to the chase, grab the code from github.

Protocols in Swift With Core Data from Skye Road Systems on Vimeo.

This year, with the release of Swift, there are some pretty radical changes. Yet the Core Data stack initialization code is still the same.

There is nothing wrong with the default template code but there isn’t really anything right about it either. It is far better than it once was but it is still overly verbose and hard to follow.

Therefore, I present my Swift Core Data stack code that I will be using as I grok this language.

saveContext()

func saveContext () {
  var error: NSError? = nil
  let moc = self.managedObjectContext
  if moc == nil {
    return
  }
  if !managedObjectContext.hasChanges {
    return
  }
  if managedObjectContext.save(&error) {
    return
  }

  println("Error saving context: \(error?.localizedDescription)\n\(error?.userInfo)")
  abort()
}

The save method is always the first one that I attack. I strongly dislike having conditions inside of conditions inside of conditions. It is ugly and hard to follow. I much prefer the fail early, fail often design. In my version of the saveContext() we do just that. Every opportunity to fail (or finish) is exercised individually and if it is a failure or finish condition, we return.

All of the logic is on the left side and easy to follow.

managedObjectContext (Version 2)

Next up is the stack itself. Apple creates four variables when we really only use one. It is rare to use persistentStoreCoordinator more than once in the life cycle of an application and even more rare to use managedObjectModel more than once. So why have individual variables for them? This is even more wasteful when you realize that both are accessible from the managedObjectContext. Therefore, I prefer to roll them into one, fairly easy to follow variable.

@lazy var managedObjectContext: NSManagedObjectContext = {
  let modelURL = NSBundle.mainBundle().URLForResource("SwiftTestOne", withExtension: "momd")
  let mom = NSManagedObjectModel(contentsOfURL: modelURL)
  ZAssert(mom != nil, "Error initializing mom from: \(modelURL)")

  let psc = NSPersistentStoreCoordinator(managedObjectModel: mom)

  let urls = NSFileManager.defaultManager().URLsForDirectory(.DocumentDirectory, inDomains: .UserDomainMask)
  let storeURL = (urls[urls.endIndex-1]).URLByAppendingPathComponent("SwiftTestOne.sqlite")

  var error: NSError? = nil

  var store = psc.addPersistentStoreWithType(NSSQLiteStoreType, configuration: nil, URL: storeURL, options: nil, error: &error)
  if (store == nil) {
    println("Failed to load store")
  }
  ZAssert(store != nil, "Unresolved error \(error?.localizedDescription), \(error?.userInfo)\nAttempted to create store at \(storeURL)")

  var managedObjectContext = NSManagedObjectContext()
  managedObjectContext.persistentStoreCoordinator = psc

  return managedObjectContext
}()

Apple’s sample code uses two variables, one that is calculated and then one “private” variable that actually holds the reference. Thanks to lots of feedback from other developers we have a more elegant solution. A lazily loaded var. This simplifies the code quite a bit.

Inside of the getter is where all of the code from the other functions exist. We first grab the URL for the model and then pass that URL into the NSManagedObjectModel. We then test to make sure that the NSManagedObjectModel initialized properly. Right now ZAssert is a global function that is tied to a constant Bool to determine how it reacts to failure. I am still playing with that part so it is not fixed in stone and will get its own blog post once I am happy with it. For now it looks like:

let DEBUG = true

func ZAssert(test: Bool, message: String) {
  if (test) {
    return
  }

  println(message)

  if (!DEBUG) {
    return
  }

  var exception = NSException()
  exception.raise()
}

Note that we are creating mom as a constant. We know this object is not going to change for us so we don’t need to create it as a variable. Having constant objects like this is a pretty cool feature of Swift.

Once we know the NSManagedObjectModel has been initialized properly we can move on to our NSPersistentStoreCoordinator. Creating the NSPersistentStoreCoordinator is just a matter of passing in the initialized NSManagedObjectModel that we just created. We create the NSPersistentStoreCoordinator as another constant. Next we need to load a NSPersistentStore into the NSPersistentStoreCoordinator.

To do that we need to know where the store is going to be saved. We grab all of the possible locations for the documents directory and select the last one from the returned array. We can then append the filename of our store to the end of the NSURL.

With a location we can now ask the NSPersistentStoreCoordinator to add a store for that location. We call the method addPersistentStoreWithType on the NSPersistentStoreCoordinator and we get back either a NSPersistentStore or nothing. If we get nothing back then that is a failure which we check for.

Finally after the NSPersistentStore has been created we can create the actual NSManagedObjectContext. We just initialize the NSManagedObjectContext, hand it the NSPersistentStoreCoordinator and return.

Wrap Up

This has changed about three times already and will probably change again. I am not crazy about how the storeURL is being constructed and will probably clean that up as I go forward. I am certain my ZAssert is going to change.

If you have any suggestions on how to improve, simplify this, please shoot me an email at the usual place. Hopefully we can get down to the infamous five lines of code soon. Right now we are sitting at about 8 (we started around 11)…

Brent Simmons has been blogging about his conversion of Vesper to a Core Data application. A recent post of his titled Core Data and Deleting Objects set my teeth on edge. Brent says:

“The best advice I’ve heard about deleting managed objects is to 1) not do it, or 2) do it only at startup, before any references to those to-be-deleted objects can be made.”

I do not know who is giving Brent advice but he must be playing tricks with him or just trying to wind him up. The advice was simple; don’t delete Core Data objects or if you are going to delete them, delete them at launch.

Will that work? Sure. Is it the right answer? Not even close.

Advice like this comes from mistakes. Mistakes in application design. Mistakes in application planning. Someone, somewhere, coded himself into a corner and decided that Core Data was to blame. I hear this a lot. It is one of the common conversation starters I have with new clients.

So what is the right answer? Plan your application out. Plan your application for deleting objects.

When we are talking about working on iOS the easiest way to handle this is to use the built in tools that the framework already provides for you. Use the NSFetchedResultsController. Use it everywhere it makes sense. Squeeze it into places that it kind of makes sense. Why? It watches the NSManagedObjectContext for you! It will tell you when an object has been inserted, updated or deleted! It is like magic!

Don’t like it or it doesn’t fit for you? Build your own! Seriously, the core of the NSFetchedResultsController is not hard at all. Here is a very basic one that just watches for deletes:

//
//  MCDeleteWatcher.h
//  MCDeleteWatcher
//
//  Created by Marcus S. Zarra on 2/24/14.
//  Copyright (c) 2014 MartianCraft. All rights reserved.
//  Permission is hereby granted, free of charge, to any person
//  obtaining a copy of this software and associated documentation
//  files (the "Software"), to deal in the Software without
//  restriction, including without limitation the rights to use,
//  copy, modify, merge, publish, distribute, sublicense, and/or sell
//  copies of the Software, and to permit persons to whom the
//  Software is furnished to do so, subject to the following
//  conditions:
//
//  The above copyright notice and this permission notice shall be
//  included in all copies or substantial portions of the Software.
//
//  THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
//  EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
//  OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
//  NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
//  HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
//  WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
//  FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
//  OTHER DEALINGS IN THE SOFTWARE.
//

typedef void (^DeletedObjectsBlock)(NSSet *deletedObjects);

@interface MCDeleteWatcher : NSObject

@property (copy) DeletedObjectsBlock deletedObjectsBlock;

- (id)initWithPersistentStoreCoordinator:(NSPersistentStoreCoordinator*)psc;

- (void)addObjectToWatch:(NSManagedObject*)object;
- (void)addObjectsToWatch:(NSArray*)objects;

@end

//
//  MCDeleteWatcher.m
//  MCDeleteWatcher
//
//  Created by Marcus S. Zarra on 2/24/14.
//  Copyright (c) 2014 MartianCraft. All rights reserved.
//  Permission is hereby granted, free of charge, to any person
//  obtaining a copy of this software and associated documentation
//  files (the "Software"), to deal in the Software without
//  restriction, including without limitation the rights to use,
//  copy, modify, merge, publish, distribute, sublicense, and/or sell
//  copies of the Software, and to permit persons to whom the
//  Software is furnished to do so, subject to the following
//  conditions:
//
//  The above copyright notice and this permission notice shall be
//  included in all copies or substantial portions of the Software.
//
//  THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
//  EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
//  OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
//  NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
//  HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
//  WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
//  FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
//  OTHER DEALINGS IN THE SOFTWARE.
//
#import "MCDeleteWatcher.h"

@interface MCDeleteWatcher()

@property (weak) NSPersistentStoreCoordinator *persistentStoreCoordinator;
@property (strong) NSMutableSet *objectsToWatch;

@end

@implementation MCDeleteWatcher

- (id)initWithPersistentStoreCoordinator:(NSPersistentStoreCoordinator*)psc;
{
  ZAssert(psc, @"PSC is nil!");
  ZAssert([NSThread isMainThread], @"Initialization must be on main thread");

  if (!(self = [super init])) return nil;

  [[NSNotificationCenter defaultCenter] addObserver:self selector:@selector(contextUpdated:) name:NSManagedObjectContextObjectsDidChangeNotification object:nil];

  [self setPersistentStoreCoordinator:psc];
  [self setObjectsToWatch:[NSMutableSet set]];

  return self;
}

- (void)dealloc
{
  [[NSNotificationCenter defaultCenter] removeObserver:self];
}

- (void)addObjectToWatch:(NSManagedObject*)object;
{
  [[self objectsToWatch] addObject:object];
}

- (void)addObjectsToWatch:(NSArray*)objects;
{
  [[self objectsToWatch] addObjectsFromArray:objects];
}

- (void)contextUpdated:(NSNotification*)notification
{
  if (![self deletedObjectsBlock]) return;

  if ([[notification object] persistentStoreCoordinator] != [self persistentStoreCoordinator]) return;

  NSSet *deleted = [[notification userInfo] objectForKey:NSDeletedObjectsKey];
  if (![[self objectsToWatch] intersectsSet:deleted]) return;

  NSMutableSet *objectsDeleted = [NSMutableSet set];
  for (NSManagedObject *object in deleted) {
    if ([[self objectsToWatch] containsObject:object]) [objectsDeleted addObject:object];
  }

  if ([NSThread isMainThread]) {
    [self deletedObjectsBlock](objectsDeleted);
  } else {
    dispatch_async(dispatch_get_main_queue(), ^{
      [self deletedObjectsBlock](objectsDeleted);
    });
  }
}

@end

So why are deleted NSManagedObject instances so dangerous? Well it depends on your version of Core Data. Prior to iOS 5 (meaning iOS 3 and 4) if you tried to access a property on a deleted NSManagedObject instance you would get an immediate exception of “CoreData could not fulfill a fault” which would result in your application crashing.

I like to pretend that iOS 5 never happened.

In iOS 6 and 7, accessing the property will not cause a crash. You will just get nil back which can be unexpected. However if you try and set a property, you get the familiar crash.

How do we avoid this edge case? Well, it is kind of like memory management, when you have released the object (aka deleted it) don’t touch it again!

Watch for notifications on objects that can be deleted under you. React to those notifications. Plan for them. Presenting an edit view and the object is deleted? React!

If you are in legacy code and need to test for an object to see if it was deleted from under you and the ripple is too large to do it right then you can ask the object -isDeleted and you can also test for the NSManagedObjectContext being nil.

Be warned though. -isDeleted really should be called -isScheduledForDeletion as it will only return YES if the object will be deleted during the next save. Once the NSManagedObjectContext has been saved it will return NO.

Testing -managedObjectContext for nil also has a catch. There are multiple situations where the -managedObjectContext property of a NSManagedObject can be nil. For example, you can create a NSManagedObject without a context. Therefore this is not an absolute test either.

You can also play around with -[NSManagdObjectContext existingObjectWithID:error:] if you want.

These are a code smells.

Your application should be handling deletes properly and should know that the object has been deleted and react to it. Waiting until you are on the edge of the cliff and then asking the now-deleted object if it has been deleted is bad.

What is the right answer?

Plan for deletions.

Core Data is a framework with a nearly impossible job. Writing a universal persistence engine is right up there with solving PI. You can go really deep but you are never going to “solve it”. Eventually it is “good enough” and has edge cases.

There is a reason Brent keeps coming back to Core Data. Writing your own persistence engine is more trouble than it is worth. Better to use an existing framework that has a team of highly skilled engineers working on it than to write your own. Yes it will have edges. Yes it can break. But it is better than the alternative 99.999% of the time.

Our job as developers is to learn where those edges are and plan for them.

Don’t scream in the darkness; learn how to turn on the light.

To be honest, I don’t have a lot of use cases for them myself. They are definitely not one of the core features of Core Data that I recommend people learning when they are initially getting comfortable with the framework.

In this article we will discuss one use case for fetched properties and the impacts.

## The Use Case

The use case for fetched properties that I have run across a few times comes into play when you have more than one persistent store file on disk. Imagine you are building a recipe application (one of my favorite examples). You decide to include a pre-built read-only database with existing recipes. However, your application has the ability to add notes and social comments to a recipe.

You want to keep the recipe database as read only (you have a separate one for new recipes) but you want the user to be able to add comments. Where do we put the data?

In this contrived situation, storing the comments (and other metadata) in another store makes sense. Unfortunately we can’t have relationships across physically separate stores.

Enter the Fetched Property.

## Fetched Property

A fetched property is a property added to a `NSManagedObject` entity that instead of storing a value or a relationship, it stores a `NSFetchRequest`. When the property is accessed for the first time the `NSFetchRequest` is fired and the results are returned.

A fetched property always returns a `NSArray` (well a subclass but that is a minor detail) and it can be configured to sort the results.

Unfortunately, the editor in Xcode does not permit adding sort criteria so the only way to add a sort to a fetched property is to create the fetched property in code. Hopefully that will be corrected in some future release of Xcode.

What does a fetched property look like? In the Core Data model editor, a fetched property is added just like an attribute or a relationship. Then in the Data Model inspector you can configure the `NSFetchRequest`.

A Fetched Property shown in Xcode’s data modeler

The Destination is the entity that will be returned by the fetched property. The predicate is a string representation of the `NSPredicate` configured within the `NSFetchRequest`.

Further, the predicate can use one of two variables to help configure it:

`$FETCH_SOURCE` gets replaced by a reference to the entity that owns the fetched property. By using this variable we can reference properties in the owning entity.

`$FETCHED_PROPERTY` gets replaced by a reference to the the property description of the fetched property. The property description includes key value pairs that are accessible from within the predicate. I have not run across a situation where I have used this variable.

## The sharp edges

There are unfortunately some concerns with fetched properties.

Unlike a relationship, there is no way to pre-fetch a fetched property. Therefore, if you are going to fetch a large number of entities and then desire to access the fetched property for those properties, they are going to be fetched individually. This will drastically impact performance.

Fetched Properties are only fetched once per context without a reset. This means that if you add other objects that would qualify for the fetched property after the property has been fetched then they won’t be included if you call the fetched property again. To *reset* the fetched property requires a call to `-refreshObject:mergeChanges:`.

A fetched property always returns an array. While this is not a major issue if in fact you want more than one object returned. However, when that is not the case it is an additional method call that you need to make every time or add a convenience method. More code equals more bugs.

## To use or not to use

Fetched properties are not a main line piece of Core Data. It appears that even the Core Data team (or the Xcode team at least) agrees with that assessment based on how little effort is given to them in the model editor. Should you use them?

It depends. If you are joining two separate persistent stores and need a *soft* relationship between entities in those stores then yes, you can use them. They do work.

Be mindful of the edges, they are sharp.

While this approach is inexpensive, the test-discover-reboot-fix-build-test cycle just got to be too much for even this frugal Scot.

Enter the Mac mini

My new solution has 2 parts: a maxed out Mac mini with VMware Fusion to support all the targeted OS X versions and a scripted piece that will sync new test builds to the VMs.

The current $799 Mac mini has a quad-core Intel Core i7, a 1TB HD and is expandable to 16GB of RAM. Our local MicroCenter had a $749 sale on that model so I picked one up along with a 16GB RAM upgrade. After I setup 4 VMs, one for each of 10.6 – 10.9, I found the performance to be incredibly slow. Analyzing the issue quickly identified the speed of the stock HD as a bottleneck, so after considering returning the whole kit for a BTO Fusion Drive model, I picked up an OWC 240GB Mercury EXTREME Pro 6G SSD, and now the performance is great. (Installing an extra HD in a Mac mini is possible, but if you do, make sure you watch and understand the videos on the topic and make sure you order the correct parts to install in your Mac mini.)

Moving the builds around

Each of my Mac Xcode projects now has an extra scheme called MyApp test build. The following scheme settings are used: In Run MyApp.app, I’m using the Release build configuration and I’ve set Launch to Wait for MyApp.app to launch since I don’t intend to run these builds from Xcode. Most importantly, in Build->Post Actions, I’ve added a Run Script Action with Provide build settings from set to the app. The script below creates a new uniquely-named folder in the $root_destination_folder every time you build and will copy the resulting product into that newly created folder. The folder name combines date/time, product name, and the current git describe. The $root_destination_folder should be in a folder that is synced by a service. I used Dropbox at first, but it doesn’t seem optimized for the large number of small files that compose a Mac application bundle, even with LAN syncing turned on. I’m now using BitTorrent Sync, which uses the BitTorrent protocol. Even as a beta release, I had great success with it. By adding the shared folder to the BitTorrent Sync client on each test VM, every time I make a test build, it automatically appears on each VM.

By running multiple OS X versions in VMs simultaneously and syncing test builds, I’ve nearly eliminated all the waiting involved in testing and iterating across multiple OS X versions.

root_destination_folder=/Users/fraser/Development/test_builds_sync
date=`date +%Y%m%d-%H%M%S`
product=$PRODUCT_NAME
git=/usr/bin/git
cd $SRCROOT
version=`$git describe --dirty`
full_dir_path=$root_destination_folder/$date-$product-$version
mkdir -p $full_dir_path
cp -RH $TARGET_BUILD_DIR/$FULL_PRODUCT_NAME $full_dir_path

Note 1: For testing on Mac OS X 10.6 Snow Leopard, only Snow Leopard Server is supported in VMware Fusion. Apple has made Snow Leopard Server available to paid Mac developers as a free download. The provided serial number expires at the end of 2014.

For my own workflow, I like to minimize the number of tools used and number of switches between apps needed to complete a task.  So, I decided to attempt to use Xcode exclusively to interact with Git and share my results.  So far I have been pleasantly surprised at what all Xcode can do with Git. If you have not taken a look at Xcode’s support for Git, you may be surprised how much you can accomplish.

This article assumes basic familiarity with Xcode and Git, and describes Git functionality present in Xcode version 4.6.2.

NEW GIT PROJECT SETUP IN XCODE

Since Git is a distributed version control system, a repository can be created locally when starting a project, or on a remote server and then cloned.  Xcode can handle both situations.

When creating a new Xcode project, you can include a local git repository by checking the “Create local git repository for this project” option.  Xcode will initialize the repository and perform an initial commit with the template files for you.

If you are sharing your project with a team or just want a backup of your project on another machine, you can set up a remote copy of the repository.  The typical way this is done is to create an empty repository on a git service like GitHub or Bitbucket.  Once the repository is available, return to Xcode and open the Organizer. Select Repositories to view all the version control repositories that Xcode is aware of, and find the new project repository.  Select Remotes for the new project, add then click the Add Remote button.

Xcode will present a dialog to add the remote. You can follow the default naming standard for a git remote and give it the name “origin”, or you use a custom name.  Then specify the remote URL for the repository, which will be provided by Bitbucket.

If the remote repository is private and requires authentication, you can enter it after the remote is added.  Select the remote in the Organizer list, and an authentication interface will appear below the list.

Once the remote is added and authentication provided, the master branch needs to be pushed to it.  Return to the Xcode project window.  From the Xcode menu, select File | Source Code | Push… Xcode will present a sheet which will allow you to select a remote to push to, and a branch to push.  Note that Xcode has checked with the remote repository, and indicates that the master branch will be created in the remote repository with the push.

Once the push is complete, the remote repository is available for updates and for other users.

USING AN EXISTING REMOTE PROJECT IN XCODE

To clone a copy of an existing remote repository, open the Organizer in Xcode and select Repositories.  Click the plus (“+”) button in the lower left hand corner of the Organizer, and select “Checkout or Clone Repository…”.

Xcode will present a dialog requesting a URL or file path.  Xcode can handle both ssh and https URLs for git repositories.  Be sure to specify the full URL for the repository, which is typically available on the project page for Github or Bitbucket.

If the repository is private and requires authentication, Xcode will request your credentials for the repository.

Provide your credentials and click OK.  Xcode will store your credentials in the keychain for subsequent accesses of the remote repository.  Note that Xcode can also handle ssh key authentication in addition to name and password.  Once Xcode has authenticated with the remote repository, Xcode will request a location to store the project, and then project will be cloned.  Once cloned the project can be opened or shown in the finder.

If you run into an issue with using the Checkout or Clone approach and authentication, Select “Add Repository…” instead.  You can then add your authentication information for the repository, and clone from there.  This approach worked for me in cases where using Checkout or Clone did not.

When the clone is complete, the local working copy is ready for updates.

MAKING AND COMMITTING CHANGES

Once you have a working copy of your project, it’s time to get to work.  As you make changes to the project, Xcode will indicate when files have been changed from the working copy.

An “M” next to a file indicates it has been modified, and an “A” indicates the file is new to the repository.

To commit changes, select File | Source Control | Commit from the Xcode menu.  Xcode will display all the differences from the working copy in the commit view.  If you only want to commit some of the changes, you can check or uncheck files as desired to include or exclude them from the commit.  In addition, you can select only the files you want to commit before selecting File | Source Control | Commit from the Xcode menu, and only the files you have selected will be displayed in the commit view.

In this example, I have added a label to the storyboard with a corresponding property in the view controller, and have added a new class to the project.  I only want to commit the label changes, so I have selected those and added a commit message in the bottom section.  In addition to making file level selections for a commit, Xcode can do line level selections for a commit.

In this example, I have work in progress in myExperimentalMethod, but I have added the desired functionality to myNewMethod and would like to commit so other members of the team can use it while I finish myExperimentalMethod.  By clicking on the numbers in the center column I can select whether a change should be included in or excluded from the commit, or I can discard the change.

Note that Xcode will not show deleted files that have been removed from the project.  When a file is deleted from an Xcode project, the project will indicate that the project has been modified, but the file will no longer be visible in the Xcode project view.  The deleted file will be staged for the next commit and will be included in the next commit, but it will not be visible in the project view or the commit view.

LOOKING AT HISTORY

Xcode provides a Versions editor, which has three different perspectives on the git history for a file.  To use the Versions editor, select the file in the Standard editor in Xcode, the switch to the Versions editor using the editor segmented control in the upper right hand corner of the Xcode window.

The three perspectives are Comparison, Blame, and Log, and can be selected using the segmented control in the lower right portion of the editor pane when the Versions editor is active.

The Comparison view will initially show changes in the working copy from the most recent commit.  Changes can be discarded by clicking on the number in the center column and selecting Discard Change from the menu.  The Comparison view can also compare any two arbitrary commits.  To do this, click the clock icon at the bottom of the center column.  Xcode will present a view of the commits that have taken place for the file.  Adjust the two white pointers to select the version to display in each window.  Xcode will display the commit information for each commit as you move the arrow past it.  Once selected, Xcode will highlight the code differences between the versions.

If something in the code does not make sense or is not clear, it can be helpful to talk to the person who coded it.  Blame view can identify the author of each line of code by showing who made each change in the file, and corresponding commit information for each change.

To see detailed information for each commit, hover over the name and date section and an info button will appear in the far right edge.  Click the info button to see commit information.  Clicking View Changes will show the comparison view that is used for committing for all the files included in that commit.

The Log view will show the history of commits in the right hand side of the view.  Hovering over each commit will display an info button which can be clicked to show the same detailed information about each commit that Blame shows.

In the Repository section of the Organizer, logs are available for both the working copy and branches.  If the working copy is selected, Xcode can even show commits specific to a selected file.

When looking at branches, select a branch to see recent commits for that branch.  For all history, you can expand the commit by clicking on the arrow to the left of the commit hash to see what files were included in the commit, and you can click on the View Changes button to view all the changes in the comparison view.

USING BRANCHES

Branches can be a very effective tool to isolate new features or experiments in code.  Xcode has pretty good support for branches, but it is not shown in the project view.  The first method you can use to commit code to a branch is to select “Commit to Branch…” instead of “Commit X Files” from the commit view.

Xcode will ask you to select a branch to commit to, or will allow you to create a new branch.

Once you have committed to a branch from master, you will be automatically switched to that branch.  You can continue making changes and commits to the branch.  So how do you know what branch you are on in Xcode, or get back to the master branch, or switch to another branch?  Visit the Repositories in the Organizer, find the repository for your project, and select the working copy.

To see what branch you are currently on, look in the upper right hand corner of the Repository view.

To switch back to master or to another branch, click the “Switch Branch” button in the lower right hand corner.  Select another branch, and your Xcode project workspace will be updated to reflect the current contents of the other branch.

When you are ready to merge a branch, switch to the branch you want to merge into first from the Organizer.  Then switch back to the project view,  and select File | Source Control | Merger from the Xcode menu.  Xcode will ask which branch you would like to merge into your current branch.

Xcode will then present a merge view, which will allow you to review each difference between the current branch and merge branch.

Use the sliders to selectively include or exclude changes from the branch in the merge.

If there is a conflict in the merge, the merge view will highlight the conflict in the merge view with red and a question mark in the center.

The merge view will offer four choices for resolving the conflict: keep both changes, placing the left before right, keep only the left changes, keep only the right changes, and keep both changes, placing the right before left.  In addition the code can be directly edited in the merge view.

KEEPING IN SYNC WITH REMOTE REPOSITORIES

As you make changes in your local working copy you will want to keep them in sync with the remote repository.  Xcode offers support for pulling from and pushing to a remote repository, and for tracking remote branches.

There are two ways to pull from a remote repository. The first is from the project window.  Select File | Source Control | Pull from the Xcode menu when viewing a project window.   If there are no uncommitted changes in the working copy, Xcode will present a dialog to select which remote and branch to pull from. (Note that a pull can be completed using command line Git when changes are present, but Xcode will not pull with uncommitted changes in the working directory.)

Alternatively, the Pull button from the Organizer Repositories view can be used when a working copy is selected.

If a conflict is detected on the pull, Xcode will present the merge viewer to resolve the conflict.  Just like resolving a conflict between branches, the merge viewer can be used to select which change(s) should be kept and in what order they should be if both are desired. If you do not want to resolve the conflict, click the Cancel button in the merge view and the pull will not take place.

If the conflict is resolved, the working copy will be modified and will need to be committed and pushed.

To push changes to the remote repository, select File | Source Control | Push from the Xcode menu when viewing a project window.

A branch can also be pushed to the remote repository.  Xcode will detect if the branch does not yet exist in the remote, and will indicate if the branch will be created by a push.

Once a branch has been created on the remote repository, other working copies can track that branch.   To track a branch, visit Organizer, Repositories, and select Remotes for the project repository.  Expand the remote name to see the available branches.  (In my testing, I was not able to get Xcode to refresh remote branches without restarting Xcode).

Select a remote branch and click the Track Branch button at the bottom of the view.  This will pull down the branch from the remote repository to the local repository, will allow you to switch to the branch in Xcode, and will allow pulls and pushes to take place from it.

SUMMARY

As we have seen here, Xcode has very usable support for common Git tasks, including setting up Git for a new project, cloning an existing project, handling modifications and commits, viewing history, using branches, and pushing and pulling from remote repositories.  Xcode does not have direct support for stashing, tags, or more advanced topics like rebasing or submodules.  However, all of the items that Xcode does not support can be performed using the command line tools or using a third party tool.  In my day to day work with a distributed development team, I am frequently able to perform all of my Git tasks in Xcode, and only rarely need to resort to the command line.  Take a second look at Xcode’s Git support if you have not done so before, and give feedback to the Xcode team so they can keep enhancing and improving Git support in Xcode.

1. A happy chord progression in a major key
2. A simple drumbeat
3. A glockenspiel sound

And now I present to you, Creating a Happy Appy Song

[ylwm_vimeo height=”400″ width=”600″]66576979[/ylwm_vimeo]

Several responses suggested taking things into my own hands by rolling my own logging mechanism when building an app I intend to ship. I think this is likely the approach I will take in the future, however, it doesn’t help my immediate problem. How do I get crash logs from an app I already shipped that is running on client’s device not physically located near me? Here’s a summary of what people suggested. Drill down in the settings app and copy the contents of the crash log like this (click/tap to enlarge):

Then, paste that into an email:

Then you can send the crash log to any email address you specify.

It certainly is not a pretty approach, but it will get the job done.

Thanks to the folks who responded to my call for help, @davidiom, @therealkerni, @thenighttrader, and @rckoenes. I appreciate it!