Here are the details of the upgrade:

Fixed Bugs

• Changes for iPhone OS 3.0 compatibility and stability (sorry about the crashes).
• Fixed some minor display glitches.

Features Added

• A new icon for flipping back to the front of the application.

This release is really only a bug fix release. I intend to add some cool new features in 1.3.0 in the near future. If you have features you’d like to see in a future version of the application drop me a comment.

You can find information about other releases on the Fairway release notes.

Here are the details of the upgrade:

Fixed Bugs

• Loading of editors now properly animates keyboards and other controls.
• On the main screen the list of clubs now cleanly displays and doesn’t jump around when few recommendations are displayed.
• Fixed issues that may be encountered in low memory situations on the device.
• Occasionally Fairway wasn’t recommending the ideal club when small changes were made to the distance slider.

Features Added

• Management (create, update, delete, and reorder) of custom course locations and easily filter swings on them from the main screen. Touch and swipe within a cool new locations chooser or touch the buttons on the left and right to move through the list of locations. Touch a locations name to filter on that type.
• Adjusted font sizes to allow more data to be displayed.

I wanted to thank the users whose feedback went into this release. I know it’s been a few months since the last release but look for more changes and exciting features to arrive soon. I’m constantly trying to make this application the best it can be and welcome new ideas and comments.

You can find information about other releases on the Fairway release notes.

Update: Version 1.2.0 has been approved and should now be available in the AppStore now.

Last evening I was working on some new image effects in my new iPhone application (details coming soon) and decided to try to implement this effect for use on the iPhone using Core Graphics. I used the python code from Gus as a foundation and converted it to a Core Graphics effects class which I’m calling WAImageDropShadowEffect. This class can be generically reused on the iPhone to recreate this effect for any image by using this effect class to draw from your UIView.

Below is a picture of the sample application I put together showing off this new effect:

I’m hoping Gus and Sebastiaan don’t mind the reuse, I’ve made sure to attribute them in the sample.

The license is pretty much wide open so long as you retain the disclaimer. You can download this code from our open source section or via subversion here:

svn co http://svn.wideasleep.com/public/trunk/

After you take it for a swing let us know what you think or visit the Fairway community. We’re always happy to hear from our users. We’re currently working on version 1.1 which will include customizable shot locations, club fade/draw bias, and a number of other user requested features.

I’ve been meaning to put together a posting entailing my journey to 1.0. Needless to say it’s been 2 months and I’ve recently released version 1.0.2. Despite Matt Gemmell beating me to the punch, and writing an great article, I felt that it was finally time to write-up my experience.

Backstory

One of the principle drivers for why I write software applications is to solve interesting problems or make my commonly performed activity easier. If I consider myself an average person then I will in turn be solving a problem that others are having as well.

I’ve been a golfer for nearly 20 years now. Of that time I was a caddie for about 7 years as well as the recipient of the Evans Scholarship. During my time as a caddie I developed an appreciation for the decision making process involved in club selection. The casual observer (and likely the higher handicap golfer) would see the problem as simply your X yards from the hole which means you use club A. What they aren’t likely factoring in is the wind, temperature, location, environment of the ball (grass height, dirt on it, etc), pin position, landing area on the green, line of sight, etc. Any number of factors are involved in selecting the right club to use in making a “golf” shot which aren’t immediately obvious.

Personally I enjoy attacking most things in life analytically, and golf is no exception. I think this analytical approach is was why I’ve been drawn to the Pelz school of swing thought. In his book, Short Game Bible, Pelz provides a detailed analysis of the technique he’s evolved over the years to improve shotmaking. He recommends creating a single consistent swing tempo and then dividing that swing into 4 different sub-swings by varying the distance one takes the clubs back and through the ball. Using this technique you can take your short game clubs (Gap Wedge, Sand Wedge, Lob Wedge, X Wedge) and extrapolate 16 (4 x 4) different swings that will go 16 different distances thus giving you the ability to attack the pin from almost anywhere under 100 yards. There are slight variations you can make to this swing to handle other obstacles like sand or deep grass but the foundation of the approach is simple, consistent tempo combined with 4 distinct swing distances. It’s this simplicity that makes the Pelz approach interesting.

