Introduction to the Xcode module
This chapter features an introduction to the Xcode module; it serves as a foundation for understanding the basics of the native developer interface. We need to understand the basic layout and capabilities of the Xcode portion of the iPhone SDK before we can move into the detailed processes of how to get the application onto the iTunes App Store. Once you have a foundational understanding of the basic functionality of the Xcode module – its essential features – when we get to Chapter 8 (the PhoneGap chapter) you will have no problem with the processes (which are quite extensive and can be rather confusing for a first-time developer) for exporting your application to the iTunes App Store. Alternatively, another always current source for this introduction to the Xcode module would be the Apple document A Tour of Xcode,1 which is an extensive document covering everything about Xcode comprehensively.
Before we get into the how-to of Xcode development, a word about the software I am using as I explain the functions of the SDK; my version at the time of writing may not be the most recent version of the software by the time you read this. This is because there are updates nearly every year to the developer environment by Apple – not to mention also that we can usually expect to see a new iteration of the iPhone almost every June. The significant points to remember about these last few chapters now are broad concepts, and these broad conceptual directions will be useful across the future iterations of the developer environment. The developer environment I am working from, and the one from which the example screen shots are shown, are from version 3.2.1 of the Xcode module. There is a difference between the Xcode developer version (3.2.1) and the iPhone OS (version 3). These are not the same thing necessarily – the Xcode version is a version of the SDK not the version of the iPhone operating system: the Xcode version and the iPhone operating system are intricately related, but these are not the same thing and should not be referred to interchangeably. When you talk about versions of operating systems and developer kits you are talking about different inter-related aspects of iPhone development.
When developing for the iPhone operating system, keep in mind that should you choose to, you do have the option to develop applications that are specifically targeted for certain versions of the iPhone OS. You can specify within Xcode the version of the operating system for which you are making the app. It may well be the developer’s decision to specify that the app you are making is for the iPhone OS 3.0 and later, or should you want to leverage specific portions of the iPhone (3.1 or 3.1.2)2 you can choose to set the target iPhone operating system for later systems only. As we’ve seen in our chapter on InfoPoint, which uses the call functionality of the iPhone device, when we make applications they may not have functionality on devices other than the iPhone – this will be the case if we’ve used components of one device that are non-existent on another. The Xcode module is the place you can specify what device capabilities are required by the end user in order to use the app.
As with Dashcode, you are able to select among a few different iPhone templates; you can find these templates by clicking ‘create a new Xcode project’. You should see a screen similar to the one in Figure 7.1.
From the template screen we see the following Xcode templates for the iPhone (your screen may vary, slightly depending on your Xcode version): Navigation-based Application; OpenGL ES Application; Tab Bar Application; Utility Application; View-based application; Window-based application.
Regarding templates, these won’t be the ones we will work from in the next chapter, but it is useful to know something about them. We just don’t use them for the type of work we’ll be doing, i.e. using a framework for mobile development. This book isn’t about native application development specifically, although we do rely on the functionality of the native application development environment. A good overview of the typologies of applications in provided in the ‘iPhone Human Interface Guidelines’ available on the developer website: http://developer.apple.com/iphone (see also the Consulted listing at the end of this chapter).
The iPhone Human Interface Guidelines actually presents the principles of good app design generally, so it is a useful source when you begin developing outside of Dashcode templates. The typologies we’ll explore are essentially the kinds of applications that Apple recognizes. There are very good reasons for controlling the types of interfaces Apple will allow. On the one hand, a terrible interface is going to result in poor usability and people are going to associate their iPhone with poor usability. On the other hand, another reason why Apple would want to control the different ways you might present buttons and icons is that if all developers conform to a certain kind of framework, then users of the iTunes App Store may more readily understand the functionality of each new app as all are using a similar framework for presentation of functions in the interface.
So, for the reasons mentioned above, the Human Interface Guidelines are important, but for our purposes here it isn’t necessary to extensively review this document because of where the apps in this book were initially designed from. Our Dashcode template-based projects were modified versions of already existing Human Interface designs that were provided in the software. It is useful to know that these guidelines exist, however, should you ever choose to start making iPhone apps with pure HTML, i.e. outside of the Dashcode templates. All of the apps I’ve sent to the iTunes App Store have been approved, and all were from Dashcode templates, so the success rate for getting apps approved partially stems from working from the tools already provided. The Human Interface Guidelines are what you will need to follow if you don’t use Dashcode templates.
As an overview of an important portion of the iPhone Human Interface Guidelines, I want to expound on the articulated typology of applications and how these typologies may be of use for access to library information or other information provision. Although all of the apps we’ve developed are modified versions of the Dashcode template, with the Human Interface Guidelines document it is now possible to also specify what kind of app it is; according to the Apple documentation, there are three broad categories of apps, namely Productivity, Utility and Immersive. I’ve thought about what each type might look like as a library application:
1. Productivity apps – This app will resemble our browser app but its use is task oriented: users will be able to specify certain information to receive based on immediate need. As an example of a productivity app that could be developed in a library setting: the ability to be notified from this iPhone app of an item status for pretty much any given book when the item is returned to the library. Some library catalogs already allow this option – an email notification when an item is available, but suppose your catalog does not handle that kind of functionality – this app can could help to give your users up-to-the-minute information about items when their status changes. That would be a productivity app.
2. Utility apps – As the documentation defines it, utility apps that could be created for the library setting would be those that provided quick views of information. One possible app for a library setting would be an ‘Hours that the Library is open’ app – smaller libraries might just break this app into days of the week, while if you are a larger library, you can use this app to quickly notify the user of the app what library is open.
3. Immersive apps – Typically these are full-screen applications; apps of this typology are usually gaming apps. This type of application could be developed in a library setting for animated wayfinding – I am thinking here of finding certain portions of the stacks – that could be a compelling immersive app in a library setting.
As we transition now back to the Xcode interface before us, we will go ahead and select a template to use as an example of the properties of the developer environment. After you select any template (I selected here the navigation-based application) from the Xcode template list, you will then see the main screen of the Xcode developer environment.
The remainder of this chapter will cover each section of the Xcode environment. Don’t be intimidated by this screen. It seems that there is a lot going on, and in a sense there is much to learn here. The breakdown of the sections will be presented as a sort of orientation to the interface and because I’m taking the perspective that we are all beginners here, any librarian should be able to keep up with this orientation. It helps if you have the screen open in front of you and follow on your computer as well. I’ll begin at the top of the Xcode screen, and I’ll also use documented terminology, i.e. I’m not making up terms for boxes, so that if you get into the help screen, you’ll find that the terminology will line up with what is here, making your life a lot easier in the process.
The documentation calls the entire top portion of this window the Toolbar. If you’re slightly confused about what is inclusive of the Toolbar, it is essentially everything in the top portion of the screen: it includes that drop down bar with text ‘Simulator 3.1.2’ in the title, the ‘Action’ drop down, the Breakpoints tool, the build and run button, the tasks icon, and the Info tool.
The area on the immediate left side of the screen, the left side-bar, is referred to as the Groups and Files list. As you’ll notice in this portion, the component parts of the application are composed as folders – they are really folders in the sense of the way we think of folders on a computer – they are here as a way to keep track of the parts in use of the app, but they aren’t really web folders as such. Everything you see here gets compiled when we build the app – the compiled file is called a binary. It is the compiled binary which we then upload to the iTunes connect website. Without a cross-platform mobile web framework like PhoneGap we wouldn’t be able to easily configure any kind of app here. The way that PhoneGap works is to create a structure to all of these components such that for the most part all we are required to do is to take our generated web files from Dashcode (the files we uploaded to our server to make the mobile Safari apps) and place those into one portion of the framework.
That area in the middle of the screen that says ‘No Editor’ is where you will be able to make changes to the text of files that make up the app. In our case we’ll be modifying portions of files that will come pre-loaded. Certain parts that we’ll need to put in here will be specifying the name of the application as well as pointing towards our applications main screen and icon. For now it is important to know that elements of text that appear here will be modified. The documentation refers to this area as the Text Editor.
You should now focus your attention at the bottom part of the Xcode interface box. The lower gutter does not look like much right now, but there will be important information on the build or other warning and errors in compiling the build here in the lower gutter of the screen. The Xcode documentation calls this bottom area the Status Bar. This will give us crucial information about the app when we bring all the component parts together in the Build phase. You don’t have to know the exact programming of how to build an app, but there are certain pieces that are brought together and the app either builds or fails to build. This information is provided in the Status Bar. You will have to get your app to successfully build if you want to get it onto the iPhone App Store.
From your template you can go ahead and try to get the app to build. You are able to build the app by clicking on the ‘build and run’ button located in the middle of the toolbar. There isn’t anything in the app right now, however, so when the app is simulated (assuming a successful build) what you are going to see is a blank app. What you’ll notice in the Status Bar is real-time reporting of how the app is getting built, and a notification of ‘building’ in the left corner of the Status Bar. If everything gets linked properly and the application is compiled, the iPhone simulator will be launched with the application will run. Because we haven’t done anything with Xcode, but just compiled the files that are already there, there won’t be anything in the simulator – it’ll just be a black screen, which you can close. Finally, also notice that in the lower right corner of the Status Bar is the word ‘succeeded’. That means that everything compiled properly. We’ll be discussing this in the next chapter. There are a few tweaks we’ll need to do if we aren’t getting the app to compile, and the Xcode interface will let us know which parts of the app need to be fixed so we can launch successfully.
Finally, I’d like to point you to some of the drop-down menus at the top of the screen. I’m going to focus on those that you need to know about in the next chapter. Find the Project menu at the top of the screen and then select the Edit Project Settings. This will load an extensive set of configurable attributes of the Xcode project (as shown in Figure 7.3). We will need to know about a few of the attributes here.
There are two crucial settings to be aware of as you go about building an app in Xcode. There is an active SDK that you are building on, and which you can configure to be a simulated device, or your can configure the active SDK to be an actual device, like the iPhone, in which case the app that you build can be built and tested on your development iPhone.
After you set the active SDK for the app, you can also choose an ‘active configuration’, which is either set to ‘debug’ or to ‘release’ the app. Each configuration has a different purpose and you are able to switch among them (the configurations) as you go about developing apps; the interconnectedness of these two options is such that (in terms of the actual workflow) you would first simulate the app using the simulate option of the SDK, paired with the debug active configuration, thus allowing you to see how the app functions before you build it for release to the App Store. Building for release to the iTunes store requires also a specific pairing of the active SDK with the active configuration. This will make more sense in the next chapter as we model these settings with a live example.
It is crucial to know about the active configuration as well as the active SDK. One useful way to think about what is meant by ‘active’ in these terms is that this is the setting that is selected when the app is built. It is important to note that you can switch between the active configurations within the interface – it’s only set when you hit build.
There is a set of tabs in the top portion of the Project Settings window. You will notice at the top of this window is a list of tabs: General, Build, Configurations and Comments. Our discussion for the purposes of what we’ll be configuring in the next chapter is focused on the Build Tab. Here is where we will need to make changes unique to each application that we make. Specifically, in the next chapter we will be modifying the code signing area. Each app needs to have an identified signature as well as a developer certificate attached to it. There are even specific types of signature codes for your apps depending on what you want the app to be able to do. If you scroll down on this screen you will see the Code Signing heading.
Code signing makes a lot more sense once we have an app that we’re working on getting into the iTunes App Store – so for the purposes in this chapter, be aware of this setting and we’ll be stopping back into this element of the Project Settings in the next chapter as we go about fine-tuning the code signing elements, particularly the Code Signing Identity for individual applications. The process isn’t completely straightforward, but the next chapter will walk us through the rest of the way. We’ll come back to this section shortly.
That concludes your orientation to this interface; you now know the essential components of the Xcode interface, and you have your portions of the screen that help you organize the component parts of the app and also point to the application executable. We’ve got more background information than we need now for the next chapter. We absolutely needed to know the components of the interface before we started making use of those components with PhoneGap. Now that we have a conceptual understanding of the Xcode tool, we’re ready to start making our Dashcode app into a native Xcode app. The next chapter will take you all the way to the iPhone App Store. It will deliver to your users a compelling and next-generation level of library service.
Wikipedia – iPhone OS Version History, http://en.wikipedia.org/wiki/IPhone_OS_version_history
Apple Documentation – iPhone Human Interface Guidelines http://developer.apple.com/iphone/library/documentation/UserExperience/Conceptual/MobileHIG/Introduction/Introduction.html; A tourofXcode http://developer.apple.com/mac/library/documentation/DeveloperTools/Conceptual/A_Tour_of_Xcode/000-Introduction/qt_intro.html
1.Available at http://developer.apple.com/ (just navigate to this page and search for ‘xcode tour’ – you will find that document and other related help guides). As an aside, the Xcode module isn’t just for building iPhone applications, but also provides the way to develop other applications and tools for Macs – in other words, you can develop software for the Mac OS from this module, too. Note that Apple’s Xcode overview is not iPhone specific.
2.How does the iPhone OS 3.0 differ from 3.1 and 3.1.2? There is a great Wikipedia Article on this topic, but, simply put, most of the major advances to the iPhone OS came about in the 3.0 upgrade – things like copying and pasting and cutting that were not in the 2.0 OS. Additionally, the iPhone OS upgrade from 2.0 to 3.0 saw the integration of mobile push technology into the app environment. There are several ways to enable the user to be alerted to new information but probably the most familiar way to users of the iPhone is mobile push, the red alert status that appears over the app (a push notification that something has changed, or the app has a new status to show you). In the OS 3 apps cannot really multi-task, i.e. you can’t run multiple apps at once – this is due to the limited processing power of the iPhone device. Although it does have limitations to what you can do, this doesn’t mean it isn’t a powerful platform from which to develop. Early indications of the 4.0 iPhone software are that that apps could be started and stopped – such that a type of multi-tasking looks imminent in the next release of the iPhone OS.