MacBook 2015 released with 12″ Retina Display. My Thoughts & Comparison

design_retina_large

On 9th March 2015, Apple announced (among other things…) an all new MacBook, I won’t go into the marketing details as you’ll find those everywhere else. Essentially however its an ultra low power, ultra light, 12″ MacBook with a Retina Display. As a heavy 11″ MacBook Air user I can confidently say I think they’ve really pulled it out the bag this time.

Firstly looking at the overall dimensions of the 12″ MacBook I was very surprised to see its smaller than the 11″ Air (just about) in every dimension, whilst also being lighter and having a 1″ bigger display.

Device Height Width Depth Weight
2014 MacBook Air 11″ 0.11-0.68″ (0.3-1.7 cm) 11.8″ (30 cm) 7.56″ (19.2 cm) 2.38 lb (1.08 kg)
2015 MacBook 12″ Retina 0.14-0.52″ (0.35-1.31 cm) 11.04″ (28.05 cm) 7.74″ (19.65 cm) 2.03 lb (0.92 kg)

To summarise, the thinnest part of the MacBook is thicker than the thinnest part of an Air by 0.05 cm (which perhaps is a good thing if you’ve seen how thin and almost transparent the MacBook Air 11″ display is) and its slightly deeper, apart from that its almost identical in its dimensions, which is great if (like me) you’ve invested in bags/sleeves and the likes, all your non-technical accessories will still work.

Additionally its battery life estimates and tech specs are very comparable if not identical to the battery in the 11″ MacBook Air. Meaning you get your retina display without any compromise… Except one…

The next part of this post is purely speculation until proper benchmarks arrive, however, after some digging into the Intel Core M, i’ve noticed only 5 Broadwell architecture CPU’s exist and one in particular matches the top spec CPU mentioned by Tim Cook in the Apple Keynote almost identically. I’ll take a look at that top spec CPU vs the top spec CPU of the 11″ MacBook Air.

Device CPU Power Cores Benchmark
2014 MacBook Air 11″ Intel Core i7-4650U 15W Max TDP 2 (4 logical) 4156*
2015 MacBook 12″ Retina Intel Core M-5Y71 4.5W Max TDP 2 (4 logical) 2780*

* according to cpubenchmark.net

What this shows is the 2014 MacBook Air 11″ in its top spec config scores 66% higher than the 2015 MacBook 12″ Retina. However what it shows me is that trade off has been made in choosing an ultra low powered CPU to maintain battery life whilst giving the user a Retina Display. Remembering, the benchmark used isn’t a real world scenario, its more of a point scoring benchmark and additionally, I have no idea what CPU the new MacBook 12″ Retina actually uses… This is just an intelligent guess. Interestingly again, both CPU’s support up to 16GB Memory, however the configs at Apple top out at 8GB.

Nevertheless if price wasn’t a factor, it’d be really tough to choose an MacBook Air 11″ over a MacBook 12″ Retina. Having a black bezel, retina display, edge to edge keyboard really sells it here for me. I was happy with the existing size of the MacBook Air 11″, but every little helps. Mondays keynote was the first time I truly agreed with and believed Jonny Ive when he said something along the lines of “we’ve really tried to optimise the efficiency of the MacBook’s design as much as possible”.

 

The next thing that sparked by interest was the inclusion of USB-C for… everything, (for those who don’t know, its a new USB standard that allows power, data + different standards over a single cable). I travel a lot and although my Air rarely runs out of a battery when i’m out of reach of a power outlet, its interesting to think that you could buy a 29$ USB-C to USB cable and potentially charge your MacBook 12″ Retina using the same portable battery pack you use to charge your iPhone / iPad, it is to be confirmed, but i guess it wouldn’t be reaching far to expect this. UPDATE: I can confirm you can charge your MacBook 12″ with a portable battery pack you use for your iPad/iPhone. 🙂

Power pack charging MacBook

 

[follow_me]
Those are my initial thoughts beyond the keynote and various tech blog info out there and i’ll try to update this post once my Space Grey top spec MacBook 12″ with Retina Display has arrived and i’ve (with sentiment) retired my trustworthy and fantastic MacBook Air 11″.

 

SuperRecord an ActiveRecord implementation in Swift

All the media buzz around swift seems to be having some tangible effect. I won’t go into the opinionated slaw of Swift VS Objective-C VS Swift VS XYZ here :). Many of you know I freelance in the iOS space around London and beyond for SuperArmstrong and one of my recent clients asked me to work on a greenfield project to replace a very old wrapped web app they had. When we got down to the nitty gritties, one of their few requirements was that it should be written in Swift. My jaw did drop a little… considering this was about 20 days after Swift had first been publicly announced. After some conversation, we came to the mutual conclusion that they were brave.

