2011 11" MacBook Air vs. 2011 15" MacBook Pro Xcode Performance

I just picked up the just released 2011 11" MacBook Air in the hopes of using that to replace my 2011 15" MacBook Pro. In the event it didn't perform well enough it would be given to the wife (actually, this was the original plan anyways, so if it can be a decent development machine, all the better)...

Here are the specs (Both with Lion and Xcode 4.2 and iOS 5 Beta 4).

1. Decked out 2011 11" MacBook Air
1. 1.8Ghz Core i7
2. 256GB SSD (The faster Samsung one)
3. 4GB Memory
2. Decked out 2011 15" MacBook Pro
1. 2.3GHz Core i7
2. 400GB SSD (OWC w/SandForce, not OEM)
3. 8GB Memory

For me the only thing that matters is Xcode performance. I just a project with the following characteristics, and measured a build from the time of pushing play to the time of the simulator launching with the login on the build displayed.

1. 224 Source Files
2. 63 XIB's
3. 419 Resources

Here are the results:

1. Clean Build
1. MacBook Air: 38 seconds
2. MacBook Pro: 16 seconds
2. Repeat Build (No Clean, Simulator Left Running)
1. MacBook Air: 8 seconds
2. MacBook Pro: 8 seconds

It was expected the MacBook Pro would be faster. From a clean build it's significantly faster. From an existing build where you're touching a few files Xcode indexing to know what's changed or not makes it a wash. As most of the time we're just changing a couple files at a time the MacBook Air seems fast enough for development, just knowing that the clean build will take almost twice as long.

Also, to explain the difference, the actual copying of resources, launching the simulator, etc. took about the same time. There was a moderate difference in the compilation time, but the static analysis is where the MacBook Air lost out. The MacBook Pro killed it with the extra two cores and processor speed.

Now, the debate... I think I'm going to try out the MacBook Air and see how it goes...

UPDATE: After using the MacBook Air I decided to stick with the MacBook Pro. That extra speed really matters when someone is looking over your shoulder. Particularly, at a client. Although, if you are used to a non-SSD MacBook Pro (particularly, the 2010 variety) you'll be happy with the performance of the Air.

OSX Lion and Xcode 4.1

We've upgraded to OSX Lion and Xcode 4.1 and it has been an interesting process. Here's the steps we took.

1. The first was to make sure we were upgraded to 10.6.8 before we started anything.
2. Purchase and download OSX Lion from the App Store (Note, you before starting the installation you may want to create a bootable drive)
3. Install OSX Lion
4. Java is not installed by default, so after Lion is installed you can install Java by going to a Terminal and typing "java -version" and it'll start a download to install Java.
5. Before installing Xcode 4.1 it's good to remove any previous versions of Xcode
1. Uninstall any previous Xcode by issuing a "sudo /Developer/Library/uninstall-devtools"
2. In ~/Library issue a "find . -name *Xcode*" and remove each file/directory
3. In ~/Library issue a "find . -name *Simulator*" and remove each file/directory
4. Reboot
6. Next find Xcode 4.1 on the App Store and download and install it. This just installs the installer. You then have to install it. The installer can be removed when you're finished.
7. If Xcode launches with errors or has no menu times you'll need to reinstall iTunes. The download has the 64-bit universal builds now.

The only issue we've seen is that Core Location isn't working in the simulator and generates an error. See our post on the developer forums.

Reading and Translating a DWARF'd iOS Crash Dump

So what the heck does it mean when a crash log has the following lines?

Thread 0 name:  Dispatch queue: com.apple.main-thread
Thread 0 Crashed:
0   libobjc.A.dylib                   0x35167c98 0x35165000 + 11416
1   CoreFoundation                    0x315b1cd6 0x315b0000 + 7382
2   CoreFoundation                    0x316620b8 0x315b0000 + 729272
3   CoreFoundation                    0x31663438 0x315b0000 + 734264
4   CoreFoundation                    0x315b9f98 0x315b0000 + 40856
5   CoreFoundation                    0x315c094e 0x315b0000 + 67918
6   Foundation                        0x34e9831a 0x34e81000 + 95002

Chances are, your Released application has Debug symbols stripped (DWARF), but have no fear, the Developer tools come with the right script to help with this. It's called symbolicatecrash, and with Xcode 4+ it gets installed to:

/Developer/Platforms/iPhoneOS.platform/Developer/Library/PrivateFrameworks/DTDeviceKit.framework/Versions/A/Resources/symbolicatecrash

I've simply create an alias in my bash resource on login, but you may prefer a symbolic link. Hopefully you've kept a copy of the build when it was released, because the dYSM file contains the right mojo to add the symbols back. The following sample translates the often cryptic lines of a .crash file into something more understandable:

symbolicatecrash MyOopsAppWithABadBug.crash MyOopsAppWithABadBug.app.dSYM

The options are more clearly defined by adding the -h switch:

symbolicatecrash  -h
usage:
   /Developer/Platforms/iPhoneOS.platform/Developer/Library/PrivateFrameworks/DTDeviceKit.framework/
Versions/A/Resources/symbolicatecrash [-Ah] [-o ] LOGFILE [SYMBOL_PATH ...]
 
   Symbolicates a crashdump LOGFILE which may be "-" to refer to stdin. By default,
   all heuristics will be employed in an attempt to symbolicate all addresses.
   Additional symbol files can be found under specified directories.
 