Now imagine taking this Pelz approach and applying it to your entire swing. Not all clubs need 4 swings but lets say you have 2 per club that aren’t short game clubs. That’s (14 – 4 – 1 (putter)) = 9 x 2 = 18 swings. Doing simple math we now have 18 + 16 = 34 swings for attacking a normal game of golf. Wait, what about those other situations I talked about earier? Hitting into the wind? In the rough vs. the fairway? Sand? Lets suppose that you have 2 more swings for each of those situations … that’s 9 x 3 x 2 = 54 more swings, add that to our current 34 and you have 88 swings. What I hope your quickly seeing is one of the problems that Fairway is attempting to solve. You quickly cringe at the mountain of numbers you need to remember extrapolate this technique to your entire game. Even if you don’t agree to applying the Pelz approach to your entire game just about any golfer will admit that there are a huge number of swings involved in playing golf that Fairway can help manage.

Paper Fairway

My first attempt at solving this problem was low-tech. I did what any card carrying 43 folders reader would do, I used an index card!!! Actually I used grid index cards on which I created rows for each club and then columns for each swing. This worked well for each of the simple swings but quickly got out of hand if you tried also handling various location based swings. Then there was the wear and tear I hadn’t accounted for on the cards from constant holding and putting in my pockets. Each card lasted me 2-3 games of golf and I either lost it or it was beaten to a wrinkled pulp. Losing it was obviously bad as I lost important data about my game.

Design via Moleskin

My second attempt at solving this problem was high-tech. I did what any good Apple developer would do, I wrote an iPhone application. Before I get ahead of myself though I did start designing Fairway in low-tech way, sketching in my Moleskin. Below are some of my initial sketches:

As you can see from the first image I tried directly applying the grid technique to the primary view on the phone. The obvious problems with this are that the iPhone doesn’t have the horizontal room to clearly display 4 columns along with club information. Even if icons were used it would have been a very busy view and it was hard to figure out how to handle more than 4 swings per club within this layout.

You can also see in the first image some ideas on swing icons as well as paging controls for bags. I wanted to be able to mange more than one bag of clubs at a time.

In the second image you can see my initial design for the primary views rounded corners along with initial thoughts on a vertical distance scrubber. While it would have been more precise using a vertical scrubber (longer distance to slide) I had issues with cleanly laying out the other controls needed for the current and future versions of the application with this layout.

Early Design & Revisions

Once I had done some sketches and played around with the beta versions of the iPhone SDK I began coding up some initial screens. At the same time I started coding I began talking with Fernando Lins about creating graphics and to get feedback from a designer on my UI. Here are a few of our early mockups.

I’m willing to bet you can easily identify the ones designed by me and those designed by Fernando. While I’m “decent” at designing and laying out user interfaces I’m not a professional designer. It’s however important to realize a few things about revising and designing your early user interfaces.

First and foremost your initial designs should try almost everything that comes to mind. Enter your early brainstorming sessions with your mind open to any and all possibilities because you never know what path a design will take you down. As you can see from my early mockups I was still stuck on the grid design. What was highlighted from actually mocking it up was how tight the iPhone 320×480 screen is (funny considering it’s the largest screen out there). I really wanted to try implementing it on the device despite the fact that I thought it wouldn’t work. It taught me quickly about what I as a golfer wanted and needed to see in this first screen which was detailed club information. Quickly and succinctly seeing the swing, club, and distance information was far more important than seeing everything possible on one screen.

The second thing to realize when designing and revising your user interfaces is how important it is to involve a graphics designer early in your development process. I know other people have said the same thing but it bears repeating. Not only do they bring color and spacial design experience to the table but they really start visually extracting some of the essence of your application in ways that you likely can’t do on your own. For me it was a huge motivation during development to see high quality design mockups of my application. The earlier you engage a designer the earlier you’ll being to see the reward.

Interaction Design

Whenever I’m working with someone on a user interface one of the first things I try to do is make them forget about the computer and show or draw the problem for me. I know this sounds simple, but how often have you actually done it? What I usually find is that I can solve the problem in a way that is comfortable and meaningful to the user and not an obvious product of a developers interpretation of the problem.

For Fairway I had to put myself in the shoes of the user being sure to put myself into the environment in which Fairway was to be used, on the golf course. What I wanted first and foremost was to see all of my swing options as quickly as possible. To me this translates into the smallest number of interactions with the richest set of usable data possible.

Interaction with an iPhone or iPod Touch requires pressing the on or home button and then a single slide to unlock the phone which I had to take into account if I wanted my users to use Fairway ~ 50+ shots per round, more like ~70+ if they use it for putting as well. From here I assume Fairway is running so I wanted to allow them to find their club in 1 – 3 additional clicks depending on details. The primary control for Fairway is the distance slider which is used to dial in the distance from the pin. The secondary control (along the bottom) is a location filter which allows you to quickly reduce your swing options based on preassigned swing locations.

