Xcode 4 hands-on: be sure to RTFM first
Xcode 4 hands-on: be sure to RTFM first

            
  
  
  
      

      

      
        Xcode 4 is probably the most significant change to Apple's developer tools  …
      

      
    



  

  
      
    
    
                      
                      
          
 When Apple bought NeXT, one of the things it was getting was a set developer tools: Interface Builder, used to construct the GUI; and Project Builder, which was used for managing code and resources. Combined, they enabled rapid application development.  Although these tools were well ahead of their time when they were created, in many ways they'd fallen behind by the time they saw their first release from Apple.  There have been some significant updates to the tools since, including the renaming of Project Builder to Xcode and the integration of iOS development, but these didn't fundamentally alter the behavior of the two applications. 
 Xcode 4.0, released Thursday, appears to be the most radical departure yet.  It contains very significant changes and will require equally significant revisions to a developer's workflow.  Still, the overall benefits look to ultimately be worth the effort.  The new tools are so sprawling that it will be impossible to thoroughly review XCode 4 here; instead, we'll focus on its overall approach, and a few specific functionalities.  
Major consolidations
 One word to describe the previous incarnations of Apple's developer tools is "sprawling."  If you needed to do performance monitoring, a separate tool—Instruments—had to be launched (Instruments had replaced a small collection of independent apps, so this was an improvement).  To lay out the user interface, you needed a trip to Interface Builder.  Keeping any files used by IB in sync with the code editing you did in Xcode was largely a manual process.  Working within Xcode tended to spawn a collection of individual windows for code and data model editing, debugging, checking logged messages, and the like.  Things got pretty cluttered very fast. 
 Apple had already taken some baby steps toward consolidation, integrating a minimal debugger into the main code editing window and producing Instruments.  But overall, developing for either of its OSes required a huge assortment of dedicated windows and palettes. 

          
                      
                  
                    
        
          
    
    
          
          
 There were some advantages to this, in that having windows that were specifically designed for a certain task tended to be better and more focused at accomplishing it. Xcode may have had window clutter, but those windows lacked some of the painful visual clutter that many development environments suffer from, with dozens of separate tool palettes vying for attention.  Still, the juggling required to keep Xcode and Interface Builder in sync was a serious pain. 

    
          
                  
          
    
    
      Yes, it's possible to make this much of a mess out of your work environment. Click for full size

          
  
        
            

 With Xcode 4, Apple has made a major effort at consolidation, and has attempted to balance window and visual clutter.  Instead of independent windows for everything, the application now relies on tabs, each of which can be customized for a specific task.  For example, it's possible to set up one tab for code editing, with a list of source files, a large editing area, and a small column of code snippets.  Another can be set up for debugging, and a third to edit Core Data object models.  It's still very easy to clutter one of the tabs up, but that's a user's choice, and the tabs do provide a nice way of avoiding window clutter.
 The other major bit of consolidation is the integration of Interface Builder's GUI-editing abilities into Xcode proper.  This takes a bit of getting used to—typically, doing anything in IB required at least two windows and a palette—but its implementation is pure, unadulterated goodness.  You no longer have to take any special efforts to keep your class files in sync between the two applications.  And, once you set up a tab appropriately, it's possible to directly modify code files using your interface layout. 

    
          
                  
          
    
    
      It's just like IB, but all in one window.

          
  
        
            

 Interface Builder has always relied on outlets, which provide a class reference to another object in the same IB file; and actions, methods that get triggered when the user performs an action like clicking a button.  You can create and populate these in IB, but then you still have to ensure that the code file contains the corresponding items.  Now, it's simple.  Create an instance of your object in the IB file, and you can control-drag from anything else in IB to the header file for that object.  Xcode will then ask whether you want an outlet or action, and populate the header file accordingly.  This is a bit easier to see than explain.  

          
                  
                    
        
          
    
    
          
          

    
          
                  
          
    
    
      It's incredibly simple to add an outlet for the "Open URL" contextual menu.

          
  
        
            

 Overall, this consolidation is good.  But it's a radical departure from the past, and it's impossible to shoehorn existing workflows into it.  This is one case where RTFM really applies; unless you're willing to spend the time to familiarize yourself with the changes involved and experiment with the interface a bit, the new Xcode will probably get in the way of your productivity.  And, even with the best of intentions, it's difficult to avoid having the new interface get very cramped and cluttered. 