Options:
 
   -A  Only symbolicate the application, not libraries
   -o  If specified, the symbolicated log will be written to OUTPUT_FILE (defaults to stdout)
   -h  Display this message
   -v  Verbose

Abracadabra! Those lines are easier to read now, but we have some work left to find the double-release or message sent to an object that is already evicted:

Thread 0 name:  Dispatch queue: com.apple.main-thread
Thread 0 Crashed:
0   libobjc.A.dylib                   0x34499c98 objc_msgSend + 16
1   CoreFoundation                    0x308e3cd6 CFRetain + 62
2   CoreFoundation                    0x309940b8 __CFBasicHashStandardRetainValue + 8
3   CoreFoundation                    0x30995438 __CFBasicHashAddValue + 100
4   CoreFoundation                    0x308ebf98 CFDictionarySetValue + 68
5   CoreFoundation                    0x308f294e -[__NSCFDictionary setObject:forKey:] + 54
6   Foundation                        0x341ca31a -[NSMutableDictionary(NSKeyValueCoding)setValue:forKey:] + 10

You can read more about the Debug and Symbolification process here: http://developer.apple.com/tools/xcode/symbolizingcrashdumps.html

Zbar on Android with the NDK

We've had experience writing an automobile VIN (Code 39) scanner on both iPhone and Android. In the case of the iPhone we leverage the ZBar library and the Android the ZXing library. Unfortunately, Android has been a tremendous amount of work. There was a tremendous amount of fracturing with the camera drivers to code around to tune the image capture. But that's another story...

For the image processing the ZXing library on Android with was simply not as fast or accurate as capturing   Code 39 barcodes (no opinion on QR, etc.) as ZBar on the iPhone. This left an interesting customer service dilemma as Android would be subpar. We looked at a few options and settled on an interesting proposition.

Android recently introduced the NDK (Native Development Kit) that allows you to build native code from C/C++. Interesting... We realized that there was a good chance that we could get the ZBar library running on Android with the NDK (at least for the image processing). We did have to rewrite the build/make system as the NDK does not have full make/configure support. But, after investing time in this we were able to build the ZBar library on the NDK and leverage their JNI wrapper to invoke this code on Android.

So far the results have been excellent. The ZBar library on Android is 50% faster in recognition for Code 39 and a lot more accurate.

We'll be donating an example project to the ZBar project once we can remove the client specific portions.

Also, just be aware this only applies for Code 39. We have no idea how the image processing quality compares for the other formats.

How to Upgrade Test in the iOS Simulator

For the purpose of upgrade testing in automation it's useful to have a build of the previous version of the application. Of course, for actual device installs this is easy with the use of adhoc builds and .ipa files, but for the Simulator this is a little more involved. It is feasible if you follow the following steps.

1. Launch the Simulator (/Developer/Platforms/iPhoneSimulator.platform/Developer/Applications/iPhone Simulator.app) and set the hardware and version to the appropriate settings.
2. Delete any existing apps in the simulator.
3. Put a breakpoint in the main function (i.e. first line of the main function main.m). This is to ensure that no code writes any files to the build directory (i.e. CoreData, Analytics, Preloading URL's, etc.).
4. Run the project in debug and stop the program once it reaches the breakpoint in the main function.
5. At this point if you followed step (2) and only have one application it should be easy to locate in ~/Library/Application Support/iPhone Simulator/[version]/Applications and can easily be tar'ed up and archived and moved around.

Now in an automated testing script you can remove any applications from the simulator, untar the appropriate archive, exercise preloading (i.e. logging in) to get the simulator in a state to test an upgrade. Now, simply build the project and have it install over this version and test any upgrade scenarios.

This has even worked from Xcode 3.2.6 builds being applied to Xcode 4.0.1.

iPhone Open Source Automation

Testing iPhone apps is always thought of last and is typically performed manually. At Lolay we believe in a strong automation investment to allow testing as we develop so that we can have confidence in the stability of our builds as we develop.

Checkout a demonstration of how to automate the iOS platform / iPhone using all open source. This is all compatible with ANT and Maven in any continuous environment. In this demo you will be shown on open source can perform a basic test in Where U At? and run through both positive and negative testing. At the end you can see the JUnit results including screen shots of the failure.

Vimeo: How to automate the iPhone using open source

BIA/Kelsey Reviews Lolay, Future of Things to Come

Gary recently spoke with Mike Boland from BIA/Kelsey about Lolay's social and location-based efforts. You can read the details here.



We are excited to note several key areas where Lolay will be focusing its efforts:

• Where U At? iOS: Where U At? for iOS will have some major updates within the next two weeks. Look out for the details!
  
• Where U At? Android: We have been working diligently to release Where U At? for Android and are pleased to announce it will be in the Marketplace very soon!
  
• Lolay's Incubator: Helping other developers (novice to experienced) create apps that make money and solve a problem out of the starting gate. Our Lab Werx platform will serve as the foundation for quick success.
  
• Partnerships: We are looking for like-minded people, companies and mobile efforts that are complimentary to Lolay's mission to change the way people interact. Feel free to Connect with Us.

Looking forward to a great 2011!