Like many of the apps I work on, this project relied heavily on CoreData, as a convenience I decided i’d try out a library that I have a lot of respect for (even though its had its challenging moments) “MagicalRecord”, having only done organic CoreData for the past few years. As you probably know, Objective-C and Swift can sit alongside in a project and work in unison… however, not all the interoperability is 100% sound. I soon started to endure strange bugs and thanks to the incompleteness of Swift lldb support at the time (especially when mixing with Objective-C) these bugs soon became quite difficult to track down.

The most annoying was this:

let entityDescription = NSEntityDescription.entityForName("Pokemon", inManagedObjectContext: context)

Although harmless… this would actually fail when trying to insert an entity of that description into your managed object context. The culprit here? the NSString to String bridging (or vice versa).

To get around this bug (which I won’t go into too much detail) I began using:

let entityName = "Pokemon" as NSString
let entityDescription = NSEntityDescription.entityForName(entityName, inManagedObjectContext: context)

Performing a forced downcast to NSString. So great, now it works… However, many of the MagicalRecord finders and helpers I was using, would not have these forced downcasts as they came from the Objective-C world. I first forked MagicalRecord, after delving into the source-code, making many changes for better Swift support, fixing some threading irregularities I then realised I was putting a lot of work into making something work that had more functionality than I required at the time. So I embarked on making a Swift ActiveRecord style “companion” to CoreData.

The reason I say “companion” and not “wrapper” is that I didn’t want to abstract away CoreData too much or remove the power from the hands of the developer. I wanted to make the developer’s life easier, whilst maintaining their flexibility.

I’d much rather do something like this:

let pokemon = Pokemon.createNewEntity() as Pokemon

and avoid the above lines + more.

Thereby SuperRecord was born. The original goals for SuperRecord were simple.

  1. Give me the ActiveRecord style finders I crave, optimise them, keep my application level code tidy, but still performant.
  2. Rather than me typing out the same code in each project to handle batch updates on my UITableView and UICollectionView classes, have a special “one size fits all” class that will act as your NSFetchedResultsControllerDelegate, providing “safe” batch updated to your reusable views.
  3. Additionally, I didn’t wanna have to spend too much time creating NSFetchedResultsControllers all the time either, so I added some helpers for this too.
  4. Be written in Swift, keeping the public API’s simple and stable, but changing the implementation as Swift changed and moved with updates.

In late October 2014 whilst still very much a work in progress, I released the first public version and it was featured in the great iOS Dev Weekly newsletter. I decided to release it early as I saw a lot of discussion around CoreData and Swift and thought there’d be a lot of people interested in this OSS effort, so we could build up a good toolset as a community. I’m still the only maintainer… (not by choice) but its early days :).

Below is some extract from the README.md but I suggest you head over to the project on github for more information and feel free to checkout the demo project also on github which shows how to use the safe batched updates along with some other common tasks.

 

Core Files

  • NSManagedObjectExtension.swift This extension is responsible for most of the “finder” functionality and has operations such as deleteAll()findOrCreateWithAttribute()createEntity() and allows you to specify your own NSManagedObjectContext or use the default one (running on the main thread).
  • NSFetchedResultsControllerExtension.swift In constant development, this Extension allows the easy creation of FetchedResultsControllers for use with UICollectionView and UITableView that utilise the SuperFetchedResultsControllerDelegate for safe batch updates.
  • SuperFetchedResultsControllerDelegate.swift heavily inspired by past-projects i’ve worked on along with other popular open source projects. This handles safe batch updatesto UICollectionView and UITableView across iOS 7 and iOS 8. It can be used on its own with your NSFetchedResultsController or alternatively, its automatically used by the NSFetchedResultsControllerExtension methods included in SuperRecord.
  • SuperCoreDataStack.swift a boilerplate experimental main thread CoreData stack. Can be used either as a sqlite store or in memory store. Simply by calling SuperCoreDataStack.defaultStack() for SQLite or SuperCoreDataStack.inMemoryStack() for an in memory store. Of course you have access to your context .context / .saveContext()

Usage

Create a new Entity

Assuming you have an NSManagedObject of type “Pokemon” you could do the following

let pokemon = Pokemon.createNewEntity() as Pokemon

Please add @objc(className) above the class name of all your NSManagedObject subclasses (as shown in the demo project) for now. Better support will be coming in the future.

Creating an NSFetchedResultsController

This feature is currently in progress with basic support so far, in future versions, sorting and sectionNameKeyPath’s will be supported. Until then you can create your own NSFetchedResultsController, however, if you have no need for the above missing functionality then simply use

lazy var fetchedResultsController: NSFetchedResultsController = self.superFetchedResultsController()

func superFetchedResultsController() -> NSFetchedResultsController {
return NSFetchedResultsController.superFetchedResultsController("Pokemon", tableView: tableView)
}

With Pokemon being the entity name of your NSManagedObject.

Delete Entities