In the above screenshot you see the primary, secondary, and detail controls highlighted. In it you can clearly see that the controls them selves are larger than they seem. Each and every controls size and position was meticulously selected, tested, and reselected to get what you now see.

• The distance slider being the primary control is likely the first control the user interacts with is easy to hit and prominent. Also important to note is that a user is likely using their thumb to interact with the distance slider. Given this, their thumb should not hide the distance label which is just above the slider in large easy to read text. In the initial mockups above you can see that their thumb may have covered their distance.
• The secondary controls seem like simple text labels at first but are in fact buttons that are larger than their text making them easy targets yet not cluttering the view.
• The swing details control, which is much larger than the icon itself, flips up the list (like in Maps) and shows club & swing details when pressed. This also happens when a recommended or other club is touched in the table.
• The gear settings control which I use instead of the “i” icon you see in most applications is the only exception to the rule in terms of size. It’s still plenty large to hit when your intending to but I wanted to make sure it wasn’t accidently selected during play so it’s a bit smaller than the details control button.

At the last C4[2] conference the keynote talk was given by Craig Hockenberry. During the talk he really drove home that this device is not a laptop and that designing software for the iPhone is different than other devices or computers we’re familiar with. He also reiterated something I had been trying to do which was design the software by actually using it. I know it sounds simple but so many apps in the AppStore seem like they missed this step.

I do have to admit though that I missed something fairly important in Fairway until I used it one day at the range. It somehow slipped my mind after playing golf for 20 years that we wear a glove on the course (not usually while putting though). Gloves are typically worn on the hand opposite our dominant hand and are used to improve control over the club. Since I’m a right handed person I wear my glove on my left hand which is also the hand I primarily use for my iPhone. This poses a problem since you can’t use the iPhone wearing a glove. I now had to take into account that my application was going to be used in the hand opposite that which most users were comfortable. To address this potential problem I made the distance and detail controls invertible on the main screen (flipped left to right).

It’s a small touch but if it makes a small fraction of my users a bit more comfortable with my application I’ve done my job. Thanks to Twitteriffic and Craig for the idea of control inversion.

GPS Not Included

I wanted to take a second to address some initial shock people had using my application at first, there’s no GPS. I know it may seem forboden for an iPhone application to not be tricked out with every bell and whistle. My primary concern with writing Fairway was quickly recommending clubs and swings to use. I don’t want to detract from the beauty and grandeur of the game by playing with your iPhone waiting for the GPS to attain a lock. It can sometimes take minutes to get an actual lock on your position, minutes you should be spending focusing on your swing. Also don’t forget that this application is designed for the iPod Touch, iPhone, and iPhone 3g. I’d lose 2/3 of that audience if I leveraged GPS to a huge degree.

Creating Custom Table Cells

After the data entry controls the most important view in the application is the club & swing list. In it the user can see all of the clubs and associated swings that are “usable” based on their distance and location information. This list needed to be clear in direct sunlight conditions as well as the shade you may encounter on the course.

As you can see I chose a slight white gradient behind the default cells with dark green text for the text. I did this to add some textural perspective and dimension to the interface itself. I think it looks clean and offers subtle hints to touch it. Adding these effects also helps them clearly see the data in both bright and shady situations by adding contrast to the contained text and graphics. The recommended swing (green) and touched swing (blue) are drawn using the CGGradientRef Core Graphics API. Though the original gradients were designed by Fernando I chose to render them using code instead.

Within each row is a swing icon that can have optional text associated with it. It also contains the name, brand, and model of the club associated with that swing. Finally it contains the distance you can hit that particular swing in the selected format for the user (yards, feet, or meters). This is all of the information a golfer needs to identify the swing type (icon & text), club, and expected distance the swing is meant to produce.

I tried to give people a huge selection of icons to use to represent their swing. Because I didn’t know what creative ways people might come up with to help them remember their swing I provided 1/4, 1/2, 3/4, and 4/4 (full swing) icons as well as a large set of gem of various colors and shapes.

Because of the variety of icons and the fact that I allow text (2-3 characters) to be entered on both dark and light icons I had to figure out where the text was being drawn and then make the text and shadow an appropriate color. This enabled the text to be easily and quickly readable in any situation. It’ a small detail that can have a dramatic impact in terms of usability.

Rounded Tables

