The flaws in Apple’s Camera Browser Sample

Haritha Mohan,debugging
Photo

Yes, this application is from 2012. Yes, this is in Apple’s documentation archive.

However, I used this sample to build an application recently and spent more time than I would like to admit trying to figure out why Apple’s Camera Browser app kept crashing. So I am writing this inaugural blog post in case it helps anyone else but mostly for me to make sense of why the app was crashing in the first place and the steps my colleagues (Shoutout to Manuel (opens in a new tab) and Rolf (opens in a new tab) for helping) and I took to get the app up and running.

TLDR: The core two lessons learned from this experience: never underestimate the power of a well-phrased grep command and using the debugger with good breakpoints.

Alright, first things first... what exactly was the issue?

After downloading the sample code for the Camera Browser from Apple’s site, I tried running the application on my local machine to get a better understanding of its behavior. After connecting my phone to my macbook and trying to click the open button to open a session in the app, the application would mysteriously crash. I pursued a plethora of measures to try to troubleshoot this- ensured my iPhone was unlocked, ensured my devices had the right permissions and access, restarted my macbook in hopes of somehow resolving this issue- nothing worked.

So then I looked into the XCode project and there were a couple errors that needed to be addressed first:

Outdated macOS version:

Oftentimes when dealing with older applications (In this case the sample was created in 2012..) there can be compatibility issues with things such as the operating system or applications versions.

In this case, the specific error was:

~/CameraBrowser/English.lproj/MainMenu.xib error build: Compiling for earlier than macOS 10.6 is no longer supported. 

Ta-da! Now that the macOS Deployment target matches our system’s there should be no more issues with deploying, right? Sike! Looking deeper into the issue, the error specifically points to the MainMenu.xib file (and this is where the grep comes into play, by grepping for the version in the directory it also points you to this file)

After navigating to that file > (On the right panel) Identity and Type > Interface Builder Document > We can see that the Builds For field has been set to Unknown macOS Version…which turns out to be the culprit of this deployment mess. So update this value to the desired version range and it addresses the issue..finally.

Photo

Outdated Auto Layout:

Another error that was present in Xcode when attempting to build the application:

~/CameraBrowser-2/English.lproj/MainMenu.xib error build: Auto Layout before OS X 10.7
Photo

Ok so at this point there were no blaring red errors in Xcode- a good sign…and the build succeeded! Yay…right? But as you can see by the length of the post, the troubles don’t end here...unfortunately. So now the Camera Browser app launched successfully and my phone was showing up as one of the devices. Now, when I clicked the open button a list of files and its metadata would populate the list view and then the app would crash. So, compared to where we initially started the application now progresses a little further..

But unlike the other previous errors we addressed in Xcode, there were no blatant error messages to follow or any sort of guidance for that matter. By this point, Apple was playing with my feelings for real. And I didn’t know if there was a light at the end of this debugging tunnel lol. But this is where our protagonist comes to play- the debugger.

Turning to the debugger..

To reach the end result, a lot of breakpoints were set and played around with, but to keep things to the point:

After the application crashed, looking at the stack trace provided insightful information on where to place breakpoints based on where exactly the app was crashing. Some key breakpoints used were initially at the didAddItem and then the didEncounterError selectors. In the case of an error occurring the application was not handling that appropriately, but by adding this to the method:

if (error == NULL)
    return;

and removing the NSBeginAlertSheet call (which also happens to be deprecated).

But still, of course, the crashing persisted. Another key tool used to get more context on what exactly was going on in the system at the time of the error is by using the Console application and starting it simultaneously when opening a session in the camera browser app. Using a tool like the console doesn’t necessarily guarantee a solution, but it can provide helpful context and guide you in the right direction towards the solution.

After looking through our handy stack trace again, the following error put an end to this puzzle once and for all:

Cannot remove an observer <NSTableBinder 0x6000037b86e0> for the key path "metadataIfAvailable.{TIFF}.Make" from <ICCameraFile 0x7fc92582d940>, most likely because the value for the key "metadataIfAvailable" has changed without an appropriate KVO notification being sent. Check the KVO-compliance of the ICCameraFile class.

So in this case, once again since the sample app was made back in 2012, the KVOs have since changed but the code was not reflective of those changes. Looking into the AppController.m file, any references to the “metadataIfAvailable” had to be removed.

A little more on the context of this bug, because I was unaware of what exactly a KVO was and why that was making the application crash: KVO Compilance (opens in a new tab)

And now, at long last, the Camera Browser application works!!! Now after opening a session, all the photos and videos from my phone are visible in the list view and the corresponding functionalities (ex: downloading an image) works as well.

Fin.

Side note: A lot of this information may seem trivial to some, but as a dev early in her career sometimes the trivial information is quite priceless. Oftentimes, I think it’s good to have a reminder of the tools we have at our disposal, like the debugger, and how exactly to best leverage them to our advantage. The debugging process can be tedious but if there is anything I learned from an experience is to stay resilient and try to keep your mind on the bigger picture and not let functional fixedness stand in your way of reaching a solution.

© Haritha Mohan.RSS