I’m planning on adding much more powerful functionality around Delete soon, such as deleteAllWithPredicate() or deleteEntity(), right now all that is available is

Pokemon.deleteAll()

Method Listing

This isn’t an exhaustive list of all methods and classes, however it includes some of the most useful ones.

  • NSManagedObjectExtension
  • findAllWithPredicate(predicate: NSPredicate!, context: NSManagedObjectContext) -> NSArray
  • findAllWithPredicate(predicate: NSPredicate!) -> NSArray
  • deleteAll(context: NSManagedObjectContext) -> Void
  • deleteAll() -> Void
  • findAll(context: NSManagedObjectContext) -> NSArray
  • findAll() -> NSArray
  • findFirstOrCreateWithPredicate(predicate: NSPredicate!) -> NSManagedObject
  • findFirstOrCreateWithPredicate(predicate: NSPredicate!, context: NSManagedObjectContext) -> NSManagedObject
  • createNewEntity() -> NSManagedObject
  • findFirstOrCreateWithAttribute(attribute: NSString!, value: NSString!, context: NSManagedObjectContext) -> NSManagedObject
  • findFirstOrCreateWithAttribute(attribute: NSString!, value: NSString!) -> NSManagedObject
  • NSFetchedResultsControllerExtension
  • superFetchedResultsController(entityName: NSString!, collectionView: UICollectionView) -> NSFetchedResultsController
  • superFetchedResultsController(entityName: NSString!, tableView: UITableView) -> NSFetchedResultsController

NSFetchedResultsControllers created using this method will automatically handle safe batch updates.

Developer Notes

This whole project is a work in progress, a learning exercise and has been released “early” so that it can be built and collaborated on with feedback from the community. I’m using it in a project I work on everyday, so hopefully it’ll improve and gain more functionality, thread-safety and error handling over time.

The next key things to be worked on are Optionality (as this has changed in every Swift BETA), the CoreDataStack, adding more finders with more functionality and improving the NSFetchedResultsControllerExtension.

 

 

Brisk a simple lightweight Networking Framework written in Swift


This is gonna be a short and sweet blog post… I’ve been working on a little pet project to practise and learn some Swift, so I thought, what do I use the most in projects these days… its networking. I’ve published on github.com my first attempt Brisk, its no where near complete and only has basic functionality right now, but if it becomes interesting i’ll pick up the effort and add more, until then, its a great educational exercise, you can check it out here and be sure to contribute back 🙂 it should work on both OS X and iOS and is MIT Licensed.

 

Reading Linux extfs (ext2/3/4) in Mac OS X

I have a collection of both Mac OS X and Linux servers dotted around the place… Sometimes I need to read ext4 formatted drives on my Mac’s… this always proves an annoying problem where I have to mount them inside a Virtual Machine and copy things across…. Pain and Slow!

I searched the interweb for a solution to this… and most  guides are about 3 years out of date, so here’s one from 2013 that works on Lion / Mountain Lion and even Mavericks DP1/2.

Download and Install : OSXFUSE-2.5.4.dmg (this took off where MacFuse left off and even has compatibility for old MacFuse plugins).

Download and Install : fuse-ext2-0.0.7.dmg

Plug in your ext fs formatted drive… Voila! I wouldn’t rely on this in a production environment mind you… but its decent if you just need to grab some files from a USB drive quickly for example.

 

Instantly gain insight on someone else’s iOS App Architecture with MADebugTools

Just a quick post to say i’ve posted my first piece of code in over 5 years to GitHub. Its a clever little Objective-C iOS Category on UIViewController that seemlessly overlays a UILabel on every single view controller managed view with the class, nib or storyboard name that is used. Great for debugging old or inherited projects with minefield architectures. It uses some cool libobjc runtime techniques to accomplish this, but implementing the category is a case of dropping it into your project and Build+Go!

Category in Action

Grab the source code here as usual, follow me @italoarmstrong on twitter 🙂

 

 

Asus EeePC S101 to Asus Macbook Nano OSX86

Ever wanted to turn your boring netbook into a fully fledged lively Macbook Nano, the worlds smallest Mac OS X powered machine!?! well now you can! The how to below covers all the aspects of getting Mac OS X 10.5.6 Leopard working on your EeePC S101, but should work similarly with any Atom CPU, Intel Chipset Netbook. The best thing about all this is that Mac OS X is IPV6 enabled out the box!

Firstly, the finished product.

Macbook Nano on an Asus EeePC S101

Asus EeePC S101 Sideview

Out the box most things work, however once a little tweaking has been done the following are fully working:

  • Sound (Output Only)
  • Graphics (With Quartz Extreme)
  • Network (WiFi Only)
  • Hotkeys
  • Sleep
  • Battery Indicator
  • Bootup / Shutdown
  • Speedstep (battery life)
  • + Anything else i can think of… …