About Tanoro

Christopher "Tanoro" Gray is a web programmer and science advocate especially concerned with resource management technologies, biology, and artificial intelligence. He is a student of epistemology and philosophy as well as an Atheist competent in Christian theology.


HOME  >  Development Journal

Dev Journal

Xcode 4 Issue, View outlet and NIB Name Set
Monday, Jul 11, 2011 2:57pm

Here is a rather obscure issue that appears to have eluded many of your tutorial websites about Xcode.

Xcode reports issues: "Unsupported Configuration; View Controller - {var} view outlet and NIB Name set".

This error points to one of your NIB files, but doesn't explain in detail what is wrong with it. The problem is that a view controller in your NIB is defined as having a label Xcode doesn't recognize as the class attached to that controller. In this case, this happened when I was adding and removing unwanted view controllers during the early stages of this project. An early copy of the root view controller was attached to my MainWindow NIB even after I deleted it. I went to the MainWindow NIB and set the attached view controller to the class I needed it to be, but Xcode retained the label belonging to the old view controller.

If I moused over the view controller icon in the middle pain (on the left edge of the editor pane), I saw the name of the old view controller I had long since deleted. Unfortunately, I couldn't find a way to edit this.


Just remove the view controller that Xcode is complaining about and add a fresh one. Be sure to make a note of all of the connections from the controller before removing it. Xcode will now recognize it and stop complaining.

Xcode 4 compiles app and produces white screen
Monday, Jul 11, 2011 2:27pm

I encountered an unusual problem that I spent much of the day trying to figure out on Friday. I managed to find a solution near the end of the day.

My boss gave me the details on the navigation based app we are working on at the moment. I started from an example project that had some built-in navigation already in it. I wanted to remove these from the app as they appeared non-standard. I also wanted to walk myself through the process of adding a new and standardized set of view controllers and really getting familiar with how building navigation in an app works. This would also be value later if I wanted to keep a backup of this project as a snippet to examine later for future use. I like having clean code for this because it's easier to examine.

So I made a backup of the entire project, moving it into a directory where I could begin numbering my backups incrementally. After deciding on how and where I'd structure my backups, I deleted any leftovers from earlier instances of this project.

I opened my latest backup, intent on going on from there. Xcode reported no unusual issues. I compiled and ran the project in the simulator and it produced an odd result.


  1. The app loaded into a white screen and nothing more.
  2. All NSLogs reported normal.
  3. Xcode reported no unusual issues or errors.

I combed through my code carefully, checked all of my NIBs, and recompiled several times and nothing worked. compiling onto my iPhone also didn't work. I dug around on the web, trying to find someone with a similar error, but I wasn't entirely sure what I was seeing.

While stumbling around, I found that the app began to work if I changed the name of the directory in which the project was held back to its original name. I was really confused now. Was Xcode somehow caching the directory name? My coworker, who had some experience in compiling binaries for Linux, explained that some compilers have two steps. The first saves a configuration of the program while the second compiles it. This makes subsequent compiles of the same program faster. This gave me a lead.

In the Organizer window (on the Projects tab), I found an archive of "Derived Data" libraries associated with my projects and many were highlighted in red, displaying "not found" next to them. I removed all of the "not found" libraries and tried recompiling the app once more. Everything worked then.

The Development Journal and Basics of Xcode
Monday, Jul 11, 2011 1:20pm

Now that I have had the chance to finally upgrade my website with the latest version of my CMS, Majicko, I am taking a moment to branch off my personal blogs to include a development journal to keep track of my new understandings within the professional realm of programming and application development. In this archive, I will publish additions to my personal sum of programming knowledge as well as attempt to add to the sum of the collective knowledge by publishing these notes on the web for all to find.

Before I kick things off, let me start with a basic highlight of my current professional status. I am a programmer with Bandwise LLC in Shreveport, LA. I specialize in PHP and MySQL with some practical understandings of Javascript, Ajax, JSON, and even Flash. My routines at work involve making websites and furthering the development on my content management system, Majicko, and doing any flash work that our customers request.

Recently, my boss has purchased for me an iPhone and iMac with the instruction to begin learning Objective C programming. I am now easing into the realms of C programming for the development of iPhone apps for Bandwise. I am rather looking forward to this as it will widen the scope of my skills. As this archive is meant for the sharing of knowledge rather than anecdotal experiences, I will forward anyone interested in details of my professional work up to this point to my About Me page where my work in conventional web design is described in detail. Let's cut to the chase now.

The setup I'm using is a typical iMac manufactured 2011 with Xcode 4. I've never used a Mac before, so I'm getting accustomed to the new O/S as well as the new development software, which is itself brand new. This has been an added challenge for me as most tutorial articles, videos, and books available right now instruct using Xcode 3, which is very very different.

I found this video extremely helpful in familiarizing myself with Xcode 4 and allowing me to grok what tutorials meant when explaining something in Xcode 3.


Having zero experience in C prior to this, staring at a file full of objective C if slightly daunting, like any programming language seen at first glance. One of the first things I noted is that C compilers take a very strict inventory of every variable and what data type is meant for them. PHP is convenient in that a lot of data types (i.e. strings and integers) can be freely swapped around and the parser will understand so long as you don't do something silly like try to use a non-numeric string in a math formula.

I also noted that there are a lot of stray characters in Obejctive C that a LOT of tutorials look around without ever explaining what they do. After some reading, I learned that Objective C is to C very much like jquery is to Javascript. It is an extension built on top of the existing construct with its own exclusive syntax. For example, the @ symbol appears to precede most string characters in the code I was examining. This is nothing more than a marker to tell the compiler that this string should be recognized at a piece of Objective C rather than normal C.

I'll elaborate more on that as I learn on it. I'd like to speak a little about the general structure of your typical Objective C programs, specifically where apps are concerned. Based on what I've seen so far, which might not be completely accurate, apps written in Xcode have a few components.

NIB: These are xib files in Xcode 4 and details the visual design of the app.
Headers: These are .h files which contain the initial declarations of a class.
Implementations: These are .m files that contain the details of what a class does. These are usually paired with a .h file.

Again, all of that may be slightly inaccurate or over-simplified, but bear with me. The general scope of the project appears to be that Xcode defines an initial NIB (xib file) that calls upon the app delegate, which is one of the classes made up by a header and implementation pair. The app delegate is then used to call upon whatever else you define in your code. This ties the app together and making it work.

I'll explain all of this in more detail as it all becomes clearer to me. I will also detail issues and resolutions that I discover as I proceed.

Powered by Insty-Site! 2007-2018 Shreveport Web Design by Bandwise LLC