Better tools
 The UI is hardly the only place where changes were made.  With Xcode 4, Apple is now defaulting to using LLVM GCC (which uses the GCC infrastructure to compile via LLVM), and providing the LLVM 2.0 compiler as an option.  You can also skip using the GDB debugger in favor of LLDB.  Apple has been signaling it intends to move to LLVM for a while, given it can more readily shape the direction of the project and take advantage of its more liberal BSD licensing conditions.  With Xcode 4, it's well on its way to accomplishing that. 

    
          
                  
          
    
    
      It's possible to leave GCC behind in Xcode 4.

          
  
        
            

 Both LLVM and LLDB are quite a bit faster than their GPLed counterparts.  As far as I can tell, LLVM-compiled code performed indistinguishably from GCC, and loading it into LLDB was quite a bit faster than starting up GDB (the latter has always been a frustration of mine, so this feature would have been very welcome if LLDB were a bit better behaved).  Right now, LLDB doesn't insert new lines between logged messages or format object descriptions properly for logging, making the console output an unusable mass of text.  It's intensely frustrating. 
 The process of switching from GDB to LLDB was also frustrating.  Changing compilers to LLVM required a trip to the project build settings, which operated the same as it had in previous versions.  Switching to LLDB, however, required diving into the world of build schemes, which are new to Xcode 4.  These allow finer-grained control over how a build is performed, enabling multiple related projects (like libraries and applications) to be chained together, and more.  It's a more powerful system, but again, it requires careful reading of the documentation before it can be used effectively.  The wisdom of completely separating compiler and debugger settings is pretty debatable, too.  

          
                  
                    
        
          
    
    
          
          
 Xcode 4 also promises better integration with the source code management systems Git and Subversion.  These are generally viewed as tools to enable multiple people to safely work on the same code, but they can also be extremely helpful for individual developers, since they allow anyone to save their work iteratively, or try speculative approaches knowing that it will be easy to back out to where they were when they started. 
By default, Xcode 4 now starts up a Git repository in the project directory. In theory, it's possible to get an existing project updated to work with Git, but in practice, it proved rather involved. Creating a Git repository via the command line was simple enough, after which I closed the project and cloned the repository into my working directory; when Xcode was relaunched, the version control menu items were enabled. 
Updating a Git repository is a two-step process:  commit the changes, then push them to the repository.  Unfortunately, trying to commit the changes paralyzed Xcode.  It appeared that the process of trying to commit modified a project file, creating new changes to commit, which messed the whole process up.  Xcode quickly took over 90 percent of all four cores (kudos to Apple for its threading!), and stayed there even after I cancelled the commit.

    
          
                  
          
    
    
      Thanks to Git, Xcode's 21 threads are grabbing all the processing time they can.

          
  
        
            

 To avoid this, I've added a .gitignore file that tells the system not to include many of the project settings.  This has allowed me to commit code, but means that I don't end up saving the configurations of all my tabs, meaning I'll have to recreate my work environment if anything goes wrong.  I've tried Git on a new project as well, and although it can successfully push and commit in its default state, I still get cryptic error messages while doing so.  Clearly, this needs a bit of work. 

          
                  
                    
        
          
    
    
          
          
Other niceties
 If Xcode 4 is going to force you to relearn how to work, then it offers some nice inducements in exchange.  Errors in code are flagged while you type, and the system even offers suggestions on how best to fix them; forgotten semicolons should be a thing of the past.  The code completion system has also been significantly improved, making it much easier to find the appropriate method call without resorting to the documentation.  Inline help is also greatly expanded. Option-clicking in code brings up a popup window with relevant details, such as where a variable was defined or basic details about a class or method.  Control-clicking on many widgets or panes will include the option of bringing up a help document, often with a video-based demonstration of working within Xcode 4. 

    
          
                  
          
    
    
      Prepared code snippets include Core Data, Grand Central Dispatch, and basic C execution.

          
  
        
            

 The library of predefined code snippets has been greatly expanded, and now covers most of the typical tasks you'll come across in your code, from initializing your class to fast enumerating through an array.  File template libraries for classes, protocols, user interface files, and more are all present.  Apple has clearly put a lot of effort into cutting down on the amount of canned code you need to type out.  Finding the right item has been made much easier by pervasive search boxes—so, putting "enum" into the code snippet search box got me three ways to enumerate through a collection, and a declaration for a C-style enum. 
 One thing that may or may not be a nicety is the Organizer, which keeps a list of projects, code repositories, and iOS devices for testing.  All of that is fine, but it also handles the help system.  As a result, if you're looking for help on using the Organizer, you can't view the problem and view the help page at the same time without opening the help page in a browser. 

          
                  
                    
        
          
    
    

        
        
          
          
 That last annoyance serves as a pretty good indication of where Xcode 4 stands.  It's got the best of intentions about a lot of things, but the results can be a bit mixed.  Where they work—the extensive inline help, the integration of Interface Builder, the elimination of window clutter—they work brilliantly.  But there are a lot of areas where an attention to detail doesn't quite show, like the problems with using Git and the annoyance of trying to get help for the Organizer.  From my perspective, the jury's still out on other things, like the new "schemes" approach to managing builds. 
 Overall, it appears that Xcode 4 will cost a couple of days of work while a developer gets familiar with all its new features and how best to use them.  But once those days are spent, they'll probably be offset by productivity gains.  And as Apple updates the software further and LLVM technology improves, I expect a lot of its rough edges will go away. 


          
                  

                  
          






  
  
          
  

  
    

    
      John is Ars Technica's science editor. He has a Bachelor of Arts in Biochemistry from Columbia University, and a Ph.D. in Molecular and Cell Biology from the University of California, Berkeley. When physically separated from his keyboard, he tends to seek out a bicycle, or a scenic location for communing with his hiking boots.

    
  



  
    
    
    83 Comments
  
      





  
              
  


  
    
      
      
    
    
              
                      
              
            
                    
        
                    
                    
        
                    
                    
        
                    
                    
        
                    
                    
        
                  



  

  