My goal for the list view was to make it familiar and fun to use. The first app in my mind that was easy and fun to use on iPhone OS 1.0 was the Stocks application. I really enjoyed how you could slide that list up and down and not only would it bounce but it would appear to be etched/sunken into the background because the rounded edges were always visible. I thought for sure that Apple would have this in their SDK and smiled when I saw the UITableViewStyleGrouped style. I was then immediately disappointed when I saw that it didn’t have this expected behavior. This left me with no options in the early NDA days to do anything but to roll my own. If you look at my sketches up top you can see I had thoughts of an early version sketched out. Here is how it was finally implemented.

In this image I’ve highlighted four small views that are positioned above the UITableView. The background of the view is clear and the arc and the area opposing the table is filled in black. An example of the code needed to draw the upper left arc and to fill it is:

CGContextRef context = UIGraphicsGetCurrentContext();
CGContextSaveGState(context);
[self.color set];

CGContextBeginPath(context);

if (WARoundedTopLeftCorner == self.position) {
  CGContextMoveToPoint(context, CGRectGetMaxX(rect)/2,
    CGRectGetMinY(rect));
  CGContextAddLineToPoint(context, CGRectGetMinX(rect),
    CGRectGetMinY(rect));
  CGContextAddLineToPoint(context, CGRectGetMinX(rect),
    CGRectGetMaxY(rect)/2);
  [WIShapeView addArcToPath:rect
                    context:context
                 startAngle:180
                   arcAngle:90];
}

CGContextFillPath(context);
CGContextRestoreGState(context);

Note – for the addArcToPath code see the quartz docs.

I chose to use code in drawing these shapes instead of using images because I could and I suck at most graphics tools. In fact wherever I could I chose to render something via code over using images. Obviously there are places I “could” have written code to render that I didn’t. It was more a comfort factor than an exact science. I chose to leverage Fernando on some of the larger problems and not these smaller ones.

Using the implementation of the overlay of the views on top of the table view will only work if the background color of the table view itself is set to black. This requires that you write a custom UITableViewCell to draw it’s background and inset it slightly so it looks like the grouped style people are familiar with. This will allow the table to slide under the corner views and give it the effect of being inset into the foreground much like the stock application. The only remaining piece of code to be done is to create 3 categories of table cells. Those cells that are at the top, middle, and bottom of the table. The ones at the top and bottom can reuse the view you created above to draw rounded edges on the top and bottom. This will provide the effect of the table being rounded on all sides. Be careful to put the rounded views at the far corners of the cells. You may need to play with the placement of all of the views to get them exact.

Crashing the UITableView

When a golfer is on the course they rapidly scrub in their distance from the pin and expect the table to update appropriately. My first implementation accepted real time updates from the slider and on each update added and removed the appropriate cells from the table view using animation. The code was straight forward enough except for one small flaw, it crashed the application after a few seconds of use. I submitted radar 6020225 detailing the issue with example code but it has yet to be fixed. I tried a number of creative ways to work around this problem but still keep animation and the real-time updating.

So what was I going to do? After meeting with Apple at number of different WWDC labs I finally got the idea to introduce an artificial delay that while not perceivable to the user would allow me to reload the table without crashing it. The code is rather easy using:

performSelector:withObject:afterDelay:

I introduced a 0.25 second delay and within the called selector I just setup the underlying data structures of the table and the told the table to reload. The unfortunate impact of this implementation is that it isn’t animated. While not ideal it is actually very performant and after using it for a long time I actually prefer it to not animate. The animation felt distracting at times and seemed to prevent the user from quickly getting their recommendation. Another note on this implementation, be sure to not enqueue all of the scrubber changes to the selector, if one is already enqueued then ignore the others.

One final thing I wanted to mention around the animation of the UITableView was performance. While it animated smoothly in the simulator (it still crashed) it was actually slow and dropped frames on the iPhone. Because the table wasn’t designed to be updates that quickly and the fact that I was trying to do it with animation in real-time caused it to stuttered and drop frames. I didn’t see this side effect though until after I tried running on the device. Don’t assume because you tested your application in the simulator that it will run just as well on the device. You will likely have to iterate to attain a solid user experience.

Tolerances

Something you may have noticed in the list view is that there are often many more swings shown than you might at first think are necessary. If the user selected 182 yards why are there clubs going from 162 – 202 yards. On the golf course there are other conditions like elevation of the green relative to the golfer, wind direction, etc. that are hard problems to solve in a user interface yet still need to be taken into account. Because of this I allow the user to select a tolerance for the application that is applied to their suggested clubs.

