Xcode insights of an Eclipse/Java developer

For over 8 years I’ve used Java, the Eclipse IDE and many other Eclipse technologies to get my work done. But when RAP switched to the new protocol to enable all kinds of clients to connect to the RAP server, I had to face Objective-C and Xcode to develop a native RAP client for iOS devices.

In this post I’d like to show you my Xcode experiences and how they compare to the Eclipse IDE we all know and love.

Installation

First of all you need a Mac. It should be at least a Core 2 Duo machine with OS X Lion (10.7) installed. You can download XCode 4 for free at the Mac App Store. Make sure you have enough spare time and bandwidth. Once Xcode is downloaded, installed and started, it will continue to download and install other components like SDKs, iOS Simulators, Documentation, …

For my source code repository, although Git support is integrated in Xcode, I prefer the more powerful (but commercial) Git client Tower. The free Git client from GitHub is ok, too

Some Stuff to Blow Up

In order to get to know Xcode better, you need a project to mess around with. To find an example project, just have a look at the hundreds Apple Sample Projects. In a later blog post I will show you how to create your own project and write some Objective-C.

A nice, small example to start with is the Reachability sample. You can browse and download the sample code by clicking on the “Download Sample Code” button on the top part of the webpage. The downloaded ZIP will contain an Xcode project (folder with resources and classes and a .xcodeproj file) which you can open by double-clicking the Reachability.xcodeproj. The differences in the source code aside, you can browse and edit the same as in the Eclipse IDE.

There are four key aspects of an Xcode project you should know:

1. Project Info
   
   Here you configure the version of iOS  your App should work on. This will affect the APIs you will have available.
2. Target
   A Target is more or less a collection of resources and code that is built against a set of frameworks (libraries or parts of iOS) and other Targets.
3. Target Summary
   
   This is a bit like a mix of an Eclipse Bundle+Feature+Product configuration. The key aspects of your Target are defined here: A Bundle Identifier, Version and other configurations such as on which device class it should run, the splash screen, App icon and the entry point of the App.
4. Target Build Phases
   
   This is the equivalent of the Eclipse build.properties. This configuration part contains the resources to include, the classes to compile and the dependencies on other Targets or frameworks.

Features

The Xcode IDE contains most of the things you need for iOS development: writing code and unit tests, and analyzing, debugging and deploying your application.

Xcode 4 features a single window layout, called the workspace window, that looks very similar to Eclipse. Besides editing code, there are five actions that you can perform with Xcode:

• Run (To run and debug your App)
• Test (Execute your Unit Tests)
• Profile (Memory Analyzer and other Instruments)
• Analyze (Static Code Analysis)
• Archive (This is the first step to deploying your App to a device or to the App Store)

Run

Like the Run & Debug actions in Eclipse those actions are performed on Launch Configurations – in Xcode they are called “Scheme with Destination”.

You‘ll find Actions and Schemes with Destination on the top left of the IDE.

Usually you select your Scheme (Launch Configuration for your App) and choose your Destination. The Destinations range from iPad / iPhone Simulators in different iOS versions to the devices that are currently connected to your machine.

Executing the “Run” action will run the selected Scheme on the selected Destination.

In Eclipse, Run and Debug are separate actions. In Xcode, on the other hand, you can debug with the Run Action. The default settings will compile and run all the code launched from within Xcode in debug mode. If you don’t want to include debug instructions,  Archiving will compile your App for distribution. It is a good idea to create some test distributions as the debug instructions may be affecting your App’s performance.

To close on the Run&Debug topic, along the way, you may encounter some problems with your code’s memory management. Make sure you always have a breakpoint on objc_exception_throw and enable the options

NSZombieEnabled = YES;
NSDeallocateZombies = NO;

in your Scheme to debug retain and release problems. For more information, see the “Finding Memory Leaks” section in Apple’s Debugging Applications document.

Test

Test driven development in Xcode is quite similar to Eclipse with JUnit. Just import SenTest (included in Xcode 4) in your test classes:
#import <SenTestingKit/SenTestingKit.h>
Then create your setUp and tearDown methods. Test case methods are prefixed with test and if you need a mocking framework, I suggest taking a look at OCMock.

The IDE integration and support of test driven behavior is sort of suboptimal. There are no Quick-Fixes like in Eclipse to create classes, methods and etc. from within your test classes. And the result of your tests are displayed as compile errors in the Xcode UI. There is also no real test reporting UI or a red/green indicator.  When your tests are successful, an overlay will be displayed for a couple of seconds saying “Test Succeeded”.

Profile & Analyze

For more advanced analysis of your code, the Analyze action does a really good job with static code analysis in finding common coding mistakes. The Profile action provides you with a set of tools to find issues in your app – ranging from memory to performance problems.

Archive (aka Deployment)

Archive can be compared the the Eclipse Product Export. To enable the Archive action and export your App, you need to have ‘ iOS Device‘ or a real device selected as Destination. Then you can use the Archive action from the menu: Product -> Archive. Your archived App will now appear in the Organizer. From here you can export the .ipa to install it to a device or send it to the App Store.

Apple provides you with two ways to distribute your Apps. The iOS Developer Program for Individuals and Companies ($99 / Year) is used to distribute your Apps via the App Store and up to 100 test devices. The iOS Developer Enterprise Program allows you to create proprietary in-house Apps for an unlimited number of users within your company (not via the App Store). Of course you can always start coding without subscribing to a Developer Program, but then you will be limited to the Simulator.

To provide the App .ipa to your 100 testers, you can host your own ad-hoc installation website or just use the free TestFlight service.

Refactorings

Check. Well, kind of… Refactorings can be done to a certain extent. You can rename local variables, extract methods, … but it is by far not comparable to what Eclipse JDT offers.

Continuous Integration

Continuous Integration (CI) is also possible with Xcode. Most of Xcode’s functionality is accessible from the command line to automate building, testing, etc. with the common tools like Hudson/Jenkins. Have a look at Holger’s blog entry about Continuous Integration for iOS Apps.

Keyboard Shortcuts

In the Eclipse IDE I use shortcuts all the time. I compiled a list of Xcode Hotkeys for the most common actions I also use in Eclipse:

• Switch between the Header and Source file
  • Control + Command  + Up Arrow
• Display documentation
  • Option + Click
• Jump to definition
  • Command + Click
• Autocomplete
  • Control + Space
• Rename in File
  • Control + Command + E
• Beginning and end of a line
  • Command + Left Arrow
  • Command + Right Arrow
• Jump between words of a line
  • Option + Left Arrow
  • Option + Right Arrow
• Open Type
  • Command + Shift + o
• Outline
  • Control + 6
• Comment Selection
  • Command + /
• Kill line to the end of line
  • Control + K
• Run
  • Command + R
• Test
  • Command + U
• Clean
  • Shift + Command + K
• Switch to the previous opened file
  • Option + Shift + Left Arrow
• Switch to the next opened file
  • Option + Shift + Right Arrow

Interested?

Once you know how things compare to Eclipse it should not be too hard to find your way around Xcode. Especially in the beginning, the Apple Documentation (Objective-C, iOS) helped me a lot. Honestly, it’s the best documentation I’ve ever seen. And on iTunes U, you have free access to iOS development lectures in video podcasts for free from Stanford University.

Of course StackOverflow is also a great community to get answers and hints on problems you may encounter. If you have other tips for Eclipse developers getting started in Xcode, it would be great to see your comments here.