This tolerance allows them to see a wider range of clubs that they can mentally decide to ignore or perhaps use. I can’t make all of the decisions but I could help narrow down their options.

Many-to-many Relationship Editing

One of the larger problems I encountered with Fairway was managing the relationships between bags and clubs. Because I knew I wanted to give users complete control of how they grouped their clubs (into bags) I needed to ensure that the user experience was still simple yet powerful. To do this I wanted to allow them to add any arbitrary club to a bag and then when editing a club quickly see and edit which bags it was in. Below you can see an example movie that shows first adding an existing club to a bag and then going to that club and editing the bags that it’s in.

As you can see for the additive portion of bag and club management I leveraged the modal view functionality on the UIViewController. This encouraged a simple familiar workflow of choosing the item to add and then updating the list based on the selection. Everyone who’s used Mail for deleting or moving is familiar with this interaction. The only variability to the workflow was when adding a club to a bag I first had to ask the user if it was a new or existing club and act accordingly.

The other interaction when managing a many-to-many relationship is the deleting or removing from the relationships. When I first implemented this I used the built in delete functionality of the UITableView that everyone was familiar with. When you clicked the red minus button on the left it rotated and then presented you with a Delete confirmation button on the right. Simple enough but I was very bothered by something with this action.

The user was not deleting the club or the bag, instead they were “removing” the club from the bag or vice versa. It’s a subtle difference but a few of the people I showed it to thought it was deleting the club and were either confused or concerned about deleting. Unfortunately the current UITableView from Apple doesn’t support customizing the delete behavior or widgets. Again I had no other option than to roll my own.

I really liked the behavior of the existing delete interface and didn’t see the need to create a new technique and have to train the user how to use it to remove something. Because of this I simply strived to reproduce the existing behavior of the delete within a UITableView to manage my removal of clubs and bags. Sounds simple enough but here are the interactions:

• Switching into editing mode is the primary driver of showing the remove controls for the table. Mail has a swipe feature as well but for the purposes of this implementation I did not implement that behavior (due to release constraints but I will soon).
• Leaving editing mode should hide all editing controls and resets their state.
• The default editing state, lets call it the “zero” state, of the cell presents a circular remove button on the left and then some other content like labels on the right.
• Selecting the circular remove button should cause it to rotate 90° and at the same time reveal from the right hand side of the cell a confirmation button. During the animation all of the content on the right needs to also resize to make room for the confirm button. Lets call this the “confirm” state of the cell.
• Selecting a circular remove button in the confirm causes the right hand confirm button to reverse the animation and disappear while at the same time rotating the left hand circular remove button -90°, resizing all of the content to take up the new room, and placing the cell back into the zero state.
• Selecting the confirm button from the confirm state causes the row within the cell to be removed and appropriate action on some delegate to be performed.
• Selecting a circular remove button on any other cell should cause any cell that is currently in confirm state to animate out and back to zero state. At the same time it should transition that new cell into the confirm state.
• Scrolling any table should cause any cell currently in the confirm state to animate back into the zero state.

The simple elegant behavior that a user experiences while interacting with these cells is backed by a complex orchestra of interactions within the code. As you can see there were quite a number of behaviors that aren’t 100% obvious when you first use a table. Only after playing with them for a while was I able to note their exact behaviors and once I had recorded my observations implementing them was fairly straightforward. Here is a small movie showing the final interactions I described above using Fairways remove cell.

I think the hardest part of the implementation for me was getting the confirm button to reveal properly. I toyed with core animation on that buttons layers over and over again and was never able to get it quite right. It doesn’t slide in from off screen and it doesn’t just fade into being, it fades and reveals concurrently. I don’t know if this is considered a hack but I placed a small view where the button would reside, behind any views in the cell but above the z-order of the confirm button and then animated the resize left and right. The image below highlights where the view would have been in green.

If there are other more elegant ways of accomplishing this I’d love to hear about them.

First Launch

When the user first opens Fairway I thought it was important that they be able to see it in action in it’s full glory. The only real way to do this is to seed the users application with sample data. Because I thought it was so important I shipped the application with an entire sample database containing all of my actual club data. When the user first launches the application they are presented with this question:

Assuming they answer Yes they will have 17 clubs with 67 swings. Just as easily as they were added the user can goto the settings and remove them at any time. If they happen to choose No they will be presented with the following screen:

This is also the dialog they are presented with during normal usage of the application whenever Fairway can’t suggest a swing for their distance and filter criteria. It animates in from the top of the screen and centers itself within the list view. When criteria is entered that matches a swing it swoops off the screen out of view. Wherever possible I wanted the user to receive some type of feedback, even when I had nothing to show them. The more they feel at home using my application the happier they are.

The Grass is Greener

No golf application can be complete without a little flair. Throughout the use of fairway you’ll find bits of golf spread throughout. From the golf ball on the distance slider, to the club on the main screen to show / hide swing details, to subtle and not so subtle hints of grass throughout. When I was working on the application I used a number of different background textures for my club management views. From green pinstripes to the default gritty look I tried them all, that was until Fernando gave me something more. I wanted something to pop and yet really pull the user into the application, when confronted with this problem he gave me a nice grass texture to place behind my views.

It’s different and distinctive and I think not to distracting. I really love the color ranges of the iPhone and think using the grass texture really lends well to classifying Fairway as a golf application.

Wrapping it up …

I’ve covered a number of the features within Fairway in this article but I’ve mostly stuck to the challenging problems I encountered during it’s development. It really takes a lot of put together a complete application with all of it’s rough edges filed away. For me it took at least a month longer than I had anticipated. My release guidelines were very simple, don’t release with bugs. Not a single known bug or glitch of any kind, zero, nada. If you noticed it then odds are someone else will as well.

I had a bug at the end of my release that only occurred when you added and removed samples from the application more than 2 times. Despite the fact that this was something no one is likely to ever encounter I held the release a few days until I fixed it. Had I released with that bug, odds are that a user would have encountered it and they would have been the first comment on my application in the AppStore.

I appreciate that you’ve made it this far in the article. I really do enjoy sharing my ideas and solutions with people and hope you took some tidbits away from this article. If Fairway is an application you think you would like or want to support then you can read more about it or check it out on the AppStore.

My biggest goal releasing this application wasn’t just to release a golf application that I would use. It was to release a golf application I was proud of, one I didn’t cut corners on, one that I could recommend to any golfer with an iPhone. Heck even one I could recommend to someone interested in user interface design and interaction. I highly suggest you set similarly high bars for your release. It’s not enough to release an average iPhone application, you should instead strive to push the envelope and make your application distinctive and innovative.

Like most Apple users & developers I watched the recent announcements of new MacBook (MB), MacBook Pro (MBP), and updated MacBook Air (MBA) laptops with excitement. It has been a long time since Apple had updated the design of the MB and while the MBA V1 was nice but it had a number of public pitfalls. Needless to say Apple released some sweet new hardware that really pushed the design envelope and the lust factor of most users & developers.

After being bated with the new laptops I began asking around to see if anyone was interested in purchasing my 1.5 year old 17” MBP. Believe it or not I actually found someone quite quickly. They were interested in the 17” as a mobile video editing platform. The price was right and the timing was flexible, what more could I ask for?

I then began my usual death spiral of paralysis of analysis (as my friends kindly call it) where I overanalyze the new machines and my usage patterns. I went back and forth between the MBP, MB, and MBA. My primary requirements for a new machine are:

1. It had to be lighter than the 17”, commuting daily with that thing was becoming a chore.
2. My iPhone application development on Fairway (AppStore) and a yet to be released iPhone application couldn’t be negatively affected.
3. I didn’t want the overall quality of my mobile experience to go down. What I mean by this is the quality of the screen and overall hardware.

After analyzing the different machines for a week and half I had decided on the MB. It had mobile prowess and still appeared to have the development power and configurability I was looking for out of a laptop. It wasn’t until I actually used the machine at the Apple store that I actually decided on the MB. No I didn’t purchase it at that point, I had to wait until my buyer was ready for a swap. Needless to say I contacted him and setup a swap date after I decided.

Then a flaw in my decision was found, earlier this week I found this thread on MacRumors. The thread brought about a rather lengthy debate with a lot of detail about quality issues people have witnessed in their new MB laptop LCDs. While I was comparing machines at the Apple store my biggest complaint was that I was never able to actually see any of the machines side by side. I always had to walk back and forth which was distracting and really prevented a solid comparison. Anyhow, people were seeing huge differences in the quality of their displays and despite editing of the profiles the displays weren’t quite up to snuff with those in the MBA or MBP. One of my requirements of a new laptop was to not degrade my laptop experience and after seeing some of the screenshots I couldn’t chance it with the MB.

Fast forward (because this is getting kinda long) to Thursday evening I was awaiting peoples arrival of their new MBA. No one had actually seen one yet let alone actually ran any tests to compare their performance. I know I would have been happy with the new 15” MBP but I really wanted something lighter than the 17”, it was only 1 pound lighter.

On friday morning a MBA V2 early impression thread showed up on MacRumors along with a review … I was hooked. The specs looked awesome and the display was stunning. I began calling around and found that the Schaumburg IL Apple Store actually had the 128GB SSD in stock. I hadn’t decided on HD or SSD yet but them having it in stock pretty much decided for me. I had 3 days to buy a new machine and migrate all my crap to it in order to not lose the sale of my 17”.

Ok enough with the backstory already right? On to the review data. Remember, I’m migrating from:

17” MacBook Pro (Mid 2007)

2.4 GHz Core 2 Duo, 4MB L2, 4GB RAM, 800 MHz Bus, GeForce 8600M GT w/256 MB VRAM

to the new:

13.3” MacBook Air (V2.0 Late 2008)

1.86 GHz Core 2 Duo, 6MB L2, 2GB RAM, 1.07 GHz bus, GeForce 9400M Video w/256 MB VRAM

To start I did the usual Xbench comparison. Below are the numbers:

• MacBook Pro score 101.76
• MacBook Air score 131.98

You can also see them in a side-by-side comparison. What first struck me was that the MBA scored better than a beefier MBP, even though it was older it was unexpected. What you then notice (I knew this before hand before buying it as well) is that the performance of the MBA’s SSD skews the numbers a bit. Still surprising though is that the CPU in the MBA is no slouch beating the MBP in threading, computation, and a number other tests. That combined with a very solid graphics card in the new GeForce 9400M and this machine is “on paper” a knockout. What about actual usage?

Enter Xcode, my primary mobile computing application. While I use my computer for a number of things I spend most of my productive time writing code in Xcode working on Fairway and other applications. To perform this test I figured I would first compare my iPhone application and then a beefier mac application, Adium.

First Fairway @ ~28,000 lines of code. I’m compiling this iPhone application into Debug mode for the Device (which includes compression and signing):

MacBook Pro

19 seconds (fresh Xcode start)

13 seconds (clean all and then recompile)

MacBook Air

15 seconds (fresh Xcode start)

15 seconds (clean all and then recompile)

Not too shabby … the MBA performance is consistent and generally no change when compared to the MBP which is again surprising and perfect for my needs. Now on to Adium … I did a subversion synch to the latest version on the intertubes:

svn co svn://svn.adiumx.com/adium/tags/AdiumX_1.3.2 adium-1.3.2

I then compiled using the default settings, changing nothing at all.

MacBook Pro

170 seconds (2m 50s, fresh Xcode start)

179 seconds (2m 59s, clean all and then recompile)

MacBook Air

219 seconds (3m 39s, fresh Xcode start)

219 seconds (3m 39s, clean all and then recompile)

This test really put the machines to the test causing both of their fans to kick in at about the two minute mark. It also begins to highlight the CPU differences between the MBP (2.4 GHz) and the MBA (1.86 GHz). I was surprised that they were as close as they were to be honest and expected the MBP to handily trounce the MBA by a factor of two. One thing I did notice while running these tests was that the MBA “seemed” to perform the copy phases of the build faster than MBP, again the SSD comes to the rescue. I think this helped it keep up with the MBP as the Adium project has a lot of resources being copied around to build that awesome chat application.

Now on to a few fun tests. A number of people had seen issues with MBA V1 dropping cores and frames while running many videos and wanted to know how V2 would behave. The common test apparently was to run 3 YouTube videos concurrently and the check out iStat Pro and then watch the cores, temperature, and fans. Here are the results from running this test:

Temperature

72-78 degrees

Exhaust Fan RPM

2945 – 6040 RPM (beginning to end of 3 videos)

CPU

User 40, System 11, Nice 0, Idle 49 (during tests)

I ran the test on 3 random videos that were around 2 minutes each. I didn’t notice any cores drop out and the only odd behavior was that the fans kicked in after 2 of the videos finished and the final one was still playing. I think it was just timing as the RPMs were slowly climbing on the exhaust fan.

Finally I wanted to see how the MBA would hold up while playing WoW (World of Warcraft). I know, this isn’t a gaming machine but that doesn’t mean I don’t want to play an occasional game. These test were performed in Orgrimmar last night during a lot of Halloween festivities so a lot of effects were being rendered onscreen.

WoW Max Settings 1280×800 (Shadows Off, video)

79 degrees, Fan @ 6200 RPM, Video 17-27 FPS

WoW Max Settings 1024×768 (Shadows Off, video)

78 degrees, Fan @ 6200 RPM, Video 22-29 FPS

WoW Medium Settings 1280×800 (Shadows Off, video)

77 degrees, Fan @ 6200 RPM, Video 18-29 FPS

Again, they were much better than I expected. I could actually easily play WoW with the MBA!! I ran the tests for about 30 minutes tweaking the settings repeatedly. The medium test gave the best overall experience in game. This is especially true when you go to lesser populated areas, the FPS shoots up even more.

Finally some random tidbits of data and commentary:

• Startup of my MBP takes 95 seconds while startup of my MBA w/SSD takes 25 seconds.
• Shutdown of my MBP takes 10 seconds while shutdown of my MBA takes 3 seconds.
• The MBA drives a 24” cinema display quite well. It never froze or crashed (some people reported problems with V1 of the MBA)
• I migrated all of my data having the USB ethernet dongle connected to a powered USB hub along with keyboard, mouse, and USB HD all connected to the MBA single USB port. It was smooth and the overall throughput was good. I’ll try to do some USB networking tests and report back the results.
• The angle of the MBA keyboard is much easier on the wrist than that of the MBP. Makes for writing blog entries and code easier on the body.
• Remote disk works great mounting the DVD drive of a new model iMac (my wife’s). For reference I have a gigabit network in my home.
• The backlighting of the MBA keyboard is far superior to that of the older MBP. It’s attractive on the black keys and highly usable.
• I ran PiXel Check and I have no dead or stuck pixels, a pristine display.

In summary I really enjoy the new MBA and recommend that people really consider it when purchasing their next laptop. Apple seems to have addressed a lot of the issues with the first MBA release. For me it’s quite a change from the screen size of the 17” MBP but once I was past the initial shock the rest of the experience was flawless. The MBA addresses all of my requirements for a new mobile laptop. I’m able to continue development on Fairway and other applications, commute with less weight, and the design / hardware is top notch. The screen has amazing color ranges, I can still play games, videos are smooth, and damn it’s a nice looking machine. All in all a great machine that I highly recommend.

Note – If there’s something you’d like me to test just comment below and I’ll see what I can do.

Update 1

Some people asked that I run MSR Tools. It’s a tool that lets you see the Actual CPU usage of your cores on the MBA. It really allows you to see some of the problems like core drop or CPU throttling that were occurring in V1 of the MBA.

After running it with a the “/dev/null” test (two Terminal windows running yes > /dev/null) I saw the following:

CPU 1

800 MHz – 1.86 GHz

CPU 2

800 MHz – 1.86 GHz

After running the first null test the first CPU pegs to 1.86 GHz. Upon launching the second window the CPU begins to fluctuate between 800 MHz and 1.86 GHz. This confirms what NC Macguy is seeing as well. He also ran another test with 3 videos playing and was able to get the CPU to stay at or near 1.86 GHz. I have to set that test up still but since I’m working on cycling my battery it may have to wait until later.

I don’t think the numbers above are shocking. Yes it’s weird that the CPU randomly drops down to 800 Mhz running the null test. The computer is however being presented with conflicting problems … a long running set of CPU tasks that are raising the temperature and a need to keep the machine running which requires lowering the temperature. Because it can’t offload any of the load to the GPU (like in the video test can) it throttles down the CPU and it begins to bounce around to find some equilibrium. The machine never locks up like it seemed to do in MBA V1 so that’s a big win. All in all I think the machine handled the test properly.

Here are the details of the upgrade:

Fixed Bugs

• Selecting pickers now properly spin and select the right values.
• Clubs names and descriptions are now properly truncated on the main HUD view.
• The application icon should now display properly.

Features Added

• Widened picker sliders so you can easily touch them.
• Picker sliders now prominently display currently set values.
• Club lengths can now be entered to 2 decimal places.
• Added the ability to select previously entered club brands, models, or descriptions as well as select them from a small club database for quick data entry.

I wanted to thank all of the users whose feedback went into this release. I’m constantly trying to make this application the best it can be and welcome new ideas and comments.

You can find information about other releases on the Fairway release notes.

Update: Version 1.0.2 has been approved for the AppStore so look for an update to show up soon.

After you take it for a swing let us know what you think. We’re always happy to hear from our users. We’re already hard at work on version 1.0.2 after getting some valuable user feedback on 1.0.

Update: Thanks to TUAW and iPhone Alley for covering the sale.