How to Make an App: iOS Edition

45
How to Make an App: iOS EDITION

description

Kinvey’s eBook titled, “How to Make an App: Android Edition” is a step by step guide written by developers, for developers.

Transcript of How to Make an App: iOS Edition

How to Make an App:

iOS EDITION

The iOS revolutionIt’s a story that never gets old. The weekend that iPad Minis and the fourth generation iPads went on sale (November 2-5, 2012) Apple sold over 3 million of the devices — a record for first-weekend iPad sales. Two months earlier the company had set another record: first weekend sales of over 5 million for the iPhone 5. Since the introduc-tion of the first iPhone back in 2007,

iOS-based devices (iPhone, iPad, iPad Mini and iPod Touch) continue to rewrite the definition of what constitutes a successful product. By the end of 2012, over 400 million iOS devices had been sold.

What makes iOS devices so successful? Innovation and product features are clearly a big part. Before the iPhone most people had not interacted with a multi-touch interface. They had never zoomed with a pinch or switched between portrait and landscape by merely rotating a device in their hand. Carrying a phone that knew where they were, could suggest places to eat, and could offer directions on how to get there was also a novel experience.

But features like multi-touch, accelerometers and GPS are only part of the appeal. Even with all its innovations, iOS still might not have taken off the way it has if the only people figuring out ways to use those innovations worked at Apple. Most of the capabilities available in an iPhone or iPad in fact don’t come from Apple at all. They come from legions of third-party developers who work in a vast ecosystem that is also an Apple innovation. That ecosystem includes the iPhone, iPad, iPad Mini, iPods, App Store, iTunes, ad networks — and that’s just on the consumer side. On the developer side, you have Xcode, App Loader, testing tools, iTunes Connect — the list goes on.

As of September 2012, the App Store hosted over 700,000 apps that have collectively been downloaded over 30 billion times. Apple reported for October 2012 that App Store monthly revenues were

running at $333 million — a rate of about $4 billion per year — remarkable for a store that only opened in July 2008.

Another innovation that has spurred iOS app development is “The Cloud.” Cloud services make it easier for independent developers to create, support and make money from their apps. The Cloud solves data storage and cross-device and user-to-user sharing problems. If an app stores data in the Cloud, that part of the application is called the “backend,” while the part of the app that runs on the phone and interacts with the user is called the “front end.”

A cloud may be “private” — i.e., the services belong to an organization for the benefit of its employees and business partners. Or a cloud may be “public” — i.e., a company (such as Amazon or Kinvey) owns the services, which developers can then integrate into their own apps. If you are a developer and want to build your own backend, you certainly can do that. Whether you want to or not depends on whether your backend provides functionality common to many different apps. If it does (as in a shopping cart or user authenti-cation) then perhaps that time and money would be better spent on features that offer unique value to your customer. You may be better off hooking into a commercial backend provider via an API. Then you can focus on what counts most — a unique user experience and application-specific functionality. That brings us to the first step in making an app.

Define your appMost unsuccessful apps fail for any of four reasons:

1. the app was a solution in search of a problem (i.e., no real need existed) 2. the implementation was poor 3. the app tried to do too much; or 4. the Apple App Store rejected the app (either because the implementation was poor or it violated Apple’s content policies)

Keeping the app as simple as possible is the best way to avoid these pitfalls. Most successful apps (indeed, most successful consumer tech products) are based on what is called an MVP, or minimum viable product. It’s the product with the smallest feature set that can deliver the core function without any distracting “bells and whistles.” You know you have an MVP if the product would no longer function if you removed any single feature.

But what should that core feature be? One of the best examples of an MVP is Mail. Version 1 (on the Mac) offered a clear, limited and intuitive feature set whose usefulness was immediately obvious to anyone. Today’s iPhone version integrates seamlessly with your phone, contacts and calendaring. It auto-matically corrects spelling as you type, lets you email photos directly from your photos app, and does much more. But all that came later and was built on top of a basic core function. And that’s how your first app should be built. The key is to come up with something with a clear value that changes people’s lives.

So, in drawing up your MVP feature list, ask yourself what features are key to the experience. Some basic market research is probably in order, starting with a visit to the App Store to see what already exists (possibly to be improved upon and/or to compete with you). Likely

must-have core capabilities include:

• Performance (e.g., fast screen refresh)• Offline capability (i.e., ability to work when not connected to the Internet)• Location awareness (e.g., the data/experience will change with the user’s location)• Cloud syncing (e.g., users see the same data on multiple devices)• Push notifications (i.e., sending updated information to devices as soon as it is available)

When you have a handle on what your app does, the next step is to design it. Designing your app involves making choices of how infor-mation and controls are presented to the user as well as how to implement app logic, and figuring out what data lives locally and what belongs in the Cloud.

Design your appUser experience decisions determine the app’s look and feel. They answer questions such as: What does the app look like? What screens does it have? In the software development world, onscreen objects like buttons, sliders, and fill-in boxes are called widgets. So you need to decide which types of widgets will reside on which screens. And what actions will occur as a result of the user interacting with those widgets?

Keep in mind that users will expect to interact differently with a mobile device than they do with a PC because the screens on mobile devices are much smaller. They’ll expect to use their fingers instead of a mouse or a track pad. Ideally, your app can even be used with one hand holding the device while using just a thumb for scrolling andworking the app’s other controls— the Path app is a good example, and increasingly, so is Facebook.

Your app’s features will inform its architecture, which is how you’ll divide the code and data into functional parts. If your app requires interacting with other app users or networked services, you’ll need to figure out what piece of the logic lives in the app code and what comes from the backend. For example, your app might integrate with a restau-rant recommendation engine, share user location, or pull real-time traffic data. This is done using APIs provided by various service providers — but you don’t have to wire up your app to a network to get started. You can develop a prototype using predefined representative (or “dummy”) data. It’s easier to fine-tune the front end if you don’t have to simultaneously modify your backend too. Once you get the app’s look-and-feel right, then make those backend connections.

Once you’ve got the overall concept for your app, the next step is to express that design in terms of the iOS app architecture. That archi-tecture is the model for what parts an iOS app can contain and how those parts fit together. It’s a well thought-out approach for translat-ing a product concept into actual code you can deploy on a device.

WHY iOS?Besides the features and design of your first app, there’s one more decision you need to make before you start actual development. That’s whether to deploy on Apple’s iOS platform or on Google’s Android platform. (Some of this is also covered in our ebook, How to Make an App: Android Edition.) Reasons to develop for iOS include:

Customers more willing to pay. Perhaps it’s because of Android’s open source heritage, but whatever the reason, Android apps gener-ate less than 10% of the total dollars spent on mobile apps, despite having 75% of the smartphone market itself — and despite the fact that the average selling price of an app in the Google Play is $3.79 versus Apple App Store’s $2.01. In other words, Apple users are much more willing to spend money on apps.

The Apple Ecosystem. Some developers and users prefer Apple’s closed and more tightly controlled environment. Apple’s ecosystem, consisting of Xcode, iCloud, iTunes, the App Store, the iPad, the iPhone, Mac computers, etc., offers a very holistic user experience with the ability to share data seamlessly across devices plus the

assurance of having applications pre-approved for quality and content prior to going on sale.

Xcode. Apple’s all-in-one IDE offers state-of-the-art offers features like a graphical interface builder and a syntax-aware and compiler-aware source editor.

The Apple Experience. From the fit and finish of its hardware to the customer service in its retail stores, to the way its hardware and software work flawlessly together, Apple has created the premium brand in consumer electronics. iOS developers share the benefits — so when someone downloads your iOS app, they already expect it’s a great product. And that it will also work flawlessly on their device.

Tablets. iOS has a clear advantage over Android in terms of tablet market adoption. Using Xcode, it’s also much easier to migrate an app from a phone to a tablet and vice versa than it is when develop-ing for Android.

Why Not iOS?Although iOS offers many compelling advantages as a platform for your mobile app, it also comes with some disadvantages. Here are three:

Closed Platform. iOS apps only run on Apple products so you can’t take advantage of features (like NFC) available only on non-iOS devices or market growth of non-iOS devices.

Market Growth. Today, iOS represents less than 15% of the total smartphone market, Although the total market (“the whole pie”) is still increasing at a fast rate, Android market growth outpaces iOS growth.

Approvals. The App Store’s app approval process is notoriously more time consuming than Google Play’s process.

The iOS app architectureAs noted earlier, a key reason why there are so many apps for iOS is because developing highly functional, polished apps for the platform is relatively easy. That’s mainly because of: 1) the design of the development tools, and 2) the key architectural features most iOS apps have in common. So let’s start with some concepts since it helps to know what goes into an app before trying to create one. We’ll begin with:

• Design patterns• Frameworks• Delegation• Storyboard• Windows• Outlets• Supporting files• Products

Design patterns. iOS apps implement what is known as a Mod-el-View-Controller (MVC) pattern. A pattern is a common way to structure code that solves a particular design problem. The MVC pattern separates application code in a way that allows you to easily change one part of an app without having to change other parts. An MVC pattern consists of three components:

• The Model is the logic that acts on the data, such as to store or retrieve data from a database, compute the distance between two cities on a map, etc. An example of a model is the Kinvey backend that stores your data in the Cloud as a service.

• The View provides the interface to the user; it displays the data and widgets (e.g., buttons and text fields) that allow the user to interact with the data. An iPhone app may have more than one view, as in the Contacts app, which displays a list view of all contacts or alternatively a view of each individual contact.

• The Controller is between the model and the view — i.e., it responds to user requests (made in a view) and retrieves results

(produced in a model). This is where developers spend most of their time — constructing the View Controller — by defining and attaching actions (or behaviors) to onscreen widgets. When the user taps a button, for example, it is the View Controller that determines what action will occur, such as retrieve stored data from your Kinvey-based data store. The link between a view object (like a button) to a controller action is called a connection.

Frameworks. You don’t actually have to write most of an app’s logic. It already exists as frameworks. A framework is a collection of classes that implements some function — such as connecting to the Internet, drawing a button, etc. Rather than write the code from scratch, you just use the frameworks supplied by iOS. Some frameworks are automatically present when you start a new project while others may need to be added (done via a drop down menu in Xcode’s Project Editor).

Delegation. Say, you want to customize the behavior of a framework’s object. You can’t actually modify the code of the framework class itself (prohibited since other apps may also use the framework). But what you can do is provide app-specific behavior in an application delegate object. If a delegate implements a method, it will be called by the delegating class to modify its behavior. In the Kinvey sample app (one of two examples we will be describing below), the AppDele-gate.h and AppDelegate.m — the header and implementation files for the UIApplicationDelegate, respectively — contain the code that authenticates an app to the Kinvey backend service.

Storyboards and XIBs. The MainStoryboard.storyboard file (or a .xib file, if you did not click on the “Use Storyboard” option when starting your project) contains the view information needed to implement the overall flow and display of your application and the user interface elements.

Windows. Each view (e.g., the contact list and individual contact details in the Contacts app) exists within a window. The window represents the entire device screen and is where all your views are presented.

Outlets. A variable by which a view object can be referenced in a controller. (For example, if you place a text field to capture a user's name, you might create an outlet called UITextField* nameField.)

Supporting files. These are files that provide resources (like PNG images and other static data) that your app needs as well as files that configure how the app will run. Other examples:

.pch files — precompiled headers used for the code files in your project.

.plist files — property lists that are small amounts of persistent data (like your app’s default user settings) consisting primarily of strings and numbers that you want your app to be able to access, modify if needed, and write back into the property list.

main.m file — your app’s main function. This is needed to launch the app, but you will not need to modify this file.

InfoPlist.strings file — used for localization.

Products. This is the file for your app (i.e., YourProduct.app) that is built when you click Xcode’s “run” button.

“Making an iOS app” involves working with these features in the typical, straightforward workflow:

• Storyboard your views by dragging and configuring graphicalobjects on a template

• Adding behaviors to the various widgets• Writing the classes as to define those behaviors (including

delegates)• Adding needed support files• Building and running the app• Iterating until you are satisfied with your app

This is all done within Xcode.

What’s Xcode?You can start developing functional, good-looking apps almost from the moment you download Xcode, Apple’s integrated development environment (IDE) for making iOS and Macintosh apps. Among other features, Xcode includes a source code editor, graphical user inter-face (GUI) editor (sometimes called Interface Builder), source code repository manager, compiler, and much more. iOS applications are typically developed by manipulating views graphically and by typing Objective-C code for the models and controllers.

To get Xcode, simply go to the App Store and download the applica-tion (it’s free). To do this, click on the App Store icon in your Mac’s dock, or visit https://itunes.apple.com/us/genre/ios/id36?mt=8

The app store will download and install Xcode in your Application folder. From Applications, double-click the Xcode icon to launch Xcode and you’ll see its splash screen (Figure 1). From there you can click on “Create a new Xcode project” to take you to a menu of several templates on which to base your application. Selecting a template opens an Xcode workspace pre-populated with frameworks and other files Xcode thinks you will need using that template.

Although you can develop, build and simulate your app on your computer in Xcode, you can’t run your app on a target device (even your own iPhone) until you become a registered iOS developer and join the iOS Developer Program. To do that, go to develop-er.app.com/ and navigate to the iOS Dev Center. While there, you will also find documentation, sample code and other useful resources such as information on how to submit your app to the iOS App Store.

Everything you do in Xcode is done in a window, called a workspace (Figure 2), consisting of multiple work areas, some of which are also divided into panes. All the files needed to build your app belong to a project, and the Navigator area (far left) lists all your projects (there can be several in a workspace) and all files for each project. Clicking on a file in the Navigator area shows its contents in the Editor area and invokes the appropriate editor. Clicking on a .h or .m file, for example, shows the file’s source code and invokes the Source editor, so you can edit the code. Clicking on .storyboard or .xib (sometimes called a “nib”) file shows the app’s storyboard and invokes the Inter-face Builder, so you can design a view using the Builder’s drag and drop features.

An especially handy feature is that the Editor area can have both a right and a left pane — with each pane aware of your edits in the other. So, for example, you can simultaneously edit an object’s .h

header file in the left pane and its corresponding .m in the right pane. Or you might click on a button object (displayed graphically) in the left pane and edit its method’s source code in the right pane. To toggle between a single pane (the “Standard Editor”) and double pane view (the “Assistant Editor”), use the Editor selector button on the right of the toolbar. You can option+command+click a symbol in the editor to open the definition in the opposite editor pane.

You can also resize the entire Editor area simply by dragging its borders. For even more editing space, you can also remove the Debug area or both the Debug and Utility areas using the View Selector button on the far right of the toolbar.

As its name suggests, the Debug area shows information, like variable state and console logs, helpful in debugging code.

The Utility area has two panes: the Inspector and Quick Help pane (top) and the Library pane (bottom). Although there are five inspectors — File, Help, Identity, Attributes, Size and Connec-tions — only the inspectors that are currently relevant appear in the Inspec-tor list at the top of the pane. (To see the name of an inspector, move the cursor over its icon in the Inspector selector bar.)

You will use inspectors to add and modify object attributes for views in the Interface Builder. For example, if you click on a UILabel in the Editor area of a storyboard, you can use the Attributes inspector to change the label’s color and use the Size inspector to change the label’s size.

The Help inspector shows help information about a selected class. Use the Identity inspector to view and manage an object’s metadata such as its class, runtime attributes, label and so forth. Use the

Connections inspector to view the outlets and actions of an interface object, to make new connections and to delete existing connections.

The Library pane has libraries of resources (like file templates, code snippets, interface objects and media files) that are prebuilt and ready to insert into your project. Use the Library selector to select which of these libraries (e.g., code snippets or interface objects) you wish to insert. To insert one, drag it directly into your storyboard while using the Interface Builder editor.

These are basics you need to know to get started using Xcode to build your first app. But to really understand how it’s done, it helps to walk through an actual app or two. Let’s start with a simple “Hello World” app that does not employ a backend connection, and then look at a somewhat more functional app that does.

“Hello World!” sample appThis app displays a button (“Press Me”) and a label (“Label”) so that when the user presses the button the text of the label changes to “Hello World!” as in Figure 3:

To get started, launch Xcode and select “Create a New Xcode Project.” From the iOS Application templates, select “Single View Application” and click “Next.” Fill in your product’s name and a company identifier, typically “com.yourCompanyName.” Deselect “Use Storyboards” and leave “Use Automatic Reference Counting” selected. Then click “Next” and select a destination for your projects files.

Follow these steps to make your app:

1. Select your project’s ViewController.xib file in the Navigator(Figure 4), to open the Interface Builder editor.

2. Drag a “Round Rect Button” from the Objects library (lowerright) onto the view in the Editor area; select the button’s textand type “Press Me.”

3. Drag a Label from the objects library onto the view, as well.4. Select and drag the Label sizing handles, centering the object

and making it wide enough to hold the “Hello World!” text; then,

5. With the “Hello World!” label still selected, click on centeralignment in the Attributes inspector.

6. Open the Assistant Editor (Figure 5), exposing the source codeheader file (ViewController.h) of the view controller you justbuilt graphically.

7. Select the button and control-drag from the button to justbelow the ViewController definition in the Assistant panel. Inthe form that opens, select “Action” for the connection type,type in a name (“showText”) and click “Connect.” This creates aninterface builder (IB) action as highlighted in Figure 6.

8. Next step is to create an outlet for the label. To do this, selectthe label object and control-drag from the label to just belowthe IB action you just created. Select “Outlet” as the connectiontype and enter a name “label” and click “Connect.” This createsan interface builder (IB) outlet as shown in Figure 7.

9. Finally, it’s time to add some logic to the view controller so itknows what to do when the button is pressed. To do this, select “ViewController.m” in the project navigator to show the code editor. Find the button’s IBAction you just created (near the bottom), place your cursor between the { } brackets and hit the return key a few times to create some extra space. Then in that space type the method for how you want the label you speci-fied to respond: _label.text=”Hello World!”; as highlighted in Figure 8.

Congratulations! Your app is done. To build and run your new app in the simulator, click the Xcode Run button in the left corner of the toolbar. When you click the button, the text will update.

Sample app with a backend This second app (named “Kinvey Test Drive”) lets the user type text on an iPhone and save the text to a backend service, like Kinvey. It also lets the user load text on the iPhone from their Kinvey backend. Reading about this app will help you learn:

• How to set up Kinvey’s library in an iOS project• Additional Interface Builder techniques you can use to story-board an application• How to add view controller logic to interact with the backend service, allowing you to save and retrieve data

We will first present the app as a running application and then take it apart so you can see how it was made. To make the app yourself, you can review the various sections below and replicate the steps in your copy of Xcode.

First, to see the app in action, you should download the app and run it on your system. To do that, sign up for Kinvey, then navigate to “Dev Center”, “Samples,” find the “Test Drive” app, and click on its icon. (If you can’t find it right away, make sure you select iOS as your platform on the right side of the menu bar.) Click the download button to download the app’s project files to your computer. Then launch Xcode — just double click on the .xcodeproj file in the project folder.

But before you can run the app, you need to set up the app’s Kinvey backend.

Set Up Kinvey as a Backend Data StoreTest Drive’s project files include all the code the sample app needs in order to talk to Kinvey. However, that would not be the case if you were to build an app from scratch — so you would have to go through an initial Kinvey setup procedure. This involves downloading the Kinvey library files from the downloads section of devcenter.kin-vey.com and dragging them to the Navigator’s Frameworks folder in Xcode. You also need to tell Xcode to link your project with additional iOS frameworks. To find these frameworks, click on the Project folder

at the very top of the Navigator pane — which displays the Project editor — and then select the “Build Settings” tab. For detailed instruc-tions, complete the “Getting Started” page under “Guides” on the Kinvey website. But again, you can skip this setup procedure for now in order to run the downloaded Kinvey Test Drive app.

But you must still do this step: To run any app that uses Kinvey (including Test Drive) you need to do the “Create an App” step on the Kinvey website. Click on “My Apps” in the Kinvey menu bar and then click on “Add an App,” which will open an “Add” page. Type in a name for your app and click on the Apple logo and then click “Create.” The page that opens shows your App’s credentials. Copy and paste the App Key and App Secret into the AppDelegate.m file of the download-ed Test Drive project:

You are now ready to run the app — click on the Xcode run button and wait for the simulator to open and the app to appear (Figure 9).

Clicking the “+” toolbar button opens an alert (Figure 10) with an empty field into which the user can type some text (e.g., “some new data”). Clicking “save” uploads the data to Kinvey and displays text on the screen (a table view) and also displays an alert that the save worked (Figure 11).

To test the load function, enter some data (e.g., “some data to load”) in the “name” field of the Kinvey collection. To see the load, the swipe down on the table on the phone until the refresh spinner starts, and then the new data will appear in the table (Figure 12).

Figure 13 shows the Kinvey collection after the save that Figure 10 depicts on the iPhone. Figure 14 shows the Kinvey collection after the user adds a new row to the testObjects collection using the web browser. Note that every time a save is done on the iPhone, Kinvey automatically adds a new row (displayed on a collection refresh). To add a new row manually in the browser, click “+ row,” and type some descriptive text in the “name” column. That data will now load on the iPhone when the user pulls down on the table.

Storyboard the Test Drive AppMost of the Test Drive user interface objects visible in the simulation are available in Xcode’s Object Library and can therefore be added to the view graphically. The UI objects consist of a:

• Table view• Toolbar• Tool Bar Button item – flexible space• Tool Bar Button item – Add• Table view cell• Label – Title• Refresh Control

To create this app yourself, you would follow these steps:

• Launch Xcode and select the “Single View Application” template• Select the “Use Storyboard” option• Replace the default UIviewcontroller object with a UITableView-Controller • Drag and drop the other objects, in the order listed, onto the UIviewcontroller

Also note:

• The Flexible Space Bar Button item fills up the space on the toolbar so the add button is at the right. This is a standard pattern in table-based iPhone apps.• The add button shows the system “+” sign. That is done by dragging a bar button item onto the toolbar, clicking on the Identifier drop down menu in the Attributes inspector; and then selecting the “Add” option.

As with the “Hello World!” app, once your app’s view is complete (Figure 15), you would still have to create the various methods and connections that bring them to life. This is done using the Source editor while working with the ViewController.m file.

Add View Controller LogicSince the app performs two basic operations (save data to Kinvey and load data from Kinvey) these two methods must be added to the ViewController header file. That’s done with a control-drag from the “+” bar button over to just under the “@ interface ViewController” line in ViewController.h. (Open the Assistant editor to see both the storyboard and the file source.)

During the drag, the popup appears, asking for the name and type of connection. Enter “action” for the connection type and “add” for the name. Then repeat the drag, this time from the refresh control and using “add” for the name (Figure 16).

Note: to follow this discussion it will help to have the referenced files open in your Xcode Source editor.

In ViewController.m, you will see the implementation code associated with each of the two Interface Builder methods, whose names Xcode added automatically to the .m file:

- (IBAction)add:(id)sender- (IBAction)load:(id)sender

You will also see a third section of code not associated with these methods, which starts with the line: “#pragma mark - Table View Stuff.” These methods support the table view and are part of UITableViewD-elegate and UITableViewDataSource. They handle controlling the

display of the table, and respond to user gestures. For example, swiping a table cell will show the delete button because tableView:-canEditRowAtIndexPath: returns YES and tableView:editingStyleForRowA-tIndexPath: returns UITableViewCellEditingStyleDelete. If you tap the delete button, the delegate method tableView:commitEditingStyle:for-RowAtIndexPath: is called. The code of this method deletes the data for the row and removes it from Kinvey’s data store. When the backend delete is completed, the app displays an alert describing the success or failure.

The way that all three sections (and all Kinvey-enabled apps) move data in and out of a Kinvey collection is by getting a reference to the app’s backend collection (named “testObjects”), which is filled with instances (each named “TestObject”) of the data the app wants to move. That’s why you’ll find the following code repeated three times in Test Drive’s View Controller (once for the add, once for the load, and once for the delete):

To support these statements it is required to have a data object class (TestObject). To see how these files are written in the sample project, click on TestObject.h file and TestObject.m in the Navigator pane. If you were to supply these files in your own app, you would click File > New File, and specify Objective-C class, which would be a subclass of NSObject. Then you would type in the code, with a property for each column in the Kinvey backend collection (including one for the object’s id).

As mentioned earlier, your app also needs to authenticate itself to Kinvey, which is handled by AppDelegate.h and AppDelgate.m. These files are created by Xcode when you create a new project, and start out with just a stub implementation. Look in the sample app source

files for code to copy and paste.

For both the save and load operations, however, moving the data in and out of a backend collection is only part of the work. Table 1 lists all the functions that implements the save and load in the ViewCon-troller.m file, along with pointers to its corresponding block of imple-mentation source code. (For each function, its corresponding code begins with the “Starts at” line and ends with the “Ends at” line.) Refer to Appendix 1 to find the actual source code.

Say Hello To Our WorldThe key takeaway from all this is that “making an app” is a worthwhile thing to do for anyone with a clever idea and a working knowledge of Objective-C. The proof is in the hundreds of apps succeeding in the market every day, many written by people working on their own and who never wrote an app before in their lives. As with anything else, practice does make perfect. But hopefully with all the resources available, and the knowledge gained from this ebook, you have already started down the path toward joining the growing legions of iOS app developers. If so, we welcome you!

Appendix 1 — Test Drive Sample App ViewController.m Source Code

Table of ContentsThe iOS Revolution

Step 1: Define Your App

Step 2: Design Your App

Step 3: The iOS Architecture

Step 4: What is Xcode?

Step 5: “Hello World” Sample App

Step 6: Sample App with a Backend

1

4

7

13

17

22

27

The iOS revolutionIt’s a story that never gets old. The weekend that iPad Minis and the fourth generation iPads went on sale (November 2-5, 2012) Apple sold over 3 million of the devices — a record for first-weekend iPad sales. Two months earlier the company had set another record: first weekend sales of over 5 million for the iPhone 5. Since the introduc-tion of the first iPhone back in 2007,

iOS-based devices (iPhone, iPad, iPad Mini and iPod Touch) continue to rewrite the definition of what constitutes a successful product. By the end of 2012, over 400 million iOS devices had been sold.

What makes iOS devices so successful? Innovation and product features are clearly a big part. Before the iPhone most people had not interacted with a multi-touch interface. They had never zoomed with a pinch or switched between portrait and landscape by merely rotating a device in their hand. Carrying a phone that knew where they were, could suggest places to eat, and could offer directions on how to get there was also a novel experience.

But features like multi-touch, accelerometers and GPS are only part of the appeal. Even with all its innovations, iOS still might not have taken off the way it has if the only people figuring out ways to use those innovations worked at Apple. Most of the capabilities available in an iPhone or iPad in fact don’t come from Apple at all. They come from legions of third-party developers who work in a vast ecosystem that is also an Apple innovation. That ecosystem includes the iPhone, iPad, iPad Mini, iPods, App Store, iTunes, ad networks — and that’s just on the consumer side. On the developer side, you have Xcode, App Loader, testing tools, iTunes Connect — the list goes on.

As of September 2012, the App Store hosted over 700,000 apps that have collectively been downloaded over 30 billion times. Apple reported for October 2012 that App Store monthly revenues were

running at $333 million — a rate of about $4 billion per year — remarkable for a store that only opened in July 2008.

Another innovation that has spurred iOS app development is “The Cloud.” Cloud services make it easier for independent developers to create, support and make money from their apps. The Cloud solves data storage and cross-device and user-to-user sharing problems. If an app stores data in the Cloud, that part of the application is called the “backend,” while the part of the app that runs on the phone and interacts with the user is called the “front end.”

A cloud may be “private” — i.e., the services belong to an organization for the benefit of its employees and business partners. Or a cloud may be “public” — i.e., a company (such as Amazon or Kinvey) owns the services, which developers can then integrate into their own apps. If you are a developer and want to build your own backend, you certainly can do that. Whether you want to or not depends on whether your backend provides functionality common to many different apps. If it does (as in a shopping cart or user authenti-cation) then perhaps that time and money would be better spent on features that offer unique value to your customer. You may be better off hooking into a commercial backend provider via an API. Then you can focus on what counts most — a unique user experience and application-specific functionality. That brings us to the first step in making an app.

Define your appMost unsuccessful apps fail for any of four reasons:

1. the app was a solution in search of a problem (i.e., no real need existed) 2. the implementation was poor 3. the app tried to do too much; or 4. the Apple App Store rejected the app (either because the implementation was poor or it violated Apple’s content policies)

Keeping the app as simple as possible is the best way to avoid these pitfalls. Most successful apps (indeed, most successful consumer tech products) are based on what is called an MVP, or minimum viable product. It’s the product with the smallest feature set that can deliver the core function without any distracting “bells and whistles.” You know you have an MVP if the product would no longer function if you removed any single feature.

But what should that core feature be? One of the best examples of an MVP is Mail. Version 1 (on the Mac) offered a clear, limited and intuitive feature set whose usefulness was immediately obvious to anyone. Today’s iPhone version integrates seamlessly with your phone, contacts and calendaring. It auto-matically corrects spelling as you type, lets you email photos directly from your photos app, and does much more. But all that came later and was built on top of a basic core function. And that’s how your first app should be built. The key is to come up with something with a clear value that changes people’s lives.

So, in drawing up your MVP feature list, ask yourself what features are key to the experience. Some basic market research is probably in order, starting with a visit to the App Store to see what already exists (possibly to be improved upon and/or to compete with you). Likely

must-have core capabilities include:

• Performance (e.g., fast screen refresh)• Offline capability (i.e., ability to work when not connected to the Internet)• Location awareness (e.g., the data/experience will change with the user’s location)• Cloud syncing (e.g., users see the same data on multiple devices)• Push notifications (i.e., sending updated information to devices as soon as it is available)

When you have a handle on what your app does, the next step is to design it. Designing your app involves making choices of how infor-mation and controls are presented to the user as well as how to implement app logic, and figuring out what data lives locally and what belongs in the Cloud.

Design your appUser experience decisions determine the app’s look and feel. They answer questions such as: What does the app look like? What screens does it have? In the software development world, onscreen objects like buttons, sliders, and fill-in boxes are called widgets. So you need to decide which types of widgets will reside on which screens. And what actions will occur as a result of the user interacting with those widgets?

Keep in mind that users will expect to interact differently with a mobile device than they do with a PC because the screens on mobile devices are much smaller. They’ll expect to use their fingers instead of a mouse or a track pad. Ideally, your app can even be used with one hand holding the device while using just a thumb for scrolling andworking the app’s other controls— the Path app is a good example, and increasingly, so is Facebook.

Your app’s features will inform its architecture, which is how you’ll divide the code and data into functional parts. If your app requires interacting with other app users or networked services, you’ll need to figure out what piece of the logic lives in the app code and what comes from the backend. For example, your app might integrate with a restau-rant recommendation engine, share user location, or pull real-time traffic data. This is done using APIs provided by various service providers — but you don’t have to wire up your app to a network to get started. You can develop a prototype using predefined representative (or “dummy”) data. It’s easier to fine-tune the front end if you don’t have to simultaneously modify your backend too. Once you get the app’s look-and-feel right, then make those backend connections.

Once you’ve got the overall concept for your app, the next step is to express that design in terms of the iOS app architecture. That archi-tecture is the model for what parts an iOS app can contain and how those parts fit together. It’s a well thought-out approach for translat-ing a product concept into actual code you can deploy on a device.

WHY iOS?Besides the features and design of your first app, there’s one more decision you need to make before you start actual development. That’s whether to deploy on Apple’s iOS platform or on Google’s Android platform. (Some of this is also covered in our ebook, How to Make an App: Android Edition.) Reasons to develop for iOS include:

Customers more willing to pay. Perhaps it’s because of Android’s open source heritage, but whatever the reason, Android apps gener-ate less than 10% of the total dollars spent on mobile apps, despite having 75% of the smartphone market itself — and despite the fact that the average selling price of an app in the Google Play is $3.79 versus Apple App Store’s $2.01. In other words, Apple users are much more willing to spend money on apps.

The Apple Ecosystem. Some developers and users prefer Apple’s closed and more tightly controlled environment. Apple’s ecosystem, consisting of Xcode, iCloud, iTunes, the App Store, the iPad, the iPhone, Mac computers, etc., offers a very holistic user experience with the ability to share data seamlessly across devices plus the

assurance of having applications pre-approved for quality and content prior to going on sale.

Xcode. Apple’s all-in-one IDE offers state-of-the-art offers features like a graphical interface builder and a syntax-aware and compiler-aware source editor.

The Apple Experience. From the fit and finish of its hardware to the customer service in its retail stores, to the way its hardware and software work flawlessly together, Apple has created the premium brand in consumer electronics. iOS developers share the benefits — so when someone downloads your iOS app, they already expect it’s a great product. And that it will also work flawlessly on their device.

Tablets. iOS has a clear advantage over Android in terms of tablet market adoption. Using Xcode, it’s also much easier to migrate an app from a phone to a tablet and vice versa than it is when develop-ing for Android.

Why Not iOS?Although iOS offers many compelling advantages as a platform for your mobile app, it also comes with some disadvantages. Here are three:

Closed Platform. iOS apps only run on Apple products so you can’t take advantage of features (like NFC) available only on non-iOS devices or market growth of non-iOS devices.

Market Growth. Today, iOS represents less than 15% of the total smartphone market, Although the total market (“the whole pie”) is still increasing at a fast rate, Android market growth outpaces iOS growth.

Approvals. The App Store’s app approval process is notoriously more time consuming than Google Play’s process.

The iOS app architectureAs noted earlier, a key reason why there are so many apps for iOS is because developing highly functional, polished apps for the platform is relatively easy. That’s mainly because of: 1) the design of the development tools, and 2) the key architectural features most iOS apps have in common. So let’s start with some concepts since it helps to know what goes into an app before trying to create one. We’ll begin with:

• Design patterns• Frameworks• Delegation• Storyboard• Windows• Outlets• Supporting files• Products

Design patterns. iOS apps implement what is known as a Mod-el-View-Controller (MVC) pattern. A pattern is a common way to structure code that solves a particular design problem. The MVC pattern separates application code in a way that allows you to easily change one part of an app without having to change other parts. An MVC pattern consists of three components:

• The Model is the logic that acts on the data, such as to store or retrieve data from a database, compute the distance between two cities on a map, etc. An example of a model is the Kinvey backend that stores your data in the Cloud as a service.

• The View provides the interface to the user; it displays the data and widgets (e.g., buttons and text fields) that allow the user to interact with the data. An iPhone app may have more than one view, as in the Contacts app, which displays a list view of all contacts or alternatively a view of each individual contact.

• The Controller is between the model and the view — i.e., it responds to user requests (made in a view) and retrieves results

(produced in a model). This is where developers spend most of their time — constructing the View Controller — by defining and attaching actions (or behaviors) to onscreen widgets. When the user taps a button, for example, it is the View Controller that determines what action will occur, such as retrieve stored data from your Kinvey-based data store. The link between a view object (like a button) to a controller action is called a connection.

Frameworks. You don’t actually have to write most of an app’s logic. It already exists as frameworks. A framework is a collection of classes that implements some function — such as connecting to the Internet, drawing a button, etc. Rather than write the code from scratch, you just use the frameworks supplied by iOS. Some frameworks are automatically present when you start a new project while others may need to be added (done via a drop down menu in Xcode’s Project Editor).

Delegation. Say, you want to customize the behavior of a framework’s object. You can’t actually modify the code of the framework class itself (prohibited since other apps may also use the framework). But what you can do is provide app-specific behavior in an application delegate object. If a delegate implements a method, it will be called by the delegating class to modify its behavior. In the Kinvey sample app (one of two examples we will be describing below), the AppDele-gate.h and AppDelegate.m — the header and implementation files for the UIApplicationDelegate, respectively — contain the code that authenticates an app to the Kinvey backend service.

Storyboards and XIBs. The MainStoryboard.storyboard file (or a .xib file, if you did not click on the “Use Storyboard” option when starting your project) contains the view information needed to implement the overall flow and display of your application and the user interface elements.

Windows. Each view (e.g., the contact list and individual contact details in the Contacts app) exists within a window. The window represents the entire device screen and is where all your views are presented.

Outlets. A variable by which a view object can be referenced in a controller. (For example, if you place a text field to capture a user's name, you might create an outlet called UITextField* nameField.)

Supporting files. These are files that provide resources (like PNG images and other static data) that your app needs as well as files that configure how the app will run. Other examples:

.pch files — precompiled headers used for the code files in your project.

.plist files — property lists that are small amounts of persistent data (like your app’s default user settings) consisting primarily of strings and numbers that you want your app to be able to access, modify if needed, and write back into the property list.

main.m file — your app’s main function. This is needed to launch the app, but you will not need to modify this file.

InfoPlist.strings file — used for localization.

Products. This is the file for your app (i.e., YourProduct.app) that is built when you click Xcode’s “run” button.

“Making an iOS app” involves working with these features in the typical, straightforward workflow:

• Storyboard your views by dragging and configuring graphicalobjects on a template

• Adding behaviors to the various widgets• Writing the classes as to define those behaviors (including

delegates)• Adding needed support files• Building and running the app• Iterating until you are satisfied with your app

This is all done within Xcode.

What’s Xcode?You can start developing functional, good-looking apps almost from the moment you download Xcode, Apple’s integrated development environment (IDE) for making iOS and Macintosh apps. Among other features, Xcode includes a source code editor, graphical user inter-face (GUI) editor (sometimes called Interface Builder), source code repository manager, compiler, and much more. iOS applications are typically developed by manipulating views graphically and by typing Objective-C code for the models and controllers.

To get Xcode, simply go to the App Store and download the applica-tion (it’s free). To do this, click on the App Store icon in your Mac’s dock, or visit https://itunes.apple.com/us/genre/ios/id36?mt=8

The app store will download and install Xcode in your Application folder. From Applications, double-click the Xcode icon to launch Xcode and you’ll see its splash screen (Figure 1). From there you can click on “Create a new Xcode project” to take you to a menu of several templates on which to base your application. Selecting a template opens an Xcode workspace pre-populated with frameworks and other files Xcode thinks you will need using that template.

Although you can develop, build and simulate your app on your computer in Xcode, you can’t run your app on a target device (even your own iPhone) until you become a registered iOS developer and join the iOS Developer Program. To do that, go to develop-er.app.com/ and navigate to the iOS Dev Center. While there, you will also find documentation, sample code and other useful resources such as information on how to submit your app to the iOS App Store.

Everything you do in Xcode is done in a window, called a workspace (Figure 2), consisting of multiple work areas, some of which are also divided into panes. All the files needed to build your app belong to a project, and the Navigator area (far left) lists all your projects (there can be several in a workspace) and all files for each project. Clicking on a file in the Navigator area shows its contents in the Editor area and invokes the appropriate editor. Clicking on a .h or .m file, for example, shows the file’s source code and invokes the Source editor, so you can edit the code. Clicking on .storyboard or .xib (sometimes called a “nib”) file shows the app’s storyboard and invokes the Inter-face Builder, so you can design a view using the Builder’s drag and drop features.

An especially handy feature is that the Editor area can have both a right and a left pane — with each pane aware of your edits in the other. So, for example, you can simultaneously edit an object’s .h

header file in the left pane and its corresponding .m in the right pane. Or you might click on a button object (displayed graphically) in the left pane and edit its method’s source code in the right pane. To toggle between a single pane (the “Standard Editor”) and double pane view (the “Assistant Editor”), use the Editor selector button on the right of the toolbar. You can option+command+click a symbol in the editor to open the definition in the opposite editor pane.

You can also resize the entire Editor area simply by dragging its borders. For even more editing space, you can also remove the Debug area or both the Debug and Utility areas using the View Selector button on the far right of the toolbar.

As its name suggests, the Debug area shows information, like variable state and console logs, helpful in debugging code.

The Utility area has two panes: the Inspector and Quick Help pane (top) and the Library pane (bottom). Although there are five inspectors — File, Help, Identity, Attributes, Size and Connec-tions — only the inspectors that are currently relevant appear in the Inspec-tor list at the top of the pane. (To see the name of an inspector, move the cursor over its icon in the Inspector selector bar.)

You will use inspectors to add and modify object attributes for views in the Interface Builder. For example, if you click on a UILabel in the Editor area of a storyboard, you can use the Attributes inspector to change the label’s color and use the Size inspector to change the label’s size.

The Help inspector shows help information about a selected class. Use the Identity inspector to view and manage an object’s metadata such as its class, runtime attributes, label and so forth. Use the

Connections inspector to view the outlets and actions of an interface object, to make new connections and to delete existing connections.

The Library pane has libraries of resources (like file templates, code snippets, interface objects and media files) that are prebuilt and ready to insert into your project. Use the Library selector to select which of these libraries (e.g., code snippets or interface objects) you wish to insert. To insert one, drag it directly into your storyboard while using the Interface Builder editor.

These are basics you need to know to get started using Xcode to build your first app. But to really understand how it’s done, it helps to walk through an actual app or two. Let’s start with a simple “Hello World” app that does not employ a backend connection, and then look at a somewhat more functional app that does.

“Hello World!” sample appThis app displays a button (“Press Me”) and a label (“Label”) so that when the user presses the button the text of the label changes to “Hello World!” as in Figure 3:

To get started, launch Xcode and select “Create a New Xcode Project.” From the iOS Application templates, select “Single View Application” and click “Next.” Fill in your product’s name and a company identifier, typically “com.yourCompanyName.” Deselect “Use Storyboards” and leave “Use Automatic Reference Counting” selected. Then click “Next” and select a destination for your projects files.

Follow these steps to make your app:

1. Select your project’s ViewController.xib file in the Navigator(Figure 4), to open the Interface Builder editor.

2. Drag a “Round Rect Button” from the Objects library (lowerright) onto the view in the Editor area; select the button’s textand type “Press Me.”

3. Drag a Label from the objects library onto the view, as well.4. Select and drag the Label sizing handles, centering the object

and making it wide enough to hold the “Hello World!” text; then,

5. With the “Hello World!” label still selected, click on centeralignment in the Attributes inspector.

6. Open the Assistant Editor (Figure 5), exposing the source codeheader file (ViewController.h) of the view controller you justbuilt graphically.

7. Select the button and control-drag from the button to justbelow the ViewController definition in the Assistant panel. Inthe form that opens, select “Action” for the connection type,type in a name (“showText”) and click “Connect.” This creates aninterface builder (IB) action as highlighted in Figure 6.

8. Next step is to create an outlet for the label. To do this, selectthe label object and control-drag from the label to just belowthe IB action you just created. Select “Outlet” as the connectiontype and enter a name “label” and click “Connect.” This createsan interface builder (IB) outlet as shown in Figure 7.

9. Finally, it’s time to add some logic to the view controller so itknows what to do when the button is pressed. To do this, select “ViewController.m” in the project navigator to show the code editor. Find the button’s IBAction you just created (near the bottom), place your cursor between the { } brackets and hit the return key a few times to create some extra space. Then in that space type the method for how you want the label you speci-fied to respond: _label.text=”Hello World!”; as highlighted in Figure 8.

Congratulations! Your app is done. To build and run your new app in the simulator, click the Xcode Run button in the left corner of the toolbar. When you click the button, the text will update.

Sample app with a backend This second app (named “Kinvey Test Drive”) lets the user type text on an iPhone and save the text to a backend service, like Kinvey. It also lets the user load text on the iPhone from their Kinvey backend. Reading about this app will help you learn:

• How to set up Kinvey’s library in an iOS project• Additional Interface Builder techniques you can use to story-board an application• How to add view controller logic to interact with the backend service, allowing you to save and retrieve data

We will first present the app as a running application and then take it apart so you can see how it was made. To make the app yourself, you can review the various sections below and replicate the steps in your copy of Xcode.

First, to see the app in action, you should download the app and run it on your system. To do that, sign up for Kinvey, then navigate to “Dev Center”, “Samples,” find the “Test Drive” app, and click on its icon. (If you can’t find it right away, make sure you select iOS as your platform on the right side of the menu bar.) Click the download button to download the app’s project files to your computer. Then launch Xcode — just double click on the .xcodeproj file in the project folder.

But before you can run the app, you need to set up the app’s Kinvey backend.

Set Up Kinvey as a Backend Data StoreTest Drive’s project files include all the code the sample app needs in order to talk to Kinvey. However, that would not be the case if you were to build an app from scratch — so you would have to go through an initial Kinvey setup procedure. This involves downloading the Kinvey library files from the downloads section of devcenter.kin-vey.com and dragging them to the Navigator’s Frameworks folder in Xcode. You also need to tell Xcode to link your project with additional iOS frameworks. To find these frameworks, click on the Project folder

at the very top of the Navigator pane — which displays the Project editor — and then select the “Build Settings” tab. For detailed instruc-tions, complete the “Getting Started” page under “Guides” on the Kinvey website. But again, you can skip this setup procedure for now in order to run the downloaded Kinvey Test Drive app.

But you must still do this step: To run any app that uses Kinvey (including Test Drive) you need to do the “Create an App” step on the Kinvey website. Click on “My Apps” in the Kinvey menu bar and then click on “Add an App,” which will open an “Add” page. Type in a name for your app and click on the Apple logo and then click “Create.” The page that opens shows your App’s credentials. Copy and paste the App Key and App Secret into the AppDelegate.m file of the download-ed Test Drive project:

You are now ready to run the app — click on the Xcode run button and wait for the simulator to open and the app to appear (Figure 9).

Clicking the “+” toolbar button opens an alert (Figure 10) with an empty field into which the user can type some text (e.g., “some new data”). Clicking “save” uploads the data to Kinvey and displays text on the screen (a table view) and also displays an alert that the save worked (Figure 11).

To test the load function, enter some data (e.g., “some data to load”) in the “name” field of the Kinvey collection. To see the load, the swipe down on the table on the phone until the refresh spinner starts, and then the new data will appear in the table (Figure 12).

Figure 13 shows the Kinvey collection after the save that Figure 10 depicts on the iPhone. Figure 14 shows the Kinvey collection after the user adds a new row to the testObjects collection using the web browser. Note that every time a save is done on the iPhone, Kinvey automatically adds a new row (displayed on a collection refresh). To add a new row manually in the browser, click “+ row,” and type some descriptive text in the “name” column. That data will now load on the iPhone when the user pulls down on the table.

Storyboard the Test Drive AppMost of the Test Drive user interface objects visible in the simulation are available in Xcode’s Object Library and can therefore be added to the view graphically. The UI objects consist of a:

• Table view• Toolbar• Tool Bar Button item – flexible space• Tool Bar Button item – Add• Table view cell• Label – Title• Refresh Control

To create this app yourself, you would follow these steps:

• Launch Xcode and select the “Single View Application” template• Select the “Use Storyboard” option• Replace the default UIviewcontroller object with a UITableView-Controller • Drag and drop the other objects, in the order listed, onto the UIviewcontroller

Also note:

• The Flexible Space Bar Button item fills up the space on the toolbar so the add button is at the right. This is a standard pattern in table-based iPhone apps.• The add button shows the system “+” sign. That is done by dragging a bar button item onto the toolbar, clicking on the Identifier drop down menu in the Attributes inspector; and then selecting the “Add” option.

As with the “Hello World!” app, once your app’s view is complete (Figure 15), you would still have to create the various methods and connections that bring them to life. This is done using the Source editor while working with the ViewController.m file.

Add View Controller LogicSince the app performs two basic operations (save data to Kinvey and load data from Kinvey) these two methods must be added to the ViewController header file. That’s done with a control-drag from the “+” bar button over to just under the “@ interface ViewController” line in ViewController.h. (Open the Assistant editor to see both the storyboard and the file source.)

During the drag, the popup appears, asking for the name and type of connection. Enter “action” for the connection type and “add” for the name. Then repeat the drag, this time from the refresh control and using “add” for the name (Figure 16).

Note: to follow this discussion it will help to have the referenced files open in your Xcode Source editor.

In ViewController.m, you will see the implementation code associated with each of the two Interface Builder methods, whose names Xcode added automatically to the .m file:

- (IBAction)add:(id)sender- (IBAction)load:(id)sender

You will also see a third section of code not associated with these methods, which starts with the line: “#pragma mark - Table View Stuff.” These methods support the table view and are part of UITableViewD-elegate and UITableViewDataSource. They handle controlling the

display of the table, and respond to user gestures. For example, swiping a table cell will show the delete button because tableView:-canEditRowAtIndexPath: returns YES and tableView:editingStyleForRowA-tIndexPath: returns UITableViewCellEditingStyleDelete. If you tap the delete button, the delegate method tableView:commitEditingStyle:for-RowAtIndexPath: is called. The code of this method deletes the data for the row and removes it from Kinvey’s data store. When the backend delete is completed, the app displays an alert describing the success or failure.

The way that all three sections (and all Kinvey-enabled apps) move data in and out of a Kinvey collection is by getting a reference to the app’s backend collection (named “testObjects”), which is filled with instances (each named “TestObject”) of the data the app wants to move. That’s why you’ll find the following code repeated three times in Test Drive’s View Controller (once for the add, once for the load, and once for the delete):

To support these statements it is required to have a data object class (TestObject). To see how these files are written in the sample project, click on TestObject.h file and TestObject.m in the Navigator pane. If you were to supply these files in your own app, you would click File > New File, and specify Objective-C class, which would be a subclass of NSObject. Then you would type in the code, with a property for each column in the Kinvey backend collection (including one for the object’s id).

As mentioned earlier, your app also needs to authenticate itself to Kinvey, which is handled by AppDelegate.h and AppDelgate.m. These files are created by Xcode when you create a new project, and start out with just a stub implementation. Look in the sample app source

files for code to copy and paste.

For both the save and load operations, however, moving the data in and out of a backend collection is only part of the work. Table 1 lists all the functions that implements the save and load in the ViewCon-troller.m file, along with pointers to its corresponding block of imple-mentation source code. (For each function, its corresponding code begins with the “Starts at” line and ends with the “Ends at” line.) Refer to Appendix 1 to find the actual source code.

Say Hello To Our WorldThe key takeaway from all this is that “making an app” is a worthwhile thing to do for anyone with a clever idea and a working knowledge of Objective-C. The proof is in the hundreds of apps succeeding in the market every day, many written by people working on their own and who never wrote an app before in their lives. As with anything else, practice does make perfect. But hopefully with all the resources available, and the knowledge gained from this ebook, you have already started down the path toward joining the growing legions of iOS app developers. If so, we welcome you!

Appendix 1 — Test Drive Sample App ViewController.m Source Code

The iOS revolutionIt’s a story that never gets old. The weekend that iPad Minis and the fourth generation iPads went on sale (November 2-5, 2012) Apple sold over 3 million of the devices — a record for first-weekend iPad sales. Two months earlier the company had set another record: first weekend sales of over 5 million for the iPhone 5. Since the introduc-tion of the first iPhone back in 2007,

iOS-based devices (iPhone, iPad, iPad Mini and iPod Touch) continue to rewrite the definition of what constitutes a successful product. By the end of 2012, over 400 million iOS devices had been sold.

What makes iOS devices so successful? Innovation and product features are clearly a big part. Before the iPhone most people had not interacted with a multi-touch interface. They had never zoomed with a pinch or switched between portrait and landscape by merely rotating a device in their hand. Carrying a phone that knew where they were, could suggest places to eat, and could offer directions on how to get there was also a novel experience.

But features like multi-touch, accelerometers and GPS are only part of the appeal. Even with all its innovations, iOS still might not have taken off the way it has if the only people figuring out ways to use those innovations worked at Apple. Most of the capabilities available in an iPhone or iPad in fact don’t come from Apple at all. They come from legions of third-party developers who work in a vast ecosystem that is also an Apple innovation. That ecosystem includes the iPhone, iPad, iPad Mini, iPods, App Store, iTunes, ad networks — and that’s just on the consumer side. On the developer side, you have Xcode, App Loader, testing tools, iTunes Connect — the list goes on.

As of September 2012, the App Store hosted over 700,000 apps that have collectively been downloaded over 30 billion times. Apple reported for October 2012 that App Store monthly revenues were

2

running at $333 million — a rate of about $4 billion per year — remarkable for a store that only opened in July 2008.

Another innovation that has spurred iOS app development is “The Cloud.” Cloud services make it easier for independent developers to create, support and make money from their apps. The Cloud solves data storage and cross-device and user-to-user sharing problems. If an app stores data in the Cloud, that part of the application is called the “backend,” while the part of the app that runs on the phone and interacts with the user is called the “front end.”

A cloud may be “private” — i.e., the services belong to an organization for the benefit of its employees and business partners. Or a cloud may be “public” — i.e., a company (such as Amazon or Kinvey) owns the services, which developers can then integrate into their own apps. If you are a developer and want to build your own backend, you certainly can do that. Whether you want to or not depends on whether your backend provides functionality common to many different apps. If it does (as in a shopping cart or user authenti-cation) then perhaps that time and money would be better spent on features that offer unique value to your customer. You may be better off hooking into a commercial backend provider via an API. Then you can focus on what counts most — a unique user experience and application-specific functionality. That brings us to the first step in making an app.

Define your appMost unsuccessful apps fail for any of four reasons:

1. the app was a solution in search of a problem (i.e., no real need existed) 2. the implementation was poor 3. the app tried to do too much; or 4. the Apple App Store rejected the app (either because the implementation was poor or it violated Apple’s content policies)

Keeping the app as simple as possible is the best way to avoid these pitfalls. Most successful apps (indeed, most successful consumer tech products) are based on what is called an MVP, or minimum viable product. It’s the product with the smallest feature set that can deliver the core function without any distracting “bells and whistles.” You know you have an MVP if the product would no longer function if you removed any single feature.

But what should that core feature be? One of the best examples of an MVP is Mail. Version 1 (on the Mac) offered a clear, limited and intuitive feature set whose usefulness was immediately obvious to anyone. Today’s iPhone version integrates seamlessly with your phone, contacts and calendaring. It auto-matically corrects spelling as you type, lets you email photos directly from your photos app, and does much more. But all that came later and was built on top of a basic core function. And that’s how your first app should be built. The key is to come up with something with a clear value that changes people’s lives.

So, in drawing up your MVP feature list, ask yourself what features are key to the experience. Some basic market research is probably in order, starting with a visit to the App Store to see what already exists (possibly to be improved upon and/or to compete with you). Likely

must-have core capabilities include:

• Performance (e.g., fast screen refresh)• Offline capability (i.e., ability to work when not connected to the Internet)• Location awareness (e.g., the data/experience will change with the user’s location)• Cloud syncing (e.g., users see the same data on multiple devices)• Push notifications (i.e., sending updated information to devices as soon as it is available)

When you have a handle on what your app does, the next step is to design it. Designing your app involves making choices of how infor-mation and controls are presented to the user as well as how to implement app logic, and figuring out what data lives locally and what belongs in the Cloud.

Design your appUser experience decisions determine the app’s look and feel. They answer questions such as: What does the app look like? What screens does it have? In the software development world, onscreen objects like buttons, sliders, and fill-in boxes are called widgets. So you need to decide which types of widgets will reside on which screens. And what actions will occur as a result of the user interacting with those widgets?

Keep in mind that users will expect to interact differently with a mobile device than they do with a PC because the screens on mobile devices are much smaller. They’ll expect to use their fingers instead of a mouse or a track pad. Ideally, your app can even be used with one hand holding the device while using just a thumb for scrolling andworking the app’s other controls— the Path app is a good example, and increasingly, so is Facebook.

Your app’s features will inform its architecture, which is how you’ll divide the code and data into functional parts. If your app requires interacting with other app users or networked services, you’ll need to figure out what piece of the logic lives in the app code and what comes from the backend. For example, your app might integrate with a restau-rant recommendation engine, share user location, or pull real-time traffic data. This is done using APIs provided by various service providers — but you don’t have to wire up your app to a network to get started. You can develop a prototype using predefined representative (or “dummy”) data. It’s easier to fine-tune the front end if you don’t have to simultaneously modify your backend too. Once you get the app’s look-and-feel right, then make those backend connections.

Once you’ve got the overall concept for your app, the next step is to express that design in terms of the iOS app architecture. That archi-tecture is the model for what parts an iOS app can contain and how those parts fit together. It’s a well thought-out approach for translat-ing a product concept into actual code you can deploy on a device.

WHY iOS?Besides the features and design of your first app, there’s one more decision you need to make before you start actual development. That’s whether to deploy on Apple’s iOS platform or on Google’s Android platform. (Some of this is also covered in our ebook, How to Make an App: Android Edition.) Reasons to develop for iOS include:

Customers more willing to pay. Perhaps it’s because of Android’s open source heritage, but whatever the reason, Android apps gener-ate less than 10% of the total dollars spent on mobile apps, despite having 75% of the smartphone market itself — and despite the fact that the average selling price of an app in the Google Play is $3.79 versus Apple App Store’s $2.01. In other words, Apple users are much more willing to spend money on apps.

The Apple Ecosystem. Some developers and users prefer Apple’s closed and more tightly controlled environment. Apple’s ecosystem, consisting of Xcode, iCloud, iTunes, the App Store, the iPad, the iPhone, Mac computers, etc., offers a very holistic user experience with the ability to share data seamlessly across devices plus the

assurance of having applications pre-approved for quality and content prior to going on sale.

Xcode. Apple’s all-in-one IDE offers state-of-the-art offers features like a graphical interface builder and a syntax-aware and compiler-aware source editor.

The Apple Experience. From the fit and finish of its hardware to the customer service in its retail stores, to the way its hardware and software work flawlessly together, Apple has created the premium brand in consumer electronics. iOS developers share the benefits — so when someone downloads your iOS app, they already expect it’s a great product. And that it will also work flawlessly on their device.

Tablets. iOS has a clear advantage over Android in terms of tablet market adoption. Using Xcode, it’s also much easier to migrate an app from a phone to a tablet and vice versa than it is when develop-ing for Android.

Why Not iOS?Although iOS offers many compelling advantages as a platform for your mobile app, it also comes with some disadvantages. Here are three:

Closed Platform. iOS apps only run on Apple products so you can’t take advantage of features (like NFC) available only on non-iOS devices or market growth of non-iOS devices.

Market Growth. Today, iOS represents less than 15% of the total smartphone market, Although the total market (“the whole pie”) is still increasing at a fast rate, Android market growth outpaces iOS growth.

Approvals. The App Store’s app approval process is notoriously more time consuming than Google Play’s process.

The iOS app architectureAs noted earlier, a key reason why there are so many apps for iOS is because developing highly functional, polished apps for the platform is relatively easy. That’s mainly because of: 1) the design of the development tools, and 2) the key architectural features most iOS apps have in common. So let’s start with some concepts since it helps to know what goes into an app before trying to create one. We’ll begin with:

• Design patterns• Frameworks• Delegation• Storyboard• Windows• Outlets• Supporting files• Products

Design patterns. iOS apps implement what is known as a Mod-el-View-Controller (MVC) pattern. A pattern is a common way to structure code that solves a particular design problem. The MVC pattern separates application code in a way that allows you to easily change one part of an app without having to change other parts. An MVC pattern consists of three components:

• The Model is the logic that acts on the data, such as to store or retrieve data from a database, compute the distance between two cities on a map, etc. An example of a model is the Kinvey backend that stores your data in the Cloud as a service.

• The View provides the interface to the user; it displays the data and widgets (e.g., buttons and text fields) that allow the user to interact with the data. An iPhone app may have more than one view, as in the Contacts app, which displays a list view of all contacts or alternatively a view of each individual contact.

• The Controller is between the model and the view — i.e., it responds to user requests (made in a view) and retrieves results

(produced in a model). This is where developers spend most of their time — constructing the View Controller — by defining and attaching actions (or behaviors) to onscreen widgets. When the user taps a button, for example, it is the View Controller that determines what action will occur, such as retrieve stored data from your Kinvey-based data store. The link between a view object (like a button) to a controller action is called a connection.

Frameworks. You don’t actually have to write most of an app’s logic. It already exists as frameworks. A framework is a collection of classes that implements some function — such as connecting to the Internet, drawing a button, etc. Rather than write the code from scratch, you just use the frameworks supplied by iOS. Some frameworks are automatically present when you start a new project while others may need to be added (done via a drop down menu in Xcode’s Project Editor).

Delegation. Say, you want to customize the behavior of a framework’s object. You can’t actually modify the code of the framework class itself (prohibited since other apps may also use the framework). But what you can do is provide app-specific behavior in an application delegate object. If a delegate implements a method, it will be called by the delegating class to modify its behavior. In the Kinvey sample app (one of two examples we will be describing below), the AppDele-gate.h and AppDelegate.m — the header and implementation files for the UIApplicationDelegate, respectively — contain the code that authenticates an app to the Kinvey backend service.

Storyboards and XIBs. The MainStoryboard.storyboard file (or a .xib file, if you did not click on the “Use Storyboard” option when starting your project) contains the view information needed to implement the overall flow and display of your application and the user interface elements.

Windows. Each view (e.g., the contact list and individual contact details in the Contacts app) exists within a window. The window represents the entire device screen and is where all your views are presented.

Outlets. A variable by which a view object can be referenced in a controller. (For example, if you place a text field to capture a user's name, you might create an outlet called UITextField* nameField.)

Supporting files. These are files that provide resources (like PNG images and other static data) that your app needs as well as files that configure how the app will run. Other examples:

.pch files — precompiled headers used for the code files in your project.

.plist files — property lists that are small amounts of persistent data (like your app’s default user settings) consisting primarily of strings and numbers that you want your app to be able to access, modify if needed, and write back into the property list.

main.m file — your app’s main function. This is needed to launch the app, but you will not need to modify this file.

InfoPlist.strings file — used for localization.

Products. This is the file for your app (i.e., YourProduct.app) that is built when you click Xcode’s “run” button.

“Making an iOS app” involves working with these features in the typical, straightforward workflow:

• Storyboard your views by dragging and configuring graphicalobjects on a template

• Adding behaviors to the various widgets• Writing the classes as to define those behaviors (including

delegates)• Adding needed support files• Building and running the app• Iterating until you are satisfied with your app

This is all done within Xcode.

What’s Xcode?You can start developing functional, good-looking apps almost from the moment you download Xcode, Apple’s integrated development environment (IDE) for making iOS and Macintosh apps. Among other features, Xcode includes a source code editor, graphical user inter-face (GUI) editor (sometimes called Interface Builder), source code repository manager, compiler, and much more. iOS applications are typically developed by manipulating views graphically and by typing Objective-C code for the models and controllers.

To get Xcode, simply go to the App Store and download the applica-tion (it’s free). To do this, click on the App Store icon in your Mac’s dock, or visit https://itunes.apple.com/us/genre/ios/id36?mt=8

The app store will download and install Xcode in your Application folder. From Applications, double-click the Xcode icon to launch Xcode and you’ll see its splash screen (Figure 1). From there you can click on “Create a new Xcode project” to take you to a menu of several templates on which to base your application. Selecting a template opens an Xcode workspace pre-populated with frameworks and other files Xcode thinks you will need using that template.

Although you can develop, build and simulate your app on your computer in Xcode, you can’t run your app on a target device (even your own iPhone) until you become a registered iOS developer and join the iOS Developer Program. To do that, go to develop-er.app.com/ and navigate to the iOS Dev Center. While there, you will also find documentation, sample code and other useful resources such as information on how to submit your app to the iOS App Store.

Everything you do in Xcode is done in a window, called a workspace (Figure 2), consisting of multiple work areas, some of which are also divided into panes. All the files needed to build your app belong to a project, and the Navigator area (far left) lists all your projects (there can be several in a workspace) and all files for each project. Clicking on a file in the Navigator area shows its contents in the Editor area and invokes the appropriate editor. Clicking on a .h or .m file, for example, shows the file’s source code and invokes the Source editor, so you can edit the code. Clicking on .storyboard or .xib (sometimes called a “nib”) file shows the app’s storyboard and invokes the Inter-face Builder, so you can design a view using the Builder’s drag and drop features.

An especially handy feature is that the Editor area can have both a right and a left pane — with each pane aware of your edits in the other. So, for example, you can simultaneously edit an object’s .h

header file in the left pane and its corresponding .m in the right pane. Or you might click on a button object (displayed graphically) in the left pane and edit its method’s source code in the right pane. To toggle between a single pane (the “Standard Editor”) and double pane view (the “Assistant Editor”), use the Editor selector button on the right of the toolbar. You can option+command+click a symbol in the editor to open the definition in the opposite editor pane.

You can also resize the entire Editor area simply by dragging its borders. For even more editing space, you can also remove the Debug area or both the Debug and Utility areas using the View Selector button on the far right of the toolbar.

As its name suggests, the Debug area shows information, like variable state and console logs, helpful in debugging code.

The Utility area has two panes: the Inspector and Quick Help pane (top) and the Library pane (bottom). Although there are five inspectors — File, Help, Identity, Attributes, Size and Connec-tions — only the inspectors that are currently relevant appear in the Inspec-tor list at the top of the pane. (To see the name of an inspector, move the cursor over its icon in the Inspector selector bar.)

You will use inspectors to add and modify object attributes for views in the Interface Builder. For example, if you click on a UILabel in the Editor area of a storyboard, you can use the Attributes inspector to change the label’s color and use the Size inspector to change the label’s size.

The Help inspector shows help information about a selected class. Use the Identity inspector to view and manage an object’s metadata such as its class, runtime attributes, label and so forth. Use the

Connections inspector to view the outlets and actions of an interface object, to make new connections and to delete existing connections.

The Library pane has libraries of resources (like file templates, code snippets, interface objects and media files) that are prebuilt and ready to insert into your project. Use the Library selector to select which of these libraries (e.g., code snippets or interface objects) you wish to insert. To insert one, drag it directly into your storyboard while using the Interface Builder editor.

These are basics you need to know to get started using Xcode to build your first app. But to really understand how it’s done, it helps to walk through an actual app or two. Let’s start with a simple “Hello World” app that does not employ a backend connection, and then look at a somewhat more functional app that does.

“Hello World!” sample appThis app displays a button (“Press Me”) and a label (“Label”) so that when the user presses the button the text of the label changes to “Hello World!” as in Figure 3:

To get started, launch Xcode and select “Create a New Xcode Project.” From the iOS Application templates, select “Single View Application” and click “Next.” Fill in your product’s name and a company identifier, typically “com.yourCompanyName.” Deselect “Use Storyboards” and leave “Use Automatic Reference Counting” selected. Then click “Next” and select a destination for your projects files.

Follow these steps to make your app:

1. Select your project’s ViewController.xib file in the Navigator(Figure 4), to open the Interface Builder editor.

2. Drag a “Round Rect Button” from the Objects library (lowerright) onto the view in the Editor area; select the button’s textand type “Press Me.”

3. Drag a Label from the objects library onto the view, as well.4. Select and drag the Label sizing handles, centering the object

and making it wide enough to hold the “Hello World!” text; then,

5. With the “Hello World!” label still selected, click on centeralignment in the Attributes inspector.

6. Open the Assistant Editor (Figure 5), exposing the source codeheader file (ViewController.h) of the view controller you justbuilt graphically.

7. Select the button and control-drag from the button to justbelow the ViewController definition in the Assistant panel. Inthe form that opens, select “Action” for the connection type,type in a name (“showText”) and click “Connect.” This creates aninterface builder (IB) action as highlighted in Figure 6.

8. Next step is to create an outlet for the label. To do this, selectthe label object and control-drag from the label to just belowthe IB action you just created. Select “Outlet” as the connectiontype and enter a name “label” and click “Connect.” This createsan interface builder (IB) outlet as shown in Figure 7.

9. Finally, it’s time to add some logic to the view controller so itknows what to do when the button is pressed. To do this, select “ViewController.m” in the project navigator to show the code editor. Find the button’s IBAction you just created (near the bottom), place your cursor between the { } brackets and hit the return key a few times to create some extra space. Then in that space type the method for how you want the label you speci-fied to respond: _label.text=”Hello World!”; as highlighted in Figure 8.

Congratulations! Your app is done. To build and run your new app in the simulator, click the Xcode Run button in the left corner of the toolbar. When you click the button, the text will update.

Sample app with a backend This second app (named “Kinvey Test Drive”) lets the user type text on an iPhone and save the text to a backend service, like Kinvey. It also lets the user load text on the iPhone from their Kinvey backend. Reading about this app will help you learn:

• How to set up Kinvey’s library in an iOS project• Additional Interface Builder techniques you can use to story-board an application• How to add view controller logic to interact with the backend service, allowing you to save and retrieve data

We will first present the app as a running application and then take it apart so you can see how it was made. To make the app yourself, you can review the various sections below and replicate the steps in your copy of Xcode.

First, to see the app in action, you should download the app and run it on your system. To do that, sign up for Kinvey, then navigate to “Dev Center”, “Samples,” find the “Test Drive” app, and click on its icon. (If you can’t find it right away, make sure you select iOS as your platform on the right side of the menu bar.) Click the download button to download the app’s project files to your computer. Then launch Xcode — just double click on the .xcodeproj file in the project folder.

But before you can run the app, you need to set up the app’s Kinvey backend.

Set Up Kinvey as a Backend Data StoreTest Drive’s project files include all the code the sample app needs in order to talk to Kinvey. However, that would not be the case if you were to build an app from scratch — so you would have to go through an initial Kinvey setup procedure. This involves downloading the Kinvey library files from the downloads section of devcenter.kin-vey.com and dragging them to the Navigator’s Frameworks folder in Xcode. You also need to tell Xcode to link your project with additional iOS frameworks. To find these frameworks, click on the Project folder

at the very top of the Navigator pane — which displays the Project editor — and then select the “Build Settings” tab. For detailed instruc-tions, complete the “Getting Started” page under “Guides” on the Kinvey website. But again, you can skip this setup procedure for now in order to run the downloaded Kinvey Test Drive app.

But you must still do this step: To run any app that uses Kinvey (including Test Drive) you need to do the “Create an App” step on the Kinvey website. Click on “My Apps” in the Kinvey menu bar and then click on “Add an App,” which will open an “Add” page. Type in a name for your app and click on the Apple logo and then click “Create.” The page that opens shows your App’s credentials. Copy and paste the App Key and App Secret into the AppDelegate.m file of the download-ed Test Drive project:

You are now ready to run the app — click on the Xcode run button and wait for the simulator to open and the app to appear (Figure 9).

Clicking the “+” toolbar button opens an alert (Figure 10) with an empty field into which the user can type some text (e.g., “some new data”). Clicking “save” uploads the data to Kinvey and displays text on the screen (a table view) and also displays an alert that the save worked (Figure 11).

To test the load function, enter some data (e.g., “some data to load”) in the “name” field of the Kinvey collection. To see the load, the swipe down on the table on the phone until the refresh spinner starts, and then the new data will appear in the table (Figure 12).

Figure 13 shows the Kinvey collection after the save that Figure 10 depicts on the iPhone. Figure 14 shows the Kinvey collection after the user adds a new row to the testObjects collection using the web browser. Note that every time a save is done on the iPhone, Kinvey automatically adds a new row (displayed on a collection refresh). To add a new row manually in the browser, click “+ row,” and type some descriptive text in the “name” column. That data will now load on the iPhone when the user pulls down on the table.

Storyboard the Test Drive AppMost of the Test Drive user interface objects visible in the simulation are available in Xcode’s Object Library and can therefore be added to the view graphically. The UI objects consist of a:

• Table view• Toolbar• Tool Bar Button item – flexible space• Tool Bar Button item – Add• Table view cell• Label – Title• Refresh Control

To create this app yourself, you would follow these steps:

• Launch Xcode and select the “Single View Application” template• Select the “Use Storyboard” option• Replace the default UIviewcontroller object with a UITableView-Controller • Drag and drop the other objects, in the order listed, onto the UIviewcontroller

Also note:

• The Flexible Space Bar Button item fills up the space on the toolbar so the add button is at the right. This is a standard pattern in table-based iPhone apps.• The add button shows the system “+” sign. That is done by dragging a bar button item onto the toolbar, clicking on the Identifier drop down menu in the Attributes inspector; and then selecting the “Add” option.

As with the “Hello World!” app, once your app’s view is complete (Figure 15), you would still have to create the various methods and connections that bring them to life. This is done using the Source editor while working with the ViewController.m file.

Add View Controller LogicSince the app performs two basic operations (save data to Kinvey and load data from Kinvey) these two methods must be added to the ViewController header file. That’s done with a control-drag from the “+” bar button over to just under the “@ interface ViewController” line in ViewController.h. (Open the Assistant editor to see both the storyboard and the file source.)

During the drag, the popup appears, asking for the name and type of connection. Enter “action” for the connection type and “add” for the name. Then repeat the drag, this time from the refresh control and using “add” for the name (Figure 16).

Note: to follow this discussion it will help to have the referenced files open in your Xcode Source editor.

In ViewController.m, you will see the implementation code associated with each of the two Interface Builder methods, whose names Xcode added automatically to the .m file:

- (IBAction)add:(id)sender- (IBAction)load:(id)sender

You will also see a third section of code not associated with these methods, which starts with the line: “#pragma mark - Table View Stuff.” These methods support the table view and are part of UITableViewD-elegate and UITableViewDataSource. They handle controlling the

display of the table, and respond to user gestures. For example, swiping a table cell will show the delete button because tableView:-canEditRowAtIndexPath: returns YES and tableView:editingStyleForRowA-tIndexPath: returns UITableViewCellEditingStyleDelete. If you tap the delete button, the delegate method tableView:commitEditingStyle:for-RowAtIndexPath: is called. The code of this method deletes the data for the row and removes it from Kinvey’s data store. When the backend delete is completed, the app displays an alert describing the success or failure.

The way that all three sections (and all Kinvey-enabled apps) move data in and out of a Kinvey collection is by getting a reference to the app’s backend collection (named “testObjects”), which is filled with instances (each named “TestObject”) of the data the app wants to move. That’s why you’ll find the following code repeated three times in Test Drive’s View Controller (once for the add, once for the load, and once for the delete):

To support these statements it is required to have a data object class (TestObject). To see how these files are written in the sample project, click on TestObject.h file and TestObject.m in the Navigator pane. If you were to supply these files in your own app, you would click File > New File, and specify Objective-C class, which would be a subclass of NSObject. Then you would type in the code, with a property for each column in the Kinvey backend collection (including one for the object’s id).

As mentioned earlier, your app also needs to authenticate itself to Kinvey, which is handled by AppDelegate.h and AppDelgate.m. These files are created by Xcode when you create a new project, and start out with just a stub implementation. Look in the sample app source

files for code to copy and paste.

For both the save and load operations, however, moving the data in and out of a backend collection is only part of the work. Table 1 lists all the functions that implements the save and load in the ViewCon-troller.m file, along with pointers to its corresponding block of imple-mentation source code. (For each function, its corresponding code begins with the “Starts at” line and ends with the “Ends at” line.) Refer to Appendix 1 to find the actual source code.

Say Hello To Our WorldThe key takeaway from all this is that “making an app” is a worthwhile thing to do for anyone with a clever idea and a working knowledge of Objective-C. The proof is in the hundreds of apps succeeding in the market every day, many written by people working on their own and who never wrote an app before in their lives. As with anything else, practice does make perfect. But hopefully with all the resources available, and the knowledge gained from this ebook, you have already started down the path toward joining the growing legions of iOS app developers. If so, we welcome you!

Appendix 1 — Test Drive Sample App ViewController.m Source Code

3

The iOS revolutionIt’s a story that never gets old. The weekend that iPad Minis and the fourth generation iPads went on sale (November 2-5, 2012) Apple sold over 3 million of the devices — a record for first-weekend iPad sales. Two months earlier the company had set another record: first weekend sales of over 5 million for the iPhone 5. Since the introduc-tion of the first iPhone back in 2007,

iOS-based devices (iPhone, iPad, iPad Mini and iPod Touch) continue to rewrite the definition of what constitutes a successful product. By the end of 2012, over 400 million iOS devices had been sold.

What makes iOS devices so successful? Innovation and product features are clearly a big part. Before the iPhone most people had not interacted with a multi-touch interface. They had never zoomed with a pinch or switched between portrait and landscape by merely rotating a device in their hand. Carrying a phone that knew where they were, could suggest places to eat, and could offer directions on how to get there was also a novel experience.

But features like multi-touch, accelerometers and GPS are only part of the appeal. Even with all its innovations, iOS still might not have taken off the way it has if the only people figuring out ways to use those innovations worked at Apple. Most of the capabilities available in an iPhone or iPad in fact don’t come from Apple at all. They come from legions of third-party developers who work in a vast ecosystem that is also an Apple innovation. That ecosystem includes the iPhone, iPad, iPad Mini, iPods, App Store, iTunes, ad networks — and that’s just on the consumer side. On the developer side, you have Xcode, App Loader, testing tools, iTunes Connect — the list goes on.

As of September 2012, the App Store hosted over 700,000 apps that have collectively been downloaded over 30 billion times. Apple reported for October 2012 that App Store monthly revenues were

running at $333 million — a rate of about $4 billion per year — remarkable for a store that only opened in July 2008.

Another innovation that has spurred iOS app development is “The Cloud.” Cloud services make it easier for independent developers to create, support and make money from their apps. The Cloud solves data storage and cross-device and user-to-user sharing problems. If an app stores data in the Cloud, that part of the application is called the “backend,” while the part of the app that runs on the phone and interacts with the user is called the “front end.”

A cloud may be “private” — i.e., the services belong to an organization for the benefit of its employees and business partners. Or a cloud may be “public” — i.e., a company (such as Amazon or Kinvey) owns the services, which developers can then integrate into their own apps. If you are a developer and want to build your own backend, you certainly can do that. Whether you want to or not depends on whether your backend provides functionality common to many different apps. If it does (as in a shopping cart or user authenti-cation) then perhaps that time and money would be better spent on features that offer unique value to your customer. You may be better off hooking into a commercial backend provider via an API. Then you can focus on what counts most — a unique user experience and application-specific functionality. That brings us to the first step in making an app.

Define your appMost unsuccessful apps fail for any of four reasons:

1. the app was a solution in search of a problem (i.e., no real need existed) 2. the implementation was poor 3. the app tried to do too much; or 4. the Apple App Store rejected the app (either because the implementation was poor or it violated Apple’s content policies)

Keeping the app as simple as possible is the best way to avoid these pitfalls. Most successful apps (indeed, most successful consumer tech products) are based on what is called an MVP, or minimum viable product. It’s the product with the smallest feature set that can deliver the core function without any distracting “bells and whistles.” You know you have an MVP if the product would no longer function if you removed any single feature.

But what should that core feature be? One of the best examples of an MVP is Mail. Version 1 (on the Mac) offered a clear, limited and intuitive feature set whose usefulness was immediately obvious to anyone. Today’s iPhone version integrates seamlessly with your phone, contacts and calendaring. It auto-matically corrects spelling as you type, lets you email photos directly from your photos app, and does much more. But all that came later and was built on top of a basic core function. And that’s how your first app should be built. The key is to come up with something with a clear value that changes people’s lives.

So, in drawing up your MVP feature list, ask yourself what features are key to the experience. Some basic market research is probably in order, starting with a visit to the App Store to see what already exists (possibly to be improved upon and/or to compete with you). Likely

must-have core capabilities include:

• Performance (e.g., fast screen refresh)• Offline capability (i.e., ability to work when not connected to the Internet)• Location awareness (e.g., the data/experience will change with the user’s location)• Cloud syncing (e.g., users see the same data on multiple devices)• Push notifications (i.e., sending updated information to devices as soon as it is available)

When you have a handle on what your app does, the next step is to design it. Designing your app involves making choices of how infor-mation and controls are presented to the user as well as how to implement app logic, and figuring out what data lives locally and what belongs in the Cloud.

Design your appUser experience decisions determine the app’s look and feel. They answer questions such as: What does the app look like? What screens does it have? In the software development world, onscreen objects like buttons, sliders, and fill-in boxes are called widgets. So you need to decide which types of widgets will reside on which screens. And what actions will occur as a result of the user interacting with those widgets?

Keep in mind that users will expect to interact differently with a mobile device than they do with a PC because the screens on mobile devices are much smaller. They’ll expect to use their fingers instead of a mouse or a track pad. Ideally, your app can even be used with one hand holding the device while using just a thumb for scrolling andworking the app’s other controls— the Path app is a good example, and increasingly, so is Facebook.

Your app’s features will inform its architecture, which is how you’ll divide the code and data into functional parts. If your app requires interacting with other app users or networked services, you’ll need to figure out what piece of the logic lives in the app code and what comes from the backend. For example, your app might integrate with a restau-rant recommendation engine, share user location, or pull real-time traffic data. This is done using APIs provided by various service providers — but you don’t have to wire up your app to a network to get started. You can develop a prototype using predefined representative (or “dummy”) data. It’s easier to fine-tune the front end if you don’t have to simultaneously modify your backend too. Once you get the app’s look-and-feel right, then make those backend connections.

Once you’ve got the overall concept for your app, the next step is to express that design in terms of the iOS app architecture. That archi-tecture is the model for what parts an iOS app can contain and how those parts fit together. It’s a well thought-out approach for translat-ing a product concept into actual code you can deploy on a device.

WHY iOS?Besides the features and design of your first app, there’s one more decision you need to make before you start actual development. That’s whether to deploy on Apple’s iOS platform or on Google’s Android platform. (Some of this is also covered in our ebook, How to Make an App: Android Edition.) Reasons to develop for iOS include:

Customers more willing to pay. Perhaps it’s because of Android’s open source heritage, but whatever the reason, Android apps gener-ate less than 10% of the total dollars spent on mobile apps, despite having 75% of the smartphone market itself — and despite the fact that the average selling price of an app in the Google Play is $3.79 versus Apple App Store’s $2.01. In other words, Apple users are much more willing to spend money on apps.

The Apple Ecosystem. Some developers and users prefer Apple’s closed and more tightly controlled environment. Apple’s ecosystem, consisting of Xcode, iCloud, iTunes, the App Store, the iPad, the iPhone, Mac computers, etc., offers a very holistic user experience with the ability to share data seamlessly across devices plus the

assurance of having applications pre-approved for quality and content prior to going on sale.

Xcode. Apple’s all-in-one IDE offers state-of-the-art offers features like a graphical interface builder and a syntax-aware and compiler-aware source editor.

The Apple Experience. From the fit and finish of its hardware to the customer service in its retail stores, to the way its hardware and software work flawlessly together, Apple has created the premium brand in consumer electronics. iOS developers share the benefits — so when someone downloads your iOS app, they already expect it’s a great product. And that it will also work flawlessly on their device.

Tablets. iOS has a clear advantage over Android in terms of tablet market adoption. Using Xcode, it’s also much easier to migrate an app from a phone to a tablet and vice versa than it is when develop-ing for Android.

Why Not iOS?Although iOS offers many compelling advantages as a platform for your mobile app, it also comes with some disadvantages. Here are three:

Closed Platform. iOS apps only run on Apple products so you can’t take advantage of features (like NFC) available only on non-iOS devices or market growth of non-iOS devices.

Market Growth. Today, iOS represents less than 15% of the total smartphone market, Although the total market (“the whole pie”) is still increasing at a fast rate, Android market growth outpaces iOS growth.

Approvals. The App Store’s app approval process is notoriously more time consuming than Google Play’s process.

The iOS app architectureAs noted earlier, a key reason why there are so many apps for iOS is because developing highly functional, polished apps for the platform is relatively easy. That’s mainly because of: 1) the design of the development tools, and 2) the key architectural features most iOS apps have in common. So let’s start with some concepts since it helps to know what goes into an app before trying to create one. We’ll begin with:

• Design patterns• Frameworks• Delegation• Storyboard• Windows• Outlets• Supporting files• Products

Design patterns. iOS apps implement what is known as a Mod-el-View-Controller (MVC) pattern. A pattern is a common way to structure code that solves a particular design problem. The MVC pattern separates application code in a way that allows you to easily change one part of an app without having to change other parts. An MVC pattern consists of three components:

• The Model is the logic that acts on the data, such as to store or retrieve data from a database, compute the distance between two cities on a map, etc. An example of a model is the Kinvey backend that stores your data in the Cloud as a service.

• The View provides the interface to the user; it displays the data and widgets (e.g., buttons and text fields) that allow the user to interact with the data. An iPhone app may have more than one view, as in the Contacts app, which displays a list view of all contacts or alternatively a view of each individual contact.

• The Controller is between the model and the view — i.e., it responds to user requests (made in a view) and retrieves results

(produced in a model). This is where developers spend most of their time — constructing the View Controller — by defining and attaching actions (or behaviors) to onscreen widgets. When the user taps a button, for example, it is the View Controller that determines what action will occur, such as retrieve stored data from your Kinvey-based data store. The link between a view object (like a button) to a controller action is called a connection.

Frameworks. You don’t actually have to write most of an app’s logic. It already exists as frameworks. A framework is a collection of classes that implements some function — such as connecting to the Internet, drawing a button, etc. Rather than write the code from scratch, you just use the frameworks supplied by iOS. Some frameworks are automatically present when you start a new project while others may need to be added (done via a drop down menu in Xcode’s Project Editor).

Delegation. Say, you want to customize the behavior of a framework’s object. You can’t actually modify the code of the framework class itself (prohibited since other apps may also use the framework). But what you can do is provide app-specific behavior in an application delegate object. If a delegate implements a method, it will be called by the delegating class to modify its behavior. In the Kinvey sample app (one of two examples we will be describing below), the AppDele-gate.h and AppDelegate.m — the header and implementation files for the UIApplicationDelegate, respectively — contain the code that authenticates an app to the Kinvey backend service.

Storyboards and XIBs. The MainStoryboard.storyboard file (or a .xib file, if you did not click on the “Use Storyboard” option when starting your project) contains the view information needed to implement the overall flow and display of your application and the user interface elements.

Windows. Each view (e.g., the contact list and individual contact details in the Contacts app) exists within a window. The window represents the entire device screen and is where all your views are presented.

Outlets. A variable by which a view object can be referenced in a controller. (For example, if you place a text field to capture a user's name, you might create an outlet called UITextField* nameField.)

Supporting files. These are files that provide resources (like PNG images and other static data) that your app needs as well as files that configure how the app will run. Other examples:

.pch files — precompiled headers used for the code files in your project.

.plist files — property lists that are small amounts of persistent data (like your app’s default user settings) consisting primarily of strings and numbers that you want your app to be able to access, modify if needed, and write back into the property list.

main.m file — your app’s main function. This is needed to launch the app, but you will not need to modify this file.

InfoPlist.strings file — used for localization.

Products. This is the file for your app (i.e., YourProduct.app) that is built when you click Xcode’s “run” button.

“Making an iOS app” involves working with these features in the typical, straightforward workflow:

• Storyboard your views by dragging and configuring graphicalobjects on a template

• Adding behaviors to the various widgets• Writing the classes as to define those behaviors (including

delegates)• Adding needed support files• Building and running the app• Iterating until you are satisfied with your app

This is all done within Xcode.

What’s Xcode?You can start developing functional, good-looking apps almost from the moment you download Xcode, Apple’s integrated development environment (IDE) for making iOS and Macintosh apps. Among other features, Xcode includes a source code editor, graphical user inter-face (GUI) editor (sometimes called Interface Builder), source code repository manager, compiler, and much more. iOS applications are typically developed by manipulating views graphically and by typing Objective-C code for the models and controllers.

To get Xcode, simply go to the App Store and download the applica-tion (it’s free). To do this, click on the App Store icon in your Mac’s dock, or visit https://itunes.apple.com/us/genre/ios/id36?mt=8

The app store will download and install Xcode in your Application folder. From Applications, double-click the Xcode icon to launch Xcode and you’ll see its splash screen (Figure 1). From there you can click on “Create a new Xcode project” to take you to a menu of several templates on which to base your application. Selecting a template opens an Xcode workspace pre-populated with frameworks and other files Xcode thinks you will need using that template.

Although you can develop, build and simulate your app on your computer in Xcode, you can’t run your app on a target device (even your own iPhone) until you become a registered iOS developer and join the iOS Developer Program. To do that, go to develop-er.app.com/ and navigate to the iOS Dev Center. While there, you will also find documentation, sample code and other useful resources such as information on how to submit your app to the iOS App Store.

Everything you do in Xcode is done in a window, called a workspace (Figure 2), consisting of multiple work areas, some of which are also divided into panes. All the files needed to build your app belong to a project, and the Navigator area (far left) lists all your projects (there can be several in a workspace) and all files for each project. Clicking on a file in the Navigator area shows its contents in the Editor area and invokes the appropriate editor. Clicking on a .h or .m file, for example, shows the file’s source code and invokes the Source editor, so you can edit the code. Clicking on .storyboard or .xib (sometimes called a “nib”) file shows the app’s storyboard and invokes the Inter-face Builder, so you can design a view using the Builder’s drag and drop features.

An especially handy feature is that the Editor area can have both a right and a left pane — with each pane aware of your edits in the other. So, for example, you can simultaneously edit an object’s .h

header file in the left pane and its corresponding .m in the right pane. Or you might click on a button object (displayed graphically) in the left pane and edit its method’s source code in the right pane. To toggle between a single pane (the “Standard Editor”) and double pane view (the “Assistant Editor”), use the Editor selector button on the right of the toolbar. You can option+command+click a symbol in the editor to open the definition in the opposite editor pane.

You can also resize the entire Editor area simply by dragging its borders. For even more editing space, you can also remove the Debug area or both the Debug and Utility areas using the View Selector button on the far right of the toolbar.

As its name suggests, the Debug area shows information, like variable state and console logs, helpful in debugging code.

The Utility area has two panes: the Inspector and Quick Help pane (top) and the Library pane (bottom). Although there are five inspectors — File, Help, Identity, Attributes, Size and Connec-tions — only the inspectors that are currently relevant appear in the Inspec-tor list at the top of the pane. (To see the name of an inspector, move the cursor over its icon in the Inspector selector bar.)

You will use inspectors to add and modify object attributes for views in the Interface Builder. For example, if you click on a UILabel in the Editor area of a storyboard, you can use the Attributes inspector to change the label’s color and use the Size inspector to change the label’s size.

The Help inspector shows help information about a selected class. Use the Identity inspector to view and manage an object’s metadata such as its class, runtime attributes, label and so forth. Use the

Connections inspector to view the outlets and actions of an interface object, to make new connections and to delete existing connections.

The Library pane has libraries of resources (like file templates, code snippets, interface objects and media files) that are prebuilt and ready to insert into your project. Use the Library selector to select which of these libraries (e.g., code snippets or interface objects) you wish to insert. To insert one, drag it directly into your storyboard while using the Interface Builder editor.

These are basics you need to know to get started using Xcode to build your first app. But to really understand how it’s done, it helps to walk through an actual app or two. Let’s start with a simple “Hello World” app that does not employ a backend connection, and then look at a somewhat more functional app that does.

“Hello World!” sample appThis app displays a button (“Press Me”) and a label (“Label”) so that when the user presses the button the text of the label changes to “Hello World!” as in Figure 3:

To get started, launch Xcode and select “Create a New Xcode Project.” From the iOS Application templates, select “Single View Application” and click “Next.” Fill in your product’s name and a company identifier, typically “com.yourCompanyName.” Deselect “Use Storyboards” and leave “Use Automatic Reference Counting” selected. Then click “Next” and select a destination for your projects files.

Follow these steps to make your app:

1. Select your project’s ViewController.xib file in the Navigator(Figure 4), to open the Interface Builder editor.

2. Drag a “Round Rect Button” from the Objects library (lowerright) onto the view in the Editor area; select the button’s textand type “Press Me.”

3. Drag a Label from the objects library onto the view, as well.4. Select and drag the Label sizing handles, centering the object

and making it wide enough to hold the “Hello World!” text; then,

5. With the “Hello World!” label still selected, click on centeralignment in the Attributes inspector.

6. Open the Assistant Editor (Figure 5), exposing the source codeheader file (ViewController.h) of the view controller you justbuilt graphically.

7. Select the button and control-drag from the button to justbelow the ViewController definition in the Assistant panel. Inthe form that opens, select “Action” for the connection type,type in a name (“showText”) and click “Connect.” This creates aninterface builder (IB) action as highlighted in Figure 6.

8. Next step is to create an outlet for the label. To do this, selectthe label object and control-drag from the label to just belowthe IB action you just created. Select “Outlet” as the connectiontype and enter a name “label” and click “Connect.” This createsan interface builder (IB) outlet as shown in Figure 7.

9. Finally, it’s time to add some logic to the view controller so itknows what to do when the button is pressed. To do this, select “ViewController.m” in the project navigator to show the code editor. Find the button’s IBAction you just created (near the bottom), place your cursor between the { } brackets and hit the return key a few times to create some extra space. Then in that space type the method for how you want the label you speci-fied to respond: _label.text=”Hello World!”; as highlighted in Figure 8.

Congratulations! Your app is done. To build and run your new app in the simulator, click the Xcode Run button in the left corner of the toolbar. When you click the button, the text will update.

Sample app with a backend This second app (named “Kinvey Test Drive”) lets the user type text on an iPhone and save the text to a backend service, like Kinvey. It also lets the user load text on the iPhone from their Kinvey backend. Reading about this app will help you learn:

• How to set up Kinvey’s library in an iOS project• Additional Interface Builder techniques you can use to story-board an application• How to add view controller logic to interact with the backend service, allowing you to save and retrieve data

We will first present the app as a running application and then take it apart so you can see how it was made. To make the app yourself, you can review the various sections below and replicate the steps in your copy of Xcode.

First, to see the app in action, you should download the app and run it on your system. To do that, sign up for Kinvey, then navigate to “Dev Center”, “Samples,” find the “Test Drive” app, and click on its icon. (If you can’t find it right away, make sure you select iOS as your platform on the right side of the menu bar.) Click the download button to download the app’s project files to your computer. Then launch Xcode — just double click on the .xcodeproj file in the project folder.

But before you can run the app, you need to set up the app’s Kinvey backend.

Set Up Kinvey as a Backend Data StoreTest Drive’s project files include all the code the sample app needs in order to talk to Kinvey. However, that would not be the case if you were to build an app from scratch — so you would have to go through an initial Kinvey setup procedure. This involves downloading the Kinvey library files from the downloads section of devcenter.kin-vey.com and dragging them to the Navigator’s Frameworks folder in Xcode. You also need to tell Xcode to link your project with additional iOS frameworks. To find these frameworks, click on the Project folder

at the very top of the Navigator pane — which displays the Project editor — and then select the “Build Settings” tab. For detailed instruc-tions, complete the “Getting Started” page under “Guides” on the Kinvey website. But again, you can skip this setup procedure for now in order to run the downloaded Kinvey Test Drive app.

But you must still do this step: To run any app that uses Kinvey (including Test Drive) you need to do the “Create an App” step on the Kinvey website. Click on “My Apps” in the Kinvey menu bar and then click on “Add an App,” which will open an “Add” page. Type in a name for your app and click on the Apple logo and then click “Create.” The page that opens shows your App’s credentials. Copy and paste the App Key and App Secret into the AppDelegate.m file of the download-ed Test Drive project:

You are now ready to run the app — click on the Xcode run button and wait for the simulator to open and the app to appear (Figure 9).

Clicking the “+” toolbar button opens an alert (Figure 10) with an empty field into which the user can type some text (e.g., “some new data”). Clicking “save” uploads the data to Kinvey and displays text on the screen (a table view) and also displays an alert that the save worked (Figure 11).

To test the load function, enter some data (e.g., “some data to load”) in the “name” field of the Kinvey collection. To see the load, the swipe down on the table on the phone until the refresh spinner starts, and then the new data will appear in the table (Figure 12).

Figure 13 shows the Kinvey collection after the save that Figure 10 depicts on the iPhone. Figure 14 shows the Kinvey collection after the user adds a new row to the testObjects collection using the web browser. Note that every time a save is done on the iPhone, Kinvey automatically adds a new row (displayed on a collection refresh). To add a new row manually in the browser, click “+ row,” and type some descriptive text in the “name” column. That data will now load on the iPhone when the user pulls down on the table.

Storyboard the Test Drive AppMost of the Test Drive user interface objects visible in the simulation are available in Xcode’s Object Library and can therefore be added to the view graphically. The UI objects consist of a:

• Table view• Toolbar• Tool Bar Button item – flexible space• Tool Bar Button item – Add• Table view cell• Label – Title• Refresh Control

To create this app yourself, you would follow these steps:

• Launch Xcode and select the “Single View Application” template• Select the “Use Storyboard” option• Replace the default UIviewcontroller object with a UITableView-Controller • Drag and drop the other objects, in the order listed, onto the UIviewcontroller

Also note:

• The Flexible Space Bar Button item fills up the space on the toolbar so the add button is at the right. This is a standard pattern in table-based iPhone apps.• The add button shows the system “+” sign. That is done by dragging a bar button item onto the toolbar, clicking on the Identifier drop down menu in the Attributes inspector; and then selecting the “Add” option.

As with the “Hello World!” app, once your app’s view is complete (Figure 15), you would still have to create the various methods and connections that bring them to life. This is done using the Source editor while working with the ViewController.m file.

Add View Controller LogicSince the app performs two basic operations (save data to Kinvey and load data from Kinvey) these two methods must be added to the ViewController header file. That’s done with a control-drag from the “+” bar button over to just under the “@ interface ViewController” line in ViewController.h. (Open the Assistant editor to see both the storyboard and the file source.)

During the drag, the popup appears, asking for the name and type of connection. Enter “action” for the connection type and “add” for the name. Then repeat the drag, this time from the refresh control and using “add” for the name (Figure 16).

Note: to follow this discussion it will help to have the referenced files open in your Xcode Source editor.

In ViewController.m, you will see the implementation code associated with each of the two Interface Builder methods, whose names Xcode added automatically to the .m file:

- (IBAction)add:(id)sender- (IBAction)load:(id)sender

You will also see a third section of code not associated with these methods, which starts with the line: “#pragma mark - Table View Stuff.” These methods support the table view and are part of UITableViewD-elegate and UITableViewDataSource. They handle controlling the

display of the table, and respond to user gestures. For example, swiping a table cell will show the delete button because tableView:-canEditRowAtIndexPath: returns YES and tableView:editingStyleForRowA-tIndexPath: returns UITableViewCellEditingStyleDelete. If you tap the delete button, the delegate method tableView:commitEditingStyle:for-RowAtIndexPath: is called. The code of this method deletes the data for the row and removes it from Kinvey’s data store. When the backend delete is completed, the app displays an alert describing the success or failure.

The way that all three sections (and all Kinvey-enabled apps) move data in and out of a Kinvey collection is by getting a reference to the app’s backend collection (named “testObjects”), which is filled with instances (each named “TestObject”) of the data the app wants to move. That’s why you’ll find the following code repeated three times in Test Drive’s View Controller (once for the add, once for the load, and once for the delete):

To support these statements it is required to have a data object class (TestObject). To see how these files are written in the sample project, click on TestObject.h file and TestObject.m in the Navigator pane. If you were to supply these files in your own app, you would click File > New File, and specify Objective-C class, which would be a subclass of NSObject. Then you would type in the code, with a property for each column in the Kinvey backend collection (including one for the object’s id).

As mentioned earlier, your app also needs to authenticate itself to Kinvey, which is handled by AppDelegate.h and AppDelgate.m. These files are created by Xcode when you create a new project, and start out with just a stub implementation. Look in the sample app source

files for code to copy and paste.

For both the save and load operations, however, moving the data in and out of a backend collection is only part of the work. Table 1 lists all the functions that implements the save and load in the ViewCon-troller.m file, along with pointers to its corresponding block of imple-mentation source code. (For each function, its corresponding code begins with the “Starts at” line and ends with the “Ends at” line.) Refer to Appendix 1 to find the actual source code.

Say Hello To Our WorldThe key takeaway from all this is that “making an app” is a worthwhile thing to do for anyone with a clever idea and a working knowledge of Objective-C. The proof is in the hundreds of apps succeeding in the market every day, many written by people working on their own and who never wrote an app before in their lives. As with anything else, practice does make perfect. But hopefully with all the resources available, and the knowledge gained from this ebook, you have already started down the path toward joining the growing legions of iOS app developers. If so, we welcome you!

Appendix 1 — Test Drive Sample App ViewController.m Source Code

Define your app

The iOS revolutionIt’s a story that never gets old. The weekend that iPad Minis and the fourth generation iPads went on sale (November 2-5, 2012) Apple sold over 3 million of the devices — a record for first-weekend iPad sales. Two months earlier the company had set another record: first weekend sales of over 5 million for the iPhone 5. Since the introduc-tion of the first iPhone back in 2007,

iOS-based devices (iPhone, iPad, iPad Mini and iPod Touch) continue to rewrite the definition of what constitutes a successful product. By the end of 2012, over 400 million iOS devices had been sold.

What makes iOS devices so successful? Innovation and product features are clearly a big part. Before the iPhone most people had not interacted with a multi-touch interface. They had never zoomed with a pinch or switched between portrait and landscape by merely rotating a device in their hand. Carrying a phone that knew where they were, could suggest places to eat, and could offer directions on how to get there was also a novel experience.

But features like multi-touch, accelerometers and GPS are only part of the appeal. Even with all its innovations, iOS still might not have taken off the way it has if the only people figuring out ways to use those innovations worked at Apple. Most of the capabilities available in an iPhone or iPad in fact don’t come from Apple at all. They come from legions of third-party developers who work in a vast ecosystem that is also an Apple innovation. That ecosystem includes the iPhone, iPad, iPad Mini, iPods, App Store, iTunes, ad networks — and that’s just on the consumer side. On the developer side, you have Xcode, App Loader, testing tools, iTunes Connect — the list goes on.

As of September 2012, the App Store hosted over 700,000 apps that have collectively been downloaded over 30 billion times. Apple reported for October 2012 that App Store monthly revenues were

running at $333 million — a rate of about $4 billion per year — remarkable for a store that only opened in July 2008.

Another innovation that has spurred iOS app development is “The Cloud.” Cloud services make it easier for independent developers to create, support and make money from their apps. The Cloud solves data storage and cross-device and user-to-user sharing problems. If an app stores data in the Cloud, that part of the application is called the “backend,” while the part of the app that runs on the phone and interacts with the user is called the “front end.”

A cloud may be “private” — i.e., the services belong to an organization for the benefit of its employees and business partners. Or a cloud may be “public” — i.e., a company (such as Amazon or Kinvey) owns the services, which developers can then integrate into their own apps. If you are a developer and want to build your own backend, you certainly can do that. Whether you want to or not depends on whether your backend provides functionality common to many different apps. If it does (as in a shopping cart or user authenti-cation) then perhaps that time and money would be better spent on features that offer unique value to your customer. You may be better off hooking into a commercial backend provider via an API. Then you can focus on what counts most — a unique user experience and application-specific functionality. That brings us to the first step in making an app.

Define your appMost unsuccessful apps fail for any of four reasons:

1. the app was a solution in search of a problem (i.e., no real need existed) 2. the implementation was poor 3. the app tried to do too much; or 4. the Apple App Store rejected the app (either because the implementation was poor or it violated Apple’s content policies)

Keeping the app as simple as possible is the best way to avoid these pitfalls. Most successful apps (indeed, most successful consumer tech products) are based on what is called an MVP, or minimum viable product. It’s the product with the smallest feature set that can deliver the core function without any distracting “bells and whistles.” You know you have an MVP if the product would no longer function if you removed any single feature.

But what should that core feature be? One of the best examples of an MVP is Mail. Version 1 (on the Mac) offered a clear, limited and intuitive feature set whose usefulness was immediately obvious to anyone. Today’s iPhone version integrates seamlessly with your phone, contacts and calendaring. It auto-matically corrects spelling as you type, lets you email photos directly from your photos app, and does much more. But all that came later and was built on top of a basic core function. And that’s how your first app should be built. The key is to come up with something with a clear value that changes people’s lives.

So, in drawing up your MVP feature list, ask yourself what features are key to the experience. Some basic market research is probably in order, starting with a visit to the App Store to see what already exists (possibly to be improved upon and/or to compete with you). Likely

must-have core capabilities include:

• Performance (e.g., fast screen refresh)• Offline capability (i.e., ability to work when not connected to the Internet)• Location awareness (e.g., the data/experience will change with the user’s location)• Cloud syncing (e.g., users see the same data on multiple devices)• Push notifications (i.e., sending updated information to devices as soon as it is available)

When you have a handle on what your app does, the next step is to design it. Designing your app involves making choices of how infor-mation and controls are presented to the user as well as how to implement app logic, and figuring out what data lives locally and what belongs in the Cloud.

Design your appUser experience decisions determine the app’s look and feel. They answer questions such as: What does the app look like? What screens does it have? In the software development world, onscreen objects like buttons, sliders, and fill-in boxes are called widgets. So you need to decide which types of widgets will reside on which screens. And what actions will occur as a result of the user interacting with those widgets?

Keep in mind that users will expect to interact differently with a mobile device than they do with a PC because the screens on mobile devices are much smaller. They’ll expect to use their fingers instead of a mouse or a track pad. Ideally, your app can even be used with one hand holding the device while using just a thumb for scrolling andworking the app’s other controls— the Path app is a good example, and increasingly, so is Facebook.

Your app’s features will inform its architecture, which is how you’ll divide the code and data into functional parts. If your app requires interacting with other app users or networked services, you’ll need to figure out what piece of the logic lives in the app code and what comes from the backend. For example, your app might integrate with a restau-rant recommendation engine, share user location, or pull real-time traffic data. This is done using APIs provided by various service providers — but you don’t have to wire up your app to a network to get started. You can develop a prototype using predefined representative (or “dummy”) data. It’s easier to fine-tune the front end if you don’t have to simultaneously modify your backend too. Once you get the app’s look-and-feel right, then make those backend connections.

Once you’ve got the overall concept for your app, the next step is to express that design in terms of the iOS app architecture. That archi-tecture is the model for what parts an iOS app can contain and how those parts fit together. It’s a well thought-out approach for translat-ing a product concept into actual code you can deploy on a device.

WHY iOS?Besides the features and design of your first app, there’s one more decision you need to make before you start actual development. That’s whether to deploy on Apple’s iOS platform or on Google’s Android platform. (Some of this is also covered in our ebook, How to Make an App: Android Edition.) Reasons to develop for iOS include:

Customers more willing to pay. Perhaps it’s because of Android’s open source heritage, but whatever the reason, Android apps gener-ate less than 10% of the total dollars spent on mobile apps, despite having 75% of the smartphone market itself — and despite the fact that the average selling price of an app in the Google Play is $3.79 versus Apple App Store’s $2.01. In other words, Apple users are much more willing to spend money on apps.

The Apple Ecosystem. Some developers and users prefer Apple’s closed and more tightly controlled environment. Apple’s ecosystem, consisting of Xcode, iCloud, iTunes, the App Store, the iPad, the iPhone, Mac computers, etc., offers a very holistic user experience with the ability to share data seamlessly across devices plus the

assurance of having applications pre-approved for quality and content prior to going on sale.

Xcode. Apple’s all-in-one IDE offers state-of-the-art offers features like a graphical interface builder and a syntax-aware and compiler-aware source editor.

The Apple Experience. From the fit and finish of its hardware to the customer service in its retail stores, to the way its hardware and software work flawlessly together, Apple has created the premium brand in consumer electronics. iOS developers share the benefits — so when someone downloads your iOS app, they already expect it’s a great product. And that it will also work flawlessly on their device.

Tablets. iOS has a clear advantage over Android in terms of tablet market adoption. Using Xcode, it’s also much easier to migrate an app from a phone to a tablet and vice versa than it is when develop-ing for Android.

Why Not iOS?Although iOS offers many compelling advantages as a platform for your mobile app, it also comes with some disadvantages. Here are three:

Closed Platform. iOS apps only run on Apple products so you can’t take advantage of features (like NFC) available only on non-iOS devices or market growth of non-iOS devices.

Market Growth. Today, iOS represents less than 15% of the total smartphone market, Although the total market (“the whole pie”) is still increasing at a fast rate, Android market growth outpaces iOS growth.

Approvals. The App Store’s app approval process is notoriously more time consuming than Google Play’s process.

The iOS app architectureAs noted earlier, a key reason why there are so many apps for iOS is because developing highly functional, polished apps for the platform is relatively easy. That’s mainly because of: 1) the design of the development tools, and 2) the key architectural features most iOS apps have in common. So let’s start with some concepts since it helps to know what goes into an app before trying to create one. We’ll begin with:

• Design patterns• Frameworks• Delegation• Storyboard• Windows• Outlets• Supporting files• Products

Design patterns. iOS apps implement what is known as a Mod-el-View-Controller (MVC) pattern. A pattern is a common way to structure code that solves a particular design problem. The MVC pattern separates application code in a way that allows you to easily change one part of an app without having to change other parts. An MVC pattern consists of three components:

• The Model is the logic that acts on the data, such as to store or retrieve data from a database, compute the distance between two cities on a map, etc. An example of a model is the Kinvey backend that stores your data in the Cloud as a service.

• The View provides the interface to the user; it displays the data and widgets (e.g., buttons and text fields) that allow the user to interact with the data. An iPhone app may have more than one view, as in the Contacts app, which displays a list view of all contacts or alternatively a view of each individual contact.

• The Controller is between the model and the view — i.e., it responds to user requests (made in a view) and retrieves results

(produced in a model). This is where developers spend most of their time — constructing the View Controller — by defining and attaching actions (or behaviors) to onscreen widgets. When the user taps a button, for example, it is the View Controller that determines what action will occur, such as retrieve stored data from your Kinvey-based data store. The link between a view object (like a button) to a controller action is called a connection.

Frameworks. You don’t actually have to write most of an app’s logic. It already exists as frameworks. A framework is a collection of classes that implements some function — such as connecting to the Internet, drawing a button, etc. Rather than write the code from scratch, you just use the frameworks supplied by iOS. Some frameworks are automatically present when you start a new project while others may need to be added (done via a drop down menu in Xcode’s Project Editor).

Delegation. Say, you want to customize the behavior of a framework’s object. You can’t actually modify the code of the framework class itself (prohibited since other apps may also use the framework). But what you can do is provide app-specific behavior in an application delegate object. If a delegate implements a method, it will be called by the delegating class to modify its behavior. In the Kinvey sample app (one of two examples we will be describing below), the AppDele-gate.h and AppDelegate.m — the header and implementation files for the UIApplicationDelegate, respectively — contain the code that authenticates an app to the Kinvey backend service.

Storyboards and XIBs. The MainStoryboard.storyboard file (or a .xib file, if you did not click on the “Use Storyboard” option when starting your project) contains the view information needed to implement the overall flow and display of your application and the user interface elements.

Windows. Each view (e.g., the contact list and individual contact details in the Contacts app) exists within a window. The window represents the entire device screen and is where all your views are presented.

Outlets. A variable by which a view object can be referenced in a controller. (For example, if you place a text field to capture a user's name, you might create an outlet called UITextField* nameField.)

Supporting files. These are files that provide resources (like PNG images and other static data) that your app needs as well as files that configure how the app will run. Other examples:

.pch files — precompiled headers used for the code files in your project.

.plist files — property lists that are small amounts of persistent data (like your app’s default user settings) consisting primarily of strings and numbers that you want your app to be able to access, modify if needed, and write back into the property list.

main.m file — your app’s main function. This is needed to launch the app, but you will not need to modify this file.

InfoPlist.strings file — used for localization.

Products. This is the file for your app (i.e., YourProduct.app) that is built when you click Xcode’s “run” button.

“Making an iOS app” involves working with these features in the typical, straightforward workflow:

• Storyboard your views by dragging and configuring graphicalobjects on a template

• Adding behaviors to the various widgets• Writing the classes as to define those behaviors (including

delegates)• Adding needed support files• Building and running the app• Iterating until you are satisfied with your app

This is all done within Xcode.

What’s Xcode?You can start developing functional, good-looking apps almost from the moment you download Xcode, Apple’s integrated development environment (IDE) for making iOS and Macintosh apps. Among other features, Xcode includes a source code editor, graphical user inter-face (GUI) editor (sometimes called Interface Builder), source code repository manager, compiler, and much more. iOS applications are typically developed by manipulating views graphically and by typing Objective-C code for the models and controllers.

To get Xcode, simply go to the App Store and download the applica-tion (it’s free). To do this, click on the App Store icon in your Mac’s dock, or visit https://itunes.apple.com/us/genre/ios/id36?mt=8

The app store will download and install Xcode in your Application folder. From Applications, double-click the Xcode icon to launch Xcode and you’ll see its splash screen (Figure 1). From there you can click on “Create a new Xcode project” to take you to a menu of several templates on which to base your application. Selecting a template opens an Xcode workspace pre-populated with frameworks and other files Xcode thinks you will need using that template.

Although you can develop, build and simulate your app on your computer in Xcode, you can’t run your app on a target device (even your own iPhone) until you become a registered iOS developer and join the iOS Developer Program. To do that, go to develop-er.app.com/ and navigate to the iOS Dev Center. While there, you will also find documentation, sample code and other useful resources such as information on how to submit your app to the iOS App Store.

Everything you do in Xcode is done in a window, called a workspace (Figure 2), consisting of multiple work areas, some of which are also divided into panes. All the files needed to build your app belong to a project, and the Navigator area (far left) lists all your projects (there can be several in a workspace) and all files for each project. Clicking on a file in the Navigator area shows its contents in the Editor area and invokes the appropriate editor. Clicking on a .h or .m file, for example, shows the file’s source code and invokes the Source editor, so you can edit the code. Clicking on .storyboard or .xib (sometimes called a “nib”) file shows the app’s storyboard and invokes the Inter-face Builder, so you can design a view using the Builder’s drag and drop features.

An especially handy feature is that the Editor area can have both a right and a left pane — with each pane aware of your edits in the other. So, for example, you can simultaneously edit an object’s .h

header file in the left pane and its corresponding .m in the right pane. Or you might click on a button object (displayed graphically) in the left pane and edit its method’s source code in the right pane. To toggle between a single pane (the “Standard Editor”) and double pane view (the “Assistant Editor”), use the Editor selector button on the right of the toolbar. You can option+command+click a symbol in the editor to open the definition in the opposite editor pane.

You can also resize the entire Editor area simply by dragging its borders. For even more editing space, you can also remove the Debug area or both the Debug and Utility areas using the View Selector button on the far right of the toolbar.

As its name suggests, the Debug area shows information, like variable state and console logs, helpful in debugging code.

The Utility area has two panes: the Inspector and Quick Help pane (top) and the Library pane (bottom). Although there are five inspectors — File, Help, Identity, Attributes, Size and Connec-tions — only the inspectors that are currently relevant appear in the Inspec-tor list at the top of the pane. (To see the name of an inspector, move the cursor over its icon in the Inspector selector bar.)

You will use inspectors to add and modify object attributes for views in the Interface Builder. For example, if you click on a UILabel in the Editor area of a storyboard, you can use the Attributes inspector to change the label’s color and use the Size inspector to change the label’s size.

The Help inspector shows help information about a selected class. Use the Identity inspector to view and manage an object’s metadata such as its class, runtime attributes, label and so forth. Use the

Connections inspector to view the outlets and actions of an interface object, to make new connections and to delete existing connections.

The Library pane has libraries of resources (like file templates, code snippets, interface objects and media files) that are prebuilt and ready to insert into your project. Use the Library selector to select which of these libraries (e.g., code snippets or interface objects) you wish to insert. To insert one, drag it directly into your storyboard while using the Interface Builder editor.

These are basics you need to know to get started using Xcode to build your first app. But to really understand how it’s done, it helps to walk through an actual app or two. Let’s start with a simple “Hello World” app that does not employ a backend connection, and then look at a somewhat more functional app that does.

“Hello World!” sample appThis app displays a button (“Press Me”) and a label (“Label”) so that when the user presses the button the text of the label changes to “Hello World!” as in Figure 3:

To get started, launch Xcode and select “Create a New Xcode Project.” From the iOS Application templates, select “Single View Application” and click “Next.” Fill in your product’s name and a company identifier, typically “com.yourCompanyName.” Deselect “Use Storyboards” and leave “Use Automatic Reference Counting” selected. Then click “Next” and select a destination for your projects files.

Follow these steps to make your app:

1. Select your project’s ViewController.xib file in the Navigator(Figure 4), to open the Interface Builder editor.

2. Drag a “Round Rect Button” from the Objects library (lowerright) onto the view in the Editor area; select the button’s textand type “Press Me.”

3. Drag a Label from the objects library onto the view, as well.4. Select and drag the Label sizing handles, centering the object

and making it wide enough to hold the “Hello World!” text; then,

5. With the “Hello World!” label still selected, click on centeralignment in the Attributes inspector.

6. Open the Assistant Editor (Figure 5), exposing the source codeheader file (ViewController.h) of the view controller you justbuilt graphically.

7. Select the button and control-drag from the button to justbelow the ViewController definition in the Assistant panel. Inthe form that opens, select “Action” for the connection type,type in a name (“showText”) and click “Connect.” This creates aninterface builder (IB) action as highlighted in Figure 6.

8. Next step is to create an outlet for the label. To do this, selectthe label object and control-drag from the label to just belowthe IB action you just created. Select “Outlet” as the connectiontype and enter a name “label” and click “Connect.” This createsan interface builder (IB) outlet as shown in Figure 7.

9. Finally, it’s time to add some logic to the view controller so itknows what to do when the button is pressed. To do this, select “ViewController.m” in the project navigator to show the code editor. Find the button’s IBAction you just created (near the bottom), place your cursor between the { } brackets and hit the return key a few times to create some extra space. Then in that space type the method for how you want the label you speci-fied to respond: _label.text=”Hello World!”; as highlighted in Figure 8.

Congratulations! Your app is done. To build and run your new app in the simulator, click the Xcode Run button in the left corner of the toolbar. When you click the button, the text will update.

Sample app with a backend This second app (named “Kinvey Test Drive”) lets the user type text on an iPhone and save the text to a backend service, like Kinvey. It also lets the user load text on the iPhone from their Kinvey backend. Reading about this app will help you learn:

• How to set up Kinvey’s library in an iOS project• Additional Interface Builder techniques you can use to story-board an application• How to add view controller logic to interact with the backend service, allowing you to save and retrieve data

We will first present the app as a running application and then take it apart so you can see how it was made. To make the app yourself, you can review the various sections below and replicate the steps in your copy of Xcode.

First, to see the app in action, you should download the app and run it on your system. To do that, sign up for Kinvey, then navigate to “Dev Center”, “Samples,” find the “Test Drive” app, and click on its icon. (If you can’t find it right away, make sure you select iOS as your platform on the right side of the menu bar.) Click the download button to download the app’s project files to your computer. Then launch Xcode — just double click on the .xcodeproj file in the project folder.

But before you can run the app, you need to set up the app’s Kinvey backend.

Set Up Kinvey as a Backend Data StoreTest Drive’s project files include all the code the sample app needs in order to talk to Kinvey. However, that would not be the case if you were to build an app from scratch — so you would have to go through an initial Kinvey setup procedure. This involves downloading the Kinvey library files from the downloads section of devcenter.kin-vey.com and dragging them to the Navigator’s Frameworks folder in Xcode. You also need to tell Xcode to link your project with additional iOS frameworks. To find these frameworks, click on the Project folder

at the very top of the Navigator pane — which displays the Project editor — and then select the “Build Settings” tab. For detailed instruc-tions, complete the “Getting Started” page under “Guides” on the Kinvey website. But again, you can skip this setup procedure for now in order to run the downloaded Kinvey Test Drive app.

But you must still do this step: To run any app that uses Kinvey (including Test Drive) you need to do the “Create an App” step on the Kinvey website. Click on “My Apps” in the Kinvey menu bar and then click on “Add an App,” which will open an “Add” page. Type in a name for your app and click on the Apple logo and then click “Create.” The page that opens shows your App’s credentials. Copy and paste the App Key and App Secret into the AppDelegate.m file of the download-ed Test Drive project:

You are now ready to run the app — click on the Xcode run button and wait for the simulator to open and the app to appear (Figure 9).

Clicking the “+” toolbar button opens an alert (Figure 10) with an empty field into which the user can type some text (e.g., “some new data”). Clicking “save” uploads the data to Kinvey and displays text on the screen (a table view) and also displays an alert that the save worked (Figure 11).

To test the load function, enter some data (e.g., “some data to load”) in the “name” field of the Kinvey collection. To see the load, the swipe down on the table on the phone until the refresh spinner starts, and then the new data will appear in the table (Figure 12).

Figure 13 shows the Kinvey collection after the save that Figure 10 depicts on the iPhone. Figure 14 shows the Kinvey collection after the user adds a new row to the testObjects collection using the web browser. Note that every time a save is done on the iPhone, Kinvey automatically adds a new row (displayed on a collection refresh). To add a new row manually in the browser, click “+ row,” and type some descriptive text in the “name” column. That data will now load on the iPhone when the user pulls down on the table.

Storyboard the Test Drive AppMost of the Test Drive user interface objects visible in the simulation are available in Xcode’s Object Library and can therefore be added to the view graphically. The UI objects consist of a:

• Table view• Toolbar• Tool Bar Button item – flexible space• Tool Bar Button item – Add• Table view cell• Label – Title• Refresh Control

To create this app yourself, you would follow these steps:

• Launch Xcode and select the “Single View Application” template• Select the “Use Storyboard” option• Replace the default UIviewcontroller object with a UITableView-Controller • Drag and drop the other objects, in the order listed, onto the UIviewcontroller

Also note:

• The Flexible Space Bar Button item fills up the space on the toolbar so the add button is at the right. This is a standard pattern in table-based iPhone apps.• The add button shows the system “+” sign. That is done by dragging a bar button item onto the toolbar, clicking on the Identifier drop down menu in the Attributes inspector; and then selecting the “Add” option.

As with the “Hello World!” app, once your app’s view is complete (Figure 15), you would still have to create the various methods and connections that bring them to life. This is done using the Source editor while working with the ViewController.m file.

Add View Controller LogicSince the app performs two basic operations (save data to Kinvey and load data from Kinvey) these two methods must be added to the ViewController header file. That’s done with a control-drag from the “+” bar button over to just under the “@ interface ViewController” line in ViewController.h. (Open the Assistant editor to see both the storyboard and the file source.)

During the drag, the popup appears, asking for the name and type of connection. Enter “action” for the connection type and “add” for the name. Then repeat the drag, this time from the refresh control and using “add” for the name (Figure 16).

Note: to follow this discussion it will help to have the referenced files open in your Xcode Source editor.

In ViewController.m, you will see the implementation code associated with each of the two Interface Builder methods, whose names Xcode added automatically to the .m file:

- (IBAction)add:(id)sender- (IBAction)load:(id)sender

You will also see a third section of code not associated with these methods, which starts with the line: “#pragma mark - Table View Stuff.” These methods support the table view and are part of UITableViewD-elegate and UITableViewDataSource. They handle controlling the

display of the table, and respond to user gestures. For example, swiping a table cell will show the delete button because tableView:-canEditRowAtIndexPath: returns YES and tableView:editingStyleForRowA-tIndexPath: returns UITableViewCellEditingStyleDelete. If you tap the delete button, the delegate method tableView:commitEditingStyle:for-RowAtIndexPath: is called. The code of this method deletes the data for the row and removes it from Kinvey’s data store. When the backend delete is completed, the app displays an alert describing the success or failure.

The way that all three sections (and all Kinvey-enabled apps) move data in and out of a Kinvey collection is by getting a reference to the app’s backend collection (named “testObjects”), which is filled with instances (each named “TestObject”) of the data the app wants to move. That’s why you’ll find the following code repeated three times in Test Drive’s View Controller (once for the add, once for the load, and once for the delete):

To support these statements it is required to have a data object class (TestObject). To see how these files are written in the sample project, click on TestObject.h file and TestObject.m in the Navigator pane. If you were to supply these files in your own app, you would click File > New File, and specify Objective-C class, which would be a subclass of NSObject. Then you would type in the code, with a property for each column in the Kinvey backend collection (including one for the object’s id).

As mentioned earlier, your app also needs to authenticate itself to Kinvey, which is handled by AppDelegate.h and AppDelgate.m. These files are created by Xcode when you create a new project, and start out with just a stub implementation. Look in the sample app source

files for code to copy and paste.

For both the save and load operations, however, moving the data in and out of a backend collection is only part of the work. Table 1 lists all the functions that implements the save and load in the ViewCon-troller.m file, along with pointers to its corresponding block of imple-mentation source code. (For each function, its corresponding code begins with the “Starts at” line and ends with the “Ends at” line.) Refer to Appendix 1 to find the actual source code.

Say Hello To Our WorldThe key takeaway from all this is that “making an app” is a worthwhile thing to do for anyone with a clever idea and a working knowledge of Objective-C. The proof is in the hundreds of apps succeeding in the market every day, many written by people working on their own and who never wrote an app before in their lives. As with anything else, practice does make perfect. But hopefully with all the resources available, and the knowledge gained from this ebook, you have already started down the path toward joining the growing legions of iOS app developers. If so, we welcome you!

Appendix 1 — Test Drive Sample App ViewController.m Source Code

2

5

The iOS revolutionIt’s a story that never gets old. The weekend that iPad Minis and the fourth generation iPads went on sale (November 2-5, 2012) Apple sold over 3 million of the devices — a record for first-weekend iPad sales. Two months earlier the company had set another record: first weekend sales of over 5 million for the iPhone 5. Since the introduc-tion of the first iPhone back in 2007,

iOS-based devices (iPhone, iPad, iPad Mini and iPod Touch) continue to rewrite the definition of what constitutes a successful product. By the end of 2012, over 400 million iOS devices had been sold.

What makes iOS devices so successful? Innovation and product features are clearly a big part. Before the iPhone most people had not interacted with a multi-touch interface. They had never zoomed with a pinch or switched between portrait and landscape by merely rotating a device in their hand. Carrying a phone that knew where they were, could suggest places to eat, and could offer directions on how to get there was also a novel experience.

But features like multi-touch, accelerometers and GPS are only part of the appeal. Even with all its innovations, iOS still might not have taken off the way it has if the only people figuring out ways to use those innovations worked at Apple. Most of the capabilities available in an iPhone or iPad in fact don’t come from Apple at all. They come from legions of third-party developers who work in a vast ecosystem that is also an Apple innovation. That ecosystem includes the iPhone, iPad, iPad Mini, iPods, App Store, iTunes, ad networks — and that’s just on the consumer side. On the developer side, you have Xcode, App Loader, testing tools, iTunes Connect — the list goes on.

As of September 2012, the App Store hosted over 700,000 apps that have collectively been downloaded over 30 billion times. Apple reported for October 2012 that App Store monthly revenues were

running at $333 million — a rate of about $4 billion per year — remarkable for a store that only opened in July 2008.

Another innovation that has spurred iOS app development is “The Cloud.” Cloud services make it easier for independent developers to create, support and make money from their apps. The Cloud solves data storage and cross-device and user-to-user sharing problems. If an app stores data in the Cloud, that part of the application is called the “backend,” while the part of the app that runs on the phone and interacts with the user is called the “front end.”

A cloud may be “private” — i.e., the services belong to an organization for the benefit of its employees and business partners. Or a cloud may be “public” — i.e., a company (such as Amazon or Kinvey) owns the services, which developers can then integrate into their own apps. If you are a developer and want to build your own backend, you certainly can do that. Whether you want to or not depends on whether your backend provides functionality common to many different apps. If it does (as in a shopping cart or user authenti-cation) then perhaps that time and money would be better spent on features that offer unique value to your customer. You may be better off hooking into a commercial backend provider via an API. Then you can focus on what counts most — a unique user experience and application-specific functionality. That brings us to the first step in making an app.

Define your appMost unsuccessful apps fail for any of four reasons:

1. the app was a solution in search of a problem (i.e., no real needexisted) 2. the implementation was poor3. the app tried to do too much; or4. the Apple App Store rejected the app (either because theimplementation was poor or it violated Apple’s content policies)

Keeping the app as simple as possible is the best way to avoid these pitfalls. Most successful apps (indeed, most successful consumer tech products) are based on what is called an MVP, or minimum viable product. It’s the product with the smallest feature set that can deliver the core function without any distracting “bells and whistles.” You know you have an MVP if the product would no longer function if you removed any single feature.

But what should that core feature be? One of the best examples of an MVP is Mail. Version 1 (on the Mac) offered a clear, limited and intuitive feature set whose usefulness was immediately obvious to anyone. Today’s iPhone version integrates seamlessly with your phone, contacts and calendaring. It auto-matically corrects spelling as you type, lets you email photos directly from your photos app, and does much more. But all that came later and was built on top of a basic core function. And that’s how your first app should be built. The key is to come up with something with a clear value that changes people’s lives.

So, in drawing up your MVP feature list, ask yourself what features are key to the experience. Some basic market research is probably in order, starting with a visit to the App Store to see what already exists (possibly to be improved upon and/or to compete with you). Likely

must-have core capabilities include:

• Performance (e.g., fast screen refresh)• Offline capability (i.e., ability to work when not connected to the Internet)• Location awareness (e.g., the data/experience will change with the user’s location)• Cloud syncing (e.g., users see the same data on multiple devices)• Push notifications (i.e., sending updated information to devices as soon as it is available)

When you have a handle on what your app does, the next step is to design it. Designing your app involves making choices of how infor-mation and controls are presented to the user as well as how to implement app logic, and figuring out what data lives locally and what belongs in the Cloud.

Design your appUser experience decisions determine the app’s look and feel. They answer questions such as: What does the app look like? What screens does it have? In the software development world, onscreen objects like buttons, sliders, and fill-in boxes are called widgets. So you need to decide which types of widgets will reside on which screens. And what actions will occur as a result of the user interacting with those widgets?

Keep in mind that users will expect to interact differently with a mobile device than they do with a PC because the screens on mobile devices are much smaller. They’ll expect to use their fingers instead of a mouse or a track pad. Ideally, your app can even be used with one hand holding the device while using just a thumb for scrolling andworking the app’s other controls— the Path app is a good example, and increasingly, so is Facebook.

Your app’s features will inform its architecture, which is how you’ll divide the code and data into functional parts. If your app requires interacting with other app users or networked services, you’ll need to figure out what piece of the logic lives in the app code and what comes from the backend. For example, your app might integrate with a restau-rant recommendation engine, share user location, or pull real-time traffic data. This is done using APIs provided by various service providers — but you don’t have to wire up your app to a network to get started. You can develop a prototype using predefined representative (or “dummy”) data. It’s easier to fine-tune the front end if you don’t have to simultaneously modify your backend too. Once you get the app’s look-and-feel right, then make those backend connections.

Once you’ve got the overall concept for your app, the next step is to express that design in terms of the iOS app architecture. That archi-tecture is the model for what parts an iOS app can contain and how those parts fit together. It’s a well thought-out approach for translat-ing a product concept into actual code you can deploy on a device.

WHY iOS?Besides the features and design of your first app, there’s one more decision you need to make before you start actual development. That’s whether to deploy on Apple’s iOS platform or on Google’s Android platform. (Some of this is also covered in our ebook, How to Make an App: Android Edition.) Reasons to develop for iOS include:

Customers more willing to pay. Perhaps it’s because of Android’s open source heritage, but whatever the reason, Android apps gener-ate less than 10% of the total dollars spent on mobile apps, despite having 75% of the smartphone market itself — and despite the fact that the average selling price of an app in the Google Play is $3.79 versus Apple App Store’s $2.01. In other words, Apple users are much more willing to spend money on apps.

The Apple Ecosystem. Some developers and users prefer Apple’s closed and more tightly controlled environment. Apple’s ecosystem, consisting of Xcode, iCloud, iTunes, the App Store, the iPad, the iPhone, Mac computers, etc., offers a very holistic user experience with the ability to share data seamlessly across devices plus the

assurance of having applications pre-approved for quality and content prior to going on sale.

Xcode. Apple’s all-in-one IDE offers state-of-the-art offers features like a graphical interface builder and a syntax-aware and compiler-aware source editor.

The Apple Experience. From the fit and finish of its hardware to the customer service in its retail stores, to the way its hardware and software work flawlessly together, Apple has created the premium brand in consumer electronics. iOS developers share the benefits — so when someone downloads your iOS app, they already expect it’s a great product. And that it will also work flawlessly on their device.

Tablets. iOS has a clear advantage over Android in terms of tablet market adoption. Using Xcode, it’s also much easier to migrate an app from a phone to a tablet and vice versa than it is when develop-ing for Android.

Why Not iOS?Although iOS offers many compelling advantages as a platform for your mobile app, it also comes with some disadvantages. Here are three:

Closed Platform. iOS apps only run on Apple products so you can’t take advantage of features (like NFC) available only on non-iOS devices or market growth of non-iOS devices.

Market Growth. Today, iOS represents less than 15% of the total smartphone market, Although the total market (“the whole pie”) is still increasing at a fast rate, Android market growth outpaces iOS growth.

Approvals. The App Store’s app approval process is notoriously more time consuming than Google Play’s process.

The iOS app architectureAs noted earlier, a key reason why there are so many apps for iOS is because developing highly functional, polished apps for the platform is relatively easy. That’s mainly because of: 1) the design of the development tools, and 2) the key architectural features most iOS apps have in common. So let’s start with some concepts since it helps to know what goes into an app before trying to create one. We’ll begin with:

• Design patterns• Frameworks• Delegation• Storyboard• Windows• Outlets• Supporting files• Products

Design patterns. iOS apps implement what is known as a Mod-el-View-Controller (MVC) pattern. A pattern is a common way to structure code that solves a particular design problem. The MVC pattern separates application code in a way that allows you to easily change one part of an app without having to change other parts. An MVC pattern consists of three components:

• The Model is the logic that acts on the data, such as to store or retrieve data from a database, compute the distance between two cities on a map, etc. An example of a model is the Kinvey backend that stores your data in the Cloud as a service.

• The View provides the interface to the user; it displays the data and widgets (e.g., buttons and text fields) that allow the user to interact with the data. An iPhone app may have more than one view, as in the Contacts app, which displays a list view of all contacts or alternatively a view of each individual contact.

• The Controller is between the model and the view — i.e., it responds to user requests (made in a view) and retrieves results

(produced in a model). This is where developers spend most of their time — constructing the View Controller — by defining and attaching actions (or behaviors) to onscreen widgets. When the user taps a button, for example, it is the View Controller that determines what action will occur, such as retrieve stored data from your Kinvey-based data store. The link between a view object (like a button) to a controller action is called a connection.

Frameworks. You don’t actually have to write most of an app’s logic. It already exists as frameworks. A framework is a collection of classes that implements some function — such as connecting to the Internet, drawing a button, etc. Rather than write the code from scratch, you just use the frameworks supplied by iOS. Some frameworks are automatically present when you start a new project while others may need to be added (done via a drop down menu in Xcode’s Project Editor).

Delegation. Say, you want to customize the behavior of a framework’s object. You can’t actually modify the code of the framework class itself (prohibited since other apps may also use the framework). But what you can do is provide app-specific behavior in an application delegate object. If a delegate implements a method, it will be called by the delegating class to modify its behavior. In the Kinvey sample app (one of two examples we will be describing below), the AppDele-gate.h and AppDelegate.m — the header and implementation files for the UIApplicationDelegate, respectively — contain the code that authenticates an app to the Kinvey backend service.

Storyboards and XIBs. The MainStoryboard.storyboard file (or a .xib file, if you did not click on the “Use Storyboard” option when starting your project) contains the view information needed to implement the overall flow and display of your application and the user interface elements.

Windows. Each view (e.g., the contact list and individual contact details in the Contacts app) exists within a window. The window represents the entire device screen and is where all your views are presented.

Outlets. A variable by which a view object can be referenced in a controller. (For example, if you place a text field to capture a user's name, you might create an outlet called UITextField* nameField.)

Supporting files. These are files that provide resources (like PNG images and other static data) that your app needs as well as files that configure how the app will run. Other examples:

.pch files — precompiled headers used for the code files in your project.

.plist files — property lists that are small amounts of persistent data (like your app’s default user settings) consisting primarily of strings and numbers that you want your app to be able to access, modify if needed, and write back into the property list.

main.m file — your app’s main function. This is needed to launch the app, but you will not need to modify this file.

InfoPlist.strings file — used for localization.

Products. This is the file for your app (i.e., YourProduct.app) that is built when you click Xcode’s “run” button.

“Making an iOS app” involves working with these features in the typical, straightforward workflow:

• Storyboard your views by dragging and configuring graphicalobjects on a template

• Adding behaviors to the various widgets• Writing the classes as to define those behaviors (including

delegates)• Adding needed support files• Building and running the app• Iterating until you are satisfied with your app

This is all done within Xcode.

What’s Xcode?You can start developing functional, good-looking apps almost from the moment you download Xcode, Apple’s integrated development environment (IDE) for making iOS and Macintosh apps. Among other features, Xcode includes a source code editor, graphical user inter-face (GUI) editor (sometimes called Interface Builder), source code repository manager, compiler, and much more. iOS applications are typically developed by manipulating views graphically and by typing Objective-C code for the models and controllers.

To get Xcode, simply go to the App Store and download the applica-tion (it’s free). To do this, click on the App Store icon in your Mac’s dock, or visit https://itunes.apple.com/us/genre/ios/id36?mt=8

The app store will download and install Xcode in your Application folder. From Applications, double-click the Xcode icon to launch Xcode and you’ll see its splash screen (Figure 1). From there you can click on “Create a new Xcode project” to take you to a menu of several templates on which to base your application. Selecting a template opens an Xcode workspace pre-populated with frameworks and other files Xcode thinks you will need using that template.

Although you can develop, build and simulate your app on your computer in Xcode, you can’t run your app on a target device (even your own iPhone) until you become a registered iOS developer and join the iOS Developer Program. To do that, go to develop-er.app.com/ and navigate to the iOS Dev Center. While there, you will also find documentation, sample code and other useful resources such as information on how to submit your app to the iOS App Store.

Everything you do in Xcode is done in a window, called a workspace (Figure 2), consisting of multiple work areas, some of which are also divided into panes. All the files needed to build your app belong to a project, and the Navigator area (far left) lists all your projects (there can be several in a workspace) and all files for each project. Clicking on a file in the Navigator area shows its contents in the Editor area and invokes the appropriate editor. Clicking on a .h or .m file, for example, shows the file’s source code and invokes the Source editor, so you can edit the code. Clicking on .storyboard or .xib (sometimes called a “nib”) file shows the app’s storyboard and invokes the Inter-face Builder, so you can design a view using the Builder’s drag and drop features.

An especially handy feature is that the Editor area can have both a right and a left pane — with each pane aware of your edits in the other. So, for example, you can simultaneously edit an object’s .h

header file in the left pane and its corresponding .m in the right pane. Or you might click on a button object (displayed graphically) in the left pane and edit its method’s source code in the right pane. To toggle between a single pane (the “Standard Editor”) and double pane view (the “Assistant Editor”), use the Editor selector button on the right of the toolbar. You can option+command+click a symbol in the editor to open the definition in the opposite editor pane.

You can also resize the entire Editor area simply by dragging its borders. For even more editing space, you can also remove the Debug area or both the Debug and Utility areas using the View Selector button on the far right of the toolbar.

As its name suggests, the Debug area shows information, like variable state and console logs, helpful in debugging code.

The Utility area has two panes: the Inspector and Quick Help pane (top) and the Library pane (bottom). Although there are five inspectors — File, Help, Identity, Attributes, Size and Connec-tions — only the inspectors that are currently relevant appear in the Inspec-tor list at the top of the pane. (To see the name of an inspector, move the cursor over its icon in the Inspector selector bar.)

You will use inspectors to add and modify object attributes for views in the Interface Builder. For example, if you click on a UILabel in the Editor area of a storyboard, you can use the Attributes inspector to change the label’s color and use the Size inspector to change the label’s size.

The Help inspector shows help information about a selected class. Use the Identity inspector to view and manage an object’s metadata such as its class, runtime attributes, label and so forth. Use the

Connections inspector to view the outlets and actions of an interface object, to make new connections and to delete existing connections.

The Library pane has libraries of resources (like file templates, code snippets, interface objects and media files) that are prebuilt and ready to insert into your project. Use the Library selector to select which of these libraries (e.g., code snippets or interface objects) you wish to insert. To insert one, drag it directly into your storyboard while using the Interface Builder editor.

These are basics you need to know to get started using Xcode to build your first app. But to really understand how it’s done, it helps to walk through an actual app or two. Let’s start with a simple “Hello World” app that does not employ a backend connection, and then look at a somewhat more functional app that does.

“Hello World!” sample appThis app displays a button (“Press Me”) and a label (“Label”) so that when the user presses the button the text of the label changes to “Hello World!” as in Figure 3:

To get started, launch Xcode and select “Create a New Xcode Project.” From the iOS Application templates, select “Single View Application” and click “Next.” Fill in your product’s name and a company identifier, typically “com.yourCompanyName.” Deselect “Use Storyboards” and leave “Use Automatic Reference Counting” selected. Then click “Next” and select a destination for your projects files.

Follow these steps to make your app:

1. Select your project’s ViewController.xib file in the Navigator(Figure 4), to open the Interface Builder editor.

2. Drag a “Round Rect Button” from the Objects library (lowerright) onto the view in the Editor area; select the button’s textand type “Press Me.”

3. Drag a Label from the objects library onto the view, as well.4. Select and drag the Label sizing handles, centering the object

and making it wide enough to hold the “Hello World!” text; then,

5. With the “Hello World!” label still selected, click on centeralignment in the Attributes inspector.

6. Open the Assistant Editor (Figure 5), exposing the source codeheader file (ViewController.h) of the view controller you justbuilt graphically.

7. Select the button and control-drag from the button to justbelow the ViewController definition in the Assistant panel. Inthe form that opens, select “Action” for the connection type,type in a name (“showText”) and click “Connect.” This creates aninterface builder (IB) action as highlighted in Figure 6.

8. Next step is to create an outlet for the label. To do this, selectthe label object and control-drag from the label to just belowthe IB action you just created. Select “Outlet” as the connectiontype and enter a name “label” and click “Connect.” This createsan interface builder (IB) outlet as shown in Figure 7.

9. Finally, it’s time to add some logic to the view controller so itknows what to do when the button is pressed. To do this, select “ViewController.m” in the project navigator to show the code editor. Find the button’s IBAction you just created (near the bottom), place your cursor between the { } brackets and hit the return key a few times to create some extra space. Then in that space type the method for how you want the label you speci-fied to respond: _label.text=”Hello World!”; as highlighted in Figure 8.

Congratulations! Your app is done. To build and run your new app in the simulator, click the Xcode Run button in the left corner of the toolbar. When you click the button, the text will update.

Sample app with a backend This second app (named “Kinvey Test Drive”) lets the user type text on an iPhone and save the text to a backend service, like Kinvey. It also lets the user load text on the iPhone from their Kinvey backend. Reading about this app will help you learn:

• How to set up Kinvey’s library in an iOS project• Additional Interface Builder techniques you can use to story-board an application• How to add view controller logic to interact with the backend service, allowing you to save and retrieve data

We will first present the app as a running application and then take it apart so you can see how it was made. To make the app yourself, you can review the various sections below and replicate the steps in your copy of Xcode.

First, to see the app in action, you should download the app and run it on your system. To do that, sign up for Kinvey, then navigate to “Dev Center”, “Samples,” find the “Test Drive” app, and click on its icon. (If you can’t find it right away, make sure you select iOS as your platform on the right side of the menu bar.) Click the download button to download the app’s project files to your computer. Then launch Xcode — just double click on the .xcodeproj file in the project folder.

But before you can run the app, you need to set up the app’s Kinvey backend.

Set Up Kinvey as a Backend Data StoreTest Drive’s project files include all the code the sample app needs in order to talk to Kinvey. However, that would not be the case if you were to build an app from scratch — so you would have to go through an initial Kinvey setup procedure. This involves downloading the Kinvey library files from the downloads section of devcenter.kin-vey.com and dragging them to the Navigator’s Frameworks folder in Xcode. You also need to tell Xcode to link your project with additional iOS frameworks. To find these frameworks, click on the Project folder

at the very top of the Navigator pane — which displays the Project editor — and then select the “Build Settings” tab. For detailed instruc-tions, complete the “Getting Started” page under “Guides” on the Kinvey website. But again, you can skip this setup procedure for now in order to run the downloaded Kinvey Test Drive app.

But you must still do this step: To run any app that uses Kinvey (including Test Drive) you need to do the “Create an App” step on the Kinvey website. Click on “My Apps” in the Kinvey menu bar and then click on “Add an App,” which will open an “Add” page. Type in a name for your app and click on the Apple logo and then click “Create.” The page that opens shows your App’s credentials. Copy and paste the App Key and App Secret into the AppDelegate.m file of the download-ed Test Drive project:

You are now ready to run the app — click on the Xcode run button and wait for the simulator to open and the app to appear (Figure 9).

Clicking the “+” toolbar button opens an alert (Figure 10) with an empty field into which the user can type some text (e.g., “some new data”). Clicking “save” uploads the data to Kinvey and displays text on the screen (a table view) and also displays an alert that the save worked (Figure 11).

To test the load function, enter some data (e.g., “some data to load”) in the “name” field of the Kinvey collection. To see the load, the swipe down on the table on the phone until the refresh spinner starts, and then the new data will appear in the table (Figure 12).

Figure 13 shows the Kinvey collection after the save that Figure 10 depicts on the iPhone. Figure 14 shows the Kinvey collection after the user adds a new row to the testObjects collection using the web browser. Note that every time a save is done on the iPhone, Kinvey automatically adds a new row (displayed on a collection refresh). To add a new row manually in the browser, click “+ row,” and type some descriptive text in the “name” column. That data will now load on the iPhone when the user pulls down on the table.

Storyboard the Test Drive AppMost of the Test Drive user interface objects visible in the simulation are available in Xcode’s Object Library and can therefore be added to the view graphically. The UI objects consist of a:

• Table view• Toolbar• Tool Bar Button item – flexible space• Tool Bar Button item – Add• Table view cell• Label – Title• Refresh Control

To create this app yourself, you would follow these steps:

• Launch Xcode and select the “Single View Application” template• Select the “Use Storyboard” option• Replace the default UIviewcontroller object with a UITableView-Controller • Drag and drop the other objects, in the order listed, onto the UIviewcontroller

Also note:

• The Flexible Space Bar Button item fills up the space on the toolbar so the add button is at the right. This is a standard pattern in table-based iPhone apps.• The add button shows the system “+” sign. That is done by dragging a bar button item onto the toolbar, clicking on the Identifier drop down menu in the Attributes inspector; and then selecting the “Add” option.

As with the “Hello World!” app, once your app’s view is complete (Figure 15), you would still have to create the various methods and connections that bring them to life. This is done using the Source editor while working with the ViewController.m file.

Add View Controller LogicSince the app performs two basic operations (save data to Kinvey and load data from Kinvey) these two methods must be added to the ViewController header file. That’s done with a control-drag from the “+” bar button over to just under the “@ interface ViewController” line in ViewController.h. (Open the Assistant editor to see both the storyboard and the file source.)

During the drag, the popup appears, asking for the name and type of connection. Enter “action” for the connection type and “add” for the name. Then repeat the drag, this time from the refresh control and using “add” for the name (Figure 16).

Note: to follow this discussion it will help to have the referenced files open in your Xcode Source editor.

In ViewController.m, you will see the implementation code associated with each of the two Interface Builder methods, whose names Xcode added automatically to the .m file:

- (IBAction)add:(id)sender- (IBAction)load:(id)sender

You will also see a third section of code not associated with these methods, which starts with the line: “#pragma mark - Table View Stuff.” These methods support the table view and are part of UITableViewD-elegate and UITableViewDataSource. They handle controlling the

display of the table, and respond to user gestures. For example, swiping a table cell will show the delete button because tableView:-canEditRowAtIndexPath: returns YES and tableView:editingStyleForRowA-tIndexPath: returns UITableViewCellEditingStyleDelete. If you tap the delete button, the delegate method tableView:commitEditingStyle:for-RowAtIndexPath: is called. The code of this method deletes the data for the row and removes it from Kinvey’s data store. When the backend delete is completed, the app displays an alert describing the success or failure.

The way that all three sections (and all Kinvey-enabled apps) move data in and out of a Kinvey collection is by getting a reference to the app’s backend collection (named “testObjects”), which is filled with instances (each named “TestObject”) of the data the app wants to move. That’s why you’ll find the following code repeated three times in Test Drive’s View Controller (once for the add, once for the load, and once for the delete):

To support these statements it is required to have a data object class (TestObject). To see how these files are written in the sample project, click on TestObject.h file and TestObject.m in the Navigator pane. If you were to supply these files in your own app, you would click File > New File, and specify Objective-C class, which would be a subclass of NSObject. Then you would type in the code, with a property for each column in the Kinvey backend collection (including one for the object’s id).

As mentioned earlier, your app also needs to authenticate itself to Kinvey, which is handled by AppDelegate.h and AppDelgate.m. These files are created by Xcode when you create a new project, and start out with just a stub implementation. Look in the sample app source

files for code to copy and paste.

For both the save and load operations, however, moving the data in and out of a backend collection is only part of the work. Table 1 lists all the functions that implements the save and load in the ViewCon-troller.m file, along with pointers to its corresponding block of imple-mentation source code. (For each function, its corresponding code begins with the “Starts at” line and ends with the “Ends at” line.) Refer to Appendix 1 to find the actual source code.

Say Hello To Our WorldThe key takeaway from all this is that “making an app” is a worthwhile thing to do for anyone with a clever idea and a working knowledge of Objective-C. The proof is in the hundreds of apps succeeding in the market every day, many written by people working on their own and who never wrote an app before in their lives. As with anything else, practice does make perfect. But hopefully with all the resources available, and the knowledge gained from this ebook, you have already started down the path toward joining the growing legions of iOS app developers. If so, we welcome you!

Appendix 1 — Test Drive Sample App ViewController.m Source Code

6

The iOS revolutionIt’s a story that never gets old. The weekend that iPad Minis and the fourth generation iPads went on sale (November 2-5, 2012) Apple sold over 3 million of the devices — a record for first-weekend iPad sales. Two months earlier the company had set another record: first weekend sales of over 5 million for the iPhone 5. Since the introduc-tion of the first iPhone back in 2007,

iOS-based devices (iPhone, iPad, iPad Mini and iPod Touch) continue to rewrite the definition of what constitutes a successful product. By the end of 2012, over 400 million iOS devices had been sold.

What makes iOS devices so successful? Innovation and product features are clearly a big part. Before the iPhone most people had not interacted with a multi-touch interface. They had never zoomed with a pinch or switched between portrait and landscape by merely rotating a device in their hand. Carrying a phone that knew where they were, could suggest places to eat, and could offer directions on how to get there was also a novel experience.

But features like multi-touch, accelerometers and GPS are only part of the appeal. Even with all its innovations, iOS still might not have taken off the way it has if the only people figuring out ways to use those innovations worked at Apple. Most of the capabilities available in an iPhone or iPad in fact don’t come from Apple at all. They come from legions of third-party developers who work in a vast ecosystem that is also an Apple innovation. That ecosystem includes the iPhone, iPad, iPad Mini, iPods, App Store, iTunes, ad networks — and that’s just on the consumer side. On the developer side, you have Xcode, App Loader, testing tools, iTunes Connect — the list goes on.

As of September 2012, the App Store hosted over 700,000 apps that have collectively been downloaded over 30 billion times. Apple reported for October 2012 that App Store monthly revenues were

running at $333 million — a rate of about $4 billion per year — remarkable for a store that only opened in July 2008.

Another innovation that has spurred iOS app development is “The Cloud.” Cloud services make it easier for independent developers to create, support and make money from their apps. The Cloud solves data storage and cross-device and user-to-user sharing problems. If an app stores data in the Cloud, that part of the application is called the “backend,” while the part of the app that runs on the phone and interacts with the user is called the “front end.”

A cloud may be “private” — i.e., the services belong to an organization for the benefit of its employees and business partners. Or a cloud may be “public” — i.e., a company (such as Amazon or Kinvey) owns the services, which developers can then integrate into their own apps. If you are a developer and want to build your own backend, you certainly can do that. Whether you want to or not depends on whether your backend provides functionality common to many different apps. If it does (as in a shopping cart or user authenti-cation) then perhaps that time and money would be better spent on features that offer unique value to your customer. You may be better off hooking into a commercial backend provider via an API. Then you can focus on what counts most — a unique user experience and application-specific functionality. That brings us to the first step in making an app.

Define your appMost unsuccessful apps fail for any of four reasons:

1. the app was a solution in search of a problem (i.e., no real need existed) 2. the implementation was poor 3. the app tried to do too much; or 4. the Apple App Store rejected the app (either because the implementation was poor or it violated Apple’s content policies)

Keeping the app as simple as possible is the best way to avoid these pitfalls. Most successful apps (indeed, most successful consumer tech products) are based on what is called an MVP, or minimum viable product. It’s the product with the smallest feature set that can deliver the core function without any distracting “bells and whistles.” You know you have an MVP if the product would no longer function if you removed any single feature.

But what should that core feature be? One of the best examples of an MVP is Mail. Version 1 (on the Mac) offered a clear, limited and intuitive feature set whose usefulness was immediately obvious to anyone. Today’s iPhone version integrates seamlessly with your phone, contacts and calendaring. It auto-matically corrects spelling as you type, lets you email photos directly from your photos app, and does much more. But all that came later and was built on top of a basic core function. And that’s how your first app should be built. The key is to come up with something with a clear value that changes people’s lives.

So, in drawing up your MVP feature list, ask yourself what features are key to the experience. Some basic market research is probably in order, starting with a visit to the App Store to see what already exists (possibly to be improved upon and/or to compete with you). Likely

must-have core capabilities include:

• Performance (e.g., fast screen refresh)• Offline capability (i.e., ability to work when not connected to theInternet)• Location awareness (e.g., the data/experience will change withthe user’s location)• Cloud syncing (e.g., users see the same data on multiple devices)• Push notifications (i.e., sending updated information to devicesas soon as it is available)

When you have a handle on what your app does, the next step is to design it. Designing your app involves making choices of how infor-mation and controls are presented to the user as well as how to implement app logic, and figuring out what data lives locally and what belongs in the Cloud.

Design your appUser experience decisions determine the app’s look and feel. They answer questions such as: What does the app look like? What screens does it have? In the software development world, onscreen objects like buttons, sliders, and fill-in boxes are called widgets. So you need to decide which types of widgets will reside on which screens. And what actions will occur as a result of the user interacting with those widgets?

Keep in mind that users will expect to interact differently with a mobile device than they do with a PC because the screens on mobile devices are much smaller. They’ll expect to use their fingers instead of a mouse or a track pad. Ideally, your app can even be used with one hand holding the device while using just a thumb for scrolling andworking the app’s other controls— the Path app is a good example, and increasingly, so is Facebook.

Your app’s features will inform its architecture, which is how you’ll divide the code and data into functional parts. If your app requires interacting with other app users or networked services, you’ll need to figure out what piece of the logic lives in the app code and what comes from the backend. For example, your app might integrate with a restau-rant recommendation engine, share user location, or pull real-time traffic data. This is done using APIs provided by various service providers — but you don’t have to wire up your app to a network to get started. You can develop a prototype using predefined representative (or “dummy”) data. It’s easier to fine-tune the front end if you don’t have to simultaneously modify your backend too. Once you get the app’s look-and-feel right, then make those backend connections.

Once you’ve got the overall concept for your app, the next step is to express that design in terms of the iOS app architecture. That archi-tecture is the model for what parts an iOS app can contain and how those parts fit together. It’s a well thought-out approach for translat-ing a product concept into actual code you can deploy on a device.

WHY iOS?Besides the features and design of your first app, there’s one more decision you need to make before you start actual development. That’s whether to deploy on Apple’s iOS platform or on Google’s Android platform. (Some of this is also covered in our ebook, How to Make an App: Android Edition.) Reasons to develop for iOS include:

Customers more willing to pay. Perhaps it’s because of Android’s open source heritage, but whatever the reason, Android apps gener-ate less than 10% of the total dollars spent on mobile apps, despite having 75% of the smartphone market itself — and despite the fact that the average selling price of an app in the Google Play is $3.79 versus Apple App Store’s $2.01. In other words, Apple users are much more willing to spend money on apps.

The Apple Ecosystem. Some developers and users prefer Apple’s closed and more tightly controlled environment. Apple’s ecosystem, consisting of Xcode, iCloud, iTunes, the App Store, the iPad, the iPhone, Mac computers, etc., offers a very holistic user experience with the ability to share data seamlessly across devices plus the

assurance of having applications pre-approved for quality and content prior to going on sale.

Xcode. Apple’s all-in-one IDE offers state-of-the-art offers features like a graphical interface builder and a syntax-aware and compiler-aware source editor.

The Apple Experience. From the fit and finish of its hardware to the customer service in its retail stores, to the way its hardware and software work flawlessly together, Apple has created the premium brand in consumer electronics. iOS developers share the benefits — so when someone downloads your iOS app, they already expect it’s a great product. And that it will also work flawlessly on their device.

Tablets. iOS has a clear advantage over Android in terms of tablet market adoption. Using Xcode, it’s also much easier to migrate an app from a phone to a tablet and vice versa than it is when develop-ing for Android.

Why Not iOS?Although iOS offers many compelling advantages as a platform for your mobile app, it also comes with some disadvantages. Here are three:

Closed Platform. iOS apps only run on Apple products so you can’t take advantage of features (like NFC) available only on non-iOS devices or market growth of non-iOS devices.

Market Growth. Today, iOS represents less than 15% of the total smartphone market, Although the total market (“the whole pie”) is still increasing at a fast rate, Android market growth outpaces iOS growth.

Approvals. The App Store’s app approval process is notoriously more time consuming than Google Play’s process.

The iOS app architectureAs noted earlier, a key reason why there are so many apps for iOS is because developing highly functional, polished apps for the platform is relatively easy. That’s mainly because of: 1) the design of the development tools, and 2) the key architectural features most iOS apps have in common. So let’s start with some concepts since it helps to know what goes into an app before trying to create one. We’ll begin with:

• Design patterns• Frameworks• Delegation• Storyboard• Windows• Outlets• Supporting files• Products

Design patterns. iOS apps implement what is known as a Mod-el-View-Controller (MVC) pattern. A pattern is a common way to structure code that solves a particular design problem. The MVC pattern separates application code in a way that allows you to easily change one part of an app without having to change other parts. An MVC pattern consists of three components:

• The Model is the logic that acts on the data, such as to store or retrieve data from a database, compute the distance between two cities on a map, etc. An example of a model is the Kinvey backend that stores your data in the Cloud as a service.

• The View provides the interface to the user; it displays the data and widgets (e.g., buttons and text fields) that allow the user to interact with the data. An iPhone app may have more than one view, as in the Contacts app, which displays a list view of all contacts or alternatively a view of each individual contact.

• The Controller is between the model and the view — i.e., it responds to user requests (made in a view) and retrieves results

(produced in a model). This is where developers spend most of their time — constructing the View Controller — by defining and attaching actions (or behaviors) to onscreen widgets. When the user taps a button, for example, it is the View Controller that determines what action will occur, such as retrieve stored data from your Kinvey-based data store. The link between a view object (like a button) to a controller action is called a connection.

Frameworks. You don’t actually have to write most of an app’s logic. It already exists as frameworks. A framework is a collection of classes that implements some function — such as connecting to the Internet, drawing a button, etc. Rather than write the code from scratch, you just use the frameworks supplied by iOS. Some frameworks are automatically present when you start a new project while others may need to be added (done via a drop down menu in Xcode’s Project Editor).

Delegation. Say, you want to customize the behavior of a framework’s object. You can’t actually modify the code of the framework class itself (prohibited since other apps may also use the framework). But what you can do is provide app-specific behavior in an application delegate object. If a delegate implements a method, it will be called by the delegating class to modify its behavior. In the Kinvey sample app (one of two examples we will be describing below), the AppDele-gate.h and AppDelegate.m — the header and implementation files for the UIApplicationDelegate, respectively — contain the code that authenticates an app to the Kinvey backend service.

Storyboards and XIBs. The MainStoryboard.storyboard file (or a .xib file, if you did not click on the “Use Storyboard” option when starting your project) contains the view information needed to implement the overall flow and display of your application and the user interface elements.

Windows. Each view (e.g., the contact list and individual contact details in the Contacts app) exists within a window. The window represents the entire device screen and is where all your views are presented.

Outlets. A variable by which a view object can be referenced in a controller. (For example, if you place a text field to capture a user's name, you might create an outlet called UITextField* nameField.)

Supporting files. These are files that provide resources (like PNG images and other static data) that your app needs as well as files that configure how the app will run. Other examples:

.pch files — precompiled headers used for the code files in your project.

.plist files — property lists that are small amounts of persistent data (like your app’s default user settings) consisting primarily of strings and numbers that you want your app to be able to access, modify if needed, and write back into the property list.

main.m file — your app’s main function. This is needed to launch the app, but you will not need to modify this file.

InfoPlist.strings file — used for localization.

Products. This is the file for your app (i.e., YourProduct.app) that is built when you click Xcode’s “run” button.

“Making an iOS app” involves working with these features in the typical, straightforward workflow:

• Storyboard your views by dragging and configuring graphicalobjects on a template

• Adding behaviors to the various widgets• Writing the classes as to define those behaviors (including

delegates)• Adding needed support files• Building and running the app• Iterating until you are satisfied with your app

This is all done within Xcode.

What’s Xcode?You can start developing functional, good-looking apps almost from the moment you download Xcode, Apple’s integrated development environment (IDE) for making iOS and Macintosh apps. Among other features, Xcode includes a source code editor, graphical user inter-face (GUI) editor (sometimes called Interface Builder), source code repository manager, compiler, and much more. iOS applications are typically developed by manipulating views graphically and by typing Objective-C code for the models and controllers.

To get Xcode, simply go to the App Store and download the applica-tion (it’s free). To do this, click on the App Store icon in your Mac’s dock, or visit https://itunes.apple.com/us/genre/ios/id36?mt=8

The app store will download and install Xcode in your Application folder. From Applications, double-click the Xcode icon to launch Xcode and you’ll see its splash screen (Figure 1). From there you can click on “Create a new Xcode project” to take you to a menu of several templates on which to base your application. Selecting a template opens an Xcode workspace pre-populated with frameworks and other files Xcode thinks you will need using that template.

Although you can develop, build and simulate your app on your computer in Xcode, you can’t run your app on a target device (even your own iPhone) until you become a registered iOS developer and join the iOS Developer Program. To do that, go to develop-er.app.com/ and navigate to the iOS Dev Center. While there, you will also find documentation, sample code and other useful resources such as information on how to submit your app to the iOS App Store.

Everything you do in Xcode is done in a window, called a workspace (Figure 2), consisting of multiple work areas, some of which are also divided into panes. All the files needed to build your app belong to a project, and the Navigator area (far left) lists all your projects (there can be several in a workspace) and all files for each project. Clicking on a file in the Navigator area shows its contents in the Editor area and invokes the appropriate editor. Clicking on a .h or .m file, for example, shows the file’s source code and invokes the Source editor, so you can edit the code. Clicking on .storyboard or .xib (sometimes called a “nib”) file shows the app’s storyboard and invokes the Inter-face Builder, so you can design a view using the Builder’s drag and drop features.

An especially handy feature is that the Editor area can have both a right and a left pane — with each pane aware of your edits in the other. So, for example, you can simultaneously edit an object’s .h

header file in the left pane and its corresponding .m in the right pane. Or you might click on a button object (displayed graphically) in the left pane and edit its method’s source code in the right pane. To toggle between a single pane (the “Standard Editor”) and double pane view (the “Assistant Editor”), use the Editor selector button on the right of the toolbar. You can option+command+click a symbol in the editor to open the definition in the opposite editor pane.

You can also resize the entire Editor area simply by dragging its borders. For even more editing space, you can also remove the Debug area or both the Debug and Utility areas using the View Selector button on the far right of the toolbar.

As its name suggests, the Debug area shows information, like variable state and console logs, helpful in debugging code.

The Utility area has two panes: the Inspector and Quick Help pane (top) and the Library pane (bottom). Although there are five inspectors — File, Help, Identity, Attributes, Size and Connec-tions — only the inspectors that are currently relevant appear in the Inspec-tor list at the top of the pane. (To see the name of an inspector, move the cursor over its icon in the Inspector selector bar.)

You will use inspectors to add and modify object attributes for views in the Interface Builder. For example, if you click on a UILabel in the Editor area of a storyboard, you can use the Attributes inspector to change the label’s color and use the Size inspector to change the label’s size.

The Help inspector shows help information about a selected class. Use the Identity inspector to view and manage an object’s metadata such as its class, runtime attributes, label and so forth. Use the

Connections inspector to view the outlets and actions of an interface object, to make new connections and to delete existing connections.

The Library pane has libraries of resources (like file templates, code snippets, interface objects and media files) that are prebuilt and ready to insert into your project. Use the Library selector to select which of these libraries (e.g., code snippets or interface objects) you wish to insert. To insert one, drag it directly into your storyboard while using the Interface Builder editor.

These are basics you need to know to get started using Xcode to build your first app. But to really understand how it’s done, it helps to walk through an actual app or two. Let’s start with a simple “Hello World” app that does not employ a backend connection, and then look at a somewhat more functional app that does.

“Hello World!” sample appThis app displays a button (“Press Me”) and a label (“Label”) so that when the user presses the button the text of the label changes to “Hello World!” as in Figure 3:

To get started, launch Xcode and select “Create a New Xcode Project.” From the iOS Application templates, select “Single View Application” and click “Next.” Fill in your product’s name and a company identifier, typically “com.yourCompanyName.” Deselect “Use Storyboards” and leave “Use Automatic Reference Counting” selected. Then click “Next” and select a destination for your projects files.

Follow these steps to make your app:

1. Select your project’s ViewController.xib file in the Navigator(Figure 4), to open the Interface Builder editor.

2. Drag a “Round Rect Button” from the Objects library (lowerright) onto the view in the Editor area; select the button’s textand type “Press Me.”

3. Drag a Label from the objects library onto the view, as well.4. Select and drag the Label sizing handles, centering the object

and making it wide enough to hold the “Hello World!” text; then,

5. With the “Hello World!” label still selected, click on centeralignment in the Attributes inspector.

6. Open the Assistant Editor (Figure 5), exposing the source codeheader file (ViewController.h) of the view controller you justbuilt graphically.

7. Select the button and control-drag from the button to justbelow the ViewController definition in the Assistant panel. Inthe form that opens, select “Action” for the connection type,type in a name (“showText”) and click “Connect.” This creates aninterface builder (IB) action as highlighted in Figure 6.

8. Next step is to create an outlet for the label. To do this, selectthe label object and control-drag from the label to just belowthe IB action you just created. Select “Outlet” as the connectiontype and enter a name “label” and click “Connect.” This createsan interface builder (IB) outlet as shown in Figure 7.

9. Finally, it’s time to add some logic to the view controller so itknows what to do when the button is pressed. To do this, select “ViewController.m” in the project navigator to show the code editor. Find the button’s IBAction you just created (near the bottom), place your cursor between the { } brackets and hit the return key a few times to create some extra space. Then in that space type the method for how you want the label you speci-fied to respond: _label.text=”Hello World!”; as highlighted in Figure 8.

Congratulations! Your app is done. To build and run your new app in the simulator, click the Xcode Run button in the left corner of the toolbar. When you click the button, the text will update.

Sample app with a backend This second app (named “Kinvey Test Drive”) lets the user type text on an iPhone and save the text to a backend service, like Kinvey. It also lets the user load text on the iPhone from their Kinvey backend. Reading about this app will help you learn:

• How to set up Kinvey’s library in an iOS project• Additional Interface Builder techniques you can use to story-board an application• How to add view controller logic to interact with the backend service, allowing you to save and retrieve data

We will first present the app as a running application and then take it apart so you can see how it was made. To make the app yourself, you can review the various sections below and replicate the steps in your copy of Xcode.

First, to see the app in action, you should download the app and run it on your system. To do that, sign up for Kinvey, then navigate to “Dev Center”, “Samples,” find the “Test Drive” app, and click on its icon. (If you can’t find it right away, make sure you select iOS as your platform on the right side of the menu bar.) Click the download button to download the app’s project files to your computer. Then launch Xcode — just double click on the .xcodeproj file in the project folder.

But before you can run the app, you need to set up the app’s Kinvey backend.

Set Up Kinvey as a Backend Data StoreTest Drive’s project files include all the code the sample app needs in order to talk to Kinvey. However, that would not be the case if you were to build an app from scratch — so you would have to go through an initial Kinvey setup procedure. This involves downloading the Kinvey library files from the downloads section of devcenter.kin-vey.com and dragging them to the Navigator’s Frameworks folder in Xcode. You also need to tell Xcode to link your project with additional iOS frameworks. To find these frameworks, click on the Project folder

at the very top of the Navigator pane — which displays the Project editor — and then select the “Build Settings” tab. For detailed instruc-tions, complete the “Getting Started” page under “Guides” on the Kinvey website. But again, you can skip this setup procedure for now in order to run the downloaded Kinvey Test Drive app.

But you must still do this step: To run any app that uses Kinvey (including Test Drive) you need to do the “Create an App” step on the Kinvey website. Click on “My Apps” in the Kinvey menu bar and then click on “Add an App,” which will open an “Add” page. Type in a name for your app and click on the Apple logo and then click “Create.” The page that opens shows your App’s credentials. Copy and paste the App Key and App Secret into the AppDelegate.m file of the download-ed Test Drive project:

You are now ready to run the app — click on the Xcode run button and wait for the simulator to open and the app to appear (Figure 9).

Clicking the “+” toolbar button opens an alert (Figure 10) with an empty field into which the user can type some text (e.g., “some new data”). Clicking “save” uploads the data to Kinvey and displays text on the screen (a table view) and also displays an alert that the save worked (Figure 11).

To test the load function, enter some data (e.g., “some data to load”) in the “name” field of the Kinvey collection. To see the load, the swipe down on the table on the phone until the refresh spinner starts, and then the new data will appear in the table (Figure 12).

Figure 13 shows the Kinvey collection after the save that Figure 10 depicts on the iPhone. Figure 14 shows the Kinvey collection after the user adds a new row to the testObjects collection using the web browser. Note that every time a save is done on the iPhone, Kinvey automatically adds a new row (displayed on a collection refresh). To add a new row manually in the browser, click “+ row,” and type some descriptive text in the “name” column. That data will now load on the iPhone when the user pulls down on the table.

Storyboard the Test Drive AppMost of the Test Drive user interface objects visible in the simulation are available in Xcode’s Object Library and can therefore be added to the view graphically. The UI objects consist of a:

• Table view• Toolbar• Tool Bar Button item – flexible space• Tool Bar Button item – Add• Table view cell• Label – Title• Refresh Control

To create this app yourself, you would follow these steps:

• Launch Xcode and select the “Single View Application” template• Select the “Use Storyboard” option• Replace the default UIviewcontroller object with a UITableView-Controller • Drag and drop the other objects, in the order listed, onto the UIviewcontroller

Also note:

• The Flexible Space Bar Button item fills up the space on the toolbar so the add button is at the right. This is a standard pattern in table-based iPhone apps.• The add button shows the system “+” sign. That is done by dragging a bar button item onto the toolbar, clicking on the Identifier drop down menu in the Attributes inspector; and then selecting the “Add” option.

As with the “Hello World!” app, once your app’s view is complete (Figure 15), you would still have to create the various methods and connections that bring them to life. This is done using the Source editor while working with the ViewController.m file.

Add View Controller LogicSince the app performs two basic operations (save data to Kinvey and load data from Kinvey) these two methods must be added to the ViewController header file. That’s done with a control-drag from the “+” bar button over to just under the “@ interface ViewController” line in ViewController.h. (Open the Assistant editor to see both the storyboard and the file source.)

During the drag, the popup appears, asking for the name and type of connection. Enter “action” for the connection type and “add” for the name. Then repeat the drag, this time from the refresh control and using “add” for the name (Figure 16).

Note: to follow this discussion it will help to have the referenced files open in your Xcode Source editor.

In ViewController.m, you will see the implementation code associated with each of the two Interface Builder methods, whose names Xcode added automatically to the .m file:

- (IBAction)add:(id)sender- (IBAction)load:(id)sender

You will also see a third section of code not associated with these methods, which starts with the line: “#pragma mark - Table View Stuff.” These methods support the table view and are part of UITableViewD-elegate and UITableViewDataSource. They handle controlling the

display of the table, and respond to user gestures. For example, swiping a table cell will show the delete button because tableView:-canEditRowAtIndexPath: returns YES and tableView:editingStyleForRowA-tIndexPath: returns UITableViewCellEditingStyleDelete. If you tap the delete button, the delegate method tableView:commitEditingStyle:for-RowAtIndexPath: is called. The code of this method deletes the data for the row and removes it from Kinvey’s data store. When the backend delete is completed, the app displays an alert describing the success or failure.

The way that all three sections (and all Kinvey-enabled apps) move data in and out of a Kinvey collection is by getting a reference to the app’s backend collection (named “testObjects”), which is filled with instances (each named “TestObject”) of the data the app wants to move. That’s why you’ll find the following code repeated three times in Test Drive’s View Controller (once for the add, once for the load, and once for the delete):

To support these statements it is required to have a data object class (TestObject). To see how these files are written in the sample project, click on TestObject.h file and TestObject.m in the Navigator pane. If you were to supply these files in your own app, you would click File > New File, and specify Objective-C class, which would be a subclass of NSObject. Then you would type in the code, with a property for each column in the Kinvey backend collection (including one for the object’s id).

As mentioned earlier, your app also needs to authenticate itself to Kinvey, which is handled by AppDelegate.h and AppDelgate.m. These files are created by Xcode when you create a new project, and start out with just a stub implementation. Look in the sample app source

files for code to copy and paste.

For both the save and load operations, however, moving the data in and out of a backend collection is only part of the work. Table 1 lists all the functions that implements the save and load in the ViewCon-troller.m file, along with pointers to its corresponding block of imple-mentation source code. (For each function, its corresponding code begins with the “Starts at” line and ends with the “Ends at” line.) Refer to Appendix 1 to find the actual source code.

Say Hello To Our WorldThe key takeaway from all this is that “making an app” is a worthwhile thing to do for anyone with a clever idea and a working knowledge of Objective-C. The proof is in the hundreds of apps succeeding in the market every day, many written by people working on their own and who never wrote an app before in their lives. As with anything else, practice does make perfect. But hopefully with all the resources available, and the knowledge gained from this ebook, you have already started down the path toward joining the growing legions of iOS app developers. If so, we welcome you!

Appendix 1 — Test Drive Sample App ViewController.m Source Code

Design your app

The iOS revolutionIt’s a story that never gets old. The weekend that iPad Minis and the fourth generation iPads went on sale (November 2-5, 2012) Apple sold over 3 million of the devices — a record for first-weekend iPad sales. Two months earlier the company had set another record: first weekend sales of over 5 million for the iPhone 5. Since the introduc-tion of the first iPhone back in 2007,

iOS-based devices (iPhone, iPad, iPad Mini and iPod Touch) continue to rewrite the definition of what constitutes a successful product. By the end of 2012, over 400 million iOS devices had been sold.

What makes iOS devices so successful? Innovation and product features are clearly a big part. Before the iPhone most people had not interacted with a multi-touch interface. They had never zoomed with a pinch or switched between portrait and landscape by merely rotating a device in their hand. Carrying a phone that knew where they were, could suggest places to eat, and could offer directions on how to get there was also a novel experience.

But features like multi-touch, accelerometers and GPS are only part of the appeal. Even with all its innovations, iOS still might not have taken off the way it has if the only people figuring out ways to use those innovations worked at Apple. Most of the capabilities available in an iPhone or iPad in fact don’t come from Apple at all. They come from legions of third-party developers who work in a vast ecosystem that is also an Apple innovation. That ecosystem includes the iPhone, iPad, iPad Mini, iPods, App Store, iTunes, ad networks — and that’s just on the consumer side. On the developer side, you have Xcode, App Loader, testing tools, iTunes Connect — the list goes on.

As of September 2012, the App Store hosted over 700,000 apps that have collectively been downloaded over 30 billion times. Apple reported for October 2012 that App Store monthly revenues were

running at $333 million — a rate of about $4 billion per year — remarkable for a store that only opened in July 2008.

Another innovation that has spurred iOS app development is “The Cloud.” Cloud services make it easier for independent developers to create, support and make money from their apps. The Cloud solves data storage and cross-device and user-to-user sharing problems. If an app stores data in the Cloud, that part of the application is called the “backend,” while the part of the app that runs on the phone and interacts with the user is called the “front end.”

A cloud may be “private” — i.e., the services belong to an organization for the benefit of its employees and business partners. Or a cloud may be “public” — i.e., a company (such as Amazon or Kinvey) owns the services, which developers can then integrate into their own apps. If you are a developer and want to build your own backend, you certainly can do that. Whether you want to or not depends on whether your backend provides functionality common to many different apps. If it does (as in a shopping cart or user authenti-cation) then perhaps that time and money would be better spent on features that offer unique value to your customer. You may be better off hooking into a commercial backend provider via an API. Then you can focus on what counts most — a unique user experience and application-specific functionality. That brings us to the first step in making an app.

Define your appMost unsuccessful apps fail for any of four reasons:

1. the app was a solution in search of a problem (i.e., no real need existed) 2. the implementation was poor 3. the app tried to do too much; or 4. the Apple App Store rejected the app (either because the implementation was poor or it violated Apple’s content policies)

Keeping the app as simple as possible is the best way to avoid these pitfalls. Most successful apps (indeed, most successful consumer tech products) are based on what is called an MVP, or minimum viable product. It’s the product with the smallest feature set that can deliver the core function without any distracting “bells and whistles.” You know you have an MVP if the product would no longer function if you removed any single feature.

But what should that core feature be? One of the best examples of an MVP is Mail. Version 1 (on the Mac) offered a clear, limited and intuitive feature set whose usefulness was immediately obvious to anyone. Today’s iPhone version integrates seamlessly with your phone, contacts and calendaring. It auto-matically corrects spelling as you type, lets you email photos directly from your photos app, and does much more. But all that came later and was built on top of a basic core function. And that’s how your first app should be built. The key is to come up with something with a clear value that changes people’s lives.

So, in drawing up your MVP feature list, ask yourself what features are key to the experience. Some basic market research is probably in order, starting with a visit to the App Store to see what already exists (possibly to be improved upon and/or to compete with you). Likely

must-have core capabilities include:

• Performance (e.g., fast screen refresh)• Offline capability (i.e., ability to work when not connected to the Internet)• Location awareness (e.g., the data/experience will change with the user’s location)• Cloud syncing (e.g., users see the same data on multiple devices)• Push notifications (i.e., sending updated information to devices as soon as it is available)

When you have a handle on what your app does, the next step is to design it. Designing your app involves making choices of how infor-mation and controls are presented to the user as well as how to implement app logic, and figuring out what data lives locally and what belongs in the Cloud.

Design your appUser experience decisions determine the app’s look and feel. They answer questions such as: What does the app look like? What screens does it have? In the software development world, onscreen objects like buttons, sliders, and fill-in boxes are called widgets. So you need to decide which types of widgets will reside on which screens. And what actions will occur as a result of the user interacting with those widgets?

Keep in mind that users will expect to interact differently with a mobile device than they do with a PC because the screens on mobile devices are much smaller. They’ll expect to use their fingers instead of a mouse or a track pad. Ideally, your app can even be used with one hand holding the device while using just a thumb for scrolling andworking the app’s other controls— the Path app is a good example, and increasingly, so is Facebook.

Your app’s features will inform its architecture, which is how you’ll divide the code and data into functional parts. If your app requires interacting with other app users or networked services, you’ll need to figure out what piece of the logic lives in the app code and what comes from the backend. For example, your app might integrate with a restau-rant recommendation engine, share user location, or pull real-time traffic data. This is done using APIs provided by various service providers — but you don’t have to wire up your app to a network to get started. You can develop a prototype using predefined representative (or “dummy”) data. It’s easier to fine-tune the front end if you don’t have to simultaneously modify your backend too. Once you get the app’s look-and-feel right, then make those backend connections.

Once you’ve got the overall concept for your app, the next step is to express that design in terms of the iOS app architecture. That archi-tecture is the model for what parts an iOS app can contain and how those parts fit together. It’s a well thought-out approach for translat-ing a product concept into actual code you can deploy on a device.

WHY iOS?Besides the features and design of your first app, there’s one more decision you need to make before you start actual development. That’s whether to deploy on Apple’s iOS platform or on Google’s Android platform. (Some of this is also covered in our ebook, How to Make an App: Android Edition.) Reasons to develop for iOS include:

Customers more willing to pay. Perhaps it’s because of Android’s open source heritage, but whatever the reason, Android apps gener-ate less than 10% of the total dollars spent on mobile apps, despite having 75% of the smartphone market itself — and despite the fact that the average selling price of an app in the Google Play is $3.79 versus Apple App Store’s $2.01. In other words, Apple users are much more willing to spend money on apps.

The Apple Ecosystem. Some developers and users prefer Apple’s closed and more tightly controlled environment. Apple’s ecosystem, consisting of Xcode, iCloud, iTunes, the App Store, the iPad, the iPhone, Mac computers, etc., offers a very holistic user experience with the ability to share data seamlessly across devices plus the

assurance of having applications pre-approved for quality and content prior to going on sale.

Xcode. Apple’s all-in-one IDE offers state-of-the-art offers features like a graphical interface builder and a syntax-aware and compiler-aware source editor.

The Apple Experience. From the fit and finish of its hardware to the customer service in its retail stores, to the way its hardware and software work flawlessly together, Apple has created the premium brand in consumer electronics. iOS developers share the benefits — so when someone downloads your iOS app, they already expect it’s a great product. And that it will also work flawlessly on their device.

Tablets. iOS has a clear advantage over Android in terms of tablet market adoption. Using Xcode, it’s also much easier to migrate an app from a phone to a tablet and vice versa than it is when develop-ing for Android.

Why Not iOS?Although iOS offers many compelling advantages as a platform for your mobile app, it also comes with some disadvantages. Here are three:

Closed Platform. iOS apps only run on Apple products so you can’t take advantage of features (like NFC) available only on non-iOS devices or market growth of non-iOS devices.

Market Growth. Today, iOS represents less than 15% of the total smartphone market, Although the total market (“the whole pie”) is still increasing at a fast rate, Android market growth outpaces iOS growth.

Approvals. The App Store’s app approval process is notoriously more time consuming than Google Play’s process.

The iOS app architectureAs noted earlier, a key reason why there are so many apps for iOS is because developing highly functional, polished apps for the platform is relatively easy. That’s mainly because of: 1) the design of the development tools, and 2) the key architectural features most iOS apps have in common. So let’s start with some concepts since it helps to know what goes into an app before trying to create one. We’ll begin with:

• Design patterns• Frameworks• Delegation• Storyboard• Windows• Outlets• Supporting files• Products

Design patterns. iOS apps implement what is known as a Mod-el-View-Controller (MVC) pattern. A pattern is a common way to structure code that solves a particular design problem. The MVC pattern separates application code in a way that allows you to easily change one part of an app without having to change other parts. An MVC pattern consists of three components:

• The Model is the logic that acts on the data, such as to store or retrieve data from a database, compute the distance between two cities on a map, etc. An example of a model is the Kinvey backend that stores your data in the Cloud as a service.

• The View provides the interface to the user; it displays the data and widgets (e.g., buttons and text fields) that allow the user to interact with the data. An iPhone app may have more than one view, as in the Contacts app, which displays a list view of all contacts or alternatively a view of each individual contact.

• The Controller is between the model and the view — i.e., it responds to user requests (made in a view) and retrieves results

(produced in a model). This is where developers spend most of their time — constructing the View Controller — by defining and attaching actions (or behaviors) to onscreen widgets. When the user taps a button, for example, it is the View Controller that determines what action will occur, such as retrieve stored data from your Kinvey-based data store. The link between a view object (like a button) to a controller action is called a connection.

Frameworks. You don’t actually have to write most of an app’s logic. It already exists as frameworks. A framework is a collection of classes that implements some function — such as connecting to the Internet, drawing a button, etc. Rather than write the code from scratch, you just use the frameworks supplied by iOS. Some frameworks are automatically present when you start a new project while others may need to be added (done via a drop down menu in Xcode’s Project Editor).

Delegation. Say, you want to customize the behavior of a framework’s object. You can’t actually modify the code of the framework class itself (prohibited since other apps may also use the framework). But what you can do is provide app-specific behavior in an application delegate object. If a delegate implements a method, it will be called by the delegating class to modify its behavior. In the Kinvey sample app (one of two examples we will be describing below), the AppDele-gate.h and AppDelegate.m — the header and implementation files for the UIApplicationDelegate, respectively — contain the code that authenticates an app to the Kinvey backend service.

Storyboards and XIBs. The MainStoryboard.storyboard file (or a .xib file, if you did not click on the “Use Storyboard” option when starting your project) contains the view information needed to implement the overall flow and display of your application and the user interface elements.

Windows. Each view (e.g., the contact list and individual contact details in the Contacts app) exists within a window. The window represents the entire device screen and is where all your views are presented.

Outlets. A variable by which a view object can be referenced in a controller. (For example, if you place a text field to capture a user's name, you might create an outlet called UITextField* nameField.)

Supporting files. These are files that provide resources (like PNG images and other static data) that your app needs as well as files that configure how the app will run. Other examples:

.pch files — precompiled headers used for the code files in your project.

.plist files — property lists that are small amounts of persistent data (like your app’s default user settings) consisting primarily of strings and numbers that you want your app to be able to access, modify if needed, and write back into the property list.

main.m file — your app’s main function. This is needed to launch the app, but you will not need to modify this file.

InfoPlist.strings file — used for localization.

Products. This is the file for your app (i.e., YourProduct.app) that is built when you click Xcode’s “run” button.

“Making an iOS app” involves working with these features in the typical, straightforward workflow:

• Storyboard your views by dragging and configuring graphicalobjects on a template

• Adding behaviors to the various widgets• Writing the classes as to define those behaviors (including

delegates)• Adding needed support files• Building and running the app• Iterating until you are satisfied with your app

This is all done within Xcode.

What’s Xcode?You can start developing functional, good-looking apps almost from the moment you download Xcode, Apple’s integrated development environment (IDE) for making iOS and Macintosh apps. Among other features, Xcode includes a source code editor, graphical user inter-face (GUI) editor (sometimes called Interface Builder), source code repository manager, compiler, and much more. iOS applications are typically developed by manipulating views graphically and by typing Objective-C code for the models and controllers.

To get Xcode, simply go to the App Store and download the applica-tion (it’s free). To do this, click on the App Store icon in your Mac’s dock, or visit https://itunes.apple.com/us/genre/ios/id36?mt=8

The app store will download and install Xcode in your Application folder. From Applications, double-click the Xcode icon to launch Xcode and you’ll see its splash screen (Figure 1). From there you can click on “Create a new Xcode project” to take you to a menu of several templates on which to base your application. Selecting a template opens an Xcode workspace pre-populated with frameworks and other files Xcode thinks you will need using that template.

Although you can develop, build and simulate your app on your computer in Xcode, you can’t run your app on a target device (even your own iPhone) until you become a registered iOS developer and join the iOS Developer Program. To do that, go to develop-er.app.com/ and navigate to the iOS Dev Center. While there, you will also find documentation, sample code and other useful resources such as information on how to submit your app to the iOS App Store.

Everything you do in Xcode is done in a window, called a workspace (Figure 2), consisting of multiple work areas, some of which are also divided into panes. All the files needed to build your app belong to a project, and the Navigator area (far left) lists all your projects (there can be several in a workspace) and all files for each project. Clicking on a file in the Navigator area shows its contents in the Editor area and invokes the appropriate editor. Clicking on a .h or .m file, for example, shows the file’s source code and invokes the Source editor, so you can edit the code. Clicking on .storyboard or .xib (sometimes called a “nib”) file shows the app’s storyboard and invokes the Inter-face Builder, so you can design a view using the Builder’s drag and drop features.

An especially handy feature is that the Editor area can have both a right and a left pane — with each pane aware of your edits in the other. So, for example, you can simultaneously edit an object’s .h

header file in the left pane and its corresponding .m in the right pane. Or you might click on a button object (displayed graphically) in the left pane and edit its method’s source code in the right pane. To toggle between a single pane (the “Standard Editor”) and double pane view (the “Assistant Editor”), use the Editor selector button on the right of the toolbar. You can option+command+click a symbol in the editor to open the definition in the opposite editor pane.

You can also resize the entire Editor area simply by dragging its borders. For even more editing space, you can also remove the Debug area or both the Debug and Utility areas using the View Selector button on the far right of the toolbar.

As its name suggests, the Debug area shows information, like variable state and console logs, helpful in debugging code.

The Utility area has two panes: the Inspector and Quick Help pane (top) and the Library pane (bottom). Although there are five inspectors — File, Help, Identity, Attributes, Size and Connec-tions — only the inspectors that are currently relevant appear in the Inspec-tor list at the top of the pane. (To see the name of an inspector, move the cursor over its icon in the Inspector selector bar.)

You will use inspectors to add and modify object attributes for views in the Interface Builder. For example, if you click on a UILabel in the Editor area of a storyboard, you can use the Attributes inspector to change the label’s color and use the Size inspector to change the label’s size.

The Help inspector shows help information about a selected class. Use the Identity inspector to view and manage an object’s metadata such as its class, runtime attributes, label and so forth. Use the

Connections inspector to view the outlets and actions of an interface object, to make new connections and to delete existing connections.

The Library pane has libraries of resources (like file templates, code snippets, interface objects and media files) that are prebuilt and ready to insert into your project. Use the Library selector to select which of these libraries (e.g., code snippets or interface objects) you wish to insert. To insert one, drag it directly into your storyboard while using the Interface Builder editor.

These are basics you need to know to get started using Xcode to build your first app. But to really understand how it’s done, it helps to walk through an actual app or two. Let’s start with a simple “Hello World” app that does not employ a backend connection, and then look at a somewhat more functional app that does.

“Hello World!” sample appThis app displays a button (“Press Me”) and a label (“Label”) so that when the user presses the button the text of the label changes to “Hello World!” as in Figure 3:

To get started, launch Xcode and select “Create a New Xcode Project.” From the iOS Application templates, select “Single View Application” and click “Next.” Fill in your product’s name and a company identifier, typically “com.yourCompanyName.” Deselect “Use Storyboards” and leave “Use Automatic Reference Counting” selected. Then click “Next” and select a destination for your projects files.

Follow these steps to make your app:

1. Select your project’s ViewController.xib file in the Navigator(Figure 4), to open the Interface Builder editor.

2. Drag a “Round Rect Button” from the Objects library (lowerright) onto the view in the Editor area; select the button’s textand type “Press Me.”

3. Drag a Label from the objects library onto the view, as well.4. Select and drag the Label sizing handles, centering the object

and making it wide enough to hold the “Hello World!” text; then,

5. With the “Hello World!” label still selected, click on centeralignment in the Attributes inspector.

6. Open the Assistant Editor (Figure 5), exposing the source codeheader file (ViewController.h) of the view controller you justbuilt graphically.

7. Select the button and control-drag from the button to justbelow the ViewController definition in the Assistant panel. Inthe form that opens, select “Action” for the connection type,type in a name (“showText”) and click “Connect.” This creates aninterface builder (IB) action as highlighted in Figure 6.

8. Next step is to create an outlet for the label. To do this, selectthe label object and control-drag from the label to just belowthe IB action you just created. Select “Outlet” as the connectiontype and enter a name “label” and click “Connect.” This createsan interface builder (IB) outlet as shown in Figure 7.

9. Finally, it’s time to add some logic to the view controller so itknows what to do when the button is pressed. To do this, select “ViewController.m” in the project navigator to show the code editor. Find the button’s IBAction you just created (near the bottom), place your cursor between the { } brackets and hit the return key a few times to create some extra space. Then in that space type the method for how you want the label you speci-fied to respond: _label.text=”Hello World!”; as highlighted in Figure 8.

Congratulations! Your app is done. To build and run your new app in the simulator, click the Xcode Run button in the left corner of the toolbar. When you click the button, the text will update.

Sample app with a backend This second app (named “Kinvey Test Drive”) lets the user type text on an iPhone and save the text to a backend service, like Kinvey. It also lets the user load text on the iPhone from their Kinvey backend. Reading about this app will help you learn:

• How to set up Kinvey’s library in an iOS project• Additional Interface Builder techniques you can use to story-board an application• How to add view controller logic to interact with the backend service, allowing you to save and retrieve data

We will first present the app as a running application and then take it apart so you can see how it was made. To make the app yourself, you can review the various sections below and replicate the steps in your copy of Xcode.

First, to see the app in action, you should download the app and run it on your system. To do that, sign up for Kinvey, then navigate to “Dev Center”, “Samples,” find the “Test Drive” app, and click on its icon. (If you can’t find it right away, make sure you select iOS as your platform on the right side of the menu bar.) Click the download button to download the app’s project files to your computer. Then launch Xcode — just double click on the .xcodeproj file in the project folder.

But before you can run the app, you need to set up the app’s Kinvey backend.

Set Up Kinvey as a Backend Data StoreTest Drive’s project files include all the code the sample app needs in order to talk to Kinvey. However, that would not be the case if you were to build an app from scratch — so you would have to go through an initial Kinvey setup procedure. This involves downloading the Kinvey library files from the downloads section of devcenter.kin-vey.com and dragging them to the Navigator’s Frameworks folder in Xcode. You also need to tell Xcode to link your project with additional iOS frameworks. To find these frameworks, click on the Project folder

at the very top of the Navigator pane — which displays the Project editor — and then select the “Build Settings” tab. For detailed instruc-tions, complete the “Getting Started” page under “Guides” on the Kinvey website. But again, you can skip this setup procedure for now in order to run the downloaded Kinvey Test Drive app.

But you must still do this step: To run any app that uses Kinvey (including Test Drive) you need to do the “Create an App” step on the Kinvey website. Click on “My Apps” in the Kinvey menu bar and then click on “Add an App,” which will open an “Add” page. Type in a name for your app and click on the Apple logo and then click “Create.” The page that opens shows your App’s credentials. Copy and paste the App Key and App Secret into the AppDelegate.m file of the download-ed Test Drive project:

You are now ready to run the app — click on the Xcode run button and wait for the simulator to open and the app to appear (Figure 9).

Clicking the “+” toolbar button opens an alert (Figure 10) with an empty field into which the user can type some text (e.g., “some new data”). Clicking “save” uploads the data to Kinvey and displays text on the screen (a table view) and also displays an alert that the save worked (Figure 11).

To test the load function, enter some data (e.g., “some data to load”) in the “name” field of the Kinvey collection. To see the load, the swipe down on the table on the phone until the refresh spinner starts, and then the new data will appear in the table (Figure 12).

Figure 13 shows the Kinvey collection after the save that Figure 10 depicts on the iPhone. Figure 14 shows the Kinvey collection after the user adds a new row to the testObjects collection using the web browser. Note that every time a save is done on the iPhone, Kinvey automatically adds a new row (displayed on a collection refresh). To add a new row manually in the browser, click “+ row,” and type some descriptive text in the “name” column. That data will now load on the iPhone when the user pulls down on the table.

Storyboard the Test Drive AppMost of the Test Drive user interface objects visible in the simulation are available in Xcode’s Object Library and can therefore be added to the view graphically. The UI objects consist of a:

• Table view• Toolbar• Tool Bar Button item – flexible space• Tool Bar Button item – Add• Table view cell• Label – Title• Refresh Control

To create this app yourself, you would follow these steps:

• Launch Xcode and select the “Single View Application” template• Select the “Use Storyboard” option• Replace the default UIviewcontroller object with a UITableView-Controller • Drag and drop the other objects, in the order listed, onto the UIviewcontroller

Also note:

• The Flexible Space Bar Button item fills up the space on the toolbar so the add button is at the right. This is a standard pattern in table-based iPhone apps.• The add button shows the system “+” sign. That is done by dragging a bar button item onto the toolbar, clicking on the Identifier drop down menu in the Attributes inspector; and then selecting the “Add” option.

As with the “Hello World!” app, once your app’s view is complete (Figure 15), you would still have to create the various methods and connections that bring them to life. This is done using the Source editor while working with the ViewController.m file.

Add View Controller LogicSince the app performs two basic operations (save data to Kinvey and load data from Kinvey) these two methods must be added to the ViewController header file. That’s done with a control-drag from the “+” bar button over to just under the “@ interface ViewController” line in ViewController.h. (Open the Assistant editor to see both the storyboard and the file source.)

During the drag, the popup appears, asking for the name and type of connection. Enter “action” for the connection type and “add” for the name. Then repeat the drag, this time from the refresh control and using “add” for the name (Figure 16).

Note: to follow this discussion it will help to have the referenced files open in your Xcode Source editor.

In ViewController.m, you will see the implementation code associated with each of the two Interface Builder methods, whose names Xcode added automatically to the .m file:

- (IBAction)add:(id)sender- (IBAction)load:(id)sender

You will also see a third section of code not associated with these methods, which starts with the line: “#pragma mark - Table View Stuff.” These methods support the table view and are part of UITableViewD-elegate and UITableViewDataSource. They handle controlling the

display of the table, and respond to user gestures. For example, swiping a table cell will show the delete button because tableView:-canEditRowAtIndexPath: returns YES and tableView:editingStyleForRowA-tIndexPath: returns UITableViewCellEditingStyleDelete. If you tap the delete button, the delegate method tableView:commitEditingStyle:for-RowAtIndexPath: is called. The code of this method deletes the data for the row and removes it from Kinvey’s data store. When the backend delete is completed, the app displays an alert describing the success or failure.

The way that all three sections (and all Kinvey-enabled apps) move data in and out of a Kinvey collection is by getting a reference to the app’s backend collection (named “testObjects”), which is filled with instances (each named “TestObject”) of the data the app wants to move. That’s why you’ll find the following code repeated three times in Test Drive’s View Controller (once for the add, once for the load, and once for the delete):

To support these statements it is required to have a data object class (TestObject). To see how these files are written in the sample project, click on TestObject.h file and TestObject.m in the Navigator pane. If you were to supply these files in your own app, you would click File > New File, and specify Objective-C class, which would be a subclass of NSObject. Then you would type in the code, with a property for each column in the Kinvey backend collection (including one for the object’s id).

As mentioned earlier, your app also needs to authenticate itself to Kinvey, which is handled by AppDelegate.h and AppDelgate.m. These files are created by Xcode when you create a new project, and start out with just a stub implementation. Look in the sample app source

files for code to copy and paste.

For both the save and load operations, however, moving the data in and out of a backend collection is only part of the work. Table 1 lists all the functions that implements the save and load in the ViewCon-troller.m file, along with pointers to its corresponding block of imple-mentation source code. (For each function, its corresponding code begins with the “Starts at” line and ends with the “Ends at” line.) Refer to Appendix 1 to find the actual source code.

Say Hello To Our WorldThe key takeaway from all this is that “making an app” is a worthwhile thing to do for anyone with a clever idea and a working knowledge of Objective-C. The proof is in the hundreds of apps succeeding in the market every day, many written by people working on their own and who never wrote an app before in their lives. As with anything else, practice does make perfect. But hopefully with all the resources available, and the knowledge gained from this ebook, you have already started down the path toward joining the growing legions of iOS app developers. If so, we welcome you!

Appendix 1 — Test Drive Sample App ViewController.m Source Code

3

8

The iOS revolutionIt’s a story that never gets old. The weekend that iPad Minis and the fourth generation iPads went on sale (November 2-5, 2012) Apple sold over 3 million of the devices — a record for first-weekend iPad sales. Two months earlier the company had set another record: first weekend sales of over 5 million for the iPhone 5. Since the introduc-tion of the first iPhone back in 2007,

iOS-based devices (iPhone, iPad, iPad Mini and iPod Touch) continue to rewrite the definition of what constitutes a successful product. By the end of 2012, over 400 million iOS devices had been sold.

What makes iOS devices so successful? Innovation and product features are clearly a big part. Before the iPhone most people had not interacted with a multi-touch interface. They had never zoomed with a pinch or switched between portrait and landscape by merely rotating a device in their hand. Carrying a phone that knew where they were, could suggest places to eat, and could offer directions on how to get there was also a novel experience.

But features like multi-touch, accelerometers and GPS are only part of the appeal. Even with all its innovations, iOS still might not have taken off the way it has if the only people figuring out ways to use those innovations worked at Apple. Most of the capabilities available in an iPhone or iPad in fact don’t come from Apple at all. They come from legions of third-party developers who work in a vast ecosystem that is also an Apple innovation. That ecosystem includes the iPhone, iPad, iPad Mini, iPods, App Store, iTunes, ad networks — and that’s just on the consumer side. On the developer side, you have Xcode, App Loader, testing tools, iTunes Connect — the list goes on.

As of September 2012, the App Store hosted over 700,000 apps that have collectively been downloaded over 30 billion times. Apple reported for October 2012 that App Store monthly revenues were

running at $333 million — a rate of about $4 billion per year — remarkable for a store that only opened in July 2008.

Another innovation that has spurred iOS app development is “The Cloud.” Cloud services make it easier for independent developers to create, support and make money from their apps. The Cloud solves data storage and cross-device and user-to-user sharing problems. If an app stores data in the Cloud, that part of the application is called the “backend,” while the part of the app that runs on the phone and interacts with the user is called the “front end.”

A cloud may be “private” — i.e., the services belong to an organization for the benefit of its employees and business partners. Or a cloud may be “public” — i.e., a company (such as Amazon or Kinvey) owns the services, which developers can then integrate into their own apps. If you are a developer and want to build your own backend, you certainly can do that. Whether you want to or not depends on whether your backend provides functionality common to many different apps. If it does (as in a shopping cart or user authenti-cation) then perhaps that time and money would be better spent on features that offer unique value to your customer. You may be better off hooking into a commercial backend provider via an API. Then you can focus on what counts most — a unique user experience and application-specific functionality. That brings us to the first step in making an app.

Define your appMost unsuccessful apps fail for any of four reasons:

1. the app was a solution in search of a problem (i.e., no real need existed) 2. the implementation was poor 3. the app tried to do too much; or 4. the Apple App Store rejected the app (either because the implementation was poor or it violated Apple’s content policies)

Keeping the app as simple as possible is the best way to avoid these pitfalls. Most successful apps (indeed, most successful consumer tech products) are based on what is called an MVP, or minimum viable product. It’s the product with the smallest feature set that can deliver the core function without any distracting “bells and whistles.” You know you have an MVP if the product would no longer function if you removed any single feature.

But what should that core feature be? One of the best examples of an MVP is Mail. Version 1 (on the Mac) offered a clear, limited and intuitive feature set whose usefulness was immediately obvious to anyone. Today’s iPhone version integrates seamlessly with your phone, contacts and calendaring. It auto-matically corrects spelling as you type, lets you email photos directly from your photos app, and does much more. But all that came later and was built on top of a basic core function. And that’s how your first app should be built. The key is to come up with something with a clear value that changes people’s lives.

So, in drawing up your MVP feature list, ask yourself what features are key to the experience. Some basic market research is probably in order, starting with a visit to the App Store to see what already exists (possibly to be improved upon and/or to compete with you). Likely

must-have core capabilities include:

• Performance (e.g., fast screen refresh)• Offline capability (i.e., ability to work when not connected to the Internet)• Location awareness (e.g., the data/experience will change with the user’s location)• Cloud syncing (e.g., users see the same data on multiple devices)• Push notifications (i.e., sending updated information to devices as soon as it is available)

When you have a handle on what your app does, the next step is to design it. Designing your app involves making choices of how infor-mation and controls are presented to the user as well as how to implement app logic, and figuring out what data lives locally and what belongs in the Cloud.

Design your appUser experience decisions determine the app’s look and feel. They answer questions such as: What does the app look like? What screens does it have? In the software development world, onscreen objects like buttons, sliders, and fill-in boxes are called widgets. So you need to decide which types of widgets will reside on which screens. And what actions will occur as a result of the user interacting with those widgets?

Keep in mind that users will expect to interact differently with a mobile device than they do with a PC because the screens on mobile devices are much smaller. They’ll expect to use their fingers instead of a mouse or a track pad. Ideally, your app can even be used with one hand holding the device while using just a thumb for scrolling and working the app’s other controls — the Path app is a good example, and increasingly, so is Facebook.

Your app’s features will inform its architecture, which is how you’ll divide the code and data into functional parts. If your app requires interacting with other app users or networked services, you’ll need to figure out what piece of the logic lives in the app code and what comes from the backend. For example, your app might integrate with a restau-rant recommendation engine, share user location, or pull real-time traffic data. This is done using APIs provided by various service providers — but you don’t have to wire up your app to a network to get started. You can develop a prototype using predefined representative (or “dummy”) data. It’s easier to fine-tune the front end if you don’t have to simultaneously modify your backend too. Once you get the app’s look-and-feel right, then make those backend connections.

Once you’ve got the overall concept for your app, the next step is to express that design in terms of the iOS app architecture. That archi-tecture is the model for what parts an iOS app can contain and how those parts fit together. It’s a well thought-out approach for translat-ing a product concept into actual code you can deploy on a device.

WHY iOS?Besides the features and design of your first app, there’s one more decision you need to make before you start actual development. That’s whether to deploy on Apple’s iOS platform or on Google’s Android platform. (Some of this is also covered in our ebook, How to Make an App: Android Edition.) Reasons to develop for iOS include:

Customers more willing to pay. Perhaps it’s because of Android’s open source heritage, but whatever the reason, Android apps gener-ate less than 10% of the total dollars spent on mobile apps, despite having 75% of the smartphone market itself — and despite the fact that the average selling price of an app in the Google Play is $3.79 versus Apple App Store’s $2.01. In other words, Apple users are much more willing to spend money on apps.

The Apple Ecosystem. Some developers and users prefer Apple’s closed and more tightly controlled environment. Apple’s ecosystem, consisting of Xcode, iCloud, iTunes, the App Store, the iPad, the iPhone, Mac computers, etc., offers a very holistic user experience with the ability to share data seamlessly across devices plus the

assurance of having applications pre-approved for quality and content prior to going on sale.

Xcode. Apple’s all-in-one IDE offers state-of-the-art offers features like a graphical interface builder and a syntax-aware and compiler-aware source editor.

The Apple Experience. From the fit and finish of its hardware to the customer service in its retail stores, to the way its hardware and software work flawlessly together, Apple has created the premium brand in consumer electronics. iOS developers share the benefits — so when someone downloads your iOS app, they already expect it’s a great product. And that it will also work flawlessly on their device.

Tablets. iOS has a clear advantage over Android in terms of tablet market adoption. Using Xcode, it’s also much easier to migrate an app from a phone to a tablet and vice versa than it is when develop-ing for Android.

Why Not iOS?Although iOS offers many compelling advantages as a platform for your mobile app, it also comes with some disadvantages. Here are three:

Closed Platform. iOS apps only run on Apple products so you can’t take advantage of features (like NFC) available only on non-iOS devices or market growth of non-iOS devices.

Market Growth. Today, iOS represents less than 15% of the total smartphone market, Although the total market (“the whole pie”) is still increasing at a fast rate, Android market growth outpaces iOS growth.

Approvals. The App Store’s app approval process is notoriously more time consuming than Google Play’s process.

The iOS app architectureAs noted earlier, a key reason why there are so many apps for iOS is because developing highly functional, polished apps for the platform is relatively easy. That’s mainly because of: 1) the design of the development tools, and 2) the key architectural features most iOS apps have in common. So let’s start with some concepts since it helps to know what goes into an app before trying to create one. We’ll begin with:

• Design patterns• Frameworks• Delegation• Storyboard• Windows• Outlets• Supporting files• Products

Design patterns. iOS apps implement what is known as a Mod-el-View-Controller (MVC) pattern. A pattern is a common way to structure code that solves a particular design problem. The MVC pattern separates application code in a way that allows you to easily change one part of an app without having to change other parts. An MVC pattern consists of three components:

• The Model is the logic that acts on the data, such as to store or retrieve data from a database, compute the distance between two cities on a map, etc. An example of a model is the Kinvey backend that stores your data in the Cloud as a service.

• The View provides the interface to the user; it displays the data and widgets (e.g., buttons and text fields) that allow the user to interact with the data. An iPhone app may have more than one view, as in the Contacts app, which displays a list view of all contacts or alternatively a view of each individual contact.

• The Controller is between the model and the view — i.e., it responds to user requests (made in a view) and retrieves results

(produced in a model). This is where developers spend most of their time — constructing the View Controller — by defining and attaching actions (or behaviors) to onscreen widgets. When the user taps a button, for example, it is the View Controller that determines what action will occur, such as retrieve stored data from your Kinvey-based data store. The link between a view object (like a button) to a controller action is called a connection.

Frameworks. You don’t actually have to write most of an app’s logic. It already exists as frameworks. A framework is a collection of classes that implements some function — such as connecting to the Internet, drawing a button, etc. Rather than write the code from scratch, you just use the frameworks supplied by iOS. Some frameworks are automatically present when you start a new project while others may need to be added (done via a drop down menu in Xcode’s Project Editor).

Delegation. Say, you want to customize the behavior of a framework’s object. You can’t actually modify the code of the framework class itself (prohibited since other apps may also use the framework). But what you can do is provide app-specific behavior in an application delegate object. If a delegate implements a method, it will be called by the delegating class to modify its behavior. In the Kinvey sample app (one of two examples we will be describing below), the AppDele-gate.h and AppDelegate.m — the header and implementation files for the UIApplicationDelegate, respectively — contain the code that authenticates an app to the Kinvey backend service.

Storyboards and XIBs. The MainStoryboard.storyboard file (or a .xib file, if you did not click on the “Use Storyboard” option when starting your project) contains the view information needed to implement the overall flow and display of your application and the user interface elements.

Windows. Each view (e.g., the contact list and individual contact details in the Contacts app) exists within a window. The window represents the entire device screen and is where all your views are presented.

Outlets. A variable by which a view object can be referenced in a controller. (For example, if you place a text field to capture a user's name, you might create an outlet called UITextField* nameField.)

Supporting files. These are files that provide resources (like PNG images and other static data) that your app needs as well as files that configure how the app will run. Other examples:

.pch files — precompiled headers used for the code files in your project.

.plist files — property lists that are small amounts of persistent data (like your app’s default user settings) consisting primarily of strings and numbers that you want your app to be able to access, modify if needed, and write back into the property list.

main.m file — your app’s main function. This is needed to launch the app, but you will not need to modify this file.

InfoPlist.strings file — used for localization.

Products. This is the file for your app (i.e., YourProduct.app) that is built when you click Xcode’s “run” button.

“Making an iOS app” involves working with these features in the typical, straightforward workflow:

• Storyboard your views by dragging and configuring graphicalobjects on a template

• Adding behaviors to the various widgets• Writing the classes as to define those behaviors (including

delegates)• Adding needed support files• Building and running the app• Iterating until you are satisfied with your app

This is all done within Xcode.

What’s Xcode?You can start developing functional, good-looking apps almost from the moment you download Xcode, Apple’s integrated development environment (IDE) for making iOS and Macintosh apps. Among other features, Xcode includes a source code editor, graphical user inter-face (GUI) editor (sometimes called Interface Builder), source code repository manager, compiler, and much more. iOS applications are typically developed by manipulating views graphically and by typing Objective-C code for the models and controllers.

To get Xcode, simply go to the App Store and download the applica-tion (it’s free). To do this, click on the App Store icon in your Mac’s dock, or visit https://itunes.apple.com/us/genre/ios/id36?mt=8

The app store will download and install Xcode in your Application folder. From Applications, double-click the Xcode icon to launch Xcode and you’ll see its splash screen (Figure 1). From there you can click on “Create a new Xcode project” to take you to a menu of several templates on which to base your application. Selecting a template opens an Xcode workspace pre-populated with frameworks and other files Xcode thinks you will need using that template.

Although you can develop, build and simulate your app on your computer in Xcode, you can’t run your app on a target device (even your own iPhone) until you become a registered iOS developer and join the iOS Developer Program. To do that, go to develop-er.app.com/ and navigate to the iOS Dev Center. While there, you will also find documentation, sample code and other useful resources such as information on how to submit your app to the iOS App Store.

Everything you do in Xcode is done in a window, called a workspace (Figure 2), consisting of multiple work areas, some of which are also divided into panes. All the files needed to build your app belong to a project, and the Navigator area (far left) lists all your projects (there can be several in a workspace) and all files for each project. Clicking on a file in the Navigator area shows its contents in the Editor area and invokes the appropriate editor. Clicking on a .h or .m file, for example, shows the file’s source code and invokes the Source editor, so you can edit the code. Clicking on .storyboard or .xib (sometimes called a “nib”) file shows the app’s storyboard and invokes the Inter-face Builder, so you can design a view using the Builder’s drag and drop features.

An especially handy feature is that the Editor area can have both a right and a left pane — with each pane aware of your edits in the other. So, for example, you can simultaneously edit an object’s .h

header file in the left pane and its corresponding .m in the right pane. Or you might click on a button object (displayed graphically) in the left pane and edit its method’s source code in the right pane. To toggle between a single pane (the “Standard Editor”) and double pane view (the “Assistant Editor”), use the Editor selector button on the right of the toolbar. You can option+command+click a symbol in the editor to open the definition in the opposite editor pane.

You can also resize the entire Editor area simply by dragging its borders. For even more editing space, you can also remove the Debug area or both the Debug and Utility areas using the View Selector button on the far right of the toolbar.

As its name suggests, the Debug area shows information, like variable state and console logs, helpful in debugging code.

The Utility area has two panes: the Inspector and Quick Help pane (top) and the Library pane (bottom). Although there are five inspectors — File, Help, Identity, Attributes, Size and Connec-tions — only the inspectors that are currently relevant appear in the Inspec-tor list at the top of the pane. (To see the name of an inspector, move the cursor over its icon in the Inspector selector bar.)

You will use inspectors to add and modify object attributes for views in the Interface Builder. For example, if you click on a UILabel in the Editor area of a storyboard, you can use the Attributes inspector to change the label’s color and use the Size inspector to change the label’s size.

The Help inspector shows help information about a selected class. Use the Identity inspector to view and manage an object’s metadata such as its class, runtime attributes, label and so forth. Use the

Connections inspector to view the outlets and actions of an interface object, to make new connections and to delete existing connections.

The Library pane has libraries of resources (like file templates, code snippets, interface objects and media files) that are prebuilt and ready to insert into your project. Use the Library selector to select which of these libraries (e.g., code snippets or interface objects) you wish to insert. To insert one, drag it directly into your storyboard while using the Interface Builder editor.

These are basics you need to know to get started using Xcode to build your first app. But to really understand how it’s done, it helps to walk through an actual app or two. Let’s start with a simple “Hello World” app that does not employ a backend connection, and then look at a somewhat more functional app that does.

“Hello World!” sample appThis app displays a button (“Press Me”) and a label (“Label”) so that when the user presses the button the text of the label changes to “Hello World!” as in Figure 3:

To get started, launch Xcode and select “Create a New Xcode Project.” From the iOS Application templates, select “Single View Application” and click “Next.” Fill in your product’s name and a company identifier, typically “com.yourCompanyName.” Deselect “Use Storyboards” and leave “Use Automatic Reference Counting” selected. Then click “Next” and select a destination for your projects files.

Follow these steps to make your app:

1. Select your project’s ViewController.xib file in the Navigator(Figure 4), to open the Interface Builder editor.

2. Drag a “Round Rect Button” from the Objects library (lowerright) onto the view in the Editor area; select the button’s textand type “Press Me.”

3. Drag a Label from the objects library onto the view, as well.4. Select and drag the Label sizing handles, centering the object

and making it wide enough to hold the “Hello World!” text; then,

5. With the “Hello World!” label still selected, click on centeralignment in the Attributes inspector.

6. Open the Assistant Editor (Figure 5), exposing the source codeheader file (ViewController.h) of the view controller you justbuilt graphically.

7. Select the button and control-drag from the button to justbelow the ViewController definition in the Assistant panel. Inthe form that opens, select “Action” for the connection type,type in a name (“showText”) and click “Connect.” This creates aninterface builder (IB) action as highlighted in Figure 6.

8. Next step is to create an outlet for the label. To do this, selectthe label object and control-drag from the label to just belowthe IB action you just created. Select “Outlet” as the connectiontype and enter a name “label” and click “Connect.” This createsan interface builder (IB) outlet as shown in Figure 7.

9. Finally, it’s time to add some logic to the view controller so itknows what to do when the button is pressed. To do this, select “ViewController.m” in the project navigator to show the code editor. Find the button’s IBAction you just created (near the bottom), place your cursor between the { } brackets and hit the return key a few times to create some extra space. Then in that space type the method for how you want the label you speci-fied to respond: _label.text=”Hello World!”; as highlighted in Figure 8.

Congratulations! Your app is done. To build and run your new app in the simulator, click the Xcode Run button in the left corner of the toolbar. When you click the button, the text will update.

Sample app with a backend This second app (named “Kinvey Test Drive”) lets the user type text on an iPhone and save the text to a backend service, like Kinvey. It also lets the user load text on the iPhone from their Kinvey backend. Reading about this app will help you learn:

• How to set up Kinvey’s library in an iOS project• Additional Interface Builder techniques you can use to story-board an application• How to add view controller logic to interact with the backend service, allowing you to save and retrieve data

We will first present the app as a running application and then take it apart so you can see how it was made. To make the app yourself, you can review the various sections below and replicate the steps in your copy of Xcode.

First, to see the app in action, you should download the app and run it on your system. To do that, sign up for Kinvey, then navigate to “Dev Center”, “Samples,” find the “Test Drive” app, and click on its icon. (If you can’t find it right away, make sure you select iOS as your platform on the right side of the menu bar.) Click the download button to download the app’s project files to your computer. Then launch Xcode — just double click on the .xcodeproj file in the project folder.

But before you can run the app, you need to set up the app’s Kinvey backend.

Set Up Kinvey as a Backend Data StoreTest Drive’s project files include all the code the sample app needs in order to talk to Kinvey. However, that would not be the case if you were to build an app from scratch — so you would have to go through an initial Kinvey setup procedure. This involves downloading the Kinvey library files from the downloads section of devcenter.kin-vey.com and dragging them to the Navigator’s Frameworks folder in Xcode. You also need to tell Xcode to link your project with additional iOS frameworks. To find these frameworks, click on the Project folder

at the very top of the Navigator pane — which displays the Project editor — and then select the “Build Settings” tab. For detailed instruc-tions, complete the “Getting Started” page under “Guides” on the Kinvey website. But again, you can skip this setup procedure for now in order to run the downloaded Kinvey Test Drive app.

But you must still do this step: To run any app that uses Kinvey (including Test Drive) you need to do the “Create an App” step on the Kinvey website. Click on “My Apps” in the Kinvey menu bar and then click on “Add an App,” which will open an “Add” page. Type in a name for your app and click on the Apple logo and then click “Create.” The page that opens shows your App’s credentials. Copy and paste the App Key and App Secret into the AppDelegate.m file of the download-ed Test Drive project:

You are now ready to run the app — click on the Xcode run button and wait for the simulator to open and the app to appear (Figure 9).

Clicking the “+” toolbar button opens an alert (Figure 10) with an empty field into which the user can type some text (e.g., “some new data”). Clicking “save” uploads the data to Kinvey and displays text on the screen (a table view) and also displays an alert that the save worked (Figure 11).

To test the load function, enter some data (e.g., “some data to load”) in the “name” field of the Kinvey collection. To see the load, the swipe down on the table on the phone until the refresh spinner starts, and then the new data will appear in the table (Figure 12).

Figure 13 shows the Kinvey collection after the save that Figure 10 depicts on the iPhone. Figure 14 shows the Kinvey collection after the user adds a new row to the testObjects collection using the web browser. Note that every time a save is done on the iPhone, Kinvey automatically adds a new row (displayed on a collection refresh). To add a new row manually in the browser, click “+ row,” and type some descriptive text in the “name” column. That data will now load on the iPhone when the user pulls down on the table.

Storyboard the Test Drive AppMost of the Test Drive user interface objects visible in the simulation are available in Xcode’s Object Library and can therefore be added to the view graphically. The UI objects consist of a:

• Table view• Toolbar• Tool Bar Button item – flexible space• Tool Bar Button item – Add• Table view cell• Label – Title• Refresh Control

To create this app yourself, you would follow these steps:

• Launch Xcode and select the “Single View Application” template• Select the “Use Storyboard” option• Replace the default UIviewcontroller object with a UITableView-Controller • Drag and drop the other objects, in the order listed, onto the UIviewcontroller

Also note:

• The Flexible Space Bar Button item fills up the space on the toolbar so the add button is at the right. This is a standard pattern in table-based iPhone apps.• The add button shows the system “+” sign. That is done by dragging a bar button item onto the toolbar, clicking on the Identifier drop down menu in the Attributes inspector; and then selecting the “Add” option.

As with the “Hello World!” app, once your app’s view is complete (Figure 15), you would still have to create the various methods and connections that bring them to life. This is done using the Source editor while working with the ViewController.m file.

Add View Controller LogicSince the app performs two basic operations (save data to Kinvey and load data from Kinvey) these two methods must be added to the ViewController header file. That’s done with a control-drag from the “+” bar button over to just under the “@ interface ViewController” line in ViewController.h. (Open the Assistant editor to see both the storyboard and the file source.)

During the drag, the popup appears, asking for the name and type of connection. Enter “action” for the connection type and “add” for the name. Then repeat the drag, this time from the refresh control and using “add” for the name (Figure 16).

Note: to follow this discussion it will help to have the referenced files open in your Xcode Source editor.

In ViewController.m, you will see the implementation code associated with each of the two Interface Builder methods, whose names Xcode added automatically to the .m file:

- (IBAction)add:(id)sender- (IBAction)load:(id)sender

You will also see a third section of code not associated with these methods, which starts with the line: “#pragma mark - Table View Stuff.” These methods support the table view and are part of UITableViewD-elegate and UITableViewDataSource. They handle controlling the

display of the table, and respond to user gestures. For example, swiping a table cell will show the delete button because tableView:-canEditRowAtIndexPath: returns YES and tableView:editingStyleForRowA-tIndexPath: returns UITableViewCellEditingStyleDelete. If you tap the delete button, the delegate method tableView:commitEditingStyle:for-RowAtIndexPath: is called. The code of this method deletes the data for the row and removes it from Kinvey’s data store. When the backend delete is completed, the app displays an alert describing the success or failure.

The way that all three sections (and all Kinvey-enabled apps) move data in and out of a Kinvey collection is by getting a reference to the app’s backend collection (named “testObjects”), which is filled with instances (each named “TestObject”) of the data the app wants to move. That’s why you’ll find the following code repeated three times in Test Drive’s View Controller (once for the add, once for the load, and once for the delete):

To support these statements it is required to have a data object class (TestObject). To see how these files are written in the sample project, click on TestObject.h file and TestObject.m in the Navigator pane. If you were to supply these files in your own app, you would click File > New File, and specify Objective-C class, which would be a subclass of NSObject. Then you would type in the code, with a property for each column in the Kinvey backend collection (including one for the object’s id).

As mentioned earlier, your app also needs to authenticate itself to Kinvey, which is handled by AppDelegate.h and AppDelgate.m. These files are created by Xcode when you create a new project, and start out with just a stub implementation. Look in the sample app source

files for code to copy and paste.

For both the save and load operations, however, moving the data in and out of a backend collection is only part of the work. Table 1 lists all the functions that implements the save and load in the ViewCon-troller.m file, along with pointers to its corresponding block of imple-mentation source code. (For each function, its corresponding code begins with the “Starts at” line and ends with the “Ends at” line.) Refer to Appendix 1 to find the actual source code.

Say Hello To Our WorldThe key takeaway from all this is that “making an app” is a worthwhile thing to do for anyone with a clever idea and a working knowledge of Objective-C. The proof is in the hundreds of apps succeeding in the market every day, many written by people working on their own and who never wrote an app before in their lives. As with anything else, practice does make perfect. But hopefully with all the resources available, and the knowledge gained from this ebook, you have already started down the path toward joining the growing legions of iOS app developers. If so, we welcome you!

Appendix 1 — Test Drive Sample App ViewController.m Source Code

“Your app’sfeatures will

inform its archi-tecture, which is how you’ll divide the code and data

into functional parts.”

9

The iOS revolutionIt’s a story that never gets old. The weekend that iPad Minis and the fourth generation iPads went on sale (November 2-5, 2012) Apple sold over 3 million of the devices — a record for first-weekend iPad sales. Two months earlier the company had set another record: first weekend sales of over 5 million for the iPhone 5. Since the introduc-tion of the first iPhone back in 2007,

iOS-based devices (iPhone, iPad, iPad Mini and iPod Touch) continue to rewrite the definition of what constitutes a successful product. By the end of 2012, over 400 million iOS devices had been sold.

What makes iOS devices so successful? Innovation and product features are clearly a big part. Before the iPhone most people had not interacted with a multi-touch interface. They had never zoomed with a pinch or switched between portrait and landscape by merely rotating a device in their hand. Carrying a phone that knew where they were, could suggest places to eat, and could offer directions on how to get there was also a novel experience.

But features like multi-touch, accelerometers and GPS are only part of the appeal. Even with all its innovations, iOS still might not have taken off the way it has if the only people figuring out ways to use those innovations worked at Apple. Most of the capabilities available in an iPhone or iPad in fact don’t come from Apple at all. They come from legions of third-party developers who work in a vast ecosystem that is also an Apple innovation. That ecosystem includes the iPhone, iPad, iPad Mini, iPods, App Store, iTunes, ad networks — and that’s just on the consumer side. On the developer side, you have Xcode, App Loader, testing tools, iTunes Connect — the list goes on.

As of September 2012, the App Store hosted over 700,000 apps that have collectively been downloaded over 30 billion times. Apple reported for October 2012 that App Store monthly revenues were

running at $333 million — a rate of about $4 billion per year — remarkable for a store that only opened in July 2008.

Another innovation that has spurred iOS app development is “The Cloud.” Cloud services make it easier for independent developers to create, support and make money from their apps. The Cloud solves data storage and cross-device and user-to-user sharing problems. If an app stores data in the Cloud, that part of the application is called the “backend,” while the part of the app that runs on the phone and interacts with the user is called the “front end.”

A cloud may be “private” — i.e., the services belong to an organization for the benefit of its employees and business partners. Or a cloud may be “public” — i.e., a company (such as Amazon or Kinvey) owns the services, which developers can then integrate into their own apps. If you are a developer and want to build your own backend, you certainly can do that. Whether you want to or not depends on whether your backend provides functionality common to many different apps. If it does (as in a shopping cart or user authenti-cation) then perhaps that time and money would be better spent on features that offer unique value to your customer. You may be better off hooking into a commercial backend provider via an API. Then you can focus on what counts most — a unique user experience and application-specific functionality. That brings us to the first step in making an app.

Define your appMost unsuccessful apps fail for any of four reasons:

1. the app was a solution in search of a problem (i.e., no real need existed) 2. the implementation was poor 3. the app tried to do too much; or 4. the Apple App Store rejected the app (either because the implementation was poor or it violated Apple’s content policies)

Keeping the app as simple as possible is the best way to avoid these pitfalls. Most successful apps (indeed, most successful consumer tech products) are based on what is called an MVP, or minimum viable product. It’s the product with the smallest feature set that can deliver the core function without any distracting “bells and whistles.” You know you have an MVP if the product would no longer function if you removed any single feature.

But what should that core feature be? One of the best examples of an MVP is Mail. Version 1 (on the Mac) offered a clear, limited and intuitive feature set whose usefulness was immediately obvious to anyone. Today’s iPhone version integrates seamlessly with your phone, contacts and calendaring. It auto-matically corrects spelling as you type, lets you email photos directly from your photos app, and does much more. But all that came later and was built on top of a basic core function. And that’s how your first app should be built. The key is to come up with something with a clear value that changes people’s lives.

So, in drawing up your MVP feature list, ask yourself what features are key to the experience. Some basic market research is probably in order, starting with a visit to the App Store to see what already exists (possibly to be improved upon and/or to compete with you). Likely

must-have core capabilities include:

• Performance (e.g., fast screen refresh)• Offline capability (i.e., ability to work when not connected to the Internet)• Location awareness (e.g., the data/experience will change with the user’s location)• Cloud syncing (e.g., users see the same data on multiple devices)• Push notifications (i.e., sending updated information to devices as soon as it is available)

When you have a handle on what your app does, the next step is to design it. Designing your app involves making choices of how infor-mation and controls are presented to the user as well as how to implement app logic, and figuring out what data lives locally and what belongs in the Cloud.

Design your appUser experience decisions determine the app’s look and feel. They answer questions such as: What does the app look like? What screens does it have? In the software development world, onscreen objects like buttons, sliders, and fill-in boxes are called widgets. So you need to decide which types of widgets will reside on which screens. And what actions will occur as a result of the user interacting with those widgets?

Keep in mind that users will expect to interact differently with a mobile device than they do with a PC because the screens on mobile devices are much smaller. They’ll expect to use their fingers instead of a mouse or a track pad. Ideally, your app can even be used with one hand holding the device while using just a thumb for scrolling andworking the app’s other controls— the Path app is a good example, and increasingly, so is Facebook.

Your app’s features will inform its architecture, which is how you’ll divide the code and data into functional parts. If your app requires interacting with other app users or networked services, you’ll need to figure out what piece of the logic lives in the app code and what comes from the backend. For example, your app might integrate with a restau-rant recommendation engine, share user location, or pull real-time traffic data. This is done using APIs provided by various service providers — but you don’t have to wire up your app to a network to get started. You can develop a prototype using predefined representative (or “dummy”) data. It’s easier to fine-tune the front end if you don’t have to simultaneously modify your backend too. Once you get the app’s look-and-feel right, then make those backend connections.

Once you’ve got the overall concept for your app, the next step is to express that design in terms of the iOS app architecture. That archi-tecture is the model for what parts an iOS app can contain and how those parts fit together. It’s a well thought-out approach for translat-ing a product concept into actual code you can deploy on a device.

WHY iOS?Besides the features and design of your first app, there’s one more decision you need to make before you start actual development. That’s whether to deploy on Apple’s iOS platform or on Google’s Android platform. (Some of this is also covered in our ebook, How to Make an App: Android Edition.) Reasons to develop for iOS include:

Customers more willing to pay. Perhaps it’s because of Android’s open source heritage, but whatever the reason, Android apps gener-ate less than 10% of the total dollars spent on mobile apps, despite having 75% of the smartphone market itself — and despite the fact that the average selling price of an app in the Google Play is $3.79 versus Apple App Store’s $2.01. In other words, Apple users are much more willing to spend money on apps.

The Apple Ecosystem. Some developers and users prefer Apple’s closed and more tightly controlled environment. Apple’s ecosystem, consisting of Xcode, iCloud, iTunes, the App Store, the iPad, the iPhone, Mac computers, etc., offers a very holistic user experience with the ability to share data seamlessly across devices plus the

assurance of having applications pre-approved for quality and content prior to going on sale.

Xcode. Apple’s all-in-one IDE offers state-of-the-art offers features like a graphical interface builder and a syntax-aware and compiler-aware source editor.

The Apple Experience. From the fit and finish of its hardware to the customer service in its retail stores, to the way its hardware and software work flawlessly together, Apple has created the premium brand in consumer electronics. iOS developers share the benefits — so when someone downloads your iOS app, they already expect it’s a great product. And that it will also work flawlessly on their device.

Tablets. iOS has a clear advantage over Android in terms of tablet market adoption. Using Xcode, it’s also much easier to migrate an app from a phone to a tablet and vice versa than it is when develop-ing for Android.

Why Not iOS?Although iOS offers many compelling advantages as a platform for your mobile app, it also comes with some disadvantages. Here are three:

Closed Platform. iOS apps only run on Apple products so you can’t take advantage of features (like NFC) available only on non-iOS devices or market growth of non-iOS devices.

Market Growth. Today, iOS represents less than 15% of the total smartphone market, Although the total market (“the whole pie”) is still increasing at a fast rate, Android market growth outpaces iOS growth.

Approvals. The App Store’s app approval process is notoriously more time consuming than Google Play’s process.

The iOS app architectureAs noted earlier, a key reason why there are so many apps for iOS is because developing highly functional, polished apps for the platform is relatively easy. That’s mainly because of: 1) the design of the development tools, and 2) the key architectural features most iOS apps have in common. So let’s start with some concepts since it helps to know what goes into an app before trying to create one. We’ll begin with:

• Design patterns• Frameworks• Delegation• Storyboard• Windows• Outlets• Supporting files• Products

Design patterns. iOS apps implement what is known as a Mod-el-View-Controller (MVC) pattern. A pattern is a common way to structure code that solves a particular design problem. The MVC pattern separates application code in a way that allows you to easily change one part of an app without having to change other parts. An MVC pattern consists of three components:

• The Model is the logic that acts on the data, such as to store or retrieve data from a database, compute the distance between two cities on a map, etc. An example of a model is the Kinvey backend that stores your data in the Cloud as a service.

• The View provides the interface to the user; it displays the data and widgets (e.g., buttons and text fields) that allow the user to interact with the data. An iPhone app may have more than one view, as in the Contacts app, which displays a list view of all contacts or alternatively a view of each individual contact.

• The Controller is between the model and the view — i.e., it responds to user requests (made in a view) and retrieves results

(produced in a model). This is where developers spend most of their time — constructing the View Controller — by defining and attaching actions (or behaviors) to onscreen widgets. When the user taps a button, for example, it is the View Controller that determines what action will occur, such as retrieve stored data from your Kinvey-based data store. The link between a view object (like a button) to a controller action is called a connection.

Frameworks. You don’t actually have to write most of an app’s logic. It already exists as frameworks. A framework is a collection of classes that implements some function — such as connecting to the Internet, drawing a button, etc. Rather than write the code from scratch, you just use the frameworks supplied by iOS. Some frameworks are automatically present when you start a new project while others may need to be added (done via a drop down menu in Xcode’s Project Editor).

Delegation. Say, you want to customize the behavior of a framework’s object. You can’t actually modify the code of the framework class itself (prohibited since other apps may also use the framework). But what you can do is provide app-specific behavior in an application delegate object. If a delegate implements a method, it will be called by the delegating class to modify its behavior. In the Kinvey sample app (one of two examples we will be describing below), the AppDele-gate.h and AppDelegate.m — the header and implementation files for the UIApplicationDelegate, respectively — contain the code that authenticates an app to the Kinvey backend service.

Storyboards and XIBs. The MainStoryboard.storyboard file (or a .xib file, if you did not click on the “Use Storyboard” option when starting your project) contains the view information needed to implement the overall flow and display of your application and the user interface elements.

Windows. Each view (e.g., the contact list and individual contact details in the Contacts app) exists within a window. The window represents the entire device screen and is where all your views are presented.

Outlets. A variable by which a view object can be referenced in a controller. (For example, if you place a text field to capture a user's name, you might create an outlet called UITextField* nameField.)

Supporting files. These are files that provide resources (like PNG images and other static data) that your app needs as well as files that configure how the app will run. Other examples:

.pch files — precompiled headers used for the code files in your project.

.plist files — property lists that are small amounts of persistent data (like your app’s default user settings) consisting primarily of strings and numbers that you want your app to be able to access, modify if needed, and write back into the property list.

main.m file — your app’s main function. This is needed to launch the app, but you will not need to modify this file.

InfoPlist.strings file — used for localization.

Products. This is the file for your app (i.e., YourProduct.app) that is built when you click Xcode’s “run” button.

“Making an iOS app” involves working with these features in the typical, straightforward workflow:

• Storyboard your views by dragging and configuring graphicalobjects on a template

• Adding behaviors to the various widgets• Writing the classes as to define those behaviors (including

delegates)• Adding needed support files• Building and running the app• Iterating until you are satisfied with your app

This is all done within Xcode.

What’s Xcode?You can start developing functional, good-looking apps almost from the moment you download Xcode, Apple’s integrated development environment (IDE) for making iOS and Macintosh apps. Among other features, Xcode includes a source code editor, graphical user inter-face (GUI) editor (sometimes called Interface Builder), source code repository manager, compiler, and much more. iOS applications are typically developed by manipulating views graphically and by typing Objective-C code for the models and controllers.

To get Xcode, simply go to the App Store and download the applica-tion (it’s free). To do this, click on the App Store icon in your Mac’s dock, or visit https://itunes.apple.com/us/genre/ios/id36?mt=8

The app store will download and install Xcode in your Application folder. From Applications, double-click the Xcode icon to launch Xcode and you’ll see its splash screen (Figure 1). From there you can click on “Create a new Xcode project” to take you to a menu of several templates on which to base your application. Selecting a template opens an Xcode workspace pre-populated with frameworks and other files Xcode thinks you will need using that template.

Although you can develop, build and simulate your app on your computer in Xcode, you can’t run your app on a target device (even your own iPhone) until you become a registered iOS developer and join the iOS Developer Program. To do that, go to develop-er.app.com/ and navigate to the iOS Dev Center. While there, you will also find documentation, sample code and other useful resources such as information on how to submit your app to the iOS App Store.

Everything you do in Xcode is done in a window, called a workspace (Figure 2), consisting of multiple work areas, some of which are also divided into panes. All the files needed to build your app belong to a project, and the Navigator area (far left) lists all your projects (there can be several in a workspace) and all files for each project. Clicking on a file in the Navigator area shows its contents in the Editor area and invokes the appropriate editor. Clicking on a .h or .m file, for example, shows the file’s source code and invokes the Source editor, so you can edit the code. Clicking on .storyboard or .xib (sometimes called a “nib”) file shows the app’s storyboard and invokes the Inter-face Builder, so you can design a view using the Builder’s drag and drop features.

An especially handy feature is that the Editor area can have both a right and a left pane — with each pane aware of your edits in the other. So, for example, you can simultaneously edit an object’s .h

header file in the left pane and its corresponding .m in the right pane. Or you might click on a button object (displayed graphically) in the left pane and edit its method’s source code in the right pane. To toggle between a single pane (the “Standard Editor”) and double pane view (the “Assistant Editor”), use the Editor selector button on the right of the toolbar. You can option+command+click a symbol in the editor to open the definition in the opposite editor pane.

You can also resize the entire Editor area simply by dragging its borders. For even more editing space, you can also remove the Debug area or both the Debug and Utility areas using the View Selector button on the far right of the toolbar.

As its name suggests, the Debug area shows information, like variable state and console logs, helpful in debugging code.

The Utility area has two panes: the Inspector and Quick Help pane (top) and the Library pane (bottom). Although there are five inspectors — File, Help, Identity, Attributes, Size and Connec-tions — only the inspectors that are currently relevant appear in the Inspec-tor list at the top of the pane. (To see the name of an inspector, move the cursor over its icon in the Inspector selector bar.)

You will use inspectors to add and modify object attributes for views in the Interface Builder. For example, if you click on a UILabel in the Editor area of a storyboard, you can use the Attributes inspector to change the label’s color and use the Size inspector to change the label’s size.

The Help inspector shows help information about a selected class. Use the Identity inspector to view and manage an object’s metadata such as its class, runtime attributes, label and so forth. Use the

Connections inspector to view the outlets and actions of an interface object, to make new connections and to delete existing connections.

The Library pane has libraries of resources (like file templates, code snippets, interface objects and media files) that are prebuilt and ready to insert into your project. Use the Library selector to select which of these libraries (e.g., code snippets or interface objects) you wish to insert. To insert one, drag it directly into your storyboard while using the Interface Builder editor.

These are basics you need to know to get started using Xcode to build your first app. But to really understand how it’s done, it helps to walk through an actual app or two. Let’s start with a simple “Hello World” app that does not employ a backend connection, and then look at a somewhat more functional app that does.

“Hello World!” sample appThis app displays a button (“Press Me”) and a label (“Label”) so that when the user presses the button the text of the label changes to “Hello World!” as in Figure 3:

To get started, launch Xcode and select “Create a New Xcode Project.” From the iOS Application templates, select “Single View Application” and click “Next.” Fill in your product’s name and a company identifier, typically “com.yourCompanyName.” Deselect “Use Storyboards” and leave “Use Automatic Reference Counting” selected. Then click “Next” and select a destination for your projects files.

Follow these steps to make your app:

1. Select your project’s ViewController.xib file in the Navigator(Figure 4), to open the Interface Builder editor.

2. Drag a “Round Rect Button” from the Objects library (lowerright) onto the view in the Editor area; select the button’s textand type “Press Me.”

3. Drag a Label from the objects library onto the view, as well.4. Select and drag the Label sizing handles, centering the object

and making it wide enough to hold the “Hello World!” text; then,

5. With the “Hello World!” label still selected, click on centeralignment in the Attributes inspector.

6. Open the Assistant Editor (Figure 5), exposing the source codeheader file (ViewController.h) of the view controller you justbuilt graphically.

7. Select the button and control-drag from the button to justbelow the ViewController definition in the Assistant panel. Inthe form that opens, select “Action” for the connection type,type in a name (“showText”) and click “Connect.” This creates aninterface builder (IB) action as highlighted in Figure 6.

8. Next step is to create an outlet for the label. To do this, selectthe label object and control-drag from the label to just belowthe IB action you just created. Select “Outlet” as the connectiontype and enter a name “label” and click “Connect.” This createsan interface builder (IB) outlet as shown in Figure 7.

9. Finally, it’s time to add some logic to the view controller so itknows what to do when the button is pressed. To do this, select “ViewController.m” in the project navigator to show the code editor. Find the button’s IBAction you just created (near the bottom), place your cursor between the { } brackets and hit the return key a few times to create some extra space. Then in that space type the method for how you want the label you speci-fied to respond: _label.text=”Hello World!”; as highlighted in Figure 8.

Congratulations! Your app is done. To build and run your new app in the simulator, click the Xcode Run button in the left corner of the toolbar. When you click the button, the text will update.

Sample app with a backend This second app (named “Kinvey Test Drive”) lets the user type text on an iPhone and save the text to a backend service, like Kinvey. It also lets the user load text on the iPhone from their Kinvey backend. Reading about this app will help you learn:

• How to set up Kinvey’s library in an iOS project• Additional Interface Builder techniques you can use to story-board an application• How to add view controller logic to interact with the backend service, allowing you to save and retrieve data

We will first present the app as a running application and then take it apart so you can see how it was made. To make the app yourself, you can review the various sections below and replicate the steps in your copy of Xcode.

First, to see the app in action, you should download the app and run it on your system. To do that, sign up for Kinvey, then navigate to “Dev Center”, “Samples,” find the “Test Drive” app, and click on its icon. (If you can’t find it right away, make sure you select iOS as your platform on the right side of the menu bar.) Click the download button to download the app’s project files to your computer. Then launch Xcode — just double click on the .xcodeproj file in the project folder.

But before you can run the app, you need to set up the app’s Kinvey backend.

Set Up Kinvey as a Backend Data StoreTest Drive’s project files include all the code the sample app needs in order to talk to Kinvey. However, that would not be the case if you were to build an app from scratch — so you would have to go through an initial Kinvey setup procedure. This involves downloading the Kinvey library files from the downloads section of devcenter.kin-vey.com and dragging them to the Navigator’s Frameworks folder in Xcode. You also need to tell Xcode to link your project with additional iOS frameworks. To find these frameworks, click on the Project folder

at the very top of the Navigator pane — which displays the Project editor — and then select the “Build Settings” tab. For detailed instruc-tions, complete the “Getting Started” page under “Guides” on the Kinvey website. But again, you can skip this setup procedure for now in order to run the downloaded Kinvey Test Drive app.

But you must still do this step: To run any app that uses Kinvey (including Test Drive) you need to do the “Create an App” step on the Kinvey website. Click on “My Apps” in the Kinvey menu bar and then click on “Add an App,” which will open an “Add” page. Type in a name for your app and click on the Apple logo and then click “Create.” The page that opens shows your App’s credentials. Copy and paste the App Key and App Secret into the AppDelegate.m file of the download-ed Test Drive project:

You are now ready to run the app — click on the Xcode run button and wait for the simulator to open and the app to appear (Figure 9).

Clicking the “+” toolbar button opens an alert (Figure 10) with an empty field into which the user can type some text (e.g., “some new data”). Clicking “save” uploads the data to Kinvey and displays text on the screen (a table view) and also displays an alert that the save worked (Figure 11).

To test the load function, enter some data (e.g., “some data to load”) in the “name” field of the Kinvey collection. To see the load, the swipe down on the table on the phone until the refresh spinner starts, and then the new data will appear in the table (Figure 12).

Figure 13 shows the Kinvey collection after the save that Figure 10 depicts on the iPhone. Figure 14 shows the Kinvey collection after the user adds a new row to the testObjects collection using the web browser. Note that every time a save is done on the iPhone, Kinvey automatically adds a new row (displayed on a collection refresh). To add a new row manually in the browser, click “+ row,” and type some descriptive text in the “name” column. That data will now load on the iPhone when the user pulls down on the table.

Storyboard the Test Drive AppMost of the Test Drive user interface objects visible in the simulation are available in Xcode’s Object Library and can therefore be added to the view graphically. The UI objects consist of a:

• Table view• Toolbar• Tool Bar Button item – flexible space• Tool Bar Button item – Add• Table view cell• Label – Title• Refresh Control

To create this app yourself, you would follow these steps:

• Launch Xcode and select the “Single View Application” template• Select the “Use Storyboard” option• Replace the default UIviewcontroller object with a UITableView-Controller • Drag and drop the other objects, in the order listed, onto the UIviewcontroller

Also note:

• The Flexible Space Bar Button item fills up the space on the toolbar so the add button is at the right. This is a standard pattern in table-based iPhone apps.• The add button shows the system “+” sign. That is done by dragging a bar button item onto the toolbar, clicking on the Identifier drop down menu in the Attributes inspector; and then selecting the “Add” option.

As with the “Hello World!” app, once your app’s view is complete (Figure 15), you would still have to create the various methods and connections that bring them to life. This is done using the Source editor while working with the ViewController.m file.

Add View Controller LogicSince the app performs two basic operations (save data to Kinvey and load data from Kinvey) these two methods must be added to the ViewController header file. That’s done with a control-drag from the “+” bar button over to just under the “@ interface ViewController” line in ViewController.h. (Open the Assistant editor to see both the storyboard and the file source.)

During the drag, the popup appears, asking for the name and type of connection. Enter “action” for the connection type and “add” for the name. Then repeat the drag, this time from the refresh control and using “add” for the name (Figure 16).

Note: to follow this discussion it will help to have the referenced files open in your Xcode Source editor.

In ViewController.m, you will see the implementation code associated with each of the two Interface Builder methods, whose names Xcode added automatically to the .m file:

- (IBAction)add:(id)sender- (IBAction)load:(id)sender

You will also see a third section of code not associated with these methods, which starts with the line: “#pragma mark - Table View Stuff.” These methods support the table view and are part of UITableViewD-elegate and UITableViewDataSource. They handle controlling the

display of the table, and respond to user gestures. For example, swiping a table cell will show the delete button because tableView:-canEditRowAtIndexPath: returns YES and tableView:editingStyleForRowA-tIndexPath: returns UITableViewCellEditingStyleDelete. If you tap the delete button, the delegate method tableView:commitEditingStyle:for-RowAtIndexPath: is called. The code of this method deletes the data for the row and removes it from Kinvey’s data store. When the backend delete is completed, the app displays an alert describing the success or failure.

The way that all three sections (and all Kinvey-enabled apps) move data in and out of a Kinvey collection is by getting a reference to the app’s backend collection (named “testObjects”), which is filled with instances (each named “TestObject”) of the data the app wants to move. That’s why you’ll find the following code repeated three times in Test Drive’s View Controller (once for the add, once for the load, and once for the delete):

To support these statements it is required to have a data object class (TestObject). To see how these files are written in the sample project, click on TestObject.h file and TestObject.m in the Navigator pane. If you were to supply these files in your own app, you would click File > New File, and specify Objective-C class, which would be a subclass of NSObject. Then you would type in the code, with a property for each column in the Kinvey backend collection (including one for the object’s id).

As mentioned earlier, your app also needs to authenticate itself to Kinvey, which is handled by AppDelegate.h and AppDelgate.m. These files are created by Xcode when you create a new project, and start out with just a stub implementation. Look in the sample app source

files for code to copy and paste.

For both the save and load operations, however, moving the data in and out of a backend collection is only part of the work. Table 1 lists all the functions that implements the save and load in the ViewCon-troller.m file, along with pointers to its corresponding block of imple-mentation source code. (For each function, its corresponding code begins with the “Starts at” line and ends with the “Ends at” line.) Refer to Appendix 1 to find the actual source code.

Say Hello To Our WorldThe key takeaway from all this is that “making an app” is a worthwhile thing to do for anyone with a clever idea and a working knowledge of Objective-C. The proof is in the hundreds of apps succeeding in the market every day, many written by people working on their own and who never wrote an app before in their lives. As with anything else, practice does make perfect. But hopefully with all the resources available, and the knowledge gained from this ebook, you have already started down the path toward joining the growing legions of iOS app developers. If so, we welcome you!

Appendix 1 — Test Drive Sample App ViewController.m Source Code

Why iOS?

$$$

Customers morewilling to pay

The Appleecosystem

All-in-oneIDE

{-X-}

The Appleexperience

Tablets

10

The iOS revolutionIt’s a story that never gets old. The weekend that iPad Minis and the fourth generation iPads went on sale (November 2-5, 2012) Apple sold over 3 million of the devices — a record for first-weekend iPad sales. Two months earlier the company had set another record: first weekend sales of over 5 million for the iPhone 5. Since the introduc-tion of the first iPhone back in 2007,

iOS-based devices (iPhone, iPad, iPad Mini and iPod Touch) continue to rewrite the definition of what constitutes a successful product. By the end of 2012, over 400 million iOS devices had been sold.

What makes iOS devices so successful? Innovation and product features are clearly a big part. Before the iPhone most people had not interacted with a multi-touch interface. They had never zoomed with a pinch or switched between portrait and landscape by merely rotating a device in their hand. Carrying a phone that knew where they were, could suggest places to eat, and could offer directions on how to get there was also a novel experience.

But features like multi-touch, accelerometers and GPS are only part of the appeal. Even with all its innovations, iOS still might not have taken off the way it has if the only people figuring out ways to use those innovations worked at Apple. Most of the capabilities available in an iPhone or iPad in fact don’t come from Apple at all. They come from legions of third-party developers who work in a vast ecosystem that is also an Apple innovation. That ecosystem includes the iPhone, iPad, iPad Mini, iPods, App Store, iTunes, ad networks — and that’s just on the consumer side. On the developer side, you have Xcode, App Loader, testing tools, iTunes Connect — the list goes on.

As of September 2012, the App Store hosted over 700,000 apps that have collectively been downloaded over 30 billion times. Apple reported for October 2012 that App Store monthly revenues were

running at $333 million — a rate of about $4 billion per year — remarkable for a store that only opened in July 2008.

Another innovation that has spurred iOS app development is “The Cloud.” Cloud services make it easier for independent developers to create, support and make money from their apps. The Cloud solves data storage and cross-device and user-to-user sharing problems. If an app stores data in the Cloud, that part of the application is called the “backend,” while the part of the app that runs on the phone and interacts with the user is called the “front end.”

A cloud may be “private” — i.e., the services belong to an organization for the benefit of its employees and business partners. Or a cloud may be “public” — i.e., a company (such as Amazon or Kinvey) owns the services, which developers can then integrate into their own apps. If you are a developer and want to build your own backend, you certainly can do that. Whether you want to or not depends on whether your backend provides functionality common to many different apps. If it does (as in a shopping cart or user authenti-cation) then perhaps that time and money would be better spent on features that offer unique value to your customer. You may be better off hooking into a commercial backend provider via an API. Then you can focus on what counts most — a unique user experience and application-specific functionality. That brings us to the first step in making an app.

Define your appMost unsuccessful apps fail for any of four reasons:

1. the app was a solution in search of a problem (i.e., no real need existed) 2. the implementation was poor 3. the app tried to do too much; or 4. the Apple App Store rejected the app (either because the implementation was poor or it violated Apple’s content policies)

Keeping the app as simple as possible is the best way to avoid these pitfalls. Most successful apps (indeed, most successful consumer tech products) are based on what is called an MVP, or minimum viable product. It’s the product with the smallest feature set that can deliver the core function without any distracting “bells and whistles.” You know you have an MVP if the product would no longer function if you removed any single feature.

But what should that core feature be? One of the best examples of an MVP is Mail. Version 1 (on the Mac) offered a clear, limited and intuitive feature set whose usefulness was immediately obvious to anyone. Today’s iPhone version integrates seamlessly with your phone, contacts and calendaring. It auto-matically corrects spelling as you type, lets you email photos directly from your photos app, and does much more. But all that came later and was built on top of a basic core function. And that’s how your first app should be built. The key is to come up with something with a clear value that changes people’s lives.

So, in drawing up your MVP feature list, ask yourself what features are key to the experience. Some basic market research is probably in order, starting with a visit to the App Store to see what already exists (possibly to be improved upon and/or to compete with you). Likely

must-have core capabilities include:

• Performance (e.g., fast screen refresh)• Offline capability (i.e., ability to work when not connected to the Internet)• Location awareness (e.g., the data/experience will change with the user’s location)• Cloud syncing (e.g., users see the same data on multiple devices)• Push notifications (i.e., sending updated information to devices as soon as it is available)

When you have a handle on what your app does, the next step is to design it. Designing your app involves making choices of how infor-mation and controls are presented to the user as well as how to implement app logic, and figuring out what data lives locally and what belongs in the Cloud.

Design your appUser experience decisions determine the app’s look and feel. They answer questions such as: What does the app look like? What screens does it have? In the software development world, onscreen objects like buttons, sliders, and fill-in boxes are called widgets. So you need to decide which types of widgets will reside on which screens. And what actions will occur as a result of the user interacting with those widgets?

Keep in mind that users will expect to interact differently with a mobile device than they do with a PC because the screens on mobile devices are much smaller. They’ll expect to use their fingers instead of a mouse or a track pad. Ideally, your app can even be used with one hand holding the device while using just a thumb for scrolling andworking the app’s other controls— the Path app is a good example, and increasingly, so is Facebook.

Your app’s features will inform its architecture, which is how you’ll divide the code and data into functional parts. If your app requires interacting with other app users or networked services, you’ll need to figure out what piece of the logic lives in the app code and what comes from the backend. For example, your app might integrate with a restau-rant recommendation engine, share user location, or pull real-time traffic data. This is done using APIs provided by various service providers — but you don’t have to wire up your app to a network to get started. You can develop a prototype using predefined representative (or “dummy”) data. It’s easier to fine-tune the front end if you don’t have to simultaneously modify your backend too. Once you get the app’s look-and-feel right, then make those backend connections.

Once you’ve got the overall concept for your app, the next step is to express that design in terms of the iOS app architecture. That archi-tecture is the model for what parts an iOS app can contain and how those parts fit together. It’s a well thought-out approach for translat-ing a product concept into actual code you can deploy on a device.

WHY iOS?Besides the features and design of your first app, there’s one more decision you need to make before you start actual development. That’s whether to deploy on Apple’s iOS platform or on Google’s Android platform. (Some of this is also covered in our ebook, How to Make an App: Android Edition.) Reasons to develop for iOS include:

Customers more willing to pay. Perhaps it’s because of Android’s open source heritage, but whatever the reason, Android apps gener-ate less than 10% of the total dollars spent on mobile apps, despite having 75% of the smartphone market itself — and despite the fact that the average selling price of an app in the Google Play is $3.79 versus Apple App Store’s $2.01. In other words, Apple users are much more willing to spend money on apps.

The Apple Ecosystem. Some developers and users prefer Apple’s closed and more tightly controlled environment. Apple’s ecosystem, consisting of Xcode, iCloud, iTunes, the App Store, the iPad, the iPhone, Mac computers, etc., offers a very holistic user experience with the ability to share data seamlessly across devices plus the

assurance of having applications pre-approved for quality and content prior to going on sale.

Xcode. Apple’s all-in-one IDE offers state-of-the-art offers features like a graphical interface builder and a syntax-aware and compiler-aware source editor.

The Apple Experience. From the fit and finish of its hardware to the customer service in its retail stores, to the way its hardware and software work flawlessly together, Apple has created the premium brand in consumer electronics. iOS developers share the benefits — so when someone downloads your iOS app, they already expect it’s a great product. And that it will also work flawlessly on their device.

Tablets. iOS has a clear advantage over Android in terms of tablet market adoption. Using Xcode, it’s also much easier to migrate an app from a phone to a tablet and vice versa than it is when develop-ing for Android.

Why Not iOS?Although iOS offers many compelling advantages as a platform for your mobile app, it also comes with some disadvantages. Here are three:

Closed Platform. iOS apps only run on Apple products so you can’t take advantage of features (like NFC) available only on non-iOS devices or market growth of non-iOS devices.

Market Growth. Today, iOS represents less than 15% of the total smartphone market, Although the total market (“the whole pie”) is still increasing at a fast rate, Android market growth outpaces iOS growth.

Approvals. The App Store’s app approval process is notoriously more time consuming than Google Play’s process.

The iOS app architectureAs noted earlier, a key reason why there are so many apps for iOS is because developing highly functional, polished apps for the platform is relatively easy. That’s mainly because of: 1) the design of the development tools, and 2) the key architectural features most iOS apps have in common. So let’s start with some concepts since it helps to know what goes into an app before trying to create one. We’ll begin with:

• Design patterns• Frameworks• Delegation• Storyboard• Windows• Outlets• Supporting files• Products

Design patterns. iOS apps implement what is known as a Mod-el-View-Controller (MVC) pattern. A pattern is a common way to structure code that solves a particular design problem. The MVC pattern separates application code in a way that allows you to easily change one part of an app without having to change other parts. An MVC pattern consists of three components:

• The Model is the logic that acts on the data, such as to store or retrieve data from a database, compute the distance between two cities on a map, etc. An example of a model is the Kinvey backend that stores your data in the Cloud as a service.

• The View provides the interface to the user; it displays the data and widgets (e.g., buttons and text fields) that allow the user to interact with the data. An iPhone app may have more than one view, as in the Contacts app, which displays a list view of all contacts or alternatively a view of each individual contact.

• The Controller is between the model and the view — i.e., it responds to user requests (made in a view) and retrieves results

(produced in a model). This is where developers spend most of their time — constructing the View Controller — by defining and attaching actions (or behaviors) to onscreen widgets. When the user taps a button, for example, it is the View Controller that determines what action will occur, such as retrieve stored data from your Kinvey-based data store. The link between a view object (like a button) to a controller action is called a connection.

Frameworks. You don’t actually have to write most of an app’s logic. It already exists as frameworks. A framework is a collection of classes that implements some function — such as connecting to the Internet, drawing a button, etc. Rather than write the code from scratch, you just use the frameworks supplied by iOS. Some frameworks are automatically present when you start a new project while others may need to be added (done via a drop down menu in Xcode’s Project Editor).

Delegation. Say, you want to customize the behavior of a framework’s object. You can’t actually modify the code of the framework class itself (prohibited since other apps may also use the framework). But what you can do is provide app-specific behavior in an application delegate object. If a delegate implements a method, it will be called by the delegating class to modify its behavior. In the Kinvey sample app (one of two examples we will be describing below), the AppDele-gate.h and AppDelegate.m — the header and implementation files for the UIApplicationDelegate, respectively — contain the code that authenticates an app to the Kinvey backend service.

Storyboards and XIBs. The MainStoryboard.storyboard file (or a .xib file, if you did not click on the “Use Storyboard” option when starting your project) contains the view information needed to implement the overall flow and display of your application and the user interface elements.

Windows. Each view (e.g., the contact list and individual contact details in the Contacts app) exists within a window. The window represents the entire device screen and is where all your views are presented.

Outlets. A variable by which a view object can be referenced in a controller. (For example, if you place a text field to capture a user's name, you might create an outlet called UITextField* nameField.)

Supporting files. These are files that provide resources (like PNG images and other static data) that your app needs as well as files that configure how the app will run. Other examples:

.pch files — precompiled headers used for the code files in your project.

.plist files — property lists that are small amounts of persistent data (like your app’s default user settings) consisting primarily of strings and numbers that you want your app to be able to access, modify if needed, and write back into the property list.

main.m file — your app’s main function. This is needed to launch the app, but you will not need to modify this file.

InfoPlist.strings file — used for localization.

Products. This is the file for your app (i.e., YourProduct.app) that is built when you click Xcode’s “run” button.

“Making an iOS app” involves working with these features in the typical, straightforward workflow:

• Storyboard your views by dragging and configuring graphicalobjects on a template

• Adding behaviors to the various widgets• Writing the classes as to define those behaviors (including

delegates)• Adding needed support files• Building and running the app• Iterating until you are satisfied with your app

This is all done within Xcode.

What’s Xcode?You can start developing functional, good-looking apps almost from the moment you download Xcode, Apple’s integrated development environment (IDE) for making iOS and Macintosh apps. Among other features, Xcode includes a source code editor, graphical user inter-face (GUI) editor (sometimes called Interface Builder), source code repository manager, compiler, and much more. iOS applications are typically developed by manipulating views graphically and by typing Objective-C code for the models and controllers.

To get Xcode, simply go to the App Store and download the applica-tion (it’s free). To do this, click on the App Store icon in your Mac’s dock, or visit https://itunes.apple.com/us/genre/ios/id36?mt=8

The app store will download and install Xcode in your Application folder. From Applications, double-click the Xcode icon to launch Xcode and you’ll see its splash screen (Figure 1). From there you can click on “Create a new Xcode project” to take you to a menu of several templates on which to base your application. Selecting a template opens an Xcode workspace pre-populated with frameworks and other files Xcode thinks you will need using that template.

Although you can develop, build and simulate your app on your computer in Xcode, you can’t run your app on a target device (even your own iPhone) until you become a registered iOS developer and join the iOS Developer Program. To do that, go to develop-er.app.com/ and navigate to the iOS Dev Center. While there, you will also find documentation, sample code and other useful resources such as information on how to submit your app to the iOS App Store.

Everything you do in Xcode is done in a window, called a workspace (Figure 2), consisting of multiple work areas, some of which are also divided into panes. All the files needed to build your app belong to a project, and the Navigator area (far left) lists all your projects (there can be several in a workspace) and all files for each project. Clicking on a file in the Navigator area shows its contents in the Editor area and invokes the appropriate editor. Clicking on a .h or .m file, for example, shows the file’s source code and invokes the Source editor, so you can edit the code. Clicking on .storyboard or .xib (sometimes called a “nib”) file shows the app’s storyboard and invokes the Inter-face Builder, so you can design a view using the Builder’s drag and drop features.

An especially handy feature is that the Editor area can have both a right and a left pane — with each pane aware of your edits in the other. So, for example, you can simultaneously edit an object’s .h

header file in the left pane and its corresponding .m in the right pane. Or you might click on a button object (displayed graphically) in the left pane and edit its method’s source code in the right pane. To toggle between a single pane (the “Standard Editor”) and double pane view (the “Assistant Editor”), use the Editor selector button on the right of the toolbar. You can option+command+click a symbol in the editor to open the definition in the opposite editor pane.

You can also resize the entire Editor area simply by dragging its borders. For even more editing space, you can also remove the Debug area or both the Debug and Utility areas using the View Selector button on the far right of the toolbar.

As its name suggests, the Debug area shows information, like variable state and console logs, helpful in debugging code.

The Utility area has two panes: the Inspector and Quick Help pane (top) and the Library pane (bottom). Although there are five inspectors — File, Help, Identity, Attributes, Size and Connec-tions — only the inspectors that are currently relevant appear in the Inspec-tor list at the top of the pane. (To see the name of an inspector, move the cursor over its icon in the Inspector selector bar.)

You will use inspectors to add and modify object attributes for views in the Interface Builder. For example, if you click on a UILabel in the Editor area of a storyboard, you can use the Attributes inspector to change the label’s color and use the Size inspector to change the label’s size.

The Help inspector shows help information about a selected class. Use the Identity inspector to view and manage an object’s metadata such as its class, runtime attributes, label and so forth. Use the

Connections inspector to view the outlets and actions of an interface object, to make new connections and to delete existing connections.

The Library pane has libraries of resources (like file templates, code snippets, interface objects and media files) that are prebuilt and ready to insert into your project. Use the Library selector to select which of these libraries (e.g., code snippets or interface objects) you wish to insert. To insert one, drag it directly into your storyboard while using the Interface Builder editor.

These are basics you need to know to get started using Xcode to build your first app. But to really understand how it’s done, it helps to walk through an actual app or two. Let’s start with a simple “Hello World” app that does not employ a backend connection, and then look at a somewhat more functional app that does.

“Hello World!” sample appThis app displays a button (“Press Me”) and a label (“Label”) so that when the user presses the button the text of the label changes to “Hello World!” as in Figure 3:

To get started, launch Xcode and select “Create a New Xcode Project.” From the iOS Application templates, select “Single View Application” and click “Next.” Fill in your product’s name and a company identifier, typically “com.yourCompanyName.” Deselect “Use Storyboards” and leave “Use Automatic Reference Counting” selected. Then click “Next” and select a destination for your projects files.

Follow these steps to make your app:

1. Select your project’s ViewController.xib file in the Navigator(Figure 4), to open the Interface Builder editor.

2. Drag a “Round Rect Button” from the Objects library (lowerright) onto the view in the Editor area; select the button’s textand type “Press Me.”

3. Drag a Label from the objects library onto the view, as well.4. Select and drag the Label sizing handles, centering the object

and making it wide enough to hold the “Hello World!” text; then,

5. With the “Hello World!” label still selected, click on centeralignment in the Attributes inspector.

6. Open the Assistant Editor (Figure 5), exposing the source codeheader file (ViewController.h) of the view controller you justbuilt graphically.

7. Select the button and control-drag from the button to justbelow the ViewController definition in the Assistant panel. Inthe form that opens, select “Action” for the connection type,type in a name (“showText”) and click “Connect.” This creates aninterface builder (IB) action as highlighted in Figure 6.

8. Next step is to create an outlet for the label. To do this, selectthe label object and control-drag from the label to just belowthe IB action you just created. Select “Outlet” as the connectiontype and enter a name “label” and click “Connect.” This createsan interface builder (IB) outlet as shown in Figure 7.

9. Finally, it’s time to add some logic to the view controller so itknows what to do when the button is pressed. To do this, select “ViewController.m” in the project navigator to show the code editor. Find the button’s IBAction you just created (near the bottom), place your cursor between the { } brackets and hit the return key a few times to create some extra space. Then in that space type the method for how you want the label you speci-fied to respond: _label.text=”Hello World!”; as highlighted in Figure 8.

Congratulations! Your app is done. To build and run your new app in the simulator, click the Xcode Run button in the left corner of the toolbar. When you click the button, the text will update.

Sample app with a backend This second app (named “Kinvey Test Drive”) lets the user type text on an iPhone and save the text to a backend service, like Kinvey. It also lets the user load text on the iPhone from their Kinvey backend. Reading about this app will help you learn:

• How to set up Kinvey’s library in an iOS project• Additional Interface Builder techniques you can use to story-board an application• How to add view controller logic to interact with the backend service, allowing you to save and retrieve data

We will first present the app as a running application and then take it apart so you can see how it was made. To make the app yourself, you can review the various sections below and replicate the steps in your copy of Xcode.

First, to see the app in action, you should download the app and run it on your system. To do that, sign up for Kinvey, then navigate to “Dev Center”, “Samples,” find the “Test Drive” app, and click on its icon. (If you can’t find it right away, make sure you select iOS as your platform on the right side of the menu bar.) Click the download button to download the app’s project files to your computer. Then launch Xcode — just double click on the .xcodeproj file in the project folder.

But before you can run the app, you need to set up the app’s Kinvey backend.

Set Up Kinvey as a Backend Data StoreTest Drive’s project files include all the code the sample app needs in order to talk to Kinvey. However, that would not be the case if you were to build an app from scratch — so you would have to go through an initial Kinvey setup procedure. This involves downloading the Kinvey library files from the downloads section of devcenter.kin-vey.com and dragging them to the Navigator’s Frameworks folder in Xcode. You also need to tell Xcode to link your project with additional iOS frameworks. To find these frameworks, click on the Project folder

at the very top of the Navigator pane — which displays the Project editor — and then select the “Build Settings” tab. For detailed instruc-tions, complete the “Getting Started” page under “Guides” on the Kinvey website. But again, you can skip this setup procedure for now in order to run the downloaded Kinvey Test Drive app.

But you must still do this step: To run any app that uses Kinvey (including Test Drive) you need to do the “Create an App” step on the Kinvey website. Click on “My Apps” in the Kinvey menu bar and then click on “Add an App,” which will open an “Add” page. Type in a name for your app and click on the Apple logo and then click “Create.” The page that opens shows your App’s credentials. Copy and paste the App Key and App Secret into the AppDelegate.m file of the download-ed Test Drive project:

You are now ready to run the app — click on the Xcode run button and wait for the simulator to open and the app to appear (Figure 9).

Clicking the “+” toolbar button opens an alert (Figure 10) with an empty field into which the user can type some text (e.g., “some new data”). Clicking “save” uploads the data to Kinvey and displays text on the screen (a table view) and also displays an alert that the save worked (Figure 11).

To test the load function, enter some data (e.g., “some data to load”) in the “name” field of the Kinvey collection. To see the load, the swipe down on the table on the phone until the refresh spinner starts, and then the new data will appear in the table (Figure 12).

Figure 13 shows the Kinvey collection after the save that Figure 10 depicts on the iPhone. Figure 14 shows the Kinvey collection after the user adds a new row to the testObjects collection using the web browser. Note that every time a save is done on the iPhone, Kinvey automatically adds a new row (displayed on a collection refresh). To add a new row manually in the browser, click “+ row,” and type some descriptive text in the “name” column. That data will now load on the iPhone when the user pulls down on the table.

Storyboard the Test Drive AppMost of the Test Drive user interface objects visible in the simulation are available in Xcode’s Object Library and can therefore be added to the view graphically. The UI objects consist of a:

• Table view• Toolbar• Tool Bar Button item – flexible space• Tool Bar Button item – Add• Table view cell• Label – Title• Refresh Control

To create this app yourself, you would follow these steps:

• Launch Xcode and select the “Single View Application” template• Select the “Use Storyboard” option• Replace the default UIviewcontroller object with a UITableView-Controller • Drag and drop the other objects, in the order listed, onto the UIviewcontroller

Also note:

• The Flexible Space Bar Button item fills up the space on the toolbar so the add button is at the right. This is a standard pattern in table-based iPhone apps.• The add button shows the system “+” sign. That is done by dragging a bar button item onto the toolbar, clicking on the Identifier drop down menu in the Attributes inspector; and then selecting the “Add” option.

As with the “Hello World!” app, once your app’s view is complete (Figure 15), you would still have to create the various methods and connections that bring them to life. This is done using the Source editor while working with the ViewController.m file.

Add View Controller LogicSince the app performs two basic operations (save data to Kinvey and load data from Kinvey) these two methods must be added to the ViewController header file. That’s done with a control-drag from the “+” bar button over to just under the “@ interface ViewController” line in ViewController.h. (Open the Assistant editor to see both the storyboard and the file source.)

During the drag, the popup appears, asking for the name and type of connection. Enter “action” for the connection type and “add” for the name. Then repeat the drag, this time from the refresh control and using “add” for the name (Figure 16).

Note: to follow this discussion it will help to have the referenced files open in your Xcode Source editor.

In ViewController.m, you will see the implementation code associated with each of the two Interface Builder methods, whose names Xcode added automatically to the .m file:

- (IBAction)add:(id)sender- (IBAction)load:(id)sender

You will also see a third section of code not associated with these methods, which starts with the line: “#pragma mark - Table View Stuff.” These methods support the table view and are part of UITableViewD-elegate and UITableViewDataSource. They handle controlling the

display of the table, and respond to user gestures. For example, swiping a table cell will show the delete button because tableView:-canEditRowAtIndexPath: returns YES and tableView:editingStyleForRowA-tIndexPath: returns UITableViewCellEditingStyleDelete. If you tap the delete button, the delegate method tableView:commitEditingStyle:for-RowAtIndexPath: is called. The code of this method deletes the data for the row and removes it from Kinvey’s data store. When the backend delete is completed, the app displays an alert describing the success or failure.

The way that all three sections (and all Kinvey-enabled apps) move data in and out of a Kinvey collection is by getting a reference to the app’s backend collection (named “testObjects”), which is filled with instances (each named “TestObject”) of the data the app wants to move. That’s why you’ll find the following code repeated three times in Test Drive’s View Controller (once for the add, once for the load, and once for the delete):

To support these statements it is required to have a data object class (TestObject). To see how these files are written in the sample project, click on TestObject.h file and TestObject.m in the Navigator pane. If you were to supply these files in your own app, you would click File > New File, and specify Objective-C class, which would be a subclass of NSObject. Then you would type in the code, with a property for each column in the Kinvey backend collection (including one for the object’s id).

As mentioned earlier, your app also needs to authenticate itself to Kinvey, which is handled by AppDelegate.h and AppDelgate.m. These files are created by Xcode when you create a new project, and start out with just a stub implementation. Look in the sample app source

files for code to copy and paste.

For both the save and load operations, however, moving the data in and out of a backend collection is only part of the work. Table 1 lists all the functions that implements the save and load in the ViewCon-troller.m file, along with pointers to its corresponding block of imple-mentation source code. (For each function, its corresponding code begins with the “Starts at” line and ends with the “Ends at” line.) Refer to Appendix 1 to find the actual source code.

Say Hello To Our WorldThe key takeaway from all this is that “making an app” is a worthwhile thing to do for anyone with a clever idea and a working knowledge of Objective-C. The proof is in the hundreds of apps succeeding in the market every day, many written by people working on their own and who never wrote an app before in their lives. As with anything else, practice does make perfect. But hopefully with all the resources available, and the knowledge gained from this ebook, you have already started down the path toward joining the growing legions of iOS app developers. If so, we welcome you!

Appendix 1 — Test Drive Sample App ViewController.m Source Code

Why NOT iOS?

Closedplatform

Marketgrowth

Approvals

11

The iOS revolutionIt’s a story that never gets old. The weekend that iPad Minis and the fourth generation iPads went on sale (November 2-5, 2012) Apple sold over 3 million of the devices — a record for first-weekend iPad sales. Two months earlier the company had set another record: first weekend sales of over 5 million for the iPhone 5. Since the introduc-tion of the first iPhone back in 2007,

iOS-based devices (iPhone, iPad, iPad Mini and iPod Touch) continue to rewrite the definition of what constitutes a successful product. By the end of 2012, over 400 million iOS devices had been sold.

What makes iOS devices so successful? Innovation and product features are clearly a big part. Before the iPhone most people had not interacted with a multi-touch interface. They had never zoomed with a pinch or switched between portrait and landscape by merely rotating a device in their hand. Carrying a phone that knew where they were, could suggest places to eat, and could offer directions on how to get there was also a novel experience.

But features like multi-touch, accelerometers and GPS are only part of the appeal. Even with all its innovations, iOS still might not have taken off the way it has if the only people figuring out ways to use those innovations worked at Apple. Most of the capabilities available in an iPhone or iPad in fact don’t come from Apple at all. They come from legions of third-party developers who work in a vast ecosystem that is also an Apple innovation. That ecosystem includes the iPhone, iPad, iPad Mini, iPods, App Store, iTunes, ad networks — and that’s just on the consumer side. On the developer side, you have Xcode, App Loader, testing tools, iTunes Connect — the list goes on.

As of September 2012, the App Store hosted over 700,000 apps that have collectively been downloaded over 30 billion times. Apple reported for October 2012 that App Store monthly revenues were

running at $333 million — a rate of about $4 billion per year — remarkable for a store that only opened in July 2008.

Another innovation that has spurred iOS app development is “The Cloud.” Cloud services make it easier for independent developers to create, support and make money from their apps. The Cloud solves data storage and cross-device and user-to-user sharing problems. If an app stores data in the Cloud, that part of the application is called the “backend,” while the part of the app that runs on the phone and interacts with the user is called the “front end.”

A cloud may be “private” — i.e., the services belong to an organization for the benefit of its employees and business partners. Or a cloud may be “public” — i.e., a company (such as Amazon or Kinvey) owns the services, which developers can then integrate into their own apps. If you are a developer and want to build your own backend, you certainly can do that. Whether you want to or not depends on whether your backend provides functionality common to many different apps. If it does (as in a shopping cart or user authenti-cation) then perhaps that time and money would be better spent on features that offer unique value to your customer. You may be better off hooking into a commercial backend provider via an API. Then you can focus on what counts most — a unique user experience and application-specific functionality. That brings us to the first step in making an app.

Define your appMost unsuccessful apps fail for any of four reasons:

1. the app was a solution in search of a problem (i.e., no real need existed) 2. the implementation was poor 3. the app tried to do too much; or 4. the Apple App Store rejected the app (either because the implementation was poor or it violated Apple’s content policies)

Keeping the app as simple as possible is the best way to avoid these pitfalls. Most successful apps (indeed, most successful consumer tech products) are based on what is called an MVP, or minimum viable product. It’s the product with the smallest feature set that can deliver the core function without any distracting “bells and whistles.” You know you have an MVP if the product would no longer function if you removed any single feature.

But what should that core feature be? One of the best examples of an MVP is Mail. Version 1 (on the Mac) offered a clear, limited and intuitive feature set whose usefulness was immediately obvious to anyone. Today’s iPhone version integrates seamlessly with your phone, contacts and calendaring. It auto-matically corrects spelling as you type, lets you email photos directly from your photos app, and does much more. But all that came later and was built on top of a basic core function. And that’s how your first app should be built. The key is to come up with something with a clear value that changes people’s lives.

So, in drawing up your MVP feature list, ask yourself what features are key to the experience. Some basic market research is probably in order, starting with a visit to the App Store to see what already exists (possibly to be improved upon and/or to compete with you). Likely

must-have core capabilities include:

• Performance (e.g., fast screen refresh)• Offline capability (i.e., ability to work when not connected to the Internet)• Location awareness (e.g., the data/experience will change with the user’s location)• Cloud syncing (e.g., users see the same data on multiple devices)• Push notifications (i.e., sending updated information to devices as soon as it is available)

When you have a handle on what your app does, the next step is to design it. Designing your app involves making choices of how infor-mation and controls are presented to the user as well as how to implement app logic, and figuring out what data lives locally and what belongs in the Cloud.

Design your appUser experience decisions determine the app’s look and feel. They answer questions such as: What does the app look like? What screens does it have? In the software development world, onscreen objects like buttons, sliders, and fill-in boxes are called widgets. So you need to decide which types of widgets will reside on which screens. And what actions will occur as a result of the user interacting with those widgets?

Keep in mind that users will expect to interact differently with a mobile device than they do with a PC because the screens on mobile devices are much smaller. They’ll expect to use their fingers instead of a mouse or a track pad. Ideally, your app can even be used with one hand holding the device while using just a thumb for scrolling andworking the app’s other controls— the Path app is a good example, and increasingly, so is Facebook.

Your app’s features will inform its architecture, which is how you’ll divide the code and data into functional parts. If your app requires interacting with other app users or networked services, you’ll need to figure out what piece of the logic lives in the app code and what comes from the backend. For example, your app might integrate with a restau-rant recommendation engine, share user location, or pull real-time traffic data. This is done using APIs provided by various service providers — but you don’t have to wire up your app to a network to get started. You can develop a prototype using predefined representative (or “dummy”) data. It’s easier to fine-tune the front end if you don’t have to simultaneously modify your backend too. Once you get the app’s look-and-feel right, then make those backend connections.

Once you’ve got the overall concept for your app, the next step is to express that design in terms of the iOS app architecture. That archi-tecture is the model for what parts an iOS app can contain and how those parts fit together. It’s a well thought-out approach for translat-ing a product concept into actual code you can deploy on a device.

WHY iOS?Besides the features and design of your first app, there’s one more decision you need to make before you start actual development. That’s whether to deploy on Apple’s iOS platform or on Google’s Android platform. (Some of this is also covered in our ebook, How to Make an App: Android Edition.) Reasons to develop for iOS include:

Customers more willing to pay. Perhaps it’s because of Android’s open source heritage, but whatever the reason, Android apps gener-ate less than 10% of the total dollars spent on mobile apps, despite having 75% of the smartphone market itself — and despite the fact that the average selling price of an app in the Google Play is $3.79 versus Apple App Store’s $2.01. In other words, Apple users are much more willing to spend money on apps.

The Apple Ecosystem. Some developers and users prefer Apple’s closed and more tightly controlled environment. Apple’s ecosystem, consisting of Xcode, iCloud, iTunes, the App Store, the iPad, the iPhone, Mac computers, etc., offers a very holistic user experience with the ability to share data seamlessly across devices plus the

assurance of having applications pre-approved for quality and content prior to going on sale.

Xcode. Apple’s all-in-one IDE offers state-of-the-art offers features like a graphical interface builder and a syntax-aware and compiler-aware source editor.

The Apple Experience. From the fit and finish of its hardware to the customer service in its retail stores, to the way its hardware and software work flawlessly together, Apple has created the premium brand in consumer electronics. iOS developers share the benefits — so when someone downloads your iOS app, they already expect it’s a great product. And that it will also work flawlessly on their device.

Tablets. iOS has a clear advantage over Android in terms of tablet market adoption. Using Xcode, it’s also much easier to migrate an app from a phone to a tablet and vice versa than it is when develop-ing for Android.

Why Not iOS?Although iOS offers many compelling advantages as a platform for your mobile app, it also comes with some disadvantages. Here are three:

Closed Platform. iOS apps only run on Apple products so you can’t take advantage of features (like NFC) available only on non-iOS devices or market growth of non-iOS devices.

Market Growth. Today, iOS represents less than 15% of the total smartphone market, Although the total market (“the whole pie”) is still increasing at a fast rate, Android market growth outpaces iOS growth.

Approvals. The App Store’s app approval process is notoriously more time consuming than Google Play’s process.

The iOS app architectureAs noted earlier, a key reason why there are so many apps for iOS is because developing highly functional, polished apps for the platform is relatively easy. That’s mainly because of: 1) the design of the development tools, and 2) the key architectural features most iOS apps have in common. So let’s start with some concepts since it helps to know what goes into an app before trying to create one. We’ll begin with:

• Design patterns• Frameworks• Delegation• Storyboard• Windows• Outlets• Supporting files• Products

Design patterns. iOS apps implement what is known as a Mod-el-View-Controller (MVC) pattern. A pattern is a common way to structure code that solves a particular design problem. The MVC pattern separates application code in a way that allows you to easily change one part of an app without having to change other parts. An MVC pattern consists of three components:

• The Model is the logic that acts on the data, such as to store or retrieve data from a database, compute the distance between two cities on a map, etc. An example of a model is the Kinvey backend that stores your data in the Cloud as a service.

• The View provides the interface to the user; it displays the data and widgets (e.g., buttons and text fields) that allow the user to interact with the data. An iPhone app may have more than one view, as in the Contacts app, which displays a list view of all contacts or alternatively a view of each individual contact.

• The Controller is between the model and the view — i.e., it responds to user requests (made in a view) and retrieves results

(produced in a model). This is where developers spend most of their time — constructing the View Controller — by defining and attaching actions (or behaviors) to onscreen widgets. When the user taps a button, for example, it is the View Controller that determines what action will occur, such as retrieve stored data from your Kinvey-based data store. The link between a view object (like a button) to a controller action is called a connection.

Frameworks. You don’t actually have to write most of an app’s logic. It already exists as frameworks. A framework is a collection of classes that implements some function — such as connecting to the Internet, drawing a button, etc. Rather than write the code from scratch, you just use the frameworks supplied by iOS. Some frameworks are automatically present when you start a new project while others may need to be added (done via a drop down menu in Xcode’s Project Editor).

Delegation. Say, you want to customize the behavior of a framework’s object. You can’t actually modify the code of the framework class itself (prohibited since other apps may also use the framework). But what you can do is provide app-specific behavior in an application delegate object. If a delegate implements a method, it will be called by the delegating class to modify its behavior. In the Kinvey sample app (one of two examples we will be describing below), the AppDele-gate.h and AppDelegate.m — the header and implementation files for the UIApplicationDelegate, respectively — contain the code that authenticates an app to the Kinvey backend service.

Storyboards and XIBs. The MainStoryboard.storyboard file (or a .xib file, if you did not click on the “Use Storyboard” option when starting your project) contains the view information needed to implement the overall flow and display of your application and the user interface elements.

Windows. Each view (e.g., the contact list and individual contact details in the Contacts app) exists within a window. The window represents the entire device screen and is where all your views are presented.

Outlets. A variable by which a view object can be referenced in a controller. (For example, if you place a text field to capture a user's name, you might create an outlet called UITextField* nameField.)

Supporting files. These are files that provide resources (like PNG images and other static data) that your app needs as well as files that configure how the app will run. Other examples:

.pch files — precompiled headers used for the code files in your project.

.plist files — property lists that are small amounts of persistent data (like your app’s default user settings) consisting primarily of strings and numbers that you want your app to be able to access, modify if needed, and write back into the property list.

main.m file — your app’s main function. This is needed to launch the app, but you will not need to modify this file.

InfoPlist.strings file — used for localization.

Products. This is the file for your app (i.e., YourProduct.app) that is built when you click Xcode’s “run” button.

“Making an iOS app” involves working with these features in the typical, straightforward workflow:

• Storyboard your views by dragging and configuring graphicalobjects on a template

• Adding behaviors to the various widgets• Writing the classes as to define those behaviors (including

delegates)• Adding needed support files• Building and running the app• Iterating until you are satisfied with your app

This is all done within Xcode.

What’s Xcode?You can start developing functional, good-looking apps almost from the moment you download Xcode, Apple’s integrated development environment (IDE) for making iOS and Macintosh apps. Among other features, Xcode includes a source code editor, graphical user inter-face (GUI) editor (sometimes called Interface Builder), source code repository manager, compiler, and much more. iOS applications are typically developed by manipulating views graphically and by typing Objective-C code for the models and controllers.

To get Xcode, simply go to the App Store and download the applica-tion (it’s free). To do this, click on the App Store icon in your Mac’s dock, or visit https://itunes.apple.com/us/genre/ios/id36?mt=8

The app store will download and install Xcode in your Application folder. From Applications, double-click the Xcode icon to launch Xcode and you’ll see its splash screen (Figure 1). From there you can click on “Create a new Xcode project” to take you to a menu of several templates on which to base your application. Selecting a template opens an Xcode workspace pre-populated with frameworks and other files Xcode thinks you will need using that template.

Although you can develop, build and simulate your app on your computer in Xcode, you can’t run your app on a target device (even your own iPhone) until you become a registered iOS developer and join the iOS Developer Program. To do that, go to develop-er.app.com/ and navigate to the iOS Dev Center. While there, you will also find documentation, sample code and other useful resources such as information on how to submit your app to the iOS App Store.

Everything you do in Xcode is done in a window, called a workspace (Figure 2), consisting of multiple work areas, some of which are also divided into panes. All the files needed to build your app belong to a project, and the Navigator area (far left) lists all your projects (there can be several in a workspace) and all files for each project. Clicking on a file in the Navigator area shows its contents in the Editor area and invokes the appropriate editor. Clicking on a .h or .m file, for example, shows the file’s source code and invokes the Source editor, so you can edit the code. Clicking on .storyboard or .xib (sometimes called a “nib”) file shows the app’s storyboard and invokes the Inter-face Builder, so you can design a view using the Builder’s drag and drop features.

An especially handy feature is that the Editor area can have both a right and a left pane — with each pane aware of your edits in the other. So, for example, you can simultaneously edit an object’s .h

header file in the left pane and its corresponding .m in the right pane. Or you might click on a button object (displayed graphically) in the left pane and edit its method’s source code in the right pane. To toggle between a single pane (the “Standard Editor”) and double pane view (the “Assistant Editor”), use the Editor selector button on the right of the toolbar. You can option+command+click a symbol in the editor to open the definition in the opposite editor pane.

You can also resize the entire Editor area simply by dragging its borders. For even more editing space, you can also remove the Debug area or both the Debug and Utility areas using the View Selector button on the far right of the toolbar.

As its name suggests, the Debug area shows information, like variable state and console logs, helpful in debugging code.

The Utility area has two panes: the Inspector and Quick Help pane (top) and the Library pane (bottom). Although there are five inspectors — File, Help, Identity, Attributes, Size and Connec-tions — only the inspectors that are currently relevant appear in the Inspec-tor list at the top of the pane. (To see the name of an inspector, move the cursor over its icon in the Inspector selector bar.)

You will use inspectors to add and modify object attributes for views in the Interface Builder. For example, if you click on a UILabel in the Editor area of a storyboard, you can use the Attributes inspector to change the label’s color and use the Size inspector to change the label’s size.

The Help inspector shows help information about a selected class. Use the Identity inspector to view and manage an object’s metadata such as its class, runtime attributes, label and so forth. Use the

Connections inspector to view the outlets and actions of an interface object, to make new connections and to delete existing connections.

The Library pane has libraries of resources (like file templates, code snippets, interface objects and media files) that are prebuilt and ready to insert into your project. Use the Library selector to select which of these libraries (e.g., code snippets or interface objects) you wish to insert. To insert one, drag it directly into your storyboard while using the Interface Builder editor.

These are basics you need to know to get started using Xcode to build your first app. But to really understand how it’s done, it helps to walk through an actual app or two. Let’s start with a simple “Hello World” app that does not employ a backend connection, and then look at a somewhat more functional app that does.

“Hello World!” sample appThis app displays a button (“Press Me”) and a label (“Label”) so that when the user presses the button the text of the label changes to “Hello World!” as in Figure 3:

To get started, launch Xcode and select “Create a New Xcode Project.” From the iOS Application templates, select “Single View Application” and click “Next.” Fill in your product’s name and a company identifier, typically “com.yourCompanyName.” Deselect “Use Storyboards” and leave “Use Automatic Reference Counting” selected. Then click “Next” and select a destination for your projects files.

Follow these steps to make your app:

1. Select your project’s ViewController.xib file in the Navigator(Figure 4), to open the Interface Builder editor.

2. Drag a “Round Rect Button” from the Objects library (lowerright) onto the view in the Editor area; select the button’s textand type “Press Me.”

3. Drag a Label from the objects library onto the view, as well.4. Select and drag the Label sizing handles, centering the object

and making it wide enough to hold the “Hello World!” text; then,

5. With the “Hello World!” label still selected, click on centeralignment in the Attributes inspector.

6. Open the Assistant Editor (Figure 5), exposing the source codeheader file (ViewController.h) of the view controller you justbuilt graphically.

7. Select the button and control-drag from the button to justbelow the ViewController definition in the Assistant panel. Inthe form that opens, select “Action” for the connection type,type in a name (“showText”) and click “Connect.” This creates aninterface builder (IB) action as highlighted in Figure 6.

8. Next step is to create an outlet for the label. To do this, selectthe label object and control-drag from the label to just belowthe IB action you just created. Select “Outlet” as the connectiontype and enter a name “label” and click “Connect.” This createsan interface builder (IB) outlet as shown in Figure 7.

9. Finally, it’s time to add some logic to the view controller so itknows what to do when the button is pressed. To do this, select “ViewController.m” in the project navigator to show the code editor. Find the button’s IBAction you just created (near the bottom), place your cursor between the { } brackets and hit the return key a few times to create some extra space. Then in that space type the method for how you want the label you speci-fied to respond: _label.text=”Hello World!”; as highlighted in Figure 8.

Congratulations! Your app is done. To build and run your new app in the simulator, click the Xcode Run button in the left corner of the toolbar. When you click the button, the text will update.

Sample app with a backend This second app (named “Kinvey Test Drive”) lets the user type text on an iPhone and save the text to a backend service, like Kinvey. It also lets the user load text on the iPhone from their Kinvey backend. Reading about this app will help you learn:

• How to set up Kinvey’s library in an iOS project• Additional Interface Builder techniques you can use to story-board an application• How to add view controller logic to interact with the backend service, allowing you to save and retrieve data

We will first present the app as a running application and then take it apart so you can see how it was made. To make the app yourself, you can review the various sections below and replicate the steps in your copy of Xcode.

First, to see the app in action, you should download the app and run it on your system. To do that, sign up for Kinvey, then navigate to “Dev Center”, “Samples,” find the “Test Drive” app, and click on its icon. (If you can’t find it right away, make sure you select iOS as your platform on the right side of the menu bar.) Click the download button to download the app’s project files to your computer. Then launch Xcode — just double click on the .xcodeproj file in the project folder.

But before you can run the app, you need to set up the app’s Kinvey backend.

Set Up Kinvey as a Backend Data StoreTest Drive’s project files include all the code the sample app needs in order to talk to Kinvey. However, that would not be the case if you were to build an app from scratch — so you would have to go through an initial Kinvey setup procedure. This involves downloading the Kinvey library files from the downloads section of devcenter.kin-vey.com and dragging them to the Navigator’s Frameworks folder in Xcode. You also need to tell Xcode to link your project with additional iOS frameworks. To find these frameworks, click on the Project folder

at the very top of the Navigator pane — which displays the Project editor — and then select the “Build Settings” tab. For detailed instruc-tions, complete the “Getting Started” page under “Guides” on the Kinvey website. But again, you can skip this setup procedure for now in order to run the downloaded Kinvey Test Drive app.

But you must still do this step: To run any app that uses Kinvey (including Test Drive) you need to do the “Create an App” step on the Kinvey website. Click on “My Apps” in the Kinvey menu bar and then click on “Add an App,” which will open an “Add” page. Type in a name for your app and click on the Apple logo and then click “Create.” The page that opens shows your App’s credentials. Copy and paste the App Key and App Secret into the AppDelegate.m file of the download-ed Test Drive project:

You are now ready to run the app — click on the Xcode run button and wait for the simulator to open and the app to appear (Figure 9).

Clicking the “+” toolbar button opens an alert (Figure 10) with an empty field into which the user can type some text (e.g., “some new data”). Clicking “save” uploads the data to Kinvey and displays text on the screen (a table view) and also displays an alert that the save worked (Figure 11).

To test the load function, enter some data (e.g., “some data to load”) in the “name” field of the Kinvey collection. To see the load, the swipe down on the table on the phone until the refresh spinner starts, and then the new data will appear in the table (Figure 12).

Figure 13 shows the Kinvey collection after the save that Figure 10 depicts on the iPhone. Figure 14 shows the Kinvey collection after the user adds a new row to the testObjects collection using the web browser. Note that every time a save is done on the iPhone, Kinvey automatically adds a new row (displayed on a collection refresh). To add a new row manually in the browser, click “+ row,” and type some descriptive text in the “name” column. That data will now load on the iPhone when the user pulls down on the table.

Storyboard the Test Drive AppMost of the Test Drive user interface objects visible in the simulation are available in Xcode’s Object Library and can therefore be added to the view graphically. The UI objects consist of a:

• Table view• Toolbar• Tool Bar Button item – flexible space• Tool Bar Button item – Add• Table view cell• Label – Title• Refresh Control

To create this app yourself, you would follow these steps:

• Launch Xcode and select the “Single View Application” template• Select the “Use Storyboard” option• Replace the default UIviewcontroller object with a UITableView-Controller • Drag and drop the other objects, in the order listed, onto the UIviewcontroller

Also note:

• The Flexible Space Bar Button item fills up the space on the toolbar so the add button is at the right. This is a standard pattern in table-based iPhone apps.• The add button shows the system “+” sign. That is done by dragging a bar button item onto the toolbar, clicking on the Identifier drop down menu in the Attributes inspector; and then selecting the “Add” option.

As with the “Hello World!” app, once your app’s view is complete (Figure 15), you would still have to create the various methods and connections that bring them to life. This is done using the Source editor while working with the ViewController.m file.

Add View Controller LogicSince the app performs two basic operations (save data to Kinvey and load data from Kinvey) these two methods must be added to the ViewController header file. That’s done with a control-drag from the “+” bar button over to just under the “@ interface ViewController” line in ViewController.h. (Open the Assistant editor to see both the storyboard and the file source.)

During the drag, the popup appears, asking for the name and type of connection. Enter “action” for the connection type and “add” for the name. Then repeat the drag, this time from the refresh control and using “add” for the name (Figure 16).

Note: to follow this discussion it will help to have the referenced files open in your Xcode Source editor.

In ViewController.m, you will see the implementation code associated with each of the two Interface Builder methods, whose names Xcode added automatically to the .m file:

- (IBAction)add:(id)sender- (IBAction)load:(id)sender

You will also see a third section of code not associated with these methods, which starts with the line: “#pragma mark - Table View Stuff.” These methods support the table view and are part of UITableViewD-elegate and UITableViewDataSource. They handle controlling the

display of the table, and respond to user gestures. For example, swiping a table cell will show the delete button because tableView:-canEditRowAtIndexPath: returns YES and tableView:editingStyleForRowA-tIndexPath: returns UITableViewCellEditingStyleDelete. If you tap the delete button, the delegate method tableView:commitEditingStyle:for-RowAtIndexPath: is called. The code of this method deletes the data for the row and removes it from Kinvey’s data store. When the backend delete is completed, the app displays an alert describing the success or failure.

The way that all three sections (and all Kinvey-enabled apps) move data in and out of a Kinvey collection is by getting a reference to the app’s backend collection (named “testObjects”), which is filled with instances (each named “TestObject”) of the data the app wants to move. That’s why you’ll find the following code repeated three times in Test Drive’s View Controller (once for the add, once for the load, and once for the delete):

To support these statements it is required to have a data object class (TestObject). To see how these files are written in the sample project, click on TestObject.h file and TestObject.m in the Navigator pane. If you were to supply these files in your own app, you would click File > New File, and specify Objective-C class, which would be a subclass of NSObject. Then you would type in the code, with a property for each column in the Kinvey backend collection (including one for the object’s id).

As mentioned earlier, your app also needs to authenticate itself to Kinvey, which is handled by AppDelegate.h and AppDelgate.m. These files are created by Xcode when you create a new project, and start out with just a stub implementation. Look in the sample app source

files for code to copy and paste.

For both the save and load operations, however, moving the data in and out of a backend collection is only part of the work. Table 1 lists all the functions that implements the save and load in the ViewCon-troller.m file, along with pointers to its corresponding block of imple-mentation source code. (For each function, its corresponding code begins with the “Starts at” line and ends with the “Ends at” line.) Refer to Appendix 1 to find the actual source code.

Say Hello To Our WorldThe key takeaway from all this is that “making an app” is a worthwhile thing to do for anyone with a clever idea and a working knowledge of Objective-C. The proof is in the hundreds of apps succeeding in the market every day, many written by people working on their own and who never wrote an app before in their lives. As with anything else, practice does make perfect. But hopefully with all the resources available, and the knowledge gained from this ebook, you have already started down the path toward joining the growing legions of iOS app developers. If so, we welcome you!

Appendix 1 — Test Drive Sample App ViewController.m Source Code

iPad vs. iPhone

Of the over 700,000 iOS apps available in the App Store, 250,000 of them are specifically for iPad. Whether you develop for iPhone or iPad depends on a number of factors, including:

Screen Size. Most people do not want to watch a movie or read a book on a smartphone, so if your app is better suited for a larger screen, you should consider iPad.

Portability. On the other hand, if your app is something people are likely to use when they are “out and about,” such as when shopping, then iPhone may be your primary target.

Media. Because it is more portable, iPhone is a better device for taking pictures and video while iPad offers a better viewing and editing experience (again, because of screen size).

Consuming or Creating? As in the editing case, if your app is more about working with content than consuming it, you probably are better off developing for iPad.

12

The iOS revolutionIt’s a story that never gets old. The weekend that iPad Minis and the fourth generation iPads went on sale (November 2-5, 2012) Apple sold over 3 million of the devices — a record for first-weekend iPad sales. Two months earlier the company had set another record: first weekend sales of over 5 million for the iPhone 5. Since the introduc-tion of the first iPhone back in 2007,

iOS-based devices (iPhone, iPad, iPad Mini and iPod Touch) continue to rewrite the definition of what constitutes a successful product. By the end of 2012, over 400 million iOS devices had been sold.

What makes iOS devices so successful? Innovation and product features are clearly a big part. Before the iPhone most people had not interacted with a multi-touch interface. They had never zoomed with a pinch or switched between portrait and landscape by merely rotating a device in their hand. Carrying a phone that knew where they were, could suggest places to eat, and could offer directions on how to get there was also a novel experience.

But features like multi-touch, accelerometers and GPS are only part of the appeal. Even with all its innovations, iOS still might not have taken off the way it has if the only people figuring out ways to use those innovations worked at Apple. Most of the capabilities available in an iPhone or iPad in fact don’t come from Apple at all. They come from legions of third-party developers who work in a vast ecosystem that is also an Apple innovation. That ecosystem includes the iPhone, iPad, iPad Mini, iPods, App Store, iTunes, ad networks — and that’s just on the consumer side. On the developer side, you have Xcode, App Loader, testing tools, iTunes Connect — the list goes on.

As of September 2012, the App Store hosted over 700,000 apps that have collectively been downloaded over 30 billion times. Apple reported for October 2012 that App Store monthly revenues were

running at $333 million — a rate of about $4 billion per year — remarkable for a store that only opened in July 2008.

Another innovation that has spurred iOS app development is “The Cloud.” Cloud services make it easier for independent developers to create, support and make money from their apps. The Cloud solves data storage and cross-device and user-to-user sharing problems. If an app stores data in the Cloud, that part of the application is called the “backend,” while the part of the app that runs on the phone and interacts with the user is called the “front end.”

A cloud may be “private” — i.e., the services belong to an organization for the benefit of its employees and business partners. Or a cloud may be “public” — i.e., a company (such as Amazon or Kinvey) owns the services, which developers can then integrate into their own apps. If you are a developer and want to build your own backend, you certainly can do that. Whether you want to or not depends on whether your backend provides functionality common to many different apps. If it does (as in a shopping cart or user authenti-cation) then perhaps that time and money would be better spent on features that offer unique value to your customer. You may be better off hooking into a commercial backend provider via an API. Then you can focus on what counts most — a unique user experience and application-specific functionality. That brings us to the first step in making an app.

Define your appMost unsuccessful apps fail for any of four reasons:

1. the app was a solution in search of a problem (i.e., no real need existed) 2. the implementation was poor 3. the app tried to do too much; or 4. the Apple App Store rejected the app (either because the implementation was poor or it violated Apple’s content policies)

Keeping the app as simple as possible is the best way to avoid these pitfalls. Most successful apps (indeed, most successful consumer tech products) are based on what is called an MVP, or minimum viable product. It’s the product with the smallest feature set that can deliver the core function without any distracting “bells and whistles.” You know you have an MVP if the product would no longer function if you removed any single feature.

But what should that core feature be? One of the best examples of an MVP is Mail. Version 1 (on the Mac) offered a clear, limited and intuitive feature set whose usefulness was immediately obvious to anyone. Today’s iPhone version integrates seamlessly with your phone, contacts and calendaring. It auto-matically corrects spelling as you type, lets you email photos directly from your photos app, and does much more. But all that came later and was built on top of a basic core function. And that’s how your first app should be built. The key is to come up with something with a clear value that changes people’s lives.

So, in drawing up your MVP feature list, ask yourself what features are key to the experience. Some basic market research is probably in order, starting with a visit to the App Store to see what already exists (possibly to be improved upon and/or to compete with you). Likely

must-have core capabilities include:

• Performance (e.g., fast screen refresh)• Offline capability (i.e., ability to work when not connected to the Internet)• Location awareness (e.g., the data/experience will change with the user’s location)• Cloud syncing (e.g., users see the same data on multiple devices)• Push notifications (i.e., sending updated information to devices as soon as it is available)

When you have a handle on what your app does, the next step is to design it. Designing your app involves making choices of how infor-mation and controls are presented to the user as well as how to implement app logic, and figuring out what data lives locally and what belongs in the Cloud.

Design your appUser experience decisions determine the app’s look and feel. They answer questions such as: What does the app look like? What screens does it have? In the software development world, onscreen objects like buttons, sliders, and fill-in boxes are called widgets. So you need to decide which types of widgets will reside on which screens. And what actions will occur as a result of the user interacting with those widgets?

Keep in mind that users will expect to interact differently with a mobile device than they do with a PC because the screens on mobile devices are much smaller. They’ll expect to use their fingers instead of a mouse or a track pad. Ideally, your app can even be used with one hand holding the device while using just a thumb for scrolling andworking the app’s other controls— the Path app is a good example, and increasingly, so is Facebook.

Your app’s features will inform its architecture, which is how you’ll divide the code and data into functional parts. If your app requires interacting with other app users or networked services, you’ll need to figure out what piece of the logic lives in the app code and what comes from the backend. For example, your app might integrate with a restau-rant recommendation engine, share user location, or pull real-time traffic data. This is done using APIs provided by various service providers — but you don’t have to wire up your app to a network to get started. You can develop a prototype using predefined representative (or “dummy”) data. It’s easier to fine-tune the front end if you don’t have to simultaneously modify your backend too. Once you get the app’s look-and-feel right, then make those backend connections.

Once you’ve got the overall concept for your app, the next step is to express that design in terms of the iOS app architecture. That archi-tecture is the model for what parts an iOS app can contain and how those parts fit together. It’s a well thought-out approach for translat-ing a product concept into actual code you can deploy on a device.

WHY iOS?Besides the features and design of your first app, there’s one more decision you need to make before you start actual development. That’s whether to deploy on Apple’s iOS platform or on Google’s Android platform. (Some of this is also covered in our ebook, How to Make an App: Android Edition.) Reasons to develop for iOS include:

Customers more willing to pay. Perhaps it’s because of Android’s open source heritage, but whatever the reason, Android apps gener-ate less than 10% of the total dollars spent on mobile apps, despite having 75% of the smartphone market itself — and despite the fact that the average selling price of an app in the Google Play is $3.79 versus Apple App Store’s $2.01. In other words, Apple users are much more willing to spend money on apps.

The Apple Ecosystem. Some developers and users prefer Apple’s closed and more tightly controlled environment. Apple’s ecosystem, consisting of Xcode, iCloud, iTunes, the App Store, the iPad, the iPhone, Mac computers, etc., offers a very holistic user experience with the ability to share data seamlessly across devices plus the

assurance of having applications pre-approved for quality and content prior to going on sale.

Xcode. Apple’s all-in-one IDE offers state-of-the-art offers features like a graphical interface builder and a syntax-aware and compiler-aware source editor.

The Apple Experience. From the fit and finish of its hardware to the customer service in its retail stores, to the way its hardware and software work flawlessly together, Apple has created the premium brand in consumer electronics. iOS developers share the benefits — so when someone downloads your iOS app, they already expect it’s a great product. And that it will also work flawlessly on their device.

Tablets. iOS has a clear advantage over Android in terms of tablet market adoption. Using Xcode, it’s also much easier to migrate an app from a phone to a tablet and vice versa than it is when develop-ing for Android.

Why Not iOS?Although iOS offers many compelling advantages as a platform for your mobile app, it also comes with some disadvantages. Here are three:

Closed Platform. iOS apps only run on Apple products so you can’t take advantage of features (like NFC) available only on non-iOS devices or market growth of non-iOS devices.

Market Growth. Today, iOS represents less than 15% of the total smartphone market, Although the total market (“the whole pie”) is still increasing at a fast rate, Android market growth outpaces iOS growth.

Approvals. The App Store’s app approval process is notoriously more time consuming than Google Play’s process.

The iOS app architectureAs noted earlier, a key reason why there are so many apps for iOS is because developing highly functional, polished apps for the platform is relatively easy. That’s mainly because of: 1) the design of the development tools, and 2) the key architectural features most iOS apps have in common. So let’s start with some concepts since it helps to know what goes into an app before trying to create one. We’ll begin with:

• Design patterns• Frameworks• Delegation• Storyboard• Windows• Outlets• Supporting files• Products

Design patterns. iOS apps implement what is known as a Mod-el-View-Controller (MVC) pattern. A pattern is a common way to structure code that solves a particular design problem. The MVC pattern separates application code in a way that allows you to easily change one part of an app without having to change other parts. An MVC pattern consists of three components:

• The Model is the logic that acts on the data, such as to store or retrieve data from a database, compute the distance between two cities on a map, etc. An example of a model is the Kinvey backend that stores your data in the Cloud as a service.

• The View provides the interface to the user; it displays the data and widgets (e.g., buttons and text fields) that allow the user to interact with the data. An iPhone app may have more than one view, as in the Contacts app, which displays a list view of all contacts or alternatively a view of each individual contact.

• The Controller is between the model and the view — i.e., it responds to user requests (made in a view) and retrieves results

(produced in a model). This is where developers spend most of their time — constructing the View Controller — by defining and attaching actions (or behaviors) to onscreen widgets. When the user taps a button, for example, it is the View Controller that determines what action will occur, such as retrieve stored data from your Kinvey-based data store. The link between a view object (like a button) to a controller action is called a connection.

Frameworks. You don’t actually have to write most of an app’s logic. It already exists as frameworks. A framework is a collection of classes that implements some function — such as connecting to the Internet, drawing a button, etc. Rather than write the code from scratch, you just use the frameworks supplied by iOS. Some frameworks are automatically present when you start a new project while others may need to be added (done via a drop down menu in Xcode’s Project Editor).

Delegation. Say, you want to customize the behavior of a framework’s object. You can’t actually modify the code of the framework class itself (prohibited since other apps may also use the framework). But what you can do is provide app-specific behavior in an application delegate object. If a delegate implements a method, it will be called by the delegating class to modify its behavior. In the Kinvey sample app (one of two examples we will be describing below), the AppDele-gate.h and AppDelegate.m — the header and implementation files for the UIApplicationDelegate, respectively — contain the code that authenticates an app to the Kinvey backend service.

Storyboards and XIBs. The MainStoryboard.storyboard file (or a .xib file, if you did not click on the “Use Storyboard” option when starting your project) contains the view information needed to implement the overall flow and display of your application and the user interface elements.

Windows. Each view (e.g., the contact list and individual contact details in the Contacts app) exists within a window. The window represents the entire device screen and is where all your views are presented.

Outlets. A variable by which a view object can be referenced in a controller. (For example, if you place a text field to capture a user's name, you might create an outlet called UITextField* nameField.)

Supporting files. These are files that provide resources (like PNG images and other static data) that your app needs as well as files that configure how the app will run. Other examples:

.pch files — precompiled headers used for the code files in your project.

.plist files — property lists that are small amounts of persistent data (like your app’s default user settings) consisting primarily of strings and numbers that you want your app to be able to access, modify if needed, and write back into the property list.

main.m file — your app’s main function. This is needed to launch the app, but you will not need to modify this file.

InfoPlist.strings file — used for localization.

Products. This is the file for your app (i.e., YourProduct.app) that is built when you click Xcode’s “run” button.

“Making an iOS app” involves working with these features in the typical, straightforward workflow:

• Storyboard your views by dragging and configuring graphicalobjects on a template

• Adding behaviors to the various widgets• Writing the classes as to define those behaviors (including

delegates)• Adding needed support files• Building and running the app• Iterating until you are satisfied with your app

This is all done within Xcode.

What’s Xcode?You can start developing functional, good-looking apps almost from the moment you download Xcode, Apple’s integrated development environment (IDE) for making iOS and Macintosh apps. Among other features, Xcode includes a source code editor, graphical user inter-face (GUI) editor (sometimes called Interface Builder), source code repository manager, compiler, and much more. iOS applications are typically developed by manipulating views graphically and by typing Objective-C code for the models and controllers.

To get Xcode, simply go to the App Store and download the applica-tion (it’s free). To do this, click on the App Store icon in your Mac’s dock, or visit https://itunes.apple.com/us/genre/ios/id36?mt=8

The app store will download and install Xcode in your Application folder. From Applications, double-click the Xcode icon to launch Xcode and you’ll see its splash screen (Figure 1). From there you can click on “Create a new Xcode project” to take you to a menu of several templates on which to base your application. Selecting a template opens an Xcode workspace pre-populated with frameworks and other files Xcode thinks you will need using that template.

Although you can develop, build and simulate your app on your computer in Xcode, you can’t run your app on a target device (even your own iPhone) until you become a registered iOS developer and join the iOS Developer Program. To do that, go to develop-er.app.com/ and navigate to the iOS Dev Center. While there, you will also find documentation, sample code and other useful resources such as information on how to submit your app to the iOS App Store.

Everything you do in Xcode is done in a window, called a workspace (Figure 2), consisting of multiple work areas, some of which are also divided into panes. All the files needed to build your app belong to a project, and the Navigator area (far left) lists all your projects (there can be several in a workspace) and all files for each project. Clicking on a file in the Navigator area shows its contents in the Editor area and invokes the appropriate editor. Clicking on a .h or .m file, for example, shows the file’s source code and invokes the Source editor, so you can edit the code. Clicking on .storyboard or .xib (sometimes called a “nib”) file shows the app’s storyboard and invokes the Inter-face Builder, so you can design a view using the Builder’s drag and drop features.

An especially handy feature is that the Editor area can have both a right and a left pane — with each pane aware of your edits in the other. So, for example, you can simultaneously edit an object’s .h

header file in the left pane and its corresponding .m in the right pane. Or you might click on a button object (displayed graphically) in the left pane and edit its method’s source code in the right pane. To toggle between a single pane (the “Standard Editor”) and double pane view (the “Assistant Editor”), use the Editor selector button on the right of the toolbar. You can option+command+click a symbol in the editor to open the definition in the opposite editor pane.

You can also resize the entire Editor area simply by dragging its borders. For even more editing space, you can also remove the Debug area or both the Debug and Utility areas using the View Selector button on the far right of the toolbar.

As its name suggests, the Debug area shows information, like variable state and console logs, helpful in debugging code.

The Utility area has two panes: the Inspector and Quick Help pane (top) and the Library pane (bottom). Although there are five inspectors — File, Help, Identity, Attributes, Size and Connec-tions — only the inspectors that are currently relevant appear in the Inspec-tor list at the top of the pane. (To see the name of an inspector, move the cursor over its icon in the Inspector selector bar.)

You will use inspectors to add and modify object attributes for views in the Interface Builder. For example, if you click on a UILabel in the Editor area of a storyboard, you can use the Attributes inspector to change the label’s color and use the Size inspector to change the label’s size.

The Help inspector shows help information about a selected class. Use the Identity inspector to view and manage an object’s metadata such as its class, runtime attributes, label and so forth. Use the

Connections inspector to view the outlets and actions of an interface object, to make new connections and to delete existing connections.

The Library pane has libraries of resources (like file templates, code snippets, interface objects and media files) that are prebuilt and ready to insert into your project. Use the Library selector to select which of these libraries (e.g., code snippets or interface objects) you wish to insert. To insert one, drag it directly into your storyboard while using the Interface Builder editor.

These are basics you need to know to get started using Xcode to build your first app. But to really understand how it’s done, it helps to walk through an actual app or two. Let’s start with a simple “Hello World” app that does not employ a backend connection, and then look at a somewhat more functional app that does.

“Hello World!” sample appThis app displays a button (“Press Me”) and a label (“Label”) so that when the user presses the button the text of the label changes to “Hello World!” as in Figure 3:

To get started, launch Xcode and select “Create a New Xcode Project.” From the iOS Application templates, select “Single View Application” and click “Next.” Fill in your product’s name and a company identifier, typically “com.yourCompanyName.” Deselect “Use Storyboards” and leave “Use Automatic Reference Counting” selected. Then click “Next” and select a destination for your projects files.

Follow these steps to make your app:

1. Select your project’s ViewController.xib file in the Navigator(Figure 4), to open the Interface Builder editor.

2. Drag a “Round Rect Button” from the Objects library (lowerright) onto the view in the Editor area; select the button’s textand type “Press Me.”

3. Drag a Label from the objects library onto the view, as well.4. Select and drag the Label sizing handles, centering the object

and making it wide enough to hold the “Hello World!” text; then,

5. With the “Hello World!” label still selected, click on centeralignment in the Attributes inspector.

6. Open the Assistant Editor (Figure 5), exposing the source codeheader file (ViewController.h) of the view controller you justbuilt graphically.

7. Select the button and control-drag from the button to justbelow the ViewController definition in the Assistant panel. Inthe form that opens, select “Action” for the connection type,type in a name (“showText”) and click “Connect.” This creates aninterface builder (IB) action as highlighted in Figure 6.

8. Next step is to create an outlet for the label. To do this, selectthe label object and control-drag from the label to just belowthe IB action you just created. Select “Outlet” as the connectiontype and enter a name “label” and click “Connect.” This createsan interface builder (IB) outlet as shown in Figure 7.

9. Finally, it’s time to add some logic to the view controller so itknows what to do when the button is pressed. To do this, select “ViewController.m” in the project navigator to show the code editor. Find the button’s IBAction you just created (near the bottom), place your cursor between the { } brackets and hit the return key a few times to create some extra space. Then in that space type the method for how you want the label you speci-fied to respond: _label.text=”Hello World!”; as highlighted in Figure 8.

Congratulations! Your app is done. To build and run your new app in the simulator, click the Xcode Run button in the left corner of the toolbar. When you click the button, the text will update.

Sample app with a backend This second app (named “Kinvey Test Drive”) lets the user type text on an iPhone and save the text to a backend service, like Kinvey. It also lets the user load text on the iPhone from their Kinvey backend. Reading about this app will help you learn:

• How to set up Kinvey’s library in an iOS project• Additional Interface Builder techniques you can use to story-board an application• How to add view controller logic to interact with the backend service, allowing you to save and retrieve data

We will first present the app as a running application and then take it apart so you can see how it was made. To make the app yourself, you can review the various sections below and replicate the steps in your copy of Xcode.

First, to see the app in action, you should download the app and run it on your system. To do that, sign up for Kinvey, then navigate to “Dev Center”, “Samples,” find the “Test Drive” app, and click on its icon. (If you can’t find it right away, make sure you select iOS as your platform on the right side of the menu bar.) Click the download button to download the app’s project files to your computer. Then launch Xcode — just double click on the .xcodeproj file in the project folder.

But before you can run the app, you need to set up the app’s Kinvey backend.

Set Up Kinvey as a Backend Data StoreTest Drive’s project files include all the code the sample app needs in order to talk to Kinvey. However, that would not be the case if you were to build an app from scratch — so you would have to go through an initial Kinvey setup procedure. This involves downloading the Kinvey library files from the downloads section of devcenter.kin-vey.com and dragging them to the Navigator’s Frameworks folder in Xcode. You also need to tell Xcode to link your project with additional iOS frameworks. To find these frameworks, click on the Project folder

at the very top of the Navigator pane — which displays the Project editor — and then select the “Build Settings” tab. For detailed instruc-tions, complete the “Getting Started” page under “Guides” on the Kinvey website. But again, you can skip this setup procedure for now in order to run the downloaded Kinvey Test Drive app.

But you must still do this step: To run any app that uses Kinvey (including Test Drive) you need to do the “Create an App” step on the Kinvey website. Click on “My Apps” in the Kinvey menu bar and then click on “Add an App,” which will open an “Add” page. Type in a name for your app and click on the Apple logo and then click “Create.” The page that opens shows your App’s credentials. Copy and paste the App Key and App Secret into the AppDelegate.m file of the download-ed Test Drive project:

You are now ready to run the app — click on the Xcode run button and wait for the simulator to open and the app to appear (Figure 9).

Clicking the “+” toolbar button opens an alert (Figure 10) with an empty field into which the user can type some text (e.g., “some new data”). Clicking “save” uploads the data to Kinvey and displays text on the screen (a table view) and also displays an alert that the save worked (Figure 11).

To test the load function, enter some data (e.g., “some data to load”) in the “name” field of the Kinvey collection. To see the load, the swipe down on the table on the phone until the refresh spinner starts, and then the new data will appear in the table (Figure 12).

Figure 13 shows the Kinvey collection after the save that Figure 10 depicts on the iPhone. Figure 14 shows the Kinvey collection after the user adds a new row to the testObjects collection using the web browser. Note that every time a save is done on the iPhone, Kinvey automatically adds a new row (displayed on a collection refresh). To add a new row manually in the browser, click “+ row,” and type some descriptive text in the “name” column. That data will now load on the iPhone when the user pulls down on the table.

Storyboard the Test Drive AppMost of the Test Drive user interface objects visible in the simulation are available in Xcode’s Object Library and can therefore be added to the view graphically. The UI objects consist of a:

• Table view• Toolbar• Tool Bar Button item – flexible space• Tool Bar Button item – Add• Table view cell• Label – Title• Refresh Control

To create this app yourself, you would follow these steps:

• Launch Xcode and select the “Single View Application” template• Select the “Use Storyboard” option• Replace the default UIviewcontroller object with a UITableView-Controller • Drag and drop the other objects, in the order listed, onto the UIviewcontroller

Also note:

• The Flexible Space Bar Button item fills up the space on the toolbar so the add button is at the right. This is a standard pattern in table-based iPhone apps.• The add button shows the system “+” sign. That is done by dragging a bar button item onto the toolbar, clicking on the Identifier drop down menu in the Attributes inspector; and then selecting the “Add” option.

As with the “Hello World!” app, once your app’s view is complete (Figure 15), you would still have to create the various methods and connections that bring them to life. This is done using the Source editor while working with the ViewController.m file.

Add View Controller LogicSince the app performs two basic operations (save data to Kinvey and load data from Kinvey) these two methods must be added to the ViewController header file. That’s done with a control-drag from the “+” bar button over to just under the “@ interface ViewController” line in ViewController.h. (Open the Assistant editor to see both the storyboard and the file source.)

During the drag, the popup appears, asking for the name and type of connection. Enter “action” for the connection type and “add” for the name. Then repeat the drag, this time from the refresh control and using “add” for the name (Figure 16).

Note: to follow this discussion it will help to have the referenced files open in your Xcode Source editor.

In ViewController.m, you will see the implementation code associated with each of the two Interface Builder methods, whose names Xcode added automatically to the .m file:

- (IBAction)add:(id)sender- (IBAction)load:(id)sender

You will also see a third section of code not associated with these methods, which starts with the line: “#pragma mark - Table View Stuff.” These methods support the table view and are part of UITableViewD-elegate and UITableViewDataSource. They handle controlling the

display of the table, and respond to user gestures. For example, swiping a table cell will show the delete button because tableView:-canEditRowAtIndexPath: returns YES and tableView:editingStyleForRowA-tIndexPath: returns UITableViewCellEditingStyleDelete. If you tap the delete button, the delegate method tableView:commitEditingStyle:for-RowAtIndexPath: is called. The code of this method deletes the data for the row and removes it from Kinvey’s data store. When the backend delete is completed, the app displays an alert describing the success or failure.

The way that all three sections (and all Kinvey-enabled apps) move data in and out of a Kinvey collection is by getting a reference to the app’s backend collection (named “testObjects”), which is filled with instances (each named “TestObject”) of the data the app wants to move. That’s why you’ll find the following code repeated three times in Test Drive’s View Controller (once for the add, once for the load, and once for the delete):

To support these statements it is required to have a data object class (TestObject). To see how these files are written in the sample project, click on TestObject.h file and TestObject.m in the Navigator pane. If you were to supply these files in your own app, you would click File > New File, and specify Objective-C class, which would be a subclass of NSObject. Then you would type in the code, with a property for each column in the Kinvey backend collection (including one for the object’s id).

As mentioned earlier, your app also needs to authenticate itself to Kinvey, which is handled by AppDelegate.h and AppDelgate.m. These files are created by Xcode when you create a new project, and start out with just a stub implementation. Look in the sample app source

files for code to copy and paste.

For both the save and load operations, however, moving the data in and out of a backend collection is only part of the work. Table 1 lists all the functions that implements the save and load in the ViewCon-troller.m file, along with pointers to its corresponding block of imple-mentation source code. (For each function, its corresponding code begins with the “Starts at” line and ends with the “Ends at” line.) Refer to Appendix 1 to find the actual source code.

Say Hello To Our WorldThe key takeaway from all this is that “making an app” is a worthwhile thing to do for anyone with a clever idea and a working knowledge of Objective-C. The proof is in the hundreds of apps succeeding in the market every day, many written by people working on their own and who never wrote an app before in their lives. As with anything else, practice does make perfect. But hopefully with all the resources available, and the knowledge gained from this ebook, you have already started down the path toward joining the growing legions of iOS app developers. If so, we welcome you!

Appendix 1 — Test Drive Sample App ViewController.m Source Code

Getting your app approved

Let’s say you’ve already made your iOS app, and it works great. Now “all” you need to do is get it approved by Apple so your app can go on sale in the App Store. Don’t underestimate the importance of this step or the level of effort that may be required. In fact, the best time to familiarize yourself with Apple’s App Store requirements is before you start making your app. Fortunately, a number of very helpful resources are available online to assist you. Here are four we recommend:

1 Apple’s App Store Submissions Tutorial

2 Apple’s App Review Guidelines

3 Apple’s iOS Human Interface Guidelines

4 Kinvey blog article, “6 Ways to Ensure App Store Approval”

The iOS app architecture

The iOS revolutionIt’s a story that never gets old. The weekend that iPad Minis and the fourth generation iPads went on sale (November 2-5, 2012) Apple sold over 3 million of the devices — a record for first-weekend iPad sales. Two months earlier the company had set another record: first weekend sales of over 5 million for the iPhone 5. Since the introduc-tion of the first iPhone back in 2007,

iOS-based devices (iPhone, iPad, iPad Mini and iPod Touch) continue to rewrite the definition of what constitutes a successful product. By the end of 2012, over 400 million iOS devices had been sold.

What makes iOS devices so successful? Innovation and product features are clearly a big part. Before the iPhone most people had not interacted with a multi-touch interface. They had never zoomed with a pinch or switched between portrait and landscape by merely rotating a device in their hand. Carrying a phone that knew where they were, could suggest places to eat, and could offer directions on how to get there was also a novel experience.

But features like multi-touch, accelerometers and GPS are only part of the appeal. Even with all its innovations, iOS still might not have taken off the way it has if the only people figuring out ways to use those innovations worked at Apple. Most of the capabilities available in an iPhone or iPad in fact don’t come from Apple at all. They come from legions of third-party developers who work in a vast ecosystem that is also an Apple innovation. That ecosystem includes the iPhone, iPad, iPad Mini, iPods, App Store, iTunes, ad networks — and that’s just on the consumer side. On the developer side, you have Xcode, App Loader, testing tools, iTunes Connect — the list goes on.

As of September 2012, the App Store hosted over 700,000 apps that have collectively been downloaded over 30 billion times. Apple reported for October 2012 that App Store monthly revenues were

running at $333 million — a rate of about $4 billion per year — remarkable for a store that only opened in July 2008.

Another innovation that has spurred iOS app development is “The Cloud.” Cloud services make it easier for independent developers to create, support and make money from their apps. The Cloud solves data storage and cross-device and user-to-user sharing problems. If an app stores data in the Cloud, that part of the application is called the “backend,” while the part of the app that runs on the phone and interacts with the user is called the “front end.”

A cloud may be “private” — i.e., the services belong to an organization for the benefit of its employees and business partners. Or a cloud may be “public” — i.e., a company (such as Amazon or Kinvey) owns the services, which developers can then integrate into their own apps. If you are a developer and want to build your own backend, you certainly can do that. Whether you want to or not depends on whether your backend provides functionality common to many different apps. If it does (as in a shopping cart or user authenti-cation) then perhaps that time and money would be better spent on features that offer unique value to your customer. You may be better off hooking into a commercial backend provider via an API. Then you can focus on what counts most — a unique user experience and application-specific functionality. That brings us to the first step in making an app.

Define your appMost unsuccessful apps fail for any of four reasons:

1. the app was a solution in search of a problem (i.e., no real need existed) 2. the implementation was poor 3. the app tried to do too much; or 4. the Apple App Store rejected the app (either because the implementation was poor or it violated Apple’s content policies)

Keeping the app as simple as possible is the best way to avoid these pitfalls. Most successful apps (indeed, most successful consumer tech products) are based on what is called an MVP, or minimum viable product. It’s the product with the smallest feature set that can deliver the core function without any distracting “bells and whistles.” You know you have an MVP if the product would no longer function if you removed any single feature.

But what should that core feature be? One of the best examples of an MVP is Mail. Version 1 (on the Mac) offered a clear, limited and intuitive feature set whose usefulness was immediately obvious to anyone. Today’s iPhone version integrates seamlessly with your phone, contacts and calendaring. It auto-matically corrects spelling as you type, lets you email photos directly from your photos app, and does much more. But all that came later and was built on top of a basic core function. And that’s how your first app should be built. The key is to come up with something with a clear value that changes people’s lives.

So, in drawing up your MVP feature list, ask yourself what features are key to the experience. Some basic market research is probably in order, starting with a visit to the App Store to see what already exists (possibly to be improved upon and/or to compete with you). Likely

must-have core capabilities include:

• Performance (e.g., fast screen refresh)• Offline capability (i.e., ability to work when not connected to the Internet)• Location awareness (e.g., the data/experience will change with the user’s location)• Cloud syncing (e.g., users see the same data on multiple devices)• Push notifications (i.e., sending updated information to devices as soon as it is available)

When you have a handle on what your app does, the next step is to design it. Designing your app involves making choices of how infor-mation and controls are presented to the user as well as how to implement app logic, and figuring out what data lives locally and what belongs in the Cloud.

Design your appUser experience decisions determine the app’s look and feel. They answer questions such as: What does the app look like? What screens does it have? In the software development world, onscreen objects like buttons, sliders, and fill-in boxes are called widgets. So you need to decide which types of widgets will reside on which screens. And what actions will occur as a result of the user interacting with those widgets?

Keep in mind that users will expect to interact differently with a mobile device than they do with a PC because the screens on mobile devices are much smaller. They’ll expect to use their fingers instead of a mouse or a track pad. Ideally, your app can even be used with one hand holding the device while using just a thumb for scrolling andworking the app’s other controls— the Path app is a good example, and increasingly, so is Facebook.

Your app’s features will inform its architecture, which is how you’ll divide the code and data into functional parts. If your app requires interacting with other app users or networked services, you’ll need to figure out what piece of the logic lives in the app code and what comes from the backend. For example, your app might integrate with a restau-rant recommendation engine, share user location, or pull real-time traffic data. This is done using APIs provided by various service providers — but you don’t have to wire up your app to a network to get started. You can develop a prototype using predefined representative (or “dummy”) data. It’s easier to fine-tune the front end if you don’t have to simultaneously modify your backend too. Once you get the app’s look-and-feel right, then make those backend connections.

Once you’ve got the overall concept for your app, the next step is to express that design in terms of the iOS app architecture. That archi-tecture is the model for what parts an iOS app can contain and how those parts fit together. It’s a well thought-out approach for translat-ing a product concept into actual code you can deploy on a device.

WHY iOS?Besides the features and design of your first app, there’s one more decision you need to make before you start actual development. That’s whether to deploy on Apple’s iOS platform or on Google’s Android platform. (Some of this is also covered in our ebook, How to Make an App: Android Edition.) Reasons to develop for iOS include:

Customers more willing to pay. Perhaps it’s because of Android’s open source heritage, but whatever the reason, Android apps gener-ate less than 10% of the total dollars spent on mobile apps, despite having 75% of the smartphone market itself — and despite the fact that the average selling price of an app in the Google Play is $3.79 versus Apple App Store’s $2.01. In other words, Apple users are much more willing to spend money on apps.

The Apple Ecosystem. Some developers and users prefer Apple’s closed and more tightly controlled environment. Apple’s ecosystem, consisting of Xcode, iCloud, iTunes, the App Store, the iPad, the iPhone, Mac computers, etc., offers a very holistic user experience with the ability to share data seamlessly across devices plus the

assurance of having applications pre-approved for quality and content prior to going on sale.

Xcode. Apple’s all-in-one IDE offers state-of-the-art offers features like a graphical interface builder and a syntax-aware and compiler-aware source editor.

The Apple Experience. From the fit and finish of its hardware to the customer service in its retail stores, to the way its hardware and software work flawlessly together, Apple has created the premium brand in consumer electronics. iOS developers share the benefits — so when someone downloads your iOS app, they already expect it’s a great product. And that it will also work flawlessly on their device.

Tablets. iOS has a clear advantage over Android in terms of tablet market adoption. Using Xcode, it’s also much easier to migrate an app from a phone to a tablet and vice versa than it is when develop-ing for Android.

Why Not iOS?Although iOS offers many compelling advantages as a platform for your mobile app, it also comes with some disadvantages. Here are three:

Closed Platform. iOS apps only run on Apple products so you can’t take advantage of features (like NFC) available only on non-iOS devices or market growth of non-iOS devices.

Market Growth. Today, iOS represents less than 15% of the total smartphone market, Although the total market (“the whole pie”) is still increasing at a fast rate, Android market growth outpaces iOS growth.

Approvals. The App Store’s app approval process is notoriously more time consuming than Google Play’s process.

The iOS app architectureAs noted earlier, a key reason why there are so many apps for iOS is because developing highly functional, polished apps for the platform is relatively easy. That’s mainly because of: 1) the design of the development tools, and 2) the key architectural features most iOS apps have in common. So let’s start with some concepts since it helps to know what goes into an app before trying to create one. We’ll begin with:

• Design patterns• Frameworks• Delegation• Storyboard• Windows• Outlets• Supporting files• Products

Design patterns. iOS apps implement what is known as a Mod-el-View-Controller (MVC) pattern. A pattern is a common way to structure code that solves a particular design problem. The MVC pattern separates application code in a way that allows you to easily change one part of an app without having to change other parts. An MVC pattern consists of three components:

• The Model is the logic that acts on the data, such as to store or retrieve data from a database, compute the distance between two cities on a map, etc. An example of a model is the Kinvey backend that stores your data in the Cloud as a service.

• The View provides the interface to the user; it displays the data and widgets (e.g., buttons and text fields) that allow the user to interact with the data. An iPhone app may have more than one view, as in the Contacts app, which displays a list view of all contacts or alternatively a view of each individual contact.

• The Controller is between the model and the view — i.e., it responds to user requests (made in a view) and retrieves results

(produced in a model). This is where developers spend most of their time — constructing the View Controller — by defining and attaching actions (or behaviors) to onscreen widgets. When the user taps a button, for example, it is the View Controller that determines what action will occur, such as retrieve stored data from your Kinvey-based data store. The link between a view object (like a button) to a controller action is called a connection.

Frameworks. You don’t actually have to write most of an app’s logic. It already exists as frameworks. A framework is a collection of classes that implements some function — such as connecting to the Internet, drawing a button, etc. Rather than write the code from scratch, you just use the frameworks supplied by iOS. Some frameworks are automatically present when you start a new project while others may need to be added (done via a drop down menu in Xcode’s Project Editor).

Delegation. Say, you want to customize the behavior of a framework’s object. You can’t actually modify the code of the framework class itself (prohibited since other apps may also use the framework). But what you can do is provide app-specific behavior in an application delegate object. If a delegate implements a method, it will be called by the delegating class to modify its behavior. In the Kinvey sample app (one of two examples we will be describing below), the AppDele-gate.h and AppDelegate.m — the header and implementation files for the UIApplicationDelegate, respectively — contain the code that authenticates an app to the Kinvey backend service.

Storyboards and XIBs. The MainStoryboard.storyboard file (or a .xib file, if you did not click on the “Use Storyboard” option when starting your project) contains the view information needed to implement the overall flow and display of your application and the user interface elements.

Windows. Each view (e.g., the contact list and individual contact details in the Contacts app) exists within a window. The window represents the entire device screen and is where all your views are presented.

Outlets. A variable by which a view object can be referenced in a controller. (For example, if you place a text field to capture a user's name, you might create an outlet called UITextField* nameField.)

Supporting files. These are files that provide resources (like PNG images and other static data) that your app needs as well as files that configure how the app will run. Other examples:

.pch files — precompiled headers used for the code files in your project.

.plist files — property lists that are small amounts of persistent data (like your app’s default user settings) consisting primarily of strings and numbers that you want your app to be able to access, modify if needed, and write back into the property list.

main.m file — your app’s main function. This is needed to launch the app, but you will not need to modify this file.

InfoPlist.strings file — used for localization.

Products. This is the file for your app (i.e., YourProduct.app) that is built when you click Xcode’s “run” button.

“Making an iOS app” involves working with these features in the typical, straightforward workflow:

• Storyboard your views by dragging and configuring graphicalobjects on a template

• Adding behaviors to the various widgets• Writing the classes as to define those behaviors (including

delegates)• Adding needed support files• Building and running the app• Iterating until you are satisfied with your app

This is all done within Xcode.

What’s Xcode?You can start developing functional, good-looking apps almost from the moment you download Xcode, Apple’s integrated development environment (IDE) for making iOS and Macintosh apps. Among other features, Xcode includes a source code editor, graphical user inter-face (GUI) editor (sometimes called Interface Builder), source code repository manager, compiler, and much more. iOS applications are typically developed by manipulating views graphically and by typing Objective-C code for the models and controllers.

To get Xcode, simply go to the App Store and download the applica-tion (it’s free). To do this, click on the App Store icon in your Mac’s dock, or visit https://itunes.apple.com/us/genre/ios/id36?mt=8

The app store will download and install Xcode in your Application folder. From Applications, double-click the Xcode icon to launch Xcode and you’ll see its splash screen (Figure 1). From there you can click on “Create a new Xcode project” to take you to a menu of several templates on which to base your application. Selecting a template opens an Xcode workspace pre-populated with frameworks and other files Xcode thinks you will need using that template.

Although you can develop, build and simulate your app on your computer in Xcode, you can’t run your app on a target device (even your own iPhone) until you become a registered iOS developer and join the iOS Developer Program. To do that, go to develop-er.app.com/ and navigate to the iOS Dev Center. While there, you will also find documentation, sample code and other useful resources such as information on how to submit your app to the iOS App Store.

Everything you do in Xcode is done in a window, called a workspace (Figure 2), consisting of multiple work areas, some of which are also divided into panes. All the files needed to build your app belong to a project, and the Navigator area (far left) lists all your projects (there can be several in a workspace) and all files for each project. Clicking on a file in the Navigator area shows its contents in the Editor area and invokes the appropriate editor. Clicking on a .h or .m file, for example, shows the file’s source code and invokes the Source editor, so you can edit the code. Clicking on .storyboard or .xib (sometimes called a “nib”) file shows the app’s storyboard and invokes the Inter-face Builder, so you can design a view using the Builder’s drag and drop features.

An especially handy feature is that the Editor area can have both a right and a left pane — with each pane aware of your edits in the other. So, for example, you can simultaneously edit an object’s .h

header file in the left pane and its corresponding .m in the right pane. Or you might click on a button object (displayed graphically) in the left pane and edit its method’s source code in the right pane. To toggle between a single pane (the “Standard Editor”) and double pane view (the “Assistant Editor”), use the Editor selector button on the right of the toolbar. You can option+command+click a symbol in the editor to open the definition in the opposite editor pane.

You can also resize the entire Editor area simply by dragging its borders. For even more editing space, you can also remove the Debug area or both the Debug and Utility areas using the View Selector button on the far right of the toolbar.

As its name suggests, the Debug area shows information, like variable state and console logs, helpful in debugging code.

The Utility area has two panes: the Inspector and Quick Help pane (top) and the Library pane (bottom). Although there are five inspectors — File, Help, Identity, Attributes, Size and Connec-tions — only the inspectors that are currently relevant appear in the Inspec-tor list at the top of the pane. (To see the name of an inspector, move the cursor over its icon in the Inspector selector bar.)

You will use inspectors to add and modify object attributes for views in the Interface Builder. For example, if you click on a UILabel in the Editor area of a storyboard, you can use the Attributes inspector to change the label’s color and use the Size inspector to change the label’s size.

The Help inspector shows help information about a selected class. Use the Identity inspector to view and manage an object’s metadata such as its class, runtime attributes, label and so forth. Use the

Connections inspector to view the outlets and actions of an interface object, to make new connections and to delete existing connections.

The Library pane has libraries of resources (like file templates, code snippets, interface objects and media files) that are prebuilt and ready to insert into your project. Use the Library selector to select which of these libraries (e.g., code snippets or interface objects) you wish to insert. To insert one, drag it directly into your storyboard while using the Interface Builder editor.

These are basics you need to know to get started using Xcode to build your first app. But to really understand how it’s done, it helps to walk through an actual app or two. Let’s start with a simple “Hello World” app that does not employ a backend connection, and then look at a somewhat more functional app that does.

“Hello World!” sample appThis app displays a button (“Press Me”) and a label (“Label”) so that when the user presses the button the text of the label changes to “Hello World!” as in Figure 3:

To get started, launch Xcode and select “Create a New Xcode Project.” From the iOS Application templates, select “Single View Application” and click “Next.” Fill in your product’s name and a company identifier, typically “com.yourCompanyName.” Deselect “Use Storyboards” and leave “Use Automatic Reference Counting” selected. Then click “Next” and select a destination for your projects files.

Follow these steps to make your app:

1. Select your project’s ViewController.xib file in the Navigator(Figure 4), to open the Interface Builder editor.

2. Drag a “Round Rect Button” from the Objects library (lowerright) onto the view in the Editor area; select the button’s textand type “Press Me.”

3. Drag a Label from the objects library onto the view, as well.4. Select and drag the Label sizing handles, centering the object

and making it wide enough to hold the “Hello World!” text; then,

5. With the “Hello World!” label still selected, click on centeralignment in the Attributes inspector.

6. Open the Assistant Editor (Figure 5), exposing the source codeheader file (ViewController.h) of the view controller you justbuilt graphically.

7. Select the button and control-drag from the button to justbelow the ViewController definition in the Assistant panel. Inthe form that opens, select “Action” for the connection type,type in a name (“showText”) and click “Connect.” This creates aninterface builder (IB) action as highlighted in Figure 6.

8. Next step is to create an outlet for the label. To do this, selectthe label object and control-drag from the label to just belowthe IB action you just created. Select “Outlet” as the connectiontype and enter a name “label” and click “Connect.” This createsan interface builder (IB) outlet as shown in Figure 7.

9. Finally, it’s time to add some logic to the view controller so itknows what to do when the button is pressed. To do this, select “ViewController.m” in the project navigator to show the code editor. Find the button’s IBAction you just created (near the bottom), place your cursor between the { } brackets and hit the return key a few times to create some extra space. Then in that space type the method for how you want the label you speci-fied to respond: _label.text=”Hello World!”; as highlighted in Figure 8.

Congratulations! Your app is done. To build and run your new app in the simulator, click the Xcode Run button in the left corner of the toolbar. When you click the button, the text will update.

Sample app with a backend This second app (named “Kinvey Test Drive”) lets the user type text on an iPhone and save the text to a backend service, like Kinvey. It also lets the user load text on the iPhone from their Kinvey backend. Reading about this app will help you learn:

• How to set up Kinvey’s library in an iOS project• Additional Interface Builder techniques you can use to story-board an application• How to add view controller logic to interact with the backend service, allowing you to save and retrieve data

We will first present the app as a running application and then take it apart so you can see how it was made. To make the app yourself, you can review the various sections below and replicate the steps in your copy of Xcode.

First, to see the app in action, you should download the app and run it on your system. To do that, sign up for Kinvey, then navigate to “Dev Center”, “Samples,” find the “Test Drive” app, and click on its icon. (If you can’t find it right away, make sure you select iOS as your platform on the right side of the menu bar.) Click the download button to download the app’s project files to your computer. Then launch Xcode — just double click on the .xcodeproj file in the project folder.

But before you can run the app, you need to set up the app’s Kinvey backend.

Set Up Kinvey as a Backend Data StoreTest Drive’s project files include all the code the sample app needs in order to talk to Kinvey. However, that would not be the case if you were to build an app from scratch — so you would have to go through an initial Kinvey setup procedure. This involves downloading the Kinvey library files from the downloads section of devcenter.kin-vey.com and dragging them to the Navigator’s Frameworks folder in Xcode. You also need to tell Xcode to link your project with additional iOS frameworks. To find these frameworks, click on the Project folder

at the very top of the Navigator pane — which displays the Project editor — and then select the “Build Settings” tab. For detailed instruc-tions, complete the “Getting Started” page under “Guides” on the Kinvey website. But again, you can skip this setup procedure for now in order to run the downloaded Kinvey Test Drive app.

But you must still do this step: To run any app that uses Kinvey (including Test Drive) you need to do the “Create an App” step on the Kinvey website. Click on “My Apps” in the Kinvey menu bar and then click on “Add an App,” which will open an “Add” page. Type in a name for your app and click on the Apple logo and then click “Create.” The page that opens shows your App’s credentials. Copy and paste the App Key and App Secret into the AppDelegate.m file of the download-ed Test Drive project:

You are now ready to run the app — click on the Xcode run button and wait for the simulator to open and the app to appear (Figure 9).

Clicking the “+” toolbar button opens an alert (Figure 10) with an empty field into which the user can type some text (e.g., “some new data”). Clicking “save” uploads the data to Kinvey and displays text on the screen (a table view) and also displays an alert that the save worked (Figure 11).

To test the load function, enter some data (e.g., “some data to load”) in the “name” field of the Kinvey collection. To see the load, the swipe down on the table on the phone until the refresh spinner starts, and then the new data will appear in the table (Figure 12).

Figure 13 shows the Kinvey collection after the save that Figure 10 depicts on the iPhone. Figure 14 shows the Kinvey collection after the user adds a new row to the testObjects collection using the web browser. Note that every time a save is done on the iPhone, Kinvey automatically adds a new row (displayed on a collection refresh). To add a new row manually in the browser, click “+ row,” and type some descriptive text in the “name” column. That data will now load on the iPhone when the user pulls down on the table.

Storyboard the Test Drive AppMost of the Test Drive user interface objects visible in the simulation are available in Xcode’s Object Library and can therefore be added to the view graphically. The UI objects consist of a:

• Table view• Toolbar• Tool Bar Button item – flexible space• Tool Bar Button item – Add• Table view cell• Label – Title• Refresh Control

To create this app yourself, you would follow these steps:

• Launch Xcode and select the “Single View Application” template• Select the “Use Storyboard” option• Replace the default UIviewcontroller object with a UITableView-Controller • Drag and drop the other objects, in the order listed, onto the UIviewcontroller

Also note:

• The Flexible Space Bar Button item fills up the space on the toolbar so the add button is at the right. This is a standard pattern in table-based iPhone apps.• The add button shows the system “+” sign. That is done by dragging a bar button item onto the toolbar, clicking on the Identifier drop down menu in the Attributes inspector; and then selecting the “Add” option.

As with the “Hello World!” app, once your app’s view is complete (Figure 15), you would still have to create the various methods and connections that bring them to life. This is done using the Source editor while working with the ViewController.m file.

Add View Controller LogicSince the app performs two basic operations (save data to Kinvey and load data from Kinvey) these two methods must be added to the ViewController header file. That’s done with a control-drag from the “+” bar button over to just under the “@ interface ViewController” line in ViewController.h. (Open the Assistant editor to see both the storyboard and the file source.)

During the drag, the popup appears, asking for the name and type of connection. Enter “action” for the connection type and “add” for the name. Then repeat the drag, this time from the refresh control and using “add” for the name (Figure 16).

Note: to follow this discussion it will help to have the referenced files open in your Xcode Source editor.

In ViewController.m, you will see the implementation code associated with each of the two Interface Builder methods, whose names Xcode added automatically to the .m file:

- (IBAction)add:(id)sender- (IBAction)load:(id)sender

You will also see a third section of code not associated with these methods, which starts with the line: “#pragma mark - Table View Stuff.” These methods support the table view and are part of UITableViewD-elegate and UITableViewDataSource. They handle controlling the

display of the table, and respond to user gestures. For example, swiping a table cell will show the delete button because tableView:-canEditRowAtIndexPath: returns YES and tableView:editingStyleForRowA-tIndexPath: returns UITableViewCellEditingStyleDelete. If you tap the delete button, the delegate method tableView:commitEditingStyle:for-RowAtIndexPath: is called. The code of this method deletes the data for the row and removes it from Kinvey’s data store. When the backend delete is completed, the app displays an alert describing the success or failure.

The way that all three sections (and all Kinvey-enabled apps) move data in and out of a Kinvey collection is by getting a reference to the app’s backend collection (named “testObjects”), which is filled with instances (each named “TestObject”) of the data the app wants to move. That’s why you’ll find the following code repeated three times in Test Drive’s View Controller (once for the add, once for the load, and once for the delete):

To support these statements it is required to have a data object class (TestObject). To see how these files are written in the sample project, click on TestObject.h file and TestObject.m in the Navigator pane. If you were to supply these files in your own app, you would click File > New File, and specify Objective-C class, which would be a subclass of NSObject. Then you would type in the code, with a property for each column in the Kinvey backend collection (including one for the object’s id).

As mentioned earlier, your app also needs to authenticate itself to Kinvey, which is handled by AppDelegate.h and AppDelgate.m. These files are created by Xcode when you create a new project, and start out with just a stub implementation. Look in the sample app source

files for code to copy and paste.

For both the save and load operations, however, moving the data in and out of a backend collection is only part of the work. Table 1 lists all the functions that implements the save and load in the ViewCon-troller.m file, along with pointers to its corresponding block of imple-mentation source code. (For each function, its corresponding code begins with the “Starts at” line and ends with the “Ends at” line.) Refer to Appendix 1 to find the actual source code.

Say Hello To Our WorldThe key takeaway from all this is that “making an app” is a worthwhile thing to do for anyone with a clever idea and a working knowledge of Objective-C. The proof is in the hundreds of apps succeeding in the market every day, many written by people working on their own and who never wrote an app before in their lives. As with anything else, practice does make perfect. But hopefully with all the resources available, and the knowledge gained from this ebook, you have already started down the path toward joining the growing legions of iOS app developers. If so, we welcome you!

Appendix 1 — Test Drive Sample App ViewController.m Source Code

4

14

The iOS revolutionIt’s a story that never gets old. The weekend that iPad Minis and the fourth generation iPads went on sale (November 2-5, 2012) Apple sold over 3 million of the devices — a record for first-weekend iPad sales. Two months earlier the company had set another record: first weekend sales of over 5 million for the iPhone 5. Since the introduc-tion of the first iPhone back in 2007,

iOS-based devices (iPhone, iPad, iPad Mini and iPod Touch) continue to rewrite the definition of what constitutes a successful product. By the end of 2012, over 400 million iOS devices had been sold.

What makes iOS devices so successful? Innovation and product features are clearly a big part. Before the iPhone most people had not interacted with a multi-touch interface. They had never zoomed with a pinch or switched between portrait and landscape by merely rotating a device in their hand. Carrying a phone that knew where they were, could suggest places to eat, and could offer directions on how to get there was also a novel experience.

But features like multi-touch, accelerometers and GPS are only part of the appeal. Even with all its innovations, iOS still might not have taken off the way it has if the only people figuring out ways to use those innovations worked at Apple. Most of the capabilities available in an iPhone or iPad in fact don’t come from Apple at all. They come from legions of third-party developers who work in a vast ecosystem that is also an Apple innovation. That ecosystem includes the iPhone, iPad, iPad Mini, iPods, App Store, iTunes, ad networks — and that’s just on the consumer side. On the developer side, you have Xcode, App Loader, testing tools, iTunes Connect — the list goes on.

As of September 2012, the App Store hosted over 700,000 apps that have collectively been downloaded over 30 billion times. Apple reported for October 2012 that App Store monthly revenues were

running at $333 million — a rate of about $4 billion per year — remarkable for a store that only opened in July 2008.

Another innovation that has spurred iOS app development is “The Cloud.” Cloud services make it easier for independent developers to create, support and make money from their apps. The Cloud solves data storage and cross-device and user-to-user sharing problems. If an app stores data in the Cloud, that part of the application is called the “backend,” while the part of the app that runs on the phone and interacts with the user is called the “front end.”

A cloud may be “private” — i.e., the services belong to an organization for the benefit of its employees and business partners. Or a cloud may be “public” — i.e., a company (such as Amazon or Kinvey) owns the services, which developers can then integrate into their own apps. If you are a developer and want to build your own backend, you certainly can do that. Whether you want to or not depends on whether your backend provides functionality common to many different apps. If it does (as in a shopping cart or user authenti-cation) then perhaps that time and money would be better spent on features that offer unique value to your customer. You may be better off hooking into a commercial backend provider via an API. Then you can focus on what counts most — a unique user experience and application-specific functionality. That brings us to the first step in making an app.

Define your appMost unsuccessful apps fail for any of four reasons:

1. the app was a solution in search of a problem (i.e., no real need existed) 2. the implementation was poor 3. the app tried to do too much; or 4. the Apple App Store rejected the app (either because the implementation was poor or it violated Apple’s content policies)

Keeping the app as simple as possible is the best way to avoid these pitfalls. Most successful apps (indeed, most successful consumer tech products) are based on what is called an MVP, or minimum viable product. It’s the product with the smallest feature set that can deliver the core function without any distracting “bells and whistles.” You know you have an MVP if the product would no longer function if you removed any single feature.

But what should that core feature be? One of the best examples of an MVP is Mail. Version 1 (on the Mac) offered a clear, limited and intuitive feature set whose usefulness was immediately obvious to anyone. Today’s iPhone version integrates seamlessly with your phone, contacts and calendaring. It auto-matically corrects spelling as you type, lets you email photos directly from your photos app, and does much more. But all that came later and was built on top of a basic core function. And that’s how your first app should be built. The key is to come up with something with a clear value that changes people’s lives.

So, in drawing up your MVP feature list, ask yourself what features are key to the experience. Some basic market research is probably in order, starting with a visit to the App Store to see what already exists (possibly to be improved upon and/or to compete with you). Likely

must-have core capabilities include:

• Performance (e.g., fast screen refresh)• Offline capability (i.e., ability to work when not connected to the Internet)• Location awareness (e.g., the data/experience will change with the user’s location)• Cloud syncing (e.g., users see the same data on multiple devices)• Push notifications (i.e., sending updated information to devices as soon as it is available)

When you have a handle on what your app does, the next step is to design it. Designing your app involves making choices of how infor-mation and controls are presented to the user as well as how to implement app logic, and figuring out what data lives locally and what belongs in the Cloud.

Design your appUser experience decisions determine the app’s look and feel. They answer questions such as: What does the app look like? What screens does it have? In the software development world, onscreen objects like buttons, sliders, and fill-in boxes are called widgets. So you need to decide which types of widgets will reside on which screens. And what actions will occur as a result of the user interacting with those widgets?

Keep in mind that users will expect to interact differently with a mobile device than they do with a PC because the screens on mobile devices are much smaller. They’ll expect to use their fingers instead of a mouse or a track pad. Ideally, your app can even be used with one hand holding the device while using just a thumb for scrolling andworking the app’s other controls— the Path app is a good example, and increasingly, so is Facebook.

Your app’s features will inform its architecture, which is how you’ll divide the code and data into functional parts. If your app requires interacting with other app users or networked services, you’ll need to figure out what piece of the logic lives in the app code and what comes from the backend. For example, your app might integrate with a restau-rant recommendation engine, share user location, or pull real-time traffic data. This is done using APIs provided by various service providers — but you don’t have to wire up your app to a network to get started. You can develop a prototype using predefined representative (or “dummy”) data. It’s easier to fine-tune the front end if you don’t have to simultaneously modify your backend too. Once you get the app’s look-and-feel right, then make those backend connections.

Once you’ve got the overall concept for your app, the next step is to express that design in terms of the iOS app architecture. That archi-tecture is the model for what parts an iOS app can contain and how those parts fit together. It’s a well thought-out approach for translat-ing a product concept into actual code you can deploy on a device.

WHY iOS?Besides the features and design of your first app, there’s one more decision you need to make before you start actual development. That’s whether to deploy on Apple’s iOS platform or on Google’s Android platform. (Some of this is also covered in our ebook, How to Make an App: Android Edition.) Reasons to develop for iOS include:

Customers more willing to pay. Perhaps it’s because of Android’s open source heritage, but whatever the reason, Android apps gener-ate less than 10% of the total dollars spent on mobile apps, despite having 75% of the smartphone market itself — and despite the fact that the average selling price of an app in the Google Play is $3.79 versus Apple App Store’s $2.01. In other words, Apple users are much more willing to spend money on apps.

The Apple Ecosystem. Some developers and users prefer Apple’s closed and more tightly controlled environment. Apple’s ecosystem, consisting of Xcode, iCloud, iTunes, the App Store, the iPad, the iPhone, Mac computers, etc., offers a very holistic user experience with the ability to share data seamlessly across devices plus the

assurance of having applications pre-approved for quality and content prior to going on sale.

Xcode. Apple’s all-in-one IDE offers state-of-the-art offers features like a graphical interface builder and a syntax-aware and compiler-aware source editor.

The Apple Experience. From the fit and finish of its hardware to the customer service in its retail stores, to the way its hardware and software work flawlessly together, Apple has created the premium brand in consumer electronics. iOS developers share the benefits — so when someone downloads your iOS app, they already expect it’s a great product. And that it will also work flawlessly on their device.

Tablets. iOS has a clear advantage over Android in terms of tablet market adoption. Using Xcode, it’s also much easier to migrate an app from a phone to a tablet and vice versa than it is when develop-ing for Android.

Why Not iOS?Although iOS offers many compelling advantages as a platform for your mobile app, it also comes with some disadvantages. Here are three:

Closed Platform. iOS apps only run on Apple products so you can’t take advantage of features (like NFC) available only on non-iOS devices or market growth of non-iOS devices.

Market Growth. Today, iOS represents less than 15% of the total smartphone market, Although the total market (“the whole pie”) is still increasing at a fast rate, Android market growth outpaces iOS growth.

Approvals. The App Store’s app approval process is notoriously more time consuming than Google Play’s process.

The iOS app architectureAs noted earlier, a key reason why there are so many apps for iOS is because developing highly functional, polished apps for the platform is relatively easy. That’s mainly because of: 1) the design of the development tools, and 2) the key architectural features most iOS apps have in common. So let’s start with some concepts since it helps to know what goes into an app before trying to create one. We’ll begin with:

• Design patterns• Frameworks• Delegation• Storyboard• Windows• Outlets• Supporting files• Products

Design patterns. iOS apps implement what is known as a Mod-el-View-Controller (MVC) pattern. A pattern is a common way to structure code that solves a particular design problem. The MVC pattern separates application code in a way that allows you to easily change one part of an app without having to change other parts. An MVC pattern consists of three components:

• The Model is the logic that acts on the data, such as to store orretrieve data from a database, compute the distance between twocities on a map, etc. An example of a model is the Kinvey backendthat stores your data in the Cloud as a service.

• The View provides the interface to the user; it displays the dataand widgets (e.g., buttons and text fields) that allow the user tointeract with the data. An iPhone app may have more than oneview, as in the Contacts app, which displays a list view of allcontacts or alternatively a view of each individual contact.

• The Controller is between the model and the view — i.e., itresponds to user requests (made in a view) and retrieves results

(produced in a model). This is where developers spend most of their time — constructing the View Controller — by defining and attaching actions (or behaviors) to onscreen widgets. When the user taps a button, for example, it is the View Controller that determines what action will occur, such as retrieve stored data from your Kinvey-based data store. The link between a view object (like a button) to a controller action is called a connection.

Frameworks. You don’t actually have to write most of an app’s logic. It already exists as frameworks. A framework is a collection of classes that implements some function — such as connecting to the Internet, drawing a button, etc. Rather than write the code from scratch, you just use the frameworks supplied by iOS. Some frameworks are automatically present when you start a new project while others may need to be added (done via a drop down menu in Xcode’s Project Editor).

Delegation. Say, you want to customize the behavior of a framework’s object. You can’t actually modify the code of the framework class itself (prohibited since other apps may also use the framework). But what you can do is provide app-specific behavior in an application delegate object. If a delegate implements a method, it will be called by the delegating class to modify its behavior. In the Kinvey sample app (one of two examples we will be describing below), the AppDele-gate.h and AppDelegate.m — the header and implementation files for the UIApplicationDelegate, respectively — contain the code that authenticates an app to the Kinvey backend service.

Storyboards and XIBs. The MainStoryboard.storyboard file (or a .xib file, if you did not click on the “Use Storyboard” option when starting your project) contains the view information needed to implement the overall flow and display of your application and the user interface elements.

Windows. Each view (e.g., the contact list and individual contact details in the Contacts app) exists within a window. The window represents the entire device screen and is where all your views are presented.

Outlets. A variable by which a view object can be referenced in a controller. (For example, if you place a text field to capture a user's name, you might create an outlet called UITextField* nameField.)

Supporting files. These are files that provide resources (like PNG images and other static data) that your app needs as well as files that configure how the app will run. Other examples:

.pch files — precompiled headers used for the code files in your project.

.plist files — property lists that are small amounts of persistent data (like your app’s default user settings) consisting primarily of strings and numbers that you want your app to be able to access, modify if needed, and write back into the property list.

main.m file — your app’s main function. This is needed to launch the app, but you will not need to modify this file.

InfoPlist.strings file — used for localization.

Products. This is the file for your app (i.e., YourProduct.app) that is built when you click Xcode’s “run” button.

“Making an iOS app” involves working with these features in the typical, straightforward workflow:

• Storyboard your views by dragging and configuring graphicalobjects on a template

• Adding behaviors to the various widgets• Writing the classes as to define those behaviors (including

delegates)• Adding needed support files• Building and running the app• Iterating until you are satisfied with your app

This is all done within Xcode.

What’s Xcode?You can start developing functional, good-looking apps almost from the moment you download Xcode, Apple’s integrated development environment (IDE) for making iOS and Macintosh apps. Among other features, Xcode includes a source code editor, graphical user inter-face (GUI) editor (sometimes called Interface Builder), source code repository manager, compiler, and much more. iOS applications are typically developed by manipulating views graphically and by typing Objective-C code for the models and controllers.

To get Xcode, simply go to the App Store and download the applica-tion (it’s free). To do this, click on the App Store icon in your Mac’s dock, or visit https://itunes.apple.com/us/genre/ios/id36?mt=8

The app store will download and install Xcode in your Application folder. From Applications, double-click the Xcode icon to launch Xcode and you’ll see its splash screen (Figure 1). From there you can click on “Create a new Xcode project” to take you to a menu of several templates on which to base your application. Selecting a template opens an Xcode workspace pre-populated with frameworks and other files Xcode thinks you will need using that template.

Although you can develop, build and simulate your app on your computer in Xcode, you can’t run your app on a target device (even your own iPhone) until you become a registered iOS developer and join the iOS Developer Program. To do that, go to develop-er.app.com/ and navigate to the iOS Dev Center. While there, you will also find documentation, sample code and other useful resources such as information on how to submit your app to the iOS App Store.

Everything you do in Xcode is done in a window, called a workspace (Figure 2), consisting of multiple work areas, some of which are also divided into panes. All the files needed to build your app belong to a project, and the Navigator area (far left) lists all your projects (there can be several in a workspace) and all files for each project. Clicking on a file in the Navigator area shows its contents in the Editor area and invokes the appropriate editor. Clicking on a .h or .m file, for example, shows the file’s source code and invokes the Source editor, so you can edit the code. Clicking on .storyboard or .xib (sometimes called a “nib”) file shows the app’s storyboard and invokes the Inter-face Builder, so you can design a view using the Builder’s drag and drop features.

An especially handy feature is that the Editor area can have both a right and a left pane — with each pane aware of your edits in the other. So, for example, you can simultaneously edit an object’s .h

header file in the left pane and its corresponding .m in the right pane. Or you might click on a button object (displayed graphically) in the left pane and edit its method’s source code in the right pane. To toggle between a single pane (the “Standard Editor”) and double pane view (the “Assistant Editor”), use the Editor selector button on the right of the toolbar. You can option+command+click a symbol in the editor to open the definition in the opposite editor pane.

You can also resize the entire Editor area simply by dragging its borders. For even more editing space, you can also remove the Debug area or both the Debug and Utility areas using the View Selector button on the far right of the toolbar.

As its name suggests, the Debug area shows information, like variable state and console logs, helpful in debugging code.

The Utility area has two panes: the Inspector and Quick Help pane (top) and the Library pane (bottom). Although there are five inspectors — File, Help, Identity, Attributes, Size and Connec-tions — only the inspectors that are currently relevant appear in the Inspec-tor list at the top of the pane. (To see the name of an inspector, move the cursor over its icon in the Inspector selector bar.)

You will use inspectors to add and modify object attributes for views in the Interface Builder. For example, if you click on a UILabel in the Editor area of a storyboard, you can use the Attributes inspector to change the label’s color and use the Size inspector to change the label’s size.

The Help inspector shows help information about a selected class. Use the Identity inspector to view and manage an object’s metadata such as its class, runtime attributes, label and so forth. Use the

Connections inspector to view the outlets and actions of an interface object, to make new connections and to delete existing connections.

The Library pane has libraries of resources (like file templates, code snippets, interface objects and media files) that are prebuilt and ready to insert into your project. Use the Library selector to select which of these libraries (e.g., code snippets or interface objects) you wish to insert. To insert one, drag it directly into your storyboard while using the Interface Builder editor.

These are basics you need to know to get started using Xcode to build your first app. But to really understand how it’s done, it helps to walk through an actual app or two. Let’s start with a simple “Hello World” app that does not employ a backend connection, and then look at a somewhat more functional app that does.

“Hello World!” sample appThis app displays a button (“Press Me”) and a label (“Label”) so that when the user presses the button the text of the label changes to “Hello World!” as in Figure 3:

To get started, launch Xcode and select “Create a New Xcode Project.” From the iOS Application templates, select “Single View Application” and click “Next.” Fill in your product’s name and a company identifier, typically “com.yourCompanyName.” Deselect “Use Storyboards” and leave “Use Automatic Reference Counting” selected. Then click “Next” and select a destination for your projects files.

Follow these steps to make your app:

1. Select your project’s ViewController.xib file in the Navigator(Figure 4), to open the Interface Builder editor.

2. Drag a “Round Rect Button” from the Objects library (lowerright) onto the view in the Editor area; select the button’s textand type “Press Me.”

3. Drag a Label from the objects library onto the view, as well.4. Select and drag the Label sizing handles, centering the object

and making it wide enough to hold the “Hello World!” text; then,

5. With the “Hello World!” label still selected, click on centeralignment in the Attributes inspector.

6. Open the Assistant Editor (Figure 5), exposing the source codeheader file (ViewController.h) of the view controller you justbuilt graphically.

7. Select the button and control-drag from the button to justbelow the ViewController definition in the Assistant panel. Inthe form that opens, select “Action” for the connection type,type in a name (“showText”) and click “Connect.” This creates aninterface builder (IB) action as highlighted in Figure 6.

8. Next step is to create an outlet for the label. To do this, selectthe label object and control-drag from the label to just belowthe IB action you just created. Select “Outlet” as the connectiontype and enter a name “label” and click “Connect.” This createsan interface builder (IB) outlet as shown in Figure 7.

9. Finally, it’s time to add some logic to the view controller so itknows what to do when the button is pressed. To do this, select “ViewController.m” in the project navigator to show the code editor. Find the button’s IBAction you just created (near the bottom), place your cursor between the { } brackets and hit the return key a few times to create some extra space. Then in that space type the method for how you want the label you speci-fied to respond: _label.text=”Hello World!”; as highlighted in Figure 8.

Congratulations! Your app is done. To build and run your new app in the simulator, click the Xcode Run button in the left corner of the toolbar. When you click the button, the text will update.

Sample app with a backend This second app (named “Kinvey Test Drive”) lets the user type text on an iPhone and save the text to a backend service, like Kinvey. It also lets the user load text on the iPhone from their Kinvey backend. Reading about this app will help you learn:

• How to set up Kinvey’s library in an iOS project• Additional Interface Builder techniques you can use to story-board an application• How to add view controller logic to interact with the backend service, allowing you to save and retrieve data

We will first present the app as a running application and then take it apart so you can see how it was made. To make the app yourself, you can review the various sections below and replicate the steps in your copy of Xcode.

First, to see the app in action, you should download the app and run it on your system. To do that, sign up for Kinvey, then navigate to “Dev Center”, “Samples,” find the “Test Drive” app, and click on its icon. (If you can’t find it right away, make sure you select iOS as your platform on the right side of the menu bar.) Click the download button to download the app’s project files to your computer. Then launch Xcode — just double click on the .xcodeproj file in the project folder.

But before you can run the app, you need to set up the app’s Kinvey backend.

Set Up Kinvey as a Backend Data StoreTest Drive’s project files include all the code the sample app needs in order to talk to Kinvey. However, that would not be the case if you were to build an app from scratch — so you would have to go through an initial Kinvey setup procedure. This involves downloading the Kinvey library files from the downloads section of devcenter.kin-vey.com and dragging them to the Navigator’s Frameworks folder in Xcode. You also need to tell Xcode to link your project with additional iOS frameworks. To find these frameworks, click on the Project folder

at the very top of the Navigator pane — which displays the Project editor — and then select the “Build Settings” tab. For detailed instruc-tions, complete the “Getting Started” page under “Guides” on the Kinvey website. But again, you can skip this setup procedure for now in order to run the downloaded Kinvey Test Drive app.

But you must still do this step: To run any app that uses Kinvey (including Test Drive) you need to do the “Create an App” step on the Kinvey website. Click on “My Apps” in the Kinvey menu bar and then click on “Add an App,” which will open an “Add” page. Type in a name for your app and click on the Apple logo and then click “Create.” The page that opens shows your App’s credentials. Copy and paste the App Key and App Secret into the AppDelegate.m file of the download-ed Test Drive project:

You are now ready to run the app — click on the Xcode run button and wait for the simulator to open and the app to appear (Figure 9).

Clicking the “+” toolbar button opens an alert (Figure 10) with an empty field into which the user can type some text (e.g., “some new data”). Clicking “save” uploads the data to Kinvey and displays text on the screen (a table view) and also displays an alert that the save worked (Figure 11).

To test the load function, enter some data (e.g., “some data to load”) in the “name” field of the Kinvey collection. To see the load, the swipe down on the table on the phone until the refresh spinner starts, and then the new data will appear in the table (Figure 12).

Figure 13 shows the Kinvey collection after the save that Figure 10 depicts on the iPhone. Figure 14 shows the Kinvey collection after the user adds a new row to the testObjects collection using the web browser. Note that every time a save is done on the iPhone, Kinvey automatically adds a new row (displayed on a collection refresh). To add a new row manually in the browser, click “+ row,” and type some descriptive text in the “name” column. That data will now load on the iPhone when the user pulls down on the table.

Storyboard the Test Drive AppMost of the Test Drive user interface objects visible in the simulation are available in Xcode’s Object Library and can therefore be added to the view graphically. The UI objects consist of a:

• Table view• Toolbar• Tool Bar Button item – flexible space• Tool Bar Button item – Add• Table view cell• Label – Title• Refresh Control

To create this app yourself, you would follow these steps:

• Launch Xcode and select the “Single View Application” template• Select the “Use Storyboard” option• Replace the default UIviewcontroller object with a UITableView-Controller • Drag and drop the other objects, in the order listed, onto the UIviewcontroller

Also note:

• The Flexible Space Bar Button item fills up the space on the toolbar so the add button is at the right. This is a standard pattern in table-based iPhone apps.• The add button shows the system “+” sign. That is done by dragging a bar button item onto the toolbar, clicking on the Identifier drop down menu in the Attributes inspector; and then selecting the “Add” option.

As with the “Hello World!” app, once your app’s view is complete (Figure 15), you would still have to create the various methods and connections that bring them to life. This is done using the Source editor while working with the ViewController.m file.

Add View Controller LogicSince the app performs two basic operations (save data to Kinvey and load data from Kinvey) these two methods must be added to the ViewController header file. That’s done with a control-drag from the “+” bar button over to just under the “@ interface ViewController” line in ViewController.h. (Open the Assistant editor to see both the storyboard and the file source.)

During the drag, the popup appears, asking for the name and type of connection. Enter “action” for the connection type and “add” for the name. Then repeat the drag, this time from the refresh control and using “add” for the name (Figure 16).

Note: to follow this discussion it will help to have the referenced files open in your Xcode Source editor.

In ViewController.m, you will see the implementation code associated with each of the two Interface Builder methods, whose names Xcode added automatically to the .m file:

- (IBAction)add:(id)sender- (IBAction)load:(id)sender

You will also see a third section of code not associated with these methods, which starts with the line: “#pragma mark - Table View Stuff.” These methods support the table view and are part of UITableViewD-elegate and UITableViewDataSource. They handle controlling the

display of the table, and respond to user gestures. For example, swiping a table cell will show the delete button because tableView:-canEditRowAtIndexPath: returns YES and tableView:editingStyleForRowA-tIndexPath: returns UITableViewCellEditingStyleDelete. If you tap the delete button, the delegate method tableView:commitEditingStyle:for-RowAtIndexPath: is called. The code of this method deletes the data for the row and removes it from Kinvey’s data store. When the backend delete is completed, the app displays an alert describing the success or failure.

The way that all three sections (and all Kinvey-enabled apps) move data in and out of a Kinvey collection is by getting a reference to the app’s backend collection (named “testObjects”), which is filled with instances (each named “TestObject”) of the data the app wants to move. That’s why you’ll find the following code repeated three times in Test Drive’s View Controller (once for the add, once for the load, and once for the delete):

To support these statements it is required to have a data object class (TestObject). To see how these files are written in the sample project, click on TestObject.h file and TestObject.m in the Navigator pane. If you were to supply these files in your own app, you would click File > New File, and specify Objective-C class, which would be a subclass of NSObject. Then you would type in the code, with a property for each column in the Kinvey backend collection (including one for the object’s id).

As mentioned earlier, your app also needs to authenticate itself to Kinvey, which is handled by AppDelegate.h and AppDelgate.m. These files are created by Xcode when you create a new project, and start out with just a stub implementation. Look in the sample app source

files for code to copy and paste.

For both the save and load operations, however, moving the data in and out of a backend collection is only part of the work. Table 1 lists all the functions that implements the save and load in the ViewCon-troller.m file, along with pointers to its corresponding block of imple-mentation source code. (For each function, its corresponding code begins with the “Starts at” line and ends with the “Ends at” line.) Refer to Appendix 1 to find the actual source code.

Say Hello To Our WorldThe key takeaway from all this is that “making an app” is a worthwhile thing to do for anyone with a clever idea and a working knowledge of Objective-C. The proof is in the hundreds of apps succeeding in the market every day, many written by people working on their own and who never wrote an app before in their lives. As with anything else, practice does make perfect. But hopefully with all the resources available, and the knowledge gained from this ebook, you have already started down the path toward joining the growing legions of iOS app developers. If so, we welcome you!

Appendix 1 — Test Drive Sample App ViewController.m Source Code

15

The iOS revolutionIt’s a story that never gets old. The weekend that iPad Minis and the fourth generation iPads went on sale (November 2-5, 2012) Apple sold over 3 million of the devices — a record for first-weekend iPad sales. Two months earlier the company had set another record: first weekend sales of over 5 million for the iPhone 5. Since the introduc-tion of the first iPhone back in 2007,

iOS-based devices (iPhone, iPad, iPad Mini and iPod Touch) continue to rewrite the definition of what constitutes a successful product. By the end of 2012, over 400 million iOS devices had been sold.

What makes iOS devices so successful? Innovation and product features are clearly a big part. Before the iPhone most people had not interacted with a multi-touch interface. They had never zoomed with a pinch or switched between portrait and landscape by merely rotating a device in their hand. Carrying a phone that knew where they were, could suggest places to eat, and could offer directions on how to get there was also a novel experience.

But features like multi-touch, accelerometers and GPS are only part of the appeal. Even with all its innovations, iOS still might not have taken off the way it has if the only people figuring out ways to use those innovations worked at Apple. Most of the capabilities available in an iPhone or iPad in fact don’t come from Apple at all. They come from legions of third-party developers who work in a vast ecosystem that is also an Apple innovation. That ecosystem includes the iPhone, iPad, iPad Mini, iPods, App Store, iTunes, ad networks — and that’s just on the consumer side. On the developer side, you have Xcode, App Loader, testing tools, iTunes Connect — the list goes on.

As of September 2012, the App Store hosted over 700,000 apps that have collectively been downloaded over 30 billion times. Apple reported for October 2012 that App Store monthly revenues were

running at $333 million — a rate of about $4 billion per year — remarkable for a store that only opened in July 2008.

Another innovation that has spurred iOS app development is “The Cloud.” Cloud services make it easier for independent developers to create, support and make money from their apps. The Cloud solves data storage and cross-device and user-to-user sharing problems. If an app stores data in the Cloud, that part of the application is called the “backend,” while the part of the app that runs on the phone and interacts with the user is called the “front end.”

A cloud may be “private” — i.e., the services belong to an organization for the benefit of its employees and business partners. Or a cloud may be “public” — i.e., a company (such as Amazon or Kinvey) owns the services, which developers can then integrate into their own apps. If you are a developer and want to build your own backend, you certainly can do that. Whether you want to or not depends on whether your backend provides functionality common to many different apps. If it does (as in a shopping cart or user authenti-cation) then perhaps that time and money would be better spent on features that offer unique value to your customer. You may be better off hooking into a commercial backend provider via an API. Then you can focus on what counts most — a unique user experience and application-specific functionality. That brings us to the first step in making an app.

Define your appMost unsuccessful apps fail for any of four reasons:

1. the app was a solution in search of a problem (i.e., no real need existed) 2. the implementation was poor 3. the app tried to do too much; or 4. the Apple App Store rejected the app (either because the implementation was poor or it violated Apple’s content policies)

Keeping the app as simple as possible is the best way to avoid these pitfalls. Most successful apps (indeed, most successful consumer tech products) are based on what is called an MVP, or minimum viable product. It’s the product with the smallest feature set that can deliver the core function without any distracting “bells and whistles.” You know you have an MVP if the product would no longer function if you removed any single feature.

But what should that core feature be? One of the best examples of an MVP is Mail. Version 1 (on the Mac) offered a clear, limited and intuitive feature set whose usefulness was immediately obvious to anyone. Today’s iPhone version integrates seamlessly with your phone, contacts and calendaring. It auto-matically corrects spelling as you type, lets you email photos directly from your photos app, and does much more. But all that came later and was built on top of a basic core function. And that’s how your first app should be built. The key is to come up with something with a clear value that changes people’s lives.

So, in drawing up your MVP feature list, ask yourself what features are key to the experience. Some basic market research is probably in order, starting with a visit to the App Store to see what already exists (possibly to be improved upon and/or to compete with you). Likely

must-have core capabilities include:

• Performance (e.g., fast screen refresh)• Offline capability (i.e., ability to work when not connected to the Internet)• Location awareness (e.g., the data/experience will change with the user’s location)• Cloud syncing (e.g., users see the same data on multiple devices)• Push notifications (i.e., sending updated information to devices as soon as it is available)

When you have a handle on what your app does, the next step is to design it. Designing your app involves making choices of how infor-mation and controls are presented to the user as well as how to implement app logic, and figuring out what data lives locally and what belongs in the Cloud.

Design your appUser experience decisions determine the app’s look and feel. They answer questions such as: What does the app look like? What screens does it have? In the software development world, onscreen objects like buttons, sliders, and fill-in boxes are called widgets. So you need to decide which types of widgets will reside on which screens. And what actions will occur as a result of the user interacting with those widgets?

Keep in mind that users will expect to interact differently with a mobile device than they do with a PC because the screens on mobile devices are much smaller. They’ll expect to use their fingers instead of a mouse or a track pad. Ideally, your app can even be used with one hand holding the device while using just a thumb for scrolling andworking the app’s other controls— the Path app is a good example, and increasingly, so is Facebook.

Your app’s features will inform its architecture, which is how you’ll divide the code and data into functional parts. If your app requires interacting with other app users or networked services, you’ll need to figure out what piece of the logic lives in the app code and what comes from the backend. For example, your app might integrate with a restau-rant recommendation engine, share user location, or pull real-time traffic data. This is done using APIs provided by various service providers — but you don’t have to wire up your app to a network to get started. You can develop a prototype using predefined representative (or “dummy”) data. It’s easier to fine-tune the front end if you don’t have to simultaneously modify your backend too. Once you get the app’s look-and-feel right, then make those backend connections.

Once you’ve got the overall concept for your app, the next step is to express that design in terms of the iOS app architecture. That archi-tecture is the model for what parts an iOS app can contain and how those parts fit together. It’s a well thought-out approach for translat-ing a product concept into actual code you can deploy on a device.

WHY iOS?Besides the features and design of your first app, there’s one more decision you need to make before you start actual development. That’s whether to deploy on Apple’s iOS platform or on Google’s Android platform. (Some of this is also covered in our ebook, How to Make an App: Android Edition.) Reasons to develop for iOS include:

Customers more willing to pay. Perhaps it’s because of Android’s open source heritage, but whatever the reason, Android apps gener-ate less than 10% of the total dollars spent on mobile apps, despite having 75% of the smartphone market itself — and despite the fact that the average selling price of an app in the Google Play is $3.79 versus Apple App Store’s $2.01. In other words, Apple users are much more willing to spend money on apps.

The Apple Ecosystem. Some developers and users prefer Apple’s closed and more tightly controlled environment. Apple’s ecosystem, consisting of Xcode, iCloud, iTunes, the App Store, the iPad, the iPhone, Mac computers, etc., offers a very holistic user experience with the ability to share data seamlessly across devices plus the

assurance of having applications pre-approved for quality and content prior to going on sale.

Xcode. Apple’s all-in-one IDE offers state-of-the-art offers features like a graphical interface builder and a syntax-aware and compiler-aware source editor.

The Apple Experience. From the fit and finish of its hardware to the customer service in its retail stores, to the way its hardware and software work flawlessly together, Apple has created the premium brand in consumer electronics. iOS developers share the benefits — so when someone downloads your iOS app, they already expect it’s a great product. And that it will also work flawlessly on their device.

Tablets. iOS has a clear advantage over Android in terms of tablet market adoption. Using Xcode, it’s also much easier to migrate an app from a phone to a tablet and vice versa than it is when develop-ing for Android.

Why Not iOS?Although iOS offers many compelling advantages as a platform for your mobile app, it also comes with some disadvantages. Here are three:

Closed Platform. iOS apps only run on Apple products so you can’t take advantage of features (like NFC) available only on non-iOS devices or market growth of non-iOS devices.

Market Growth. Today, iOS represents less than 15% of the total smartphone market, Although the total market (“the whole pie”) is still increasing at a fast rate, Android market growth outpaces iOS growth.

Approvals. The App Store’s app approval process is notoriously more time consuming than Google Play’s process.

The iOS app architectureAs noted earlier, a key reason why there are so many apps for iOS is because developing highly functional, polished apps for the platform is relatively easy. That’s mainly because of: 1) the design of the development tools, and 2) the key architectural features most iOS apps have in common. So let’s start with some concepts since it helps to know what goes into an app before trying to create one. We’ll begin with:

• Design patterns• Frameworks• Delegation• Storyboard• Windows• Outlets• Supporting files• Products

Design patterns. iOS apps implement what is known as a Mod-el-View-Controller (MVC) pattern. A pattern is a common way to structure code that solves a particular design problem. The MVC pattern separates application code in a way that allows you to easily change one part of an app without having to change other parts. An MVC pattern consists of three components:

• The Model is the logic that acts on the data, such as to store or retrieve data from a database, compute the distance between two cities on a map, etc. An example of a model is the Kinvey backend that stores your data in the Cloud as a service.

• The View provides the interface to the user; it displays the data and widgets (e.g., buttons and text fields) that allow the user to interact with the data. An iPhone app may have more than one view, as in the Contacts app, which displays a list view of all contacts or alternatively a view of each individual contact.

• The Controller is between the model and the view — i.e., it responds to user requests (made in a view) and retrieves results

(produced in a model). This is where developers spend most of their time — constructing the View Controller — by defining and attaching actions (or behaviors) to onscreen widgets. When the user taps a button, for example, it is the View Controller that determines what action will occur, such as retrieve stored data from your Kinvey-based data store. The link between a view object (like a button) to a controller action is called a connection.

Frameworks. You don’t actually have to write most of an app’s logic. It already exists as frameworks. A framework is a collection of classes that implements some function — such as connecting to the Internet, drawing a button, etc. Rather than write the code from scratch, you just use the frameworks supplied by iOS. Some frameworks are automatically present when you start a new project while others may need to be added (done via a drop down menu in Xcode’s Project Editor).

Delegation. Say, you want to customize the behavior of a framework’s object. You can’t actually modify the code of the framework class itself (prohibited since other apps may also use the framework). But what you can do is provide app-specific behavior in an application delegate object. If a delegate implements a method, it will be called by the delegating class to modify its behavior. In the Kinvey sample app (one of two examples we will be describing below), the AppDele-gate.h and AppDelegate.m — the header and implementation files for the UIApplicationDelegate, respectively — contain the code that authenticates an app to the Kinvey backend service.

Storyboards and XIBs. The MainStoryboard.storyboard file (or a .xib file, if you did not click on the “Use Storyboard” option when starting your project) contains the view information needed to implement the overall flow and display of your application and the user interface elements.

Windows. Each view (e.g., the contact list and individual contact details in the Contacts app) exists within a window. The window represents the entire device screen and is where all your views are presented.

Outlets. A variable by which a view object can be referenced in a controller. (For example, if you place a text field to capture a user's name, you might create an outlet called UITextField* nameField.)

Supporting files. These are files that provide resources (like PNG images and other static data) that your app needs as well as files that configure how the app will run. Other examples:

.pch files — precompiled headers used for the code files in your project.

.plist files — property lists that are small amounts of persistent data (like your app’s default user settings) consisting primarily of strings and numbers that you want your app to be able to access, modify if needed, and write back into the property list.

main.m file — your app’s main function. This is needed to launch the app, but you will not need to modify this file.

InfoPlist.strings file — used for localization.

Products. This is the file for your app (i.e., YourProduct.app) that is built when you click Xcode’s “run” button.

“Making an iOS app” involves working with these features in the typical, straightforward workflow:

• Storyboard your views by dragging and configuring graphicalobjects on a template

• Adding behaviors to the various widgets• Writing the classes as to define those behaviors (including

delegates)• Adding needed support files• Building and running the app• Iterating until you are satisfied with your app

This is all done within Xcode.

What’s Xcode?You can start developing functional, good-looking apps almost from the moment you download Xcode, Apple’s integrated development environment (IDE) for making iOS and Macintosh apps. Among other features, Xcode includes a source code editor, graphical user inter-face (GUI) editor (sometimes called Interface Builder), source code repository manager, compiler, and much more. iOS applications are typically developed by manipulating views graphically and by typing Objective-C code for the models and controllers.

To get Xcode, simply go to the App Store and download the applica-tion (it’s free). To do this, click on the App Store icon in your Mac’s dock, or visit https://itunes.apple.com/us/genre/ios/id36?mt=8

The app store will download and install Xcode in your Application folder. From Applications, double-click the Xcode icon to launch Xcode and you’ll see its splash screen (Figure 1). From there you can click on “Create a new Xcode project” to take you to a menu of several templates on which to base your application. Selecting a template opens an Xcode workspace pre-populated with frameworks and other files Xcode thinks you will need using that template.

Although you can develop, build and simulate your app on your computer in Xcode, you can’t run your app on a target device (even your own iPhone) until you become a registered iOS developer and join the iOS Developer Program. To do that, go to develop-er.app.com/ and navigate to the iOS Dev Center. While there, you will also find documentation, sample code and other useful resources such as information on how to submit your app to the iOS App Store.

Everything you do in Xcode is done in a window, called a workspace (Figure 2), consisting of multiple work areas, some of which are also divided into panes. All the files needed to build your app belong to a project, and the Navigator area (far left) lists all your projects (there can be several in a workspace) and all files for each project. Clicking on a file in the Navigator area shows its contents in the Editor area and invokes the appropriate editor. Clicking on a .h or .m file, for example, shows the file’s source code and invokes the Source editor, so you can edit the code. Clicking on .storyboard or .xib (sometimes called a “nib”) file shows the app’s storyboard and invokes the Inter-face Builder, so you can design a view using the Builder’s drag and drop features.

An especially handy feature is that the Editor area can have both a right and a left pane — with each pane aware of your edits in the other. So, for example, you can simultaneously edit an object’s .h

header file in the left pane and its corresponding .m in the right pane. Or you might click on a button object (displayed graphically) in the left pane and edit its method’s source code in the right pane. To toggle between a single pane (the “Standard Editor”) and double pane view (the “Assistant Editor”), use the Editor selector button on the right of the toolbar. You can option+command+click a symbol in the editor to open the definition in the opposite editor pane.

You can also resize the entire Editor area simply by dragging its borders. For even more editing space, you can also remove the Debug area or both the Debug and Utility areas using the View Selector button on the far right of the toolbar.

As its name suggests, the Debug area shows information, like variable state and console logs, helpful in debugging code.

The Utility area has two panes: the Inspector and Quick Help pane (top) and the Library pane (bottom). Although there are five inspectors — File, Help, Identity, Attributes, Size and Connec-tions — only the inspectors that are currently relevant appear in the Inspec-tor list at the top of the pane. (To see the name of an inspector, move the cursor over its icon in the Inspector selector bar.)

You will use inspectors to add and modify object attributes for views in the Interface Builder. For example, if you click on a UILabel in the Editor area of a storyboard, you can use the Attributes inspector to change the label’s color and use the Size inspector to change the label’s size.

The Help inspector shows help information about a selected class. Use the Identity inspector to view and manage an object’s metadata such as its class, runtime attributes, label and so forth. Use the

Connections inspector to view the outlets and actions of an interface object, to make new connections and to delete existing connections.

The Library pane has libraries of resources (like file templates, code snippets, interface objects and media files) that are prebuilt and ready to insert into your project. Use the Library selector to select which of these libraries (e.g., code snippets or interface objects) you wish to insert. To insert one, drag it directly into your storyboard while using the Interface Builder editor.

These are basics you need to know to get started using Xcode to build your first app. But to really understand how it’s done, it helps to walk through an actual app or two. Let’s start with a simple “Hello World” app that does not employ a backend connection, and then look at a somewhat more functional app that does.

“Hello World!” sample appThis app displays a button (“Press Me”) and a label (“Label”) so that when the user presses the button the text of the label changes to “Hello World!” as in Figure 3:

To get started, launch Xcode and select “Create a New Xcode Project.” From the iOS Application templates, select “Single View Application” and click “Next.” Fill in your product’s name and a company identifier, typically “com.yourCompanyName.” Deselect “Use Storyboards” and leave “Use Automatic Reference Counting” selected. Then click “Next” and select a destination for your projects files.

Follow these steps to make your app:

1. Select your project’s ViewController.xib file in the Navigator(Figure 4), to open the Interface Builder editor.

2. Drag a “Round Rect Button” from the Objects library (lowerright) onto the view in the Editor area; select the button’s textand type “Press Me.”

3. Drag a Label from the objects library onto the view, as well.4. Select and drag the Label sizing handles, centering the object

and making it wide enough to hold the “Hello World!” text; then,

5. With the “Hello World!” label still selected, click on centeralignment in the Attributes inspector.

6. Open the Assistant Editor (Figure 5), exposing the source codeheader file (ViewController.h) of the view controller you justbuilt graphically.

7. Select the button and control-drag from the button to justbelow the ViewController definition in the Assistant panel. Inthe form that opens, select “Action” for the connection type,type in a name (“showText”) and click “Connect.” This creates aninterface builder (IB) action as highlighted in Figure 6.

8. Next step is to create an outlet for the label. To do this, selectthe label object and control-drag from the label to just belowthe IB action you just created. Select “Outlet” as the connectiontype and enter a name “label” and click “Connect.” This createsan interface builder (IB) outlet as shown in Figure 7.

9. Finally, it’s time to add some logic to the view controller so itknows what to do when the button is pressed. To do this, select “ViewController.m” in the project navigator to show the code editor. Find the button’s IBAction you just created (near the bottom), place your cursor between the { } brackets and hit the return key a few times to create some extra space. Then in that space type the method for how you want the label you speci-fied to respond: _label.text=”Hello World!”; as highlighted in Figure 8.

Congratulations! Your app is done. To build and run your new app in the simulator, click the Xcode Run button in the left corner of the toolbar. When you click the button, the text will update.

Sample app with a backend This second app (named “Kinvey Test Drive”) lets the user type text on an iPhone and save the text to a backend service, like Kinvey. It also lets the user load text on the iPhone from their Kinvey backend. Reading about this app will help you learn:

• How to set up Kinvey’s library in an iOS project• Additional Interface Builder techniques you can use to story-board an application• How to add view controller logic to interact with the backend service, allowing you to save and retrieve data

We will first present the app as a running application and then take it apart so you can see how it was made. To make the app yourself, you can review the various sections below and replicate the steps in your copy of Xcode.

First, to see the app in action, you should download the app and run it on your system. To do that, sign up for Kinvey, then navigate to “Dev Center”, “Samples,” find the “Test Drive” app, and click on its icon. (If you can’t find it right away, make sure you select iOS as your platform on the right side of the menu bar.) Click the download button to download the app’s project files to your computer. Then launch Xcode — just double click on the .xcodeproj file in the project folder.

But before you can run the app, you need to set up the app’s Kinvey backend.

Set Up Kinvey as a Backend Data StoreTest Drive’s project files include all the code the sample app needs in order to talk to Kinvey. However, that would not be the case if you were to build an app from scratch — so you would have to go through an initial Kinvey setup procedure. This involves downloading the Kinvey library files from the downloads section of devcenter.kin-vey.com and dragging them to the Navigator’s Frameworks folder in Xcode. You also need to tell Xcode to link your project with additional iOS frameworks. To find these frameworks, click on the Project folder

at the very top of the Navigator pane — which displays the Project editor — and then select the “Build Settings” tab. For detailed instruc-tions, complete the “Getting Started” page under “Guides” on the Kinvey website. But again, you can skip this setup procedure for now in order to run the downloaded Kinvey Test Drive app.

But you must still do this step: To run any app that uses Kinvey (including Test Drive) you need to do the “Create an App” step on the Kinvey website. Click on “My Apps” in the Kinvey menu bar and then click on “Add an App,” which will open an “Add” page. Type in a name for your app and click on the Apple logo and then click “Create.” The page that opens shows your App’s credentials. Copy and paste the App Key and App Secret into the AppDelegate.m file of the download-ed Test Drive project:

You are now ready to run the app — click on the Xcode run button and wait for the simulator to open and the app to appear (Figure 9).

Clicking the “+” toolbar button opens an alert (Figure 10) with an empty field into which the user can type some text (e.g., “some new data”). Clicking “save” uploads the data to Kinvey and displays text on the screen (a table view) and also displays an alert that the save worked (Figure 11).

To test the load function, enter some data (e.g., “some data to load”) in the “name” field of the Kinvey collection. To see the load, the swipe down on the table on the phone until the refresh spinner starts, and then the new data will appear in the table (Figure 12).

Figure 13 shows the Kinvey collection after the save that Figure 10 depicts on the iPhone. Figure 14 shows the Kinvey collection after the user adds a new row to the testObjects collection using the web browser. Note that every time a save is done on the iPhone, Kinvey automatically adds a new row (displayed on a collection refresh). To add a new row manually in the browser, click “+ row,” and type some descriptive text in the “name” column. That data will now load on the iPhone when the user pulls down on the table.

Storyboard the Test Drive AppMost of the Test Drive user interface objects visible in the simulation are available in Xcode’s Object Library and can therefore be added to the view graphically. The UI objects consist of a:

• Table view• Toolbar• Tool Bar Button item – flexible space• Tool Bar Button item – Add• Table view cell• Label – Title• Refresh Control

To create this app yourself, you would follow these steps:

• Launch Xcode and select the “Single View Application” template• Select the “Use Storyboard” option• Replace the default UIviewcontroller object with a UITableView-Controller • Drag and drop the other objects, in the order listed, onto the UIviewcontroller

Also note:

• The Flexible Space Bar Button item fills up the space on the toolbar so the add button is at the right. This is a standard pattern in table-based iPhone apps.• The add button shows the system “+” sign. That is done by dragging a bar button item onto the toolbar, clicking on the Identifier drop down menu in the Attributes inspector; and then selecting the “Add” option.

As with the “Hello World!” app, once your app’s view is complete (Figure 15), you would still have to create the various methods and connections that bring them to life. This is done using the Source editor while working with the ViewController.m file.

Add View Controller LogicSince the app performs two basic operations (save data to Kinvey and load data from Kinvey) these two methods must be added to the ViewController header file. That’s done with a control-drag from the “+” bar button over to just under the “@ interface ViewController” line in ViewController.h. (Open the Assistant editor to see both the storyboard and the file source.)

During the drag, the popup appears, asking for the name and type of connection. Enter “action” for the connection type and “add” for the name. Then repeat the drag, this time from the refresh control and using “add” for the name (Figure 16).

Note: to follow this discussion it will help to have the referenced files open in your Xcode Source editor.

In ViewController.m, you will see the implementation code associated with each of the two Interface Builder methods, whose names Xcode added automatically to the .m file:

- (IBAction)add:(id)sender- (IBAction)load:(id)sender

You will also see a third section of code not associated with these methods, which starts with the line: “#pragma mark - Table View Stuff.” These methods support the table view and are part of UITableViewD-elegate and UITableViewDataSource. They handle controlling the

display of the table, and respond to user gestures. For example, swiping a table cell will show the delete button because tableView:-canEditRowAtIndexPath: returns YES and tableView:editingStyleForRowA-tIndexPath: returns UITableViewCellEditingStyleDelete. If you tap the delete button, the delegate method tableView:commitEditingStyle:for-RowAtIndexPath: is called. The code of this method deletes the data for the row and removes it from Kinvey’s data store. When the backend delete is completed, the app displays an alert describing the success or failure.

The way that all three sections (and all Kinvey-enabled apps) move data in and out of a Kinvey collection is by getting a reference to the app’s backend collection (named “testObjects”), which is filled with instances (each named “TestObject”) of the data the app wants to move. That’s why you’ll find the following code repeated three times in Test Drive’s View Controller (once for the add, once for the load, and once for the delete):

To support these statements it is required to have a data object class (TestObject). To see how these files are written in the sample project, click on TestObject.h file and TestObject.m in the Navigator pane. If you were to supply these files in your own app, you would click File > New File, and specify Objective-C class, which would be a subclass of NSObject. Then you would type in the code, with a property for each column in the Kinvey backend collection (including one for the object’s id).

As mentioned earlier, your app also needs to authenticate itself to Kinvey, which is handled by AppDelegate.h and AppDelgate.m. These files are created by Xcode when you create a new project, and start out with just a stub implementation. Look in the sample app source

files for code to copy and paste.

For both the save and load operations, however, moving the data in and out of a backend collection is only part of the work. Table 1 lists all the functions that implements the save and load in the ViewCon-troller.m file, along with pointers to its corresponding block of imple-mentation source code. (For each function, its corresponding code begins with the “Starts at” line and ends with the “Ends at” line.) Refer to Appendix 1 to find the actual source code.

Say Hello To Our WorldThe key takeaway from all this is that “making an app” is a worthwhile thing to do for anyone with a clever idea and a working knowledge of Objective-C. The proof is in the hundreds of apps succeeding in the market every day, many written by people working on their own and who never wrote an app before in their lives. As with anything else, practice does make perfect. But hopefully with all the resources available, and the knowledge gained from this ebook, you have already started down the path toward joining the growing legions of iOS app developers. If so, we welcome you!

Appendix 1 — Test Drive Sample App ViewController.m Source Code

16

The iOS revolutionIt’s a story that never gets old. The weekend that iPad Minis and the fourth generation iPads went on sale (November 2-5, 2012) Apple sold over 3 million of the devices — a record for first-weekend iPad sales. Two months earlier the company had set another record: first weekend sales of over 5 million for the iPhone 5. Since the introduc-tion of the first iPhone back in 2007,

iOS-based devices (iPhone, iPad, iPad Mini and iPod Touch) continue to rewrite the definition of what constitutes a successful product. By the end of 2012, over 400 million iOS devices had been sold.

What makes iOS devices so successful? Innovation and product features are clearly a big part. Before the iPhone most people had not interacted with a multi-touch interface. They had never zoomed with a pinch or switched between portrait and landscape by merely rotating a device in their hand. Carrying a phone that knew where they were, could suggest places to eat, and could offer directions on how to get there was also a novel experience.

But features like multi-touch, accelerometers and GPS are only part of the appeal. Even with all its innovations, iOS still might not have taken off the way it has if the only people figuring out ways to use those innovations worked at Apple. Most of the capabilities available in an iPhone or iPad in fact don’t come from Apple at all. They come from legions of third-party developers who work in a vast ecosystem that is also an Apple innovation. That ecosystem includes the iPhone, iPad, iPad Mini, iPods, App Store, iTunes, ad networks — and that’s just on the consumer side. On the developer side, you have Xcode, App Loader, testing tools, iTunes Connect — the list goes on.

As of September 2012, the App Store hosted over 700,000 apps that have collectively been downloaded over 30 billion times. Apple reported for October 2012 that App Store monthly revenues were

running at $333 million — a rate of about $4 billion per year — remarkable for a store that only opened in July 2008.

Another innovation that has spurred iOS app development is “The Cloud.” Cloud services make it easier for independent developers to create, support and make money from their apps. The Cloud solves data storage and cross-device and user-to-user sharing problems. If an app stores data in the Cloud, that part of the application is called the “backend,” while the part of the app that runs on the phone and interacts with the user is called the “front end.”

A cloud may be “private” — i.e., the services belong to an organization for the benefit of its employees and business partners. Or a cloud may be “public” — i.e., a company (such as Amazon or Kinvey) owns the services, which developers can then integrate into their own apps. If you are a developer and want to build your own backend, you certainly can do that. Whether you want to or not depends on whether your backend provides functionality common to many different apps. If it does (as in a shopping cart or user authenti-cation) then perhaps that time and money would be better spent on features that offer unique value to your customer. You may be better off hooking into a commercial backend provider via an API. Then you can focus on what counts most — a unique user experience and application-specific functionality. That brings us to the first step in making an app.

Define your appMost unsuccessful apps fail for any of four reasons:

1. the app was a solution in search of a problem (i.e., no real need existed) 2. the implementation was poor 3. the app tried to do too much; or 4. the Apple App Store rejected the app (either because the implementation was poor or it violated Apple’s content policies)

Keeping the app as simple as possible is the best way to avoid these pitfalls. Most successful apps (indeed, most successful consumer tech products) are based on what is called an MVP, or minimum viable product. It’s the product with the smallest feature set that can deliver the core function without any distracting “bells and whistles.” You know you have an MVP if the product would no longer function if you removed any single feature.

But what should that core feature be? One of the best examples of an MVP is Mail. Version 1 (on the Mac) offered a clear, limited and intuitive feature set whose usefulness was immediately obvious to anyone. Today’s iPhone version integrates seamlessly with your phone, contacts and calendaring. It auto-matically corrects spelling as you type, lets you email photos directly from your photos app, and does much more. But all that came later and was built on top of a basic core function. And that’s how your first app should be built. The key is to come up with something with a clear value that changes people’s lives.

So, in drawing up your MVP feature list, ask yourself what features are key to the experience. Some basic market research is probably in order, starting with a visit to the App Store to see what already exists (possibly to be improved upon and/or to compete with you). Likely

must-have core capabilities include:

• Performance (e.g., fast screen refresh)• Offline capability (i.e., ability to work when not connected to the Internet)• Location awareness (e.g., the data/experience will change with the user’s location)• Cloud syncing (e.g., users see the same data on multiple devices)• Push notifications (i.e., sending updated information to devices as soon as it is available)

When you have a handle on what your app does, the next step is to design it. Designing your app involves making choices of how infor-mation and controls are presented to the user as well as how to implement app logic, and figuring out what data lives locally and what belongs in the Cloud.

Design your appUser experience decisions determine the app’s look and feel. They answer questions such as: What does the app look like? What screens does it have? In the software development world, onscreen objects like buttons, sliders, and fill-in boxes are called widgets. So you need to decide which types of widgets will reside on which screens. And what actions will occur as a result of the user interacting with those widgets?

Keep in mind that users will expect to interact differently with a mobile device than they do with a PC because the screens on mobile devices are much smaller. They’ll expect to use their fingers instead of a mouse or a track pad. Ideally, your app can even be used with one hand holding the device while using just a thumb for scrolling andworking the app’s other controls— the Path app is a good example, and increasingly, so is Facebook.

Your app’s features will inform its architecture, which is how you’ll divide the code and data into functional parts. If your app requires interacting with other app users or networked services, you’ll need to figure out what piece of the logic lives in the app code and what comes from the backend. For example, your app might integrate with a restau-rant recommendation engine, share user location, or pull real-time traffic data. This is done using APIs provided by various service providers — but you don’t have to wire up your app to a network to get started. You can develop a prototype using predefined representative (or “dummy”) data. It’s easier to fine-tune the front end if you don’t have to simultaneously modify your backend too. Once you get the app’s look-and-feel right, then make those backend connections.

Once you’ve got the overall concept for your app, the next step is to express that design in terms of the iOS app architecture. That archi-tecture is the model for what parts an iOS app can contain and how those parts fit together. It’s a well thought-out approach for translat-ing a product concept into actual code you can deploy on a device.

WHY iOS?Besides the features and design of your first app, there’s one more decision you need to make before you start actual development. That’s whether to deploy on Apple’s iOS platform or on Google’s Android platform. (Some of this is also covered in our ebook, How to Make an App: Android Edition.) Reasons to develop for iOS include:

Customers more willing to pay. Perhaps it’s because of Android’s open source heritage, but whatever the reason, Android apps gener-ate less than 10% of the total dollars spent on mobile apps, despite having 75% of the smartphone market itself — and despite the fact that the average selling price of an app in the Google Play is $3.79 versus Apple App Store’s $2.01. In other words, Apple users are much more willing to spend money on apps.

The Apple Ecosystem. Some developers and users prefer Apple’s closed and more tightly controlled environment. Apple’s ecosystem, consisting of Xcode, iCloud, iTunes, the App Store, the iPad, the iPhone, Mac computers, etc., offers a very holistic user experience with the ability to share data seamlessly across devices plus the

assurance of having applications pre-approved for quality and content prior to going on sale.

Xcode. Apple’s all-in-one IDE offers state-of-the-art offers features like a graphical interface builder and a syntax-aware and compiler-aware source editor.

The Apple Experience. From the fit and finish of its hardware to the customer service in its retail stores, to the way its hardware and software work flawlessly together, Apple has created the premium brand in consumer electronics. iOS developers share the benefits — so when someone downloads your iOS app, they already expect it’s a great product. And that it will also work flawlessly on their device.

Tablets. iOS has a clear advantage over Android in terms of tablet market adoption. Using Xcode, it’s also much easier to migrate an app from a phone to a tablet and vice versa than it is when develop-ing for Android.

Why Not iOS?Although iOS offers many compelling advantages as a platform for your mobile app, it also comes with some disadvantages. Here are three:

Closed Platform. iOS apps only run on Apple products so you can’t take advantage of features (like NFC) available only on non-iOS devices or market growth of non-iOS devices.

Market Growth. Today, iOS represents less than 15% of the total smartphone market, Although the total market (“the whole pie”) is still increasing at a fast rate, Android market growth outpaces iOS growth.

Approvals. The App Store’s app approval process is notoriously more time consuming than Google Play’s process.

The iOS app architectureAs noted earlier, a key reason why there are so many apps for iOS is because developing highly functional, polished apps for the platform is relatively easy. That’s mainly because of: 1) the design of the development tools, and 2) the key architectural features most iOS apps have in common. So let’s start with some concepts since it helps to know what goes into an app before trying to create one. We’ll begin with:

• Design patterns• Frameworks• Delegation• Storyboard• Windows• Outlets• Supporting files• Products

Design patterns. iOS apps implement what is known as a Mod-el-View-Controller (MVC) pattern. A pattern is a common way to structure code that solves a particular design problem. The MVC pattern separates application code in a way that allows you to easily change one part of an app without having to change other parts. An MVC pattern consists of three components:

• The Model is the logic that acts on the data, such as to store or retrieve data from a database, compute the distance between two cities on a map, etc. An example of a model is the Kinvey backend that stores your data in the Cloud as a service.

• The View provides the interface to the user; it displays the data and widgets (e.g., buttons and text fields) that allow the user to interact with the data. An iPhone app may have more than one view, as in the Contacts app, which displays a list view of all contacts or alternatively a view of each individual contact.

• The Controller is between the model and the view — i.e., it responds to user requests (made in a view) and retrieves results

(produced in a model). This is where developers spend most of their time — constructing the View Controller — by defining and attaching actions (or behaviors) to onscreen widgets. When the user taps a button, for example, it is the View Controller that determines what action will occur, such as retrieve stored data from your Kinvey-based data store. The link between a view object (like a button) to a controller action is called a connection.

Frameworks. You don’t actually have to write most of an app’s logic. It already exists as frameworks. A framework is a collection of classes that implements some function — such as connecting to the Internet, drawing a button, etc. Rather than write the code from scratch, you just use the frameworks supplied by iOS. Some frameworks are automatically present when you start a new project while others may need to be added (done via a drop down menu in Xcode’s Project Editor).

Delegation. Say, you want to customize the behavior of a framework’s object. You can’t actually modify the code of the framework class itself (prohibited since other apps may also use the framework). But what you can do is provide app-specific behavior in an application delegate object. If a delegate implements a method, it will be called by the delegating class to modify its behavior. In the Kinvey sample app (one of two examples we will be describing below), the AppDele-gate.h and AppDelegate.m — the header and implementation files for the UIApplicationDelegate, respectively — contain the code that authenticates an app to the Kinvey backend service.

Storyboards and XIBs. The MainStoryboard.storyboard file (or a .xib file, if you did not click on the “Use Storyboard” option when starting your project) contains the view information needed to implement the overall flow and display of your application and the user interface elements.

Windows. Each view (e.g., the contact list and individual contact details in the Contacts app) exists within a window. The window represents the entire device screen and is where all your views are presented.

Outlets. A variable by which a view object can be referenced in a controller. (For example, if you place a text field to capture a user's name, you might create an outlet called UITextField* nameField.)

Supporting files. These are files that provide resources (like PNG images and other static data) that your app needs as well as files that configure how the app will run. Other examples:

.pch files — precompiled headers used for the code files in your project.

.plist files — property lists that are small amounts of persistent data (like your app’s default user settings) consisting primarily of strings and numbers that you want your app to be able to access, modify if needed, and write back into the property list.

main.m file — your app’s main function. This is needed to launch the app, but you will not need to modify this file.

InfoPlist.strings file — used for localization.

Products. This is the file for your app (i.e., YourProduct.app) that is built when you click Xcode’s “run” button.

“Making an iOS app” involves working with these features in the typical, straightforward workflow:

•Storyboard your views by dragging and configuring graphicalobjects on a template•Adding behaviors to the various widgets•Writing the classes as to define those behaviors (includingdelegates)•Adding needed support files•Building and running the app•Iterating until you are satisfied with your app

This is all done within Xcode.

What’s Xcode?You can start developing functional, good-looking apps almost from the moment you download Xcode, Apple’s integrated development environment (IDE) for making iOS and Macintosh apps. Among other features, Xcode includes a source code editor, graphical user inter-face (GUI) editor (sometimes called Interface Builder), source code repository manager, compiler, and much more. iOS applications are typically developed by manipulating views graphically and by typing Objective-C code for the models and controllers.

To get Xcode, simply go to the App Store and download the applica-tion (it’s free). To do this, click on the App Store icon in your Mac’s dock, or visit https://itunes.apple.com/us/genre/ios/id36?mt=8

The app store will download and install Xcode in your Application folder. From Applications, double-click the Xcode icon to launch Xcode and you’ll see its splash screen (Figure 1). From there you can click on “Create a new Xcode project” to take you to a menu of several templates on which to base your application. Selecting a template opens an Xcode workspace pre-populated with frameworks and other files Xcode thinks you will need using that template.

Although you can develop, build and simulate your app on your computer in Xcode, you can’t run your app on a target device (even your own iPhone) until you become a registered iOS developer and join the iOS Developer Program. To do that, go to develop-er.app.com/ and navigate to the iOS Dev Center. While there, you will also find documentation, sample code and other useful resources such as information on how to submit your app to the iOS App Store.

Everything you do in Xcode is done in a window, called a workspace (Figure 2), consisting of multiple work areas, some of which are also divided into panes. All the files needed to build your app belong to a project, and the Navigator area (far left) lists all your projects (there can be several in a workspace) and all files for each project. Clicking on a file in the Navigator area shows its contents in the Editor area and invokes the appropriate editor. Clicking on a .h or .m file, for example, shows the file’s source code and invokes the Source editor, so you can edit the code. Clicking on .storyboard or .xib (sometimes called a “nib”) file shows the app’s storyboard and invokes the Inter-face Builder, so you can design a view using the Builder’s drag and drop features.

An especially handy feature is that the Editor area can have both a right and a left pane — with each pane aware of your edits in the other. So, for example, you can simultaneously edit an object’s .h

header file in the left pane and its corresponding .m in the right pane. Or you might click on a button object (displayed graphically) in the left pane and edit its method’s source code in the right pane. To toggle between a single pane (the “Standard Editor”) and double pane view (the “Assistant Editor”), use the Editor selector button on the right of the toolbar. You can option+command+click a symbol in the editor to open the definition in the opposite editor pane.

You can also resize the entire Editor area simply by dragging its borders. For even more editing space, you can also remove the Debug area or both the Debug and Utility areas using the View Selector button on the far right of the toolbar.

As its name suggests, the Debug area shows information, like variable state and console logs, helpful in debugging code.

The Utility area has two panes: the Inspector and Quick Help pane (top) and the Library pane (bottom). Although there are five inspectors — File, Help, Identity, Attributes, Size and Connec-tions — only the inspectors that are currently relevant appear in the Inspec-tor list at the top of the pane. (To see the name of an inspector, move the cursor over its icon in the Inspector selector bar.)

You will use inspectors to add and modify object attributes for views in the Interface Builder. For example, if you click on a UILabel in the Editor area of a storyboard, you can use the Attributes inspector to change the label’s color and use the Size inspector to change the label’s size.

The Help inspector shows help information about a selected class. Use the Identity inspector to view and manage an object’s metadata such as its class, runtime attributes, label and so forth. Use the

Connections inspector to view the outlets and actions of an interface object, to make new connections and to delete existing connections.

The Library pane has libraries of resources (like file templates, code snippets, interface objects and media files) that are prebuilt and ready to insert into your project. Use the Library selector to select which of these libraries (e.g., code snippets or interface objects) you wish to insert. To insert one, drag it directly into your storyboard while using the Interface Builder editor.

These are basics you need to know to get started using Xcode to build your first app. But to really understand how it’s done, it helps to walk through an actual app or two. Let’s start with a simple “Hello World” app that does not employ a backend connection, and then look at a somewhat more functional app that does.

“Hello World!” sample appThis app displays a button (“Press Me”) and a label (“Label”) so that when the user presses the button the text of the label changes to “Hello World!” as in Figure 3:

To get started, launch Xcode and select “Create a New Xcode Project.” From the iOS Application templates, select “Single View Application” and click “Next.” Fill in your product’s name and a company identifier, typically “com.yourCompanyName.” Deselect “Use Storyboards” and leave “Use Automatic Reference Counting” selected. Then click “Next” and select a destination for your projects files.

Follow these steps to make your app:

1. Select your project’s ViewController.xib file in the Navigator(Figure 4), to open the Interface Builder editor.

2. Drag a “Round Rect Button” from the Objects library (lowerright) onto the view in the Editor area; select the button’s textand type “Press Me.”

3. Drag a Label from the objects library onto the view, as well.4. Select and drag the Label sizing handles, centering the object

and making it wide enough to hold the “Hello World!” text; then,

5. With the “Hello World!” label still selected, click on centeralignment in the Attributes inspector.

6. Open the Assistant Editor (Figure 5), exposing the source codeheader file (ViewController.h) of the view controller you justbuilt graphically.

7. Select the button and control-drag from the button to justbelow the ViewController definition in the Assistant panel. Inthe form that opens, select “Action” for the connection type,type in a name (“showText”) and click “Connect.” This creates aninterface builder (IB) action as highlighted in Figure 6.

8. Next step is to create an outlet for the label. To do this, selectthe label object and control-drag from the label to just belowthe IB action you just created. Select “Outlet” as the connectiontype and enter a name “label” and click “Connect.” This createsan interface builder (IB) outlet as shown in Figure 7.

9. Finally, it’s time to add some logic to the view controller so itknows what to do when the button is pressed. To do this, select “ViewController.m” in the project navigator to show the code editor. Find the button’s IBAction you just created (near the bottom), place your cursor between the { } brackets and hit the return key a few times to create some extra space. Then in that space type the method for how you want the label you speci-fied to respond: _label.text=”Hello World!”; as highlighted in Figure 8.

Congratulations! Your app is done. To build and run your new app in the simulator, click the Xcode Run button in the left corner of the toolbar. When you click the button, the text will update.

Sample app with a backend This second app (named “Kinvey Test Drive”) lets the user type text on an iPhone and save the text to a backend service, like Kinvey. It also lets the user load text on the iPhone from their Kinvey backend. Reading about this app will help you learn:

• How to set up Kinvey’s library in an iOS project• Additional Interface Builder techniques you can use to story-board an application• How to add view controller logic to interact with the backend service, allowing you to save and retrieve data

We will first present the app as a running application and then take it apart so you can see how it was made. To make the app yourself, you can review the various sections below and replicate the steps in your copy of Xcode.

First, to see the app in action, you should download the app and run it on your system. To do that, sign up for Kinvey, then navigate to “Dev Center”, “Samples,” find the “Test Drive” app, and click on its icon. (If you can’t find it right away, make sure you select iOS as your platform on the right side of the menu bar.) Click the download button to download the app’s project files to your computer. Then launch Xcode — just double click on the .xcodeproj file in the project folder.

But before you can run the app, you need to set up the app’s Kinvey backend.

Set Up Kinvey as a Backend Data StoreTest Drive’s project files include all the code the sample app needs in order to talk to Kinvey. However, that would not be the case if you were to build an app from scratch — so you would have to go through an initial Kinvey setup procedure. This involves downloading the Kinvey library files from the downloads section of devcenter.kin-vey.com and dragging them to the Navigator’s Frameworks folder in Xcode. You also need to tell Xcode to link your project with additional iOS frameworks. To find these frameworks, click on the Project folder

at the very top of the Navigator pane — which displays the Project editor — and then select the “Build Settings” tab. For detailed instruc-tions, complete the “Getting Started” page under “Guides” on the Kinvey website. But again, you can skip this setup procedure for now in order to run the downloaded Kinvey Test Drive app.

But you must still do this step: To run any app that uses Kinvey (including Test Drive) you need to do the “Create an App” step on the Kinvey website. Click on “My Apps” in the Kinvey menu bar and then click on “Add an App,” which will open an “Add” page. Type in a name for your app and click on the Apple logo and then click “Create.” The page that opens shows your App’s credentials. Copy and paste the App Key and App Secret into the AppDelegate.m file of the download-ed Test Drive project:

You are now ready to run the app — click on the Xcode run button and wait for the simulator to open and the app to appear (Figure 9).

Clicking the “+” toolbar button opens an alert (Figure 10) with an empty field into which the user can type some text (e.g., “some new data”). Clicking “save” uploads the data to Kinvey and displays text on the screen (a table view) and also displays an alert that the save worked (Figure 11).

To test the load function, enter some data (e.g., “some data to load”) in the “name” field of the Kinvey collection. To see the load, the swipe down on the table on the phone until the refresh spinner starts, and then the new data will appear in the table (Figure 12).

Figure 13 shows the Kinvey collection after the save that Figure 10 depicts on the iPhone. Figure 14 shows the Kinvey collection after the user adds a new row to the testObjects collection using the web browser. Note that every time a save is done on the iPhone, Kinvey automatically adds a new row (displayed on a collection refresh). To add a new row manually in the browser, click “+ row,” and type some descriptive text in the “name” column. That data will now load on the iPhone when the user pulls down on the table.

Storyboard the Test Drive AppMost of the Test Drive user interface objects visible in the simulation are available in Xcode’s Object Library and can therefore be added to the view graphically. The UI objects consist of a:

• Table view• Toolbar• Tool Bar Button item – flexible space• Tool Bar Button item – Add• Table view cell• Label – Title• Refresh Control

To create this app yourself, you would follow these steps:

• Launch Xcode and select the “Single View Application” template• Select the “Use Storyboard” option• Replace the default UIviewcontroller object with a UITableView-Controller • Drag and drop the other objects, in the order listed, onto the UIviewcontroller

Also note:

• The Flexible Space Bar Button item fills up the space on the toolbar so the add button is at the right. This is a standard pattern in table-based iPhone apps.• The add button shows the system “+” sign. That is done by dragging a bar button item onto the toolbar, clicking on the Identifier drop down menu in the Attributes inspector; and then selecting the “Add” option.

As with the “Hello World!” app, once your app’s view is complete (Figure 15), you would still have to create the various methods and connections that bring them to life. This is done using the Source editor while working with the ViewController.m file.

Add View Controller LogicSince the app performs two basic operations (save data to Kinvey and load data from Kinvey) these two methods must be added to the ViewController header file. That’s done with a control-drag from the “+” bar button over to just under the “@ interface ViewController” line in ViewController.h. (Open the Assistant editor to see both the storyboard and the file source.)

During the drag, the popup appears, asking for the name and type of connection. Enter “action” for the connection type and “add” for the name. Then repeat the drag, this time from the refresh control and using “add” for the name (Figure 16).

Note: to follow this discussion it will help to have the referenced files open in your Xcode Source editor.

In ViewController.m, you will see the implementation code associated with each of the two Interface Builder methods, whose names Xcode added automatically to the .m file:

- (IBAction)add:(id)sender- (IBAction)load:(id)sender

You will also see a third section of code not associated with these methods, which starts with the line: “#pragma mark - Table View Stuff.” These methods support the table view and are part of UITableViewD-elegate and UITableViewDataSource. They handle controlling the

display of the table, and respond to user gestures. For example, swiping a table cell will show the delete button because tableView:-canEditRowAtIndexPath: returns YES and tableView:editingStyleForRowA-tIndexPath: returns UITableViewCellEditingStyleDelete. If you tap the delete button, the delegate method tableView:commitEditingStyle:for-RowAtIndexPath: is called. The code of this method deletes the data for the row and removes it from Kinvey’s data store. When the backend delete is completed, the app displays an alert describing the success or failure.

The way that all three sections (and all Kinvey-enabled apps) move data in and out of a Kinvey collection is by getting a reference to the app’s backend collection (named “testObjects”), which is filled with instances (each named “TestObject”) of the data the app wants to move. That’s why you’ll find the following code repeated three times in Test Drive’s View Controller (once for the add, once for the load, and once for the delete):

To support these statements it is required to have a data object class (TestObject). To see how these files are written in the sample project, click on TestObject.h file and TestObject.m in the Navigator pane. If you were to supply these files in your own app, you would click File > New File, and specify Objective-C class, which would be a subclass of NSObject. Then you would type in the code, with a property for each column in the Kinvey backend collection (including one for the object’s id).

As mentioned earlier, your app also needs to authenticate itself to Kinvey, which is handled by AppDelegate.h and AppDelgate.m. These files are created by Xcode when you create a new project, and start out with just a stub implementation. Look in the sample app source

files for code to copy and paste.

For both the save and load operations, however, moving the data in and out of a backend collection is only part of the work. Table 1 lists all the functions that implements the save and load in the ViewCon-troller.m file, along with pointers to its corresponding block of imple-mentation source code. (For each function, its corresponding code begins with the “Starts at” line and ends with the “Ends at” line.) Refer to Appendix 1 to find the actual source code.

Say Hello To Our WorldThe key takeaway from all this is that “making an app” is a worthwhile thing to do for anyone with a clever idea and a working knowledge of Objective-C. The proof is in the hundreds of apps succeeding in the market every day, many written by people working on their own and who never wrote an app before in their lives. As with anything else, practice does make perfect. But hopefully with all the resources available, and the knowledge gained from this ebook, you have already started down the path toward joining the growing legions of iOS app developers. If so, we welcome you!

Appendix 1 — Test Drive Sample App ViewController.m Source Code

18

The iOS revolutionIt’s a story that never gets old. The weekend that iPad Minis and the fourth generation iPads went on sale (November 2-5, 2012) Apple sold over 3 million of the devices — a record for first-weekend iPad sales. Two months earlier the company had set another record: first weekend sales of over 5 million for the iPhone 5. Since the introduc-tion of the first iPhone back in 2007,

iOS-based devices (iPhone, iPad, iPad Mini and iPod Touch) continue to rewrite the definition of what constitutes a successful product. By the end of 2012, over 400 million iOS devices had been sold.

What makes iOS devices so successful? Innovation and product features are clearly a big part. Before the iPhone most people had not interacted with a multi-touch interface. They had never zoomed with a pinch or switched between portrait and landscape by merely rotating a device in their hand. Carrying a phone that knew where they were, could suggest places to eat, and could offer directions on how to get there was also a novel experience.

But features like multi-touch, accelerometers and GPS are only part of the appeal. Even with all its innovations, iOS still might not have taken off the way it has if the only people figuring out ways to use those innovations worked at Apple. Most of the capabilities available in an iPhone or iPad in fact don’t come from Apple at all. They come from legions of third-party developers who work in a vast ecosystem that is also an Apple innovation. That ecosystem includes the iPhone, iPad, iPad Mini, iPods, App Store, iTunes, ad networks — and that’s just on the consumer side. On the developer side, you have Xcode, App Loader, testing tools, iTunes Connect — the list goes on.

As of September 2012, the App Store hosted over 700,000 apps that have collectively been downloaded over 30 billion times. Apple reported for October 2012 that App Store monthly revenues were

running at $333 million — a rate of about $4 billion per year — remarkable for a store that only opened in July 2008.

Another innovation that has spurred iOS app development is “The Cloud.” Cloud services make it easier for independent developers to create, support and make money from their apps. The Cloud solves data storage and cross-device and user-to-user sharing problems. If an app stores data in the Cloud, that part of the application is called the “backend,” while the part of the app that runs on the phone and interacts with the user is called the “front end.”

A cloud may be “private” — i.e., the services belong to an organization for the benefit of its employees and business partners. Or a cloud may be “public” — i.e., a company (such as Amazon or Kinvey) owns the services, which developers can then integrate into their own apps. If you are a developer and want to build your own backend, you certainly can do that. Whether you want to or not depends on whether your backend provides functionality common to many different apps. If it does (as in a shopping cart or user authenti-cation) then perhaps that time and money would be better spent on features that offer unique value to your customer. You may be better off hooking into a commercial backend provider via an API. Then you can focus on what counts most — a unique user experience and application-specific functionality. That brings us to the first step in making an app.

Define your appMost unsuccessful apps fail for any of four reasons:

1. the app was a solution in search of a problem (i.e., no real need existed) 2. the implementation was poor 3. the app tried to do too much; or 4. the Apple App Store rejected the app (either because the implementation was poor or it violated Apple’s content policies)

Keeping the app as simple as possible is the best way to avoid these pitfalls. Most successful apps (indeed, most successful consumer tech products) are based on what is called an MVP, or minimum viable product. It’s the product with the smallest feature set that can deliver the core function without any distracting “bells and whistles.” You know you have an MVP if the product would no longer function if you removed any single feature.

But what should that core feature be? One of the best examples of an MVP is Mail. Version 1 (on the Mac) offered a clear, limited and intuitive feature set whose usefulness was immediately obvious to anyone. Today’s iPhone version integrates seamlessly with your phone, contacts and calendaring. It auto-matically corrects spelling as you type, lets you email photos directly from your photos app, and does much more. But all that came later and was built on top of a basic core function. And that’s how your first app should be built. The key is to come up with something with a clear value that changes people’s lives.

So, in drawing up your MVP feature list, ask yourself what features are key to the experience. Some basic market research is probably in order, starting with a visit to the App Store to see what already exists (possibly to be improved upon and/or to compete with you). Likely

must-have core capabilities include:

• Performance (e.g., fast screen refresh)• Offline capability (i.e., ability to work when not connected to the Internet)• Location awareness (e.g., the data/experience will change with the user’s location)• Cloud syncing (e.g., users see the same data on multiple devices)• Push notifications (i.e., sending updated information to devices as soon as it is available)

When you have a handle on what your app does, the next step is to design it. Designing your app involves making choices of how infor-mation and controls are presented to the user as well as how to implement app logic, and figuring out what data lives locally and what belongs in the Cloud.

Design your appUser experience decisions determine the app’s look and feel. They answer questions such as: What does the app look like? What screens does it have? In the software development world, onscreen objects like buttons, sliders, and fill-in boxes are called widgets. So you need to decide which types of widgets will reside on which screens. And what actions will occur as a result of the user interacting with those widgets?

Keep in mind that users will expect to interact differently with a mobile device than they do with a PC because the screens on mobile devices are much smaller. They’ll expect to use their fingers instead of a mouse or a track pad. Ideally, your app can even be used with one hand holding the device while using just a thumb for scrolling andworking the app’s other controls— the Path app is a good example, and increasingly, so is Facebook.

Your app’s features will inform its architecture, which is how you’ll divide the code and data into functional parts. If your app requires interacting with other app users or networked services, you’ll need to figure out what piece of the logic lives in the app code and what comes from the backend. For example, your app might integrate with a restau-rant recommendation engine, share user location, or pull real-time traffic data. This is done using APIs provided by various service providers — but you don’t have to wire up your app to a network to get started. You can develop a prototype using predefined representative (or “dummy”) data. It’s easier to fine-tune the front end if you don’t have to simultaneously modify your backend too. Once you get the app’s look-and-feel right, then make those backend connections.

Once you’ve got the overall concept for your app, the next step is to express that design in terms of the iOS app architecture. That archi-tecture is the model for what parts an iOS app can contain and how those parts fit together. It’s a well thought-out approach for translat-ing a product concept into actual code you can deploy on a device.

WHY iOS?Besides the features and design of your first app, there’s one more decision you need to make before you start actual development. That’s whether to deploy on Apple’s iOS platform or on Google’s Android platform. (Some of this is also covered in our ebook, How to Make an App: Android Edition.) Reasons to develop for iOS include:

Customers more willing to pay. Perhaps it’s because of Android’s open source heritage, but whatever the reason, Android apps gener-ate less than 10% of the total dollars spent on mobile apps, despite having 75% of the smartphone market itself — and despite the fact that the average selling price of an app in the Google Play is $3.79 versus Apple App Store’s $2.01. In other words, Apple users are much more willing to spend money on apps.

The Apple Ecosystem. Some developers and users prefer Apple’s closed and more tightly controlled environment. Apple’s ecosystem, consisting of Xcode, iCloud, iTunes, the App Store, the iPad, the iPhone, Mac computers, etc., offers a very holistic user experience with the ability to share data seamlessly across devices plus the

assurance of having applications pre-approved for quality and content prior to going on sale.

Xcode. Apple’s all-in-one IDE offers state-of-the-art offers features like a graphical interface builder and a syntax-aware and compiler-aware source editor.

The Apple Experience. From the fit and finish of its hardware to the customer service in its retail stores, to the way its hardware and software work flawlessly together, Apple has created the premium brand in consumer electronics. iOS developers share the benefits — so when someone downloads your iOS app, they already expect it’s a great product. And that it will also work flawlessly on their device.

Tablets. iOS has a clear advantage over Android in terms of tablet market adoption. Using Xcode, it’s also much easier to migrate an app from a phone to a tablet and vice versa than it is when develop-ing for Android.

Why Not iOS?Although iOS offers many compelling advantages as a platform for your mobile app, it also comes with some disadvantages. Here are three:

Closed Platform. iOS apps only run on Apple products so you can’t take advantage of features (like NFC) available only on non-iOS devices or market growth of non-iOS devices.

Market Growth. Today, iOS represents less than 15% of the total smartphone market, Although the total market (“the whole pie”) is still increasing at a fast rate, Android market growth outpaces iOS growth.

Approvals. The App Store’s app approval process is notoriously more time consuming than Google Play’s process.

The iOS app architectureAs noted earlier, a key reason why there are so many apps for iOS is because developing highly functional, polished apps for the platform is relatively easy. That’s mainly because of: 1) the design of the development tools, and 2) the key architectural features most iOS apps have in common. So let’s start with some concepts since it helps to know what goes into an app before trying to create one. We’ll begin with:

• Design patterns• Frameworks• Delegation• Storyboard• Windows• Outlets• Supporting files• Products

Design patterns. iOS apps implement what is known as a Mod-el-View-Controller (MVC) pattern. A pattern is a common way to structure code that solves a particular design problem. The MVC pattern separates application code in a way that allows you to easily change one part of an app without having to change other parts. An MVC pattern consists of three components:

• The Model is the logic that acts on the data, such as to store or retrieve data from a database, compute the distance between two cities on a map, etc. An example of a model is the Kinvey backend that stores your data in the Cloud as a service.

• The View provides the interface to the user; it displays the data and widgets (e.g., buttons and text fields) that allow the user to interact with the data. An iPhone app may have more than one view, as in the Contacts app, which displays a list view of all contacts or alternatively a view of each individual contact.

• The Controller is between the model and the view — i.e., it responds to user requests (made in a view) and retrieves results

(produced in a model). This is where developers spend most of their time — constructing the View Controller — by defining and attaching actions (or behaviors) to onscreen widgets. When the user taps a button, for example, it is the View Controller that determines what action will occur, such as retrieve stored data from your Kinvey-based data store. The link between a view object (like a button) to a controller action is called a connection.

Frameworks. You don’t actually have to write most of an app’s logic. It already exists as frameworks. A framework is a collection of classes that implements some function — such as connecting to the Internet, drawing a button, etc. Rather than write the code from scratch, you just use the frameworks supplied by iOS. Some frameworks are automatically present when you start a new project while others may need to be added (done via a drop down menu in Xcode’s Project Editor).

Delegation. Say, you want to customize the behavior of a framework’s object. You can’t actually modify the code of the framework class itself (prohibited since other apps may also use the framework). But what you can do is provide app-specific behavior in an application delegate object. If a delegate implements a method, it will be called by the delegating class to modify its behavior. In the Kinvey sample app (one of two examples we will be describing below), the AppDele-gate.h and AppDelegate.m — the header and implementation files for the UIApplicationDelegate, respectively — contain the code that authenticates an app to the Kinvey backend service.

Storyboards and XIBs. The MainStoryboard.storyboard file (or a .xib file, if you did not click on the “Use Storyboard” option when starting your project) contains the view information needed to implement the overall flow and display of your application and the user interface elements.

Windows. Each view (e.g., the contact list and individual contact details in the Contacts app) exists within a window. The window represents the entire device screen and is where all your views are presented.

Outlets. A variable by which a view object can be referenced in a controller. (For example, if you place a text field to capture a user's name, you might create an outlet called UITextField* nameField.)

Supporting files. These are files that provide resources (like PNG images and other static data) that your app needs as well as files that configure how the app will run. Other examples:

.pch files — precompiled headers used for the code files in your project.

.plist files — property lists that are small amounts of persistent data (like your app’s default user settings) consisting primarily of strings and numbers that you want your app to be able to access, modify if needed, and write back into the property list.

main.m file — your app’s main function. This is needed to launch the app, but you will not need to modify this file.

InfoPlist.strings file — used for localization.

Products. This is the file for your app (i.e., YourProduct.app) that is built when you click Xcode’s “run” button.

“Making an iOS app” involves working with these features in the typical, straightforward workflow:

• Storyboard your views by dragging and configuring graphicalobjects on a template

• Adding behaviors to the various widgets• Writing the classes as to define those behaviors (including

delegates)• Adding needed support files• Building and running the app• Iterating until you are satisfied with your app

This is all done within Xcode.

What’s Xcode?You can start developing functional, good-looking apps almost from the moment you download Xcode, Apple’s integrated development environment (IDE) for making iOS and Macintosh apps. Among other features, Xcode includes a source code editor, graphical user inter-face (GUI) editor (sometimes called Interface Builder), source code repository manager, compiler, and much more. iOS applications are typically developed by manipulating views graphically and by typing Objective-C code for the models and controllers.

To get Xcode, simply go to the App Store and download the applica-tion (it’s free). To do this, click on the App Store icon in your Mac’s dock, or visit https://itunes.apple.com/us/genre/ios/id36?mt=8

The app store will download and install Xcode in your Application folder. From Applications, double-click the Xcode icon to launch Xcode and you’ll see its splash screen (Figure 1). From there you can click on “Create a new Xcode project” to take you to a menu of several templates on which to base your application. Selecting a template opens an Xcode workspace pre-populated with frameworks and other files Xcode thinks you will need using that template.

Although you can develop, build and simulate your app on your computer in Xcode, you can’t run your app on a target device (even your own iPhone) until you become a registered iOS developer and join the iOS Developer Program. To do that, go to develop-er.app.com/ and navigate to the iOS Dev Center. While there, you will also find documentation, sample code and other useful resources such as information on how to submit your app to the iOS App Store.

Everything you do in Xcode is done in a window, called a workspace (Figure 2), consisting of multiple work areas, some of which are also divided into panes. All the files needed to build your app belong to a project, and the Navigator area (far left) lists all your projects (there can be several in a workspace) and all files for each project. Clicking on a file in the Navigator area shows its contents in the Editor area and invokes the appropriate editor. Clicking on a .h or .m file, for example, shows the file’s source code and invokes the Source editor, so you can edit the code. Clicking on .storyboard or .xib (sometimes called a “nib”) file shows the app’s storyboard and invokes the Inter-face Builder, so you can design a view using the Builder’s drag and drop features.

An especially handy feature is that the Editor area can have both a right and a left pane — with each pane aware of your edits in the other. So, for example, you can simultaneously edit an object’s .h

header file in the left pane and its corresponding .m in the right pane. Or you might click on a button object (displayed graphically) in the left pane and edit its method’s source code in the right pane. To toggle between a single pane (the “Standard Editor”) and double pane view (the “Assistant Editor”), use the Editor selector button on the right of the toolbar. You can option+command+click a symbol in the editor to open the definition in the opposite editor pane.

You can also resize the entire Editor area simply by dragging its borders. For even more editing space, you can also remove the Debug area or both the Debug and Utility areas using the View Selector button on the far right of the toolbar.

As its name suggests, the Debug area shows information, like variable state and console logs, helpful in debugging code.

The Utility area has two panes: the Inspector and Quick Help pane (top) and the Library pane (bottom). Although there are five inspectors — File, Help, Identity, Attributes, Size and Connec-tions — only the inspectors that are currently relevant appear in the Inspec-tor list at the top of the pane. (To see the name of an inspector, move the cursor over its icon in the Inspector selector bar.)

You will use inspectors to add and modify object attributes for views in the Interface Builder. For example, if you click on a UILabel in the Editor area of a storyboard, you can use the Attributes inspector to change the label’s color and use the Size inspector to change the label’s size.

The Help inspector shows help information about a selected class. Use the Identity inspector to view and manage an object’s metadata such as its class, runtime attributes, label and so forth. Use the

Connections inspector to view the outlets and actions of an interface object, to make new connections and to delete existing connections.

The Library pane has libraries of resources (like file templates, code snippets, interface objects and media files) that are prebuilt and ready to insert into your project. Use the Library selector to select which of these libraries (e.g., code snippets or interface objects) you wish to insert. To insert one, drag it directly into your storyboard while using the Interface Builder editor.

These are basics you need to know to get started using Xcode to build your first app. But to really understand how it’s done, it helps to walk through an actual app or two. Let’s start with a simple “Hello World” app that does not employ a backend connection, and then look at a somewhat more functional app that does.

“Hello World!” sample appThis app displays a button (“Press Me”) and a label (“Label”) so that when the user presses the button the text of the label changes to “Hello World!” as in Figure 3:

To get started, launch Xcode and select “Create a New Xcode Project.” From the iOS Application templates, select “Single View Application” and click “Next.” Fill in your product’s name and a company identifier, typically “com.yourCompanyName.” Deselect “Use Storyboards” and leave “Use Automatic Reference Counting” selected. Then click “Next” and select a destination for your projects files.

Follow these steps to make your app:

1. Select your project’s ViewController.xib file in the Navigator(Figure 4), to open the Interface Builder editor.

2. Drag a “Round Rect Button” from the Objects library (lowerright) onto the view in the Editor area; select the button’s textand type “Press Me.”

3. Drag a Label from the objects library onto the view, as well.4. Select and drag the Label sizing handles, centering the object

and making it wide enough to hold the “Hello World!” text; then,

5. With the “Hello World!” label still selected, click on centeralignment in the Attributes inspector.

6. Open the Assistant Editor (Figure 5), exposing the source codeheader file (ViewController.h) of the view controller you justbuilt graphically.

7. Select the button and control-drag from the button to justbelow the ViewController definition in the Assistant panel. Inthe form that opens, select “Action” for the connection type,type in a name (“showText”) and click “Connect.” This creates aninterface builder (IB) action as highlighted in Figure 6.

8. Next step is to create an outlet for the label. To do this, selectthe label object and control-drag from the label to just belowthe IB action you just created. Select “Outlet” as the connectiontype and enter a name “label” and click “Connect.” This createsan interface builder (IB) outlet as shown in Figure 7.

9. Finally, it’s time to add some logic to the view controller so itknows what to do when the button is pressed. To do this, select “ViewController.m” in the project navigator to show the code editor. Find the button’s IBAction you just created (near the bottom), place your cursor between the { } brackets and hit the return key a few times to create some extra space. Then in that space type the method for how you want the label you speci-fied to respond: _label.text=”Hello World!”; as highlighted in Figure 8.

Congratulations! Your app is done. To build and run your new app in the simulator, click the Xcode Run button in the left corner of the toolbar. When you click the button, the text will update.

Sample app with a backend This second app (named “Kinvey Test Drive”) lets the user type text on an iPhone and save the text to a backend service, like Kinvey. It also lets the user load text on the iPhone from their Kinvey backend. Reading about this app will help you learn:

• How to set up Kinvey’s library in an iOS project• Additional Interface Builder techniques you can use to story-board an application• How to add view controller logic to interact with the backend service, allowing you to save and retrieve data

We will first present the app as a running application and then take it apart so you can see how it was made. To make the app yourself, you can review the various sections below and replicate the steps in your copy of Xcode.

First, to see the app in action, you should download the app and run it on your system. To do that, sign up for Kinvey, then navigate to “Dev Center”, “Samples,” find the “Test Drive” app, and click on its icon. (If you can’t find it right away, make sure you select iOS as your platform on the right side of the menu bar.) Click the download button to download the app’s project files to your computer. Then launch Xcode — just double click on the .xcodeproj file in the project folder.

But before you can run the app, you need to set up the app’s Kinvey backend.

Set Up Kinvey as a Backend Data StoreTest Drive’s project files include all the code the sample app needs in order to talk to Kinvey. However, that would not be the case if you were to build an app from scratch — so you would have to go through an initial Kinvey setup procedure. This involves downloading the Kinvey library files from the downloads section of devcenter.kin-vey.com and dragging them to the Navigator’s Frameworks folder in Xcode. You also need to tell Xcode to link your project with additional iOS frameworks. To find these frameworks, click on the Project folder

at the very top of the Navigator pane — which displays the Project editor — and then select the “Build Settings” tab. For detailed instruc-tions, complete the “Getting Started” page under “Guides” on the Kinvey website. But again, you can skip this setup procedure for now in order to run the downloaded Kinvey Test Drive app.

But you must still do this step: To run any app that uses Kinvey (including Test Drive) you need to do the “Create an App” step on the Kinvey website. Click on “My Apps” in the Kinvey menu bar and then click on “Add an App,” which will open an “Add” page. Type in a name for your app and click on the Apple logo and then click “Create.” The page that opens shows your App’s credentials. Copy and paste the App Key and App Secret into the AppDelegate.m file of the download-ed Test Drive project:

You are now ready to run the app — click on the Xcode run button and wait for the simulator to open and the app to appear (Figure 9).

Clicking the “+” toolbar button opens an alert (Figure 10) with an empty field into which the user can type some text (e.g., “some new data”). Clicking “save” uploads the data to Kinvey and displays text on the screen (a table view) and also displays an alert that the save worked (Figure 11).

To test the load function, enter some data (e.g., “some data to load”) in the “name” field of the Kinvey collection. To see the load, the swipe down on the table on the phone until the refresh spinner starts, and then the new data will appear in the table (Figure 12).

Figure 13 shows the Kinvey collection after the save that Figure 10 depicts on the iPhone. Figure 14 shows the Kinvey collection after the user adds a new row to the testObjects collection using the web browser. Note that every time a save is done on the iPhone, Kinvey automatically adds a new row (displayed on a collection refresh). To add a new row manually in the browser, click “+ row,” and type some descriptive text in the “name” column. That data will now load on the iPhone when the user pulls down on the table.

Storyboard the Test Drive AppMost of the Test Drive user interface objects visible in the simulation are available in Xcode’s Object Library and can therefore be added to the view graphically. The UI objects consist of a:

• Table view• Toolbar• Tool Bar Button item – flexible space• Tool Bar Button item – Add• Table view cell• Label – Title• Refresh Control

To create this app yourself, you would follow these steps:

• Launch Xcode and select the “Single View Application” template• Select the “Use Storyboard” option• Replace the default UIviewcontroller object with a UITableView-Controller • Drag and drop the other objects, in the order listed, onto the UIviewcontroller

Also note:

• The Flexible Space Bar Button item fills up the space on the toolbar so the add button is at the right. This is a standard pattern in table-based iPhone apps.• The add button shows the system “+” sign. That is done by dragging a bar button item onto the toolbar, clicking on the Identifier drop down menu in the Attributes inspector; and then selecting the “Add” option.

As with the “Hello World!” app, once your app’s view is complete (Figure 15), you would still have to create the various methods and connections that bring them to life. This is done using the Source editor while working with the ViewController.m file.

Add View Controller LogicSince the app performs two basic operations (save data to Kinvey and load data from Kinvey) these two methods must be added to the ViewController header file. That’s done with a control-drag from the “+” bar button over to just under the “@ interface ViewController” line in ViewController.h. (Open the Assistant editor to see both the storyboard and the file source.)

During the drag, the popup appears, asking for the name and type of connection. Enter “action” for the connection type and “add” for the name. Then repeat the drag, this time from the refresh control and using “add” for the name (Figure 16).

Note: to follow this discussion it will help to have the referenced files open in your Xcode Source editor.

In ViewController.m, you will see the implementation code associated with each of the two Interface Builder methods, whose names Xcode added automatically to the .m file:

- (IBAction)add:(id)sender- (IBAction)load:(id)sender

You will also see a third section of code not associated with these methods, which starts with the line: “#pragma mark - Table View Stuff.” These methods support the table view and are part of UITableViewD-elegate and UITableViewDataSource. They handle controlling the

display of the table, and respond to user gestures. For example, swiping a table cell will show the delete button because tableView:-canEditRowAtIndexPath: returns YES and tableView:editingStyleForRowA-tIndexPath: returns UITableViewCellEditingStyleDelete. If you tap the delete button, the delegate method tableView:commitEditingStyle:for-RowAtIndexPath: is called. The code of this method deletes the data for the row and removes it from Kinvey’s data store. When the backend delete is completed, the app displays an alert describing the success or failure.

The way that all three sections (and all Kinvey-enabled apps) move data in and out of a Kinvey collection is by getting a reference to the app’s backend collection (named “testObjects”), which is filled with instances (each named “TestObject”) of the data the app wants to move. That’s why you’ll find the following code repeated three times in Test Drive’s View Controller (once for the add, once for the load, and once for the delete):

To support these statements it is required to have a data object class (TestObject). To see how these files are written in the sample project, click on TestObject.h file and TestObject.m in the Navigator pane. If you were to supply these files in your own app, you would click File > New File, and specify Objective-C class, which would be a subclass of NSObject. Then you would type in the code, with a property for each column in the Kinvey backend collection (including one for the object’s id).

As mentioned earlier, your app also needs to authenticate itself to Kinvey, which is handled by AppDelegate.h and AppDelgate.m. These files are created by Xcode when you create a new project, and start out with just a stub implementation. Look in the sample app source

files for code to copy and paste.

For both the save and load operations, however, moving the data in and out of a backend collection is only part of the work. Table 1 lists all the functions that implements the save and load in the ViewCon-troller.m file, along with pointers to its corresponding block of imple-mentation source code. (For each function, its corresponding code begins with the “Starts at” line and ends with the “Ends at” line.) Refer to Appendix 1 to find the actual source code.

Say Hello To Our WorldThe key takeaway from all this is that “making an app” is a worthwhile thing to do for anyone with a clever idea and a working knowledge of Objective-C. The proof is in the hundreds of apps succeeding in the market every day, many written by people working on their own and who never wrote an app before in their lives. As with anything else, practice does make perfect. But hopefully with all the resources available, and the knowledge gained from this ebook, you have already started down the path toward joining the growing legions of iOS app developers. If so, we welcome you!

Appendix 1 — Test Drive Sample App ViewController.m Source Code

fig. 1 Xcode welcome screen. Create a new project from here.

19

The iOS revolutionIt’s a story that never gets old. The weekend that iPad Minis and the fourth generation iPads went on sale (November 2-5, 2012) Apple sold over 3 million of the devices — a record for first-weekend iPad sales. Two months earlier the company had set another record: first weekend sales of over 5 million for the iPhone 5. Since the introduc-tion of the first iPhone back in 2007,

iOS-based devices (iPhone, iPad, iPad Mini and iPod Touch) continue to rewrite the definition of what constitutes a successful product. By the end of 2012, over 400 million iOS devices had been sold.

What makes iOS devices so successful? Innovation and product features are clearly a big part. Before the iPhone most people had not interacted with a multi-touch interface. They had never zoomed with a pinch or switched between portrait and landscape by merely rotating a device in their hand. Carrying a phone that knew where they were, could suggest places to eat, and could offer directions on how to get there was also a novel experience.

But features like multi-touch, accelerometers and GPS are only part of the appeal. Even with all its innovations, iOS still might not have taken off the way it has if the only people figuring out ways to use those innovations worked at Apple. Most of the capabilities available in an iPhone or iPad in fact don’t come from Apple at all. They come from legions of third-party developers who work in a vast ecosystem that is also an Apple innovation. That ecosystem includes the iPhone, iPad, iPad Mini, iPods, App Store, iTunes, ad networks — and that’s just on the consumer side. On the developer side, you have Xcode, App Loader, testing tools, iTunes Connect — the list goes on.

As of September 2012, the App Store hosted over 700,000 apps that have collectively been downloaded over 30 billion times. Apple reported for October 2012 that App Store monthly revenues were

running at $333 million — a rate of about $4 billion per year — remarkable for a store that only opened in July 2008.

Another innovation that has spurred iOS app development is “The Cloud.” Cloud services make it easier for independent developers to create, support and make money from their apps. The Cloud solves data storage and cross-device and user-to-user sharing problems. If an app stores data in the Cloud, that part of the application is called the “backend,” while the part of the app that runs on the phone and interacts with the user is called the “front end.”

A cloud may be “private” — i.e., the services belong to an organization for the benefit of its employees and business partners. Or a cloud may be “public” — i.e., a company (such as Amazon or Kinvey) owns the services, which developers can then integrate into their own apps. If you are a developer and want to build your own backend, you certainly can do that. Whether you want to or not depends on whether your backend provides functionality common to many different apps. If it does (as in a shopping cart or user authenti-cation) then perhaps that time and money would be better spent on features that offer unique value to your customer. You may be better off hooking into a commercial backend provider via an API. Then you can focus on what counts most — a unique user experience and application-specific functionality. That brings us to the first step in making an app.

Define your appMost unsuccessful apps fail for any of four reasons:

1. the app was a solution in search of a problem (i.e., no real need existed) 2. the implementation was poor 3. the app tried to do too much; or 4. the Apple App Store rejected the app (either because the implementation was poor or it violated Apple’s content policies)

Keeping the app as simple as possible is the best way to avoid these pitfalls. Most successful apps (indeed, most successful consumer tech products) are based on what is called an MVP, or minimum viable product. It’s the product with the smallest feature set that can deliver the core function without any distracting “bells and whistles.” You know you have an MVP if the product would no longer function if you removed any single feature.

But what should that core feature be? One of the best examples of an MVP is Mail. Version 1 (on the Mac) offered a clear, limited and intuitive feature set whose usefulness was immediately obvious to anyone. Today’s iPhone version integrates seamlessly with your phone, contacts and calendaring. It auto-matically corrects spelling as you type, lets you email photos directly from your photos app, and does much more. But all that came later and was built on top of a basic core function. And that’s how your first app should be built. The key is to come up with something with a clear value that changes people’s lives.

So, in drawing up your MVP feature list, ask yourself what features are key to the experience. Some basic market research is probably in order, starting with a visit to the App Store to see what already exists (possibly to be improved upon and/or to compete with you). Likely

must-have core capabilities include:

• Performance (e.g., fast screen refresh)• Offline capability (i.e., ability to work when not connected to the Internet)• Location awareness (e.g., the data/experience will change with the user’s location)• Cloud syncing (e.g., users see the same data on multiple devices)• Push notifications (i.e., sending updated information to devices as soon as it is available)

When you have a handle on what your app does, the next step is to design it. Designing your app involves making choices of how infor-mation and controls are presented to the user as well as how to implement app logic, and figuring out what data lives locally and what belongs in the Cloud.

Design your appUser experience decisions determine the app’s look and feel. They answer questions such as: What does the app look like? What screens does it have? In the software development world, onscreen objects like buttons, sliders, and fill-in boxes are called widgets. So you need to decide which types of widgets will reside on which screens. And what actions will occur as a result of the user interacting with those widgets?

Keep in mind that users will expect to interact differently with a mobile device than they do with a PC because the screens on mobile devices are much smaller. They’ll expect to use their fingers instead of a mouse or a track pad. Ideally, your app can even be used with one hand holding the device while using just a thumb for scrolling andworking the app’s other controls— the Path app is a good example, and increasingly, so is Facebook.

Your app’s features will inform its architecture, which is how you’ll divide the code and data into functional parts. If your app requires interacting with other app users or networked services, you’ll need to figure out what piece of the logic lives in the app code and what comes from the backend. For example, your app might integrate with a restau-rant recommendation engine, share user location, or pull real-time traffic data. This is done using APIs provided by various service providers — but you don’t have to wire up your app to a network to get started. You can develop a prototype using predefined representative (or “dummy”) data. It’s easier to fine-tune the front end if you don’t have to simultaneously modify your backend too. Once you get the app’s look-and-feel right, then make those backend connections.

Once you’ve got the overall concept for your app, the next step is to express that design in terms of the iOS app architecture. That archi-tecture is the model for what parts an iOS app can contain and how those parts fit together. It’s a well thought-out approach for translat-ing a product concept into actual code you can deploy on a device.

WHY iOS?Besides the features and design of your first app, there’s one more decision you need to make before you start actual development. That’s whether to deploy on Apple’s iOS platform or on Google’s Android platform. (Some of this is also covered in our ebook, How to Make an App: Android Edition.) Reasons to develop for iOS include:

Customers more willing to pay. Perhaps it’s because of Android’s open source heritage, but whatever the reason, Android apps gener-ate less than 10% of the total dollars spent on mobile apps, despite having 75% of the smartphone market itself — and despite the fact that the average selling price of an app in the Google Play is $3.79 versus Apple App Store’s $2.01. In other words, Apple users are much more willing to spend money on apps.

The Apple Ecosystem. Some developers and users prefer Apple’s closed and more tightly controlled environment. Apple’s ecosystem, consisting of Xcode, iCloud, iTunes, the App Store, the iPad, the iPhone, Mac computers, etc., offers a very holistic user experience with the ability to share data seamlessly across devices plus the

assurance of having applications pre-approved for quality and content prior to going on sale.

Xcode. Apple’s all-in-one IDE offers state-of-the-art offers features like a graphical interface builder and a syntax-aware and compiler-aware source editor.

The Apple Experience. From the fit and finish of its hardware to the customer service in its retail stores, to the way its hardware and software work flawlessly together, Apple has created the premium brand in consumer electronics. iOS developers share the benefits — so when someone downloads your iOS app, they already expect it’s a great product. And that it will also work flawlessly on their device.

Tablets. iOS has a clear advantage over Android in terms of tablet market adoption. Using Xcode, it’s also much easier to migrate an app from a phone to a tablet and vice versa than it is when develop-ing for Android.

Why Not iOS?Although iOS offers many compelling advantages as a platform for your mobile app, it also comes with some disadvantages. Here are three:

Closed Platform. iOS apps only run on Apple products so you can’t take advantage of features (like NFC) available only on non-iOS devices or market growth of non-iOS devices.

Market Growth. Today, iOS represents less than 15% of the total smartphone market, Although the total market (“the whole pie”) is still increasing at a fast rate, Android market growth outpaces iOS growth.

Approvals. The App Store’s app approval process is notoriously more time consuming than Google Play’s process.

The iOS app architectureAs noted earlier, a key reason why there are so many apps for iOS is because developing highly functional, polished apps for the platform is relatively easy. That’s mainly because of: 1) the design of the development tools, and 2) the key architectural features most iOS apps have in common. So let’s start with some concepts since it helps to know what goes into an app before trying to create one. We’ll begin with:

• Design patterns• Frameworks• Delegation• Storyboard• Windows• Outlets• Supporting files• Products

Design patterns. iOS apps implement what is known as a Mod-el-View-Controller (MVC) pattern. A pattern is a common way to structure code that solves a particular design problem. The MVC pattern separates application code in a way that allows you to easily change one part of an app without having to change other parts. An MVC pattern consists of three components:

• The Model is the logic that acts on the data, such as to store or retrieve data from a database, compute the distance between two cities on a map, etc. An example of a model is the Kinvey backend that stores your data in the Cloud as a service.

• The View provides the interface to the user; it displays the data and widgets (e.g., buttons and text fields) that allow the user to interact with the data. An iPhone app may have more than one view, as in the Contacts app, which displays a list view of all contacts or alternatively a view of each individual contact.

• The Controller is between the model and the view — i.e., it responds to user requests (made in a view) and retrieves results

(produced in a model). This is where developers spend most of their time — constructing the View Controller — by defining and attaching actions (or behaviors) to onscreen widgets. When the user taps a button, for example, it is the View Controller that determines what action will occur, such as retrieve stored data from your Kinvey-based data store. The link between a view object (like a button) to a controller action is called a connection.

Frameworks. You don’t actually have to write most of an app’s logic. It already exists as frameworks. A framework is a collection of classes that implements some function — such as connecting to the Internet, drawing a button, etc. Rather than write the code from scratch, you just use the frameworks supplied by iOS. Some frameworks are automatically present when you start a new project while others may need to be added (done via a drop down menu in Xcode’s Project Editor).

Delegation. Say, you want to customize the behavior of a framework’s object. You can’t actually modify the code of the framework class itself (prohibited since other apps may also use the framework). But what you can do is provide app-specific behavior in an application delegate object. If a delegate implements a method, it will be called by the delegating class to modify its behavior. In the Kinvey sample app (one of two examples we will be describing below), the AppDele-gate.h and AppDelegate.m — the header and implementation files for the UIApplicationDelegate, respectively — contain the code that authenticates an app to the Kinvey backend service.

Storyboards and XIBs. The MainStoryboard.storyboard file (or a .xib file, if you did not click on the “Use Storyboard” option when starting your project) contains the view information needed to implement the overall flow and display of your application and the user interface elements.

Windows. Each view (e.g., the contact list and individual contact details in the Contacts app) exists within a window. The window represents the entire device screen and is where all your views are presented.

Outlets. A variable by which a view object can be referenced in a controller. (For example, if you place a text field to capture a user's name, you might create an outlet called UITextField* nameField.)

Supporting files. These are files that provide resources (like PNG images and other static data) that your app needs as well as files that configure how the app will run. Other examples:

.pch files — precompiled headers used for the code files in your project.

.plist files — property lists that are small amounts of persistent data (like your app’s default user settings) consisting primarily of strings and numbers that you want your app to be able to access, modify if needed, and write back into the property list.

main.m file — your app’s main function. This is needed to launch the app, but you will not need to modify this file.

InfoPlist.strings file — used for localization.

Products. This is the file for your app (i.e., YourProduct.app) that is built when you click Xcode’s “run” button.

“Making an iOS app” involves working with these features in the typical, straightforward workflow:

• Storyboard your views by dragging and configuring graphicalobjects on a template

• Adding behaviors to the various widgets• Writing the classes as to define those behaviors (including

delegates)• Adding needed support files• Building and running the app• Iterating until you are satisfied with your app

This is all done within Xcode.

What’s Xcode?You can start developing functional, good-looking apps almost from the moment you download Xcode, Apple’s integrated development environment (IDE) for making iOS and Macintosh apps. Among other features, Xcode includes a source code editor, graphical user inter-face (GUI) editor (sometimes called Interface Builder), source code repository manager, compiler, and much more. iOS applications are typically developed by manipulating views graphically and by typing Objective-C code for the models and controllers.

To get Xcode, simply go to the App Store and download the applica-tion (it’s free). To do this, click on the App Store icon in your Mac’s dock, or visit https://itunes.apple.com/us/genre/ios/id36?mt=8

The app store will download and install Xcode in your Application folder. From Applications, double-click the Xcode icon to launch Xcode and you’ll see its splash screen (Figure 1). From there you can click on “Create a new Xcode project” to take you to a menu of several templates on which to base your application. Selecting a template opens an Xcode workspace pre-populated with frameworks and other files Xcode thinks you will need using that template.

Although you can develop, build and simulate your app on your computer in Xcode, you can’t run your app on a target device (even your own iPhone) until you become a registered iOS developer and join the iOS Developer Program. To do that, go to develop-er.app.com/ and navigate to the iOS Dev Center. While there, you will also find documentation, sample code and other useful resources such as information on how to submit your app to the iOS App Store.

Everything you do in Xcode is done in a window, called a workspace (Figure 2), consisting of multiple work areas, some of which are also divided into panes. All the files needed to build your app belong to a project, and the Navigator area (far left) lists all your projects (there can be several in a workspace) and all files for each project. Clicking on a file in the Navigator area shows its contents in the Editor area and invokes the appropriate editor. Clicking on a .h or .m file, for example, shows the file’s source code and invokes the Source editor, so you can edit the code. Clicking on .storyboard or .xib (sometimes called a “nib”) file shows the app’s storyboard and invokes the Inter-face Builder, so you can design a view using the Builder’s drag and drop features.

An especially handy feature is that the Editor area can have both a right and a left pane — with each pane aware of your edits in the other. So, for example, you can simultaneously edit an object’s .h

header file in the left pane and its corresponding .m in the right pane. Or you might click on a button object (displayed graphically) in the left pane and edit its method’s source code in the right pane. To toggle between a single pane (the “Standard Editor”) and double pane view (the “Assistant Editor”), use the Editor selector button on the right of the toolbar. You can option+command+click a symbol in the editor to open the definition in the opposite editor pane.

You can also resize the entire Editor area simply by dragging its borders. For even more editing space, you can also remove the Debug area or both the Debug and Utility areas using the View Selector button on the far right of the toolbar.

As its name suggests, the Debug area shows information, like variable state and console logs, helpful in debugging code.

The Utility area has two panes: the Inspector and Quick Help pane (top) and the Library pane (bottom). Although there are five inspectors — File, Help, Identity, Attributes, Size and Connec-tions — only the inspectors that are currently relevant appear in the Inspec-tor list at the top of the pane. (To see the name of an inspector, move the cursor over its icon in the Inspector selector bar.)

You will use inspectors to add and modify object attributes for views in the Interface Builder. For example, if you click on a UILabel in the Editor area of a storyboard, you can use the Attributes inspector to change the label’s color and use the Size inspector to change the label’s size.

The Help inspector shows help information about a selected class. Use the Identity inspector to view and manage an object’s metadata such as its class, runtime attributes, label and so forth. Use the

Connections inspector to view the outlets and actions of an interface object, to make new connections and to delete existing connections.

The Library pane has libraries of resources (like file templates, code snippets, interface objects and media files) that are prebuilt and ready to insert into your project. Use the Library selector to select which of these libraries (e.g., code snippets or interface objects) you wish to insert. To insert one, drag it directly into your storyboard while using the Interface Builder editor.

These are basics you need to know to get started using Xcode to build your first app. But to really understand how it’s done, it helps to walk through an actual app or two. Let’s start with a simple “Hello World” app that does not employ a backend connection, and then look at a somewhat more functional app that does.

“Hello World!” sample appThis app displays a button (“Press Me”) and a label (“Label”) so that when the user presses the button the text of the label changes to “Hello World!” as in Figure 3:

To get started, launch Xcode and select “Create a New Xcode Project.” From the iOS Application templates, select “Single View Application” and click “Next.” Fill in your product’s name and a company identifier, typically “com.yourCompanyName.” Deselect “Use Storyboards” and leave “Use Automatic Reference Counting” selected. Then click “Next” and select a destination for your projects files.

Follow these steps to make your app:

1. Select your project’s ViewController.xib file in the Navigator(Figure 4), to open the Interface Builder editor.

2. Drag a “Round Rect Button” from the Objects library (lowerright) onto the view in the Editor area; select the button’s textand type “Press Me.”

3. Drag a Label from the objects library onto the view, as well.4. Select and drag the Label sizing handles, centering the object

and making it wide enough to hold the “Hello World!” text; then,

5. With the “Hello World!” label still selected, click on centeralignment in the Attributes inspector.

6. Open the Assistant Editor (Figure 5), exposing the source codeheader file (ViewController.h) of the view controller you justbuilt graphically.

7. Select the button and control-drag from the button to justbelow the ViewController definition in the Assistant panel. Inthe form that opens, select “Action” for the connection type,type in a name (“showText”) and click “Connect.” This creates aninterface builder (IB) action as highlighted in Figure 6.

8. Next step is to create an outlet for the label. To do this, selectthe label object and control-drag from the label to just belowthe IB action you just created. Select “Outlet” as the connectiontype and enter a name “label” and click “Connect.” This createsan interface builder (IB) outlet as shown in Figure 7.

9. Finally, it’s time to add some logic to the view controller so itknows what to do when the button is pressed. To do this, select “ViewController.m” in the project navigator to show the code editor. Find the button’s IBAction you just created (near the bottom), place your cursor between the { } brackets and hit the return key a few times to create some extra space. Then in that space type the method for how you want the label you speci-fied to respond: _label.text=”Hello World!”; as highlighted in Figure 8.

Congratulations! Your app is done. To build and run your new app in the simulator, click the Xcode Run button in the left corner of the toolbar. When you click the button, the text will update.

Sample app with a backend This second app (named “Kinvey Test Drive”) lets the user type text on an iPhone and save the text to a backend service, like Kinvey. It also lets the user load text on the iPhone from their Kinvey backend. Reading about this app will help you learn:

• How to set up Kinvey’s library in an iOS project• Additional Interface Builder techniques you can use to story-board an application• How to add view controller logic to interact with the backend service, allowing you to save and retrieve data

We will first present the app as a running application and then take it apart so you can see how it was made. To make the app yourself, you can review the various sections below and replicate the steps in your copy of Xcode.

First, to see the app in action, you should download the app and run it on your system. To do that, sign up for Kinvey, then navigate to “Dev Center”, “Samples,” find the “Test Drive” app, and click on its icon. (If you can’t find it right away, make sure you select iOS as your platform on the right side of the menu bar.) Click the download button to download the app’s project files to your computer. Then launch Xcode — just double click on the .xcodeproj file in the project folder.

But before you can run the app, you need to set up the app’s Kinvey backend.

Set Up Kinvey as a Backend Data StoreTest Drive’s project files include all the code the sample app needs in order to talk to Kinvey. However, that would not be the case if you were to build an app from scratch — so you would have to go through an initial Kinvey setup procedure. This involves downloading the Kinvey library files from the downloads section of devcenter.kin-vey.com and dragging them to the Navigator’s Frameworks folder in Xcode. You also need to tell Xcode to link your project with additional iOS frameworks. To find these frameworks, click on the Project folder

at the very top of the Navigator pane — which displays the Project editor — and then select the “Build Settings” tab. For detailed instruc-tions, complete the “Getting Started” page under “Guides” on the Kinvey website. But again, you can skip this setup procedure for now in order to run the downloaded Kinvey Test Drive app.

But you must still do this step: To run any app that uses Kinvey (including Test Drive) you need to do the “Create an App” step on the Kinvey website. Click on “My Apps” in the Kinvey menu bar and then click on “Add an App,” which will open an “Add” page. Type in a name for your app and click on the Apple logo and then click “Create.” The page that opens shows your App’s credentials. Copy and paste the App Key and App Secret into the AppDelegate.m file of the download-ed Test Drive project:

You are now ready to run the app — click on the Xcode run button and wait for the simulator to open and the app to appear (Figure 9).

Clicking the “+” toolbar button opens an alert (Figure 10) with an empty field into which the user can type some text (e.g., “some new data”). Clicking “save” uploads the data to Kinvey and displays text on the screen (a table view) and also displays an alert that the save worked (Figure 11).

To test the load function, enter some data (e.g., “some data to load”) in the “name” field of the Kinvey collection. To see the load, the swipe down on the table on the phone until the refresh spinner starts, and then the new data will appear in the table (Figure 12).

Figure 13 shows the Kinvey collection after the save that Figure 10 depicts on the iPhone. Figure 14 shows the Kinvey collection after the user adds a new row to the testObjects collection using the web browser. Note that every time a save is done on the iPhone, Kinvey automatically adds a new row (displayed on a collection refresh). To add a new row manually in the browser, click “+ row,” and type some descriptive text in the “name” column. That data will now load on the iPhone when the user pulls down on the table.

Storyboard the Test Drive AppMost of the Test Drive user interface objects visible in the simulation are available in Xcode’s Object Library and can therefore be added to the view graphically. The UI objects consist of a:

• Table view• Toolbar• Tool Bar Button item – flexible space• Tool Bar Button item – Add• Table view cell• Label – Title• Refresh Control

To create this app yourself, you would follow these steps:

• Launch Xcode and select the “Single View Application” template• Select the “Use Storyboard” option• Replace the default UIviewcontroller object with a UITableView-Controller • Drag and drop the other objects, in the order listed, onto the UIviewcontroller

Also note:

• The Flexible Space Bar Button item fills up the space on the toolbar so the add button is at the right. This is a standard pattern in table-based iPhone apps.• The add button shows the system “+” sign. That is done by dragging a bar button item onto the toolbar, clicking on the Identifier drop down menu in the Attributes inspector; and then selecting the “Add” option.

As with the “Hello World!” app, once your app’s view is complete (Figure 15), you would still have to create the various methods and connections that bring them to life. This is done using the Source editor while working with the ViewController.m file.

Add View Controller LogicSince the app performs two basic operations (save data to Kinvey and load data from Kinvey) these two methods must be added to the ViewController header file. That’s done with a control-drag from the “+” bar button over to just under the “@ interface ViewController” line in ViewController.h. (Open the Assistant editor to see both the storyboard and the file source.)

During the drag, the popup appears, asking for the name and type of connection. Enter “action” for the connection type and “add” for the name. Then repeat the drag, this time from the refresh control and using “add” for the name (Figure 16).

Note: to follow this discussion it will help to have the referenced files open in your Xcode Source editor.

In ViewController.m, you will see the implementation code associated with each of the two Interface Builder methods, whose names Xcode added automatically to the .m file:

- (IBAction)add:(id)sender- (IBAction)load:(id)sender

You will also see a third section of code not associated with these methods, which starts with the line: “#pragma mark - Table View Stuff.” These methods support the table view and are part of UITableViewD-elegate and UITableViewDataSource. They handle controlling the

display of the table, and respond to user gestures. For example, swiping a table cell will show the delete button because tableView:-canEditRowAtIndexPath: returns YES and tableView:editingStyleForRowA-tIndexPath: returns UITableViewCellEditingStyleDelete. If you tap the delete button, the delegate method tableView:commitEditingStyle:for-RowAtIndexPath: is called. The code of this method deletes the data for the row and removes it from Kinvey’s data store. When the backend delete is completed, the app displays an alert describing the success or failure.

The way that all three sections (and all Kinvey-enabled apps) move data in and out of a Kinvey collection is by getting a reference to the app’s backend collection (named “testObjects”), which is filled with instances (each named “TestObject”) of the data the app wants to move. That’s why you’ll find the following code repeated three times in Test Drive’s View Controller (once for the add, once for the load, and once for the delete):

To support these statements it is required to have a data object class (TestObject). To see how these files are written in the sample project, click on TestObject.h file and TestObject.m in the Navigator pane. If you were to supply these files in your own app, you would click File > New File, and specify Objective-C class, which would be a subclass of NSObject. Then you would type in the code, with a property for each column in the Kinvey backend collection (including one for the object’s id).

As mentioned earlier, your app also needs to authenticate itself to Kinvey, which is handled by AppDelegate.h and AppDelgate.m. These files are created by Xcode when you create a new project, and start out with just a stub implementation. Look in the sample app source

files for code to copy and paste.

For both the save and load operations, however, moving the data in and out of a backend collection is only part of the work. Table 1 lists all the functions that implements the save and load in the ViewCon-troller.m file, along with pointers to its corresponding block of imple-mentation source code. (For each function, its corresponding code begins with the “Starts at” line and ends with the “Ends at” line.) Refer to Appendix 1 to find the actual source code.

Say Hello To Our WorldThe key takeaway from all this is that “making an app” is a worthwhile thing to do for anyone with a clever idea and a working knowledge of Objective-C. The proof is in the hundreds of apps succeeding in the market every day, many written by people working on their own and who never wrote an app before in their lives. As with anything else, practice does make perfect. But hopefully with all the resources available, and the knowledge gained from this ebook, you have already started down the path toward joining the growing legions of iOS app developers. If so, we welcome you!

Appendix 1 — Test Drive Sample App ViewController.m Source Code

fig. 2 The Xcode interface

20

The iOS revolutionIt’s a story that never gets old. The weekend that iPad Minis and the fourth generation iPads went on sale (November 2-5, 2012) Apple sold over 3 million of the devices — a record for first-weekend iPad sales. Two months earlier the company had set another record: first weekend sales of over 5 million for the iPhone 5. Since the introduc-tion of the first iPhone back in 2007,

iOS-based devices (iPhone, iPad, iPad Mini and iPod Touch) continue to rewrite the definition of what constitutes a successful product. By the end of 2012, over 400 million iOS devices had been sold.

What makes iOS devices so successful? Innovation and product features are clearly a big part. Before the iPhone most people had not interacted with a multi-touch interface. They had never zoomed with a pinch or switched between portrait and landscape by merely rotating a device in their hand. Carrying a phone that knew where they were, could suggest places to eat, and could offer directions on how to get there was also a novel experience.

But features like multi-touch, accelerometers and GPS are only part of the appeal. Even with all its innovations, iOS still might not have taken off the way it has if the only people figuring out ways to use those innovations worked at Apple. Most of the capabilities available in an iPhone or iPad in fact don’t come from Apple at all. They come from legions of third-party developers who work in a vast ecosystem that is also an Apple innovation. That ecosystem includes the iPhone, iPad, iPad Mini, iPods, App Store, iTunes, ad networks — and that’s just on the consumer side. On the developer side, you have Xcode, App Loader, testing tools, iTunes Connect — the list goes on.

As of September 2012, the App Store hosted over 700,000 apps that have collectively been downloaded over 30 billion times. Apple reported for October 2012 that App Store monthly revenues were

running at $333 million — a rate of about $4 billion per year — remarkable for a store that only opened in July 2008.

Another innovation that has spurred iOS app development is “The Cloud.” Cloud services make it easier for independent developers to create, support and make money from their apps. The Cloud solves data storage and cross-device and user-to-user sharing problems. If an app stores data in the Cloud, that part of the application is called the “backend,” while the part of the app that runs on the phone and interacts with the user is called the “front end.”

A cloud may be “private” — i.e., the services belong to an organization for the benefit of its employees and business partners. Or a cloud may be “public” — i.e., a company (such as Amazon or Kinvey) owns the services, which developers can then integrate into their own apps. If you are a developer and want to build your own backend, you certainly can do that. Whether you want to or not depends on whether your backend provides functionality common to many different apps. If it does (as in a shopping cart or user authenti-cation) then perhaps that time and money would be better spent on features that offer unique value to your customer. You may be better off hooking into a commercial backend provider via an API. Then you can focus on what counts most — a unique user experience and application-specific functionality. That brings us to the first step in making an app.

Define your appMost unsuccessful apps fail for any of four reasons:

1. the app was a solution in search of a problem (i.e., no real need existed) 2. the implementation was poor 3. the app tried to do too much; or 4. the Apple App Store rejected the app (either because the implementation was poor or it violated Apple’s content policies)

Keeping the app as simple as possible is the best way to avoid these pitfalls. Most successful apps (indeed, most successful consumer tech products) are based on what is called an MVP, or minimum viable product. It’s the product with the smallest feature set that can deliver the core function without any distracting “bells and whistles.” You know you have an MVP if the product would no longer function if you removed any single feature.

But what should that core feature be? One of the best examples of an MVP is Mail. Version 1 (on the Mac) offered a clear, limited and intuitive feature set whose usefulness was immediately obvious to anyone. Today’s iPhone version integrates seamlessly with your phone, contacts and calendaring. It auto-matically corrects spelling as you type, lets you email photos directly from your photos app, and does much more. But all that came later and was built on top of a basic core function. And that’s how your first app should be built. The key is to come up with something with a clear value that changes people’s lives.

So, in drawing up your MVP feature list, ask yourself what features are key to the experience. Some basic market research is probably in order, starting with a visit to the App Store to see what already exists (possibly to be improved upon and/or to compete with you). Likely

must-have core capabilities include:

• Performance (e.g., fast screen refresh)• Offline capability (i.e., ability to work when not connected to the Internet)• Location awareness (e.g., the data/experience will change with the user’s location)• Cloud syncing (e.g., users see the same data on multiple devices)• Push notifications (i.e., sending updated information to devices as soon as it is available)

When you have a handle on what your app does, the next step is to design it. Designing your app involves making choices of how infor-mation and controls are presented to the user as well as how to implement app logic, and figuring out what data lives locally and what belongs in the Cloud.

Design your appUser experience decisions determine the app’s look and feel. They answer questions such as: What does the app look like? What screens does it have? In the software development world, onscreen objects like buttons, sliders, and fill-in boxes are called widgets. So you need to decide which types of widgets will reside on which screens. And what actions will occur as a result of the user interacting with those widgets?

Keep in mind that users will expect to interact differently with a mobile device than they do with a PC because the screens on mobile devices are much smaller. They’ll expect to use their fingers instead of a mouse or a track pad. Ideally, your app can even be used with one hand holding the device while using just a thumb for scrolling andworking the app’s other controls— the Path app is a good example, and increasingly, so is Facebook.

Your app’s features will inform its architecture, which is how you’ll divide the code and data into functional parts. If your app requires interacting with other app users or networked services, you’ll need to figure out what piece of the logic lives in the app code and what comes from the backend. For example, your app might integrate with a restau-rant recommendation engine, share user location, or pull real-time traffic data. This is done using APIs provided by various service providers — but you don’t have to wire up your app to a network to get started. You can develop a prototype using predefined representative (or “dummy”) data. It’s easier to fine-tune the front end if you don’t have to simultaneously modify your backend too. Once you get the app’s look-and-feel right, then make those backend connections.

Once you’ve got the overall concept for your app, the next step is to express that design in terms of the iOS app architecture. That archi-tecture is the model for what parts an iOS app can contain and how those parts fit together. It’s a well thought-out approach for translat-ing a product concept into actual code you can deploy on a device.

WHY iOS?Besides the features and design of your first app, there’s one more decision you need to make before you start actual development. That’s whether to deploy on Apple’s iOS platform or on Google’s Android platform. (Some of this is also covered in our ebook, How to Make an App: Android Edition.) Reasons to develop for iOS include:

Customers more willing to pay. Perhaps it’s because of Android’s open source heritage, but whatever the reason, Android apps gener-ate less than 10% of the total dollars spent on mobile apps, despite having 75% of the smartphone market itself — and despite the fact that the average selling price of an app in the Google Play is $3.79 versus Apple App Store’s $2.01. In other words, Apple users are much more willing to spend money on apps.

The Apple Ecosystem. Some developers and users prefer Apple’s closed and more tightly controlled environment. Apple’s ecosystem, consisting of Xcode, iCloud, iTunes, the App Store, the iPad, the iPhone, Mac computers, etc., offers a very holistic user experience with the ability to share data seamlessly across devices plus the

assurance of having applications pre-approved for quality and content prior to going on sale.

Xcode. Apple’s all-in-one IDE offers state-of-the-art offers features like a graphical interface builder and a syntax-aware and compiler-aware source editor.

The Apple Experience. From the fit and finish of its hardware to the customer service in its retail stores, to the way its hardware and software work flawlessly together, Apple has created the premium brand in consumer electronics. iOS developers share the benefits — so when someone downloads your iOS app, they already expect it’s a great product. And that it will also work flawlessly on their device.

Tablets. iOS has a clear advantage over Android in terms of tablet market adoption. Using Xcode, it’s also much easier to migrate an app from a phone to a tablet and vice versa than it is when develop-ing for Android.

Why Not iOS?Although iOS offers many compelling advantages as a platform for your mobile app, it also comes with some disadvantages. Here are three:

Closed Platform. iOS apps only run on Apple products so you can’t take advantage of features (like NFC) available only on non-iOS devices or market growth of non-iOS devices.

Market Growth. Today, iOS represents less than 15% of the total smartphone market, Although the total market (“the whole pie”) is still increasing at a fast rate, Android market growth outpaces iOS growth.

Approvals. The App Store’s app approval process is notoriously more time consuming than Google Play’s process.

The iOS app architectureAs noted earlier, a key reason why there are so many apps for iOS is because developing highly functional, polished apps for the platform is relatively easy. That’s mainly because of: 1) the design of the development tools, and 2) the key architectural features most iOS apps have in common. So let’s start with some concepts since it helps to know what goes into an app before trying to create one. We’ll begin with:

• Design patterns• Frameworks• Delegation• Storyboard• Windows• Outlets• Supporting files• Products

Design patterns. iOS apps implement what is known as a Mod-el-View-Controller (MVC) pattern. A pattern is a common way to structure code that solves a particular design problem. The MVC pattern separates application code in a way that allows you to easily change one part of an app without having to change other parts. An MVC pattern consists of three components:

• The Model is the logic that acts on the data, such as to store or retrieve data from a database, compute the distance between two cities on a map, etc. An example of a model is the Kinvey backend that stores your data in the Cloud as a service.

• The View provides the interface to the user; it displays the data and widgets (e.g., buttons and text fields) that allow the user to interact with the data. An iPhone app may have more than one view, as in the Contacts app, which displays a list view of all contacts or alternatively a view of each individual contact.

• The Controller is between the model and the view — i.e., it responds to user requests (made in a view) and retrieves results

(produced in a model). This is where developers spend most of their time — constructing the View Controller — by defining and attaching actions (or behaviors) to onscreen widgets. When the user taps a button, for example, it is the View Controller that determines what action will occur, such as retrieve stored data from your Kinvey-based data store. The link between a view object (like a button) to a controller action is called a connection.

Frameworks. You don’t actually have to write most of an app’s logic. It already exists as frameworks. A framework is a collection of classes that implements some function — such as connecting to the Internet, drawing a button, etc. Rather than write the code from scratch, you just use the frameworks supplied by iOS. Some frameworks are automatically present when you start a new project while others may need to be added (done via a drop down menu in Xcode’s Project Editor).

Delegation. Say, you want to customize the behavior of a framework’s object. You can’t actually modify the code of the framework class itself (prohibited since other apps may also use the framework). But what you can do is provide app-specific behavior in an application delegate object. If a delegate implements a method, it will be called by the delegating class to modify its behavior. In the Kinvey sample app (one of two examples we will be describing below), the AppDele-gate.h and AppDelegate.m — the header and implementation files for the UIApplicationDelegate, respectively — contain the code that authenticates an app to the Kinvey backend service.

Storyboards and XIBs. The MainStoryboard.storyboard file (or a .xib file, if you did not click on the “Use Storyboard” option when starting your project) contains the view information needed to implement the overall flow and display of your application and the user interface elements.

Windows. Each view (e.g., the contact list and individual contact details in the Contacts app) exists within a window. The window represents the entire device screen and is where all your views are presented.

Outlets. A variable by which a view object can be referenced in a controller. (For example, if you place a text field to capture a user's name, you might create an outlet called UITextField* nameField.)

Supporting files. These are files that provide resources (like PNG images and other static data) that your app needs as well as files that configure how the app will run. Other examples:

.pch files — precompiled headers used for the code files in your project.

.plist files — property lists that are small amounts of persistent data (like your app’s default user settings) consisting primarily of strings and numbers that you want your app to be able to access, modify if needed, and write back into the property list.

main.m file — your app’s main function. This is needed to launch the app, but you will not need to modify this file.

InfoPlist.strings file — used for localization.

Products. This is the file for your app (i.e., YourProduct.app) that is built when you click Xcode’s “run” button.

“Making an iOS app” involves working with these features in the typical, straightforward workflow:

• Storyboard your views by dragging and configuring graphicalobjects on a template

• Adding behaviors to the various widgets• Writing the classes as to define those behaviors (including

delegates)• Adding needed support files• Building and running the app• Iterating until you are satisfied with your app

This is all done within Xcode.

What’s Xcode?You can start developing functional, good-looking apps almost from the moment you download Xcode, Apple’s integrated development environment (IDE) for making iOS and Macintosh apps. Among other features, Xcode includes a source code editor, graphical user inter-face (GUI) editor (sometimes called Interface Builder), source code repository manager, compiler, and much more. iOS applications are typically developed by manipulating views graphically and by typing Objective-C code for the models and controllers.

To get Xcode, simply go to the App Store and download the applica-tion (it’s free). To do this, click on the App Store icon in your Mac’s dock, or visit https://itunes.apple.com/us/genre/ios/id36?mt=8

The app store will download and install Xcode in your Application folder. From Applications, double-click the Xcode icon to launch Xcode and you’ll see its splash screen (Figure 1). From there you can click on “Create a new Xcode project” to take you to a menu of several templates on which to base your application. Selecting a template opens an Xcode workspace pre-populated with frameworks and other files Xcode thinks you will need using that template.

Although you can develop, build and simulate your app on your computer in Xcode, you can’t run your app on a target device (even your own iPhone) until you become a registered iOS developer and join the iOS Developer Program. To do that, go to develop-er.app.com/ and navigate to the iOS Dev Center. While there, you will also find documentation, sample code and other useful resources such as information on how to submit your app to the iOS App Store.

Everything you do in Xcode is done in a window, called a workspace (Figure 2), consisting of multiple work areas, some of which are also divided into panes. All the files needed to build your app belong to a project, and the Navigator area (far left) lists all your projects (there can be several in a workspace) and all files for each project. Clicking on a file in the Navigator area shows its contents in the Editor area and invokes the appropriate editor. Clicking on a .h or .m file, for example, shows the file’s source code and invokes the Source editor, so you can edit the code. Clicking on .storyboard or .xib (sometimes called a “nib”) file shows the app’s storyboard and invokes the Inter-face Builder, so you can design a view using the Builder’s drag and drop features.

An especially handy feature is that the Editor area can have both a right and a left pane — with each pane aware of your edits in the other. So, for example, you can simultaneously edit an object’s .h

header file in the left pane and its corresponding .m in the right pane. Or you might click on a button object (displayed graphically) in the left pane and edit its method’s source code in the right pane. To toggle between a single pane (the “Standard Editor”) and double pane view (the “Assistant Editor”), use the Editor selector button on the right of the toolbar. You can option+command+click a symbol in the editor to open the definition in the opposite editor pane.

You can also resize the entire Editor area simply by dragging its borders. For even more editing space, you can also remove the Debug area or both the Debug and Utility areas using the View Selector button on the far right of the toolbar.

As its name suggests, the Debug area shows information, like variable state and console logs, helpful in debugging code.

The Utility area has two panes: the Inspector and Quick Help pane (top) and the Library pane (bottom). Although there are five inspectors — File, Help, Identity, Attributes, Size and Connec-tions — only the inspectors that are currently relevant appear in the Inspec-tor list at the top of the pane. (To see the name of an inspector, move the cursor over its icon in the Inspector selector bar.)

You will use inspectors to add and modify object attributes for views in the Interface Builder. For example, if you click on a UILabel in the Editor area of a storyboard, you can use the Attributes inspector to change the label’s color and use the Size inspector to change the label’s size.

The Help inspector shows help information about a selected class. Use the Identity inspector to view and manage an object’s metadata such as its class, runtime attributes, label and so forth. Use the

Connections inspector to view the outlets and actions of an interface object, to make new connections and to delete existing connections.

The Library pane has libraries of resources (like file templates, code snippets, interface objects and media files) that are prebuilt and ready to insert into your project. Use the Library selector to select which of these libraries (e.g., code snippets or interface objects) you wish to insert. To insert one, drag it directly into your storyboard while using the Interface Builder editor.

These are basics you need to know to get started using Xcode to build your first app. But to really understand how it’s done, it helps to walk through an actual app or two. Let’s start with a simple “Hello World” app that does not employ a backend connection, and then look at a somewhat more functional app that does.

“Hello World!” sample appThis app displays a button (“Press Me”) and a label (“Label”) so that when the user presses the button the text of the label changes to “Hello World!” as in Figure 3:

To get started, launch Xcode and select “Create a New Xcode Project.” From the iOS Application templates, select “Single View Application” and click “Next.” Fill in your product’s name and a company identifier, typically “com.yourCompanyName.” Deselect “Use Storyboards” and leave “Use Automatic Reference Counting” selected. Then click “Next” and select a destination for your projects files.

Follow these steps to make your app:

1. Select your project’s ViewController.xib file in the Navigator(Figure 4), to open the Interface Builder editor.

2. Drag a “Round Rect Button” from the Objects library (lowerright) onto the view in the Editor area; select the button’s textand type “Press Me.”

3. Drag a Label from the objects library onto the view, as well.4. Select and drag the Label sizing handles, centering the object

and making it wide enough to hold the “Hello World!” text; then,

5. With the “Hello World!” label still selected, click on centeralignment in the Attributes inspector.

6. Open the Assistant Editor (Figure 5), exposing the source codeheader file (ViewController.h) of the view controller you justbuilt graphically.

7. Select the button and control-drag from the button to justbelow the ViewController definition in the Assistant panel. Inthe form that opens, select “Action” for the connection type,type in a name (“showText”) and click “Connect.” This creates aninterface builder (IB) action as highlighted in Figure 6.

8. Next step is to create an outlet for the label. To do this, selectthe label object and control-drag from the label to just belowthe IB action you just created. Select “Outlet” as the connectiontype and enter a name “label” and click “Connect.” This createsan interface builder (IB) outlet as shown in Figure 7.

9. Finally, it’s time to add some logic to the view controller so itknows what to do when the button is pressed. To do this, select “ViewController.m” in the project navigator to show the code editor. Find the button’s IBAction you just created (near the bottom), place your cursor between the { } brackets and hit the return key a few times to create some extra space. Then in that space type the method for how you want the label you speci-fied to respond: _label.text=”Hello World!”; as highlighted in Figure 8.

Congratulations! Your app is done. To build and run your new app in the simulator, click the Xcode Run button in the left corner of the toolbar. When you click the button, the text will update.

Sample app with a backend This second app (named “Kinvey Test Drive”) lets the user type text on an iPhone and save the text to a backend service, like Kinvey. It also lets the user load text on the iPhone from their Kinvey backend. Reading about this app will help you learn:

• How to set up Kinvey’s library in an iOS project• Additional Interface Builder techniques you can use to story-board an application• How to add view controller logic to interact with the backend service, allowing you to save and retrieve data

We will first present the app as a running application and then take it apart so you can see how it was made. To make the app yourself, you can review the various sections below and replicate the steps in your copy of Xcode.

First, to see the app in action, you should download the app and run it on your system. To do that, sign up for Kinvey, then navigate to “Dev Center”, “Samples,” find the “Test Drive” app, and click on its icon. (If you can’t find it right away, make sure you select iOS as your platform on the right side of the menu bar.) Click the download button to download the app’s project files to your computer. Then launch Xcode — just double click on the .xcodeproj file in the project folder.

But before you can run the app, you need to set up the app’s Kinvey backend.

Set Up Kinvey as a Backend Data StoreTest Drive’s project files include all the code the sample app needs in order to talk to Kinvey. However, that would not be the case if you were to build an app from scratch — so you would have to go through an initial Kinvey setup procedure. This involves downloading the Kinvey library files from the downloads section of devcenter.kin-vey.com and dragging them to the Navigator’s Frameworks folder in Xcode. You also need to tell Xcode to link your project with additional iOS frameworks. To find these frameworks, click on the Project folder

at the very top of the Navigator pane — which displays the Project editor — and then select the “Build Settings” tab. For detailed instruc-tions, complete the “Getting Started” page under “Guides” on the Kinvey website. But again, you can skip this setup procedure for now in order to run the downloaded Kinvey Test Drive app.

But you must still do this step: To run any app that uses Kinvey (including Test Drive) you need to do the “Create an App” step on the Kinvey website. Click on “My Apps” in the Kinvey menu bar and then click on “Add an App,” which will open an “Add” page. Type in a name for your app and click on the Apple logo and then click “Create.” The page that opens shows your App’s credentials. Copy and paste the App Key and App Secret into the AppDelegate.m file of the download-ed Test Drive project:

You are now ready to run the app — click on the Xcode run button and wait for the simulator to open and the app to appear (Figure 9).

Clicking the “+” toolbar button opens an alert (Figure 10) with an empty field into which the user can type some text (e.g., “some new data”). Clicking “save” uploads the data to Kinvey and displays text on the screen (a table view) and also displays an alert that the save worked (Figure 11).

To test the load function, enter some data (e.g., “some data to load”) in the “name” field of the Kinvey collection. To see the load, the swipe down on the table on the phone until the refresh spinner starts, and then the new data will appear in the table (Figure 12).

Figure 13 shows the Kinvey collection after the save that Figure 10 depicts on the iPhone. Figure 14 shows the Kinvey collection after the user adds a new row to the testObjects collection using the web browser. Note that every time a save is done on the iPhone, Kinvey automatically adds a new row (displayed on a collection refresh). To add a new row manually in the browser, click “+ row,” and type some descriptive text in the “name” column. That data will now load on the iPhone when the user pulls down on the table.

Storyboard the Test Drive AppMost of the Test Drive user interface objects visible in the simulation are available in Xcode’s Object Library and can therefore be added to the view graphically. The UI objects consist of a:

• Table view• Toolbar• Tool Bar Button item – flexible space• Tool Bar Button item – Add• Table view cell• Label – Title• Refresh Control

To create this app yourself, you would follow these steps:

• Launch Xcode and select the “Single View Application” template• Select the “Use Storyboard” option• Replace the default UIviewcontroller object with a UITableView-Controller • Drag and drop the other objects, in the order listed, onto the UIviewcontroller

Also note:

• The Flexible Space Bar Button item fills up the space on the toolbar so the add button is at the right. This is a standard pattern in table-based iPhone apps.• The add button shows the system “+” sign. That is done by dragging a bar button item onto the toolbar, clicking on the Identifier drop down menu in the Attributes inspector; and then selecting the “Add” option.

As with the “Hello World!” app, once your app’s view is complete (Figure 15), you would still have to create the various methods and connections that bring them to life. This is done using the Source editor while working with the ViewController.m file.

Add View Controller LogicSince the app performs two basic operations (save data to Kinvey and load data from Kinvey) these two methods must be added to the ViewController header file. That’s done with a control-drag from the “+” bar button over to just under the “@ interface ViewController” line in ViewController.h. (Open the Assistant editor to see both the storyboard and the file source.)

During the drag, the popup appears, asking for the name and type of connection. Enter “action” for the connection type and “add” for the name. Then repeat the drag, this time from the refresh control and using “add” for the name (Figure 16).

Note: to follow this discussion it will help to have the referenced files open in your Xcode Source editor.

In ViewController.m, you will see the implementation code associated with each of the two Interface Builder methods, whose names Xcode added automatically to the .m file:

- (IBAction)add:(id)sender- (IBAction)load:(id)sender

You will also see a third section of code not associated with these methods, which starts with the line: “#pragma mark - Table View Stuff.” These methods support the table view and are part of UITableViewD-elegate and UITableViewDataSource. They handle controlling the

display of the table, and respond to user gestures. For example, swiping a table cell will show the delete button because tableView:-canEditRowAtIndexPath: returns YES and tableView:editingStyleForRowA-tIndexPath: returns UITableViewCellEditingStyleDelete. If you tap the delete button, the delegate method tableView:commitEditingStyle:for-RowAtIndexPath: is called. The code of this method deletes the data for the row and removes it from Kinvey’s data store. When the backend delete is completed, the app displays an alert describing the success or failure.

The way that all three sections (and all Kinvey-enabled apps) move data in and out of a Kinvey collection is by getting a reference to the app’s backend collection (named “testObjects”), which is filled with instances (each named “TestObject”) of the data the app wants to move. That’s why you’ll find the following code repeated three times in Test Drive’s View Controller (once for the add, once for the load, and once for the delete):

To support these statements it is required to have a data object class (TestObject). To see how these files are written in the sample project, click on TestObject.h file and TestObject.m in the Navigator pane. If you were to supply these files in your own app, you would click File > New File, and specify Objective-C class, which would be a subclass of NSObject. Then you would type in the code, with a property for each column in the Kinvey backend collection (including one for the object’s id).

As mentioned earlier, your app also needs to authenticate itself to Kinvey, which is handled by AppDelegate.h and AppDelgate.m. These files are created by Xcode when you create a new project, and start out with just a stub implementation. Look in the sample app source

files for code to copy and paste.

For both the save and load operations, however, moving the data in and out of a backend collection is only part of the work. Table 1 lists all the functions that implements the save and load in the ViewCon-troller.m file, along with pointers to its corresponding block of imple-mentation source code. (For each function, its corresponding code begins with the “Starts at” line and ends with the “Ends at” line.) Refer to Appendix 1 to find the actual source code.

Say Hello To Our WorldThe key takeaway from all this is that “making an app” is a worthwhile thing to do for anyone with a clever idea and a working knowledge of Objective-C. The proof is in the hundreds of apps succeeding in the market every day, many written by people working on their own and who never wrote an app before in their lives. As with anything else, practice does make perfect. But hopefully with all the resources available, and the knowledge gained from this ebook, you have already started down the path toward joining the growing legions of iOS app developers. If so, we welcome you!

Appendix 1 — Test Drive Sample App ViewController.m Source Code

“...you can’t runyour app on a target device

until you become a registered iOS

developer...”

21

The iOS revolutionIt’s a story that never gets old. The weekend that iPad Minis and the fourth generation iPads went on sale (November 2-5, 2012) Apple sold over 3 million of the devices — a record for first-weekend iPad sales. Two months earlier the company had set another record: first weekend sales of over 5 million for the iPhone 5. Since the introduc-tion of the first iPhone back in 2007,

iOS-based devices (iPhone, iPad, iPad Mini and iPod Touch) continue to rewrite the definition of what constitutes a successful product. By the end of 2012, over 400 million iOS devices had been sold.

What makes iOS devices so successful? Innovation and product features are clearly a big part. Before the iPhone most people had not interacted with a multi-touch interface. They had never zoomed with a pinch or switched between portrait and landscape by merely rotating a device in their hand. Carrying a phone that knew where they were, could suggest places to eat, and could offer directions on how to get there was also a novel experience.

But features like multi-touch, accelerometers and GPS are only part of the appeal. Even with all its innovations, iOS still might not have taken off the way it has if the only people figuring out ways to use those innovations worked at Apple. Most of the capabilities available in an iPhone or iPad in fact don’t come from Apple at all. They come from legions of third-party developers who work in a vast ecosystem that is also an Apple innovation. That ecosystem includes the iPhone, iPad, iPad Mini, iPods, App Store, iTunes, ad networks — and that’s just on the consumer side. On the developer side, you have Xcode, App Loader, testing tools, iTunes Connect — the list goes on.

As of September 2012, the App Store hosted over 700,000 apps that have collectively been downloaded over 30 billion times. Apple reported for October 2012 that App Store monthly revenues were

running at $333 million — a rate of about $4 billion per year — remarkable for a store that only opened in July 2008.

Another innovation that has spurred iOS app development is “The Cloud.” Cloud services make it easier for independent developers to create, support and make money from their apps. The Cloud solves data storage and cross-device and user-to-user sharing problems. If an app stores data in the Cloud, that part of the application is called the “backend,” while the part of the app that runs on the phone and interacts with the user is called the “front end.”

A cloud may be “private” — i.e., the services belong to an organization for the benefit of its employees and business partners. Or a cloud may be “public” — i.e., a company (such as Amazon or Kinvey) owns the services, which developers can then integrate into their own apps. If you are a developer and want to build your own backend, you certainly can do that. Whether you want to or not depends on whether your backend provides functionality common to many different apps. If it does (as in a shopping cart or user authenti-cation) then perhaps that time and money would be better spent on features that offer unique value to your customer. You may be better off hooking into a commercial backend provider via an API. Then you can focus on what counts most — a unique user experience and application-specific functionality. That brings us to the first step in making an app.

Define your appMost unsuccessful apps fail for any of four reasons:

1. the app was a solution in search of a problem (i.e., no real need existed) 2. the implementation was poor 3. the app tried to do too much; or 4. the Apple App Store rejected the app (either because the implementation was poor or it violated Apple’s content policies)

Keeping the app as simple as possible is the best way to avoid these pitfalls. Most successful apps (indeed, most successful consumer tech products) are based on what is called an MVP, or minimum viable product. It’s the product with the smallest feature set that can deliver the core function without any distracting “bells and whistles.” You know you have an MVP if the product would no longer function if you removed any single feature.

But what should that core feature be? One of the best examples of an MVP is Mail. Version 1 (on the Mac) offered a clear, limited and intuitive feature set whose usefulness was immediately obvious to anyone. Today’s iPhone version integrates seamlessly with your phone, contacts and calendaring. It auto-matically corrects spelling as you type, lets you email photos directly from your photos app, and does much more. But all that came later and was built on top of a basic core function. And that’s how your first app should be built. The key is to come up with something with a clear value that changes people’s lives.

So, in drawing up your MVP feature list, ask yourself what features are key to the experience. Some basic market research is probably in order, starting with a visit to the App Store to see what already exists (possibly to be improved upon and/or to compete with you). Likely

must-have core capabilities include:

• Performance (e.g., fast screen refresh)• Offline capability (i.e., ability to work when not connected to the Internet)• Location awareness (e.g., the data/experience will change with the user’s location)• Cloud syncing (e.g., users see the same data on multiple devices)• Push notifications (i.e., sending updated information to devices as soon as it is available)

When you have a handle on what your app does, the next step is to design it. Designing your app involves making choices of how infor-mation and controls are presented to the user as well as how to implement app logic, and figuring out what data lives locally and what belongs in the Cloud.

Design your appUser experience decisions determine the app’s look and feel. They answer questions such as: What does the app look like? What screens does it have? In the software development world, onscreen objects like buttons, sliders, and fill-in boxes are called widgets. So you need to decide which types of widgets will reside on which screens. And what actions will occur as a result of the user interacting with those widgets?

Keep in mind that users will expect to interact differently with a mobile device than they do with a PC because the screens on mobile devices are much smaller. They’ll expect to use their fingers instead of a mouse or a track pad. Ideally, your app can even be used with one hand holding the device while using just a thumb for scrolling andworking the app’s other controls— the Path app is a good example, and increasingly, so is Facebook.

Your app’s features will inform its architecture, which is how you’ll divide the code and data into functional parts. If your app requires interacting with other app users or networked services, you’ll need to figure out what piece of the logic lives in the app code and what comes from the backend. For example, your app might integrate with a restau-rant recommendation engine, share user location, or pull real-time traffic data. This is done using APIs provided by various service providers — but you don’t have to wire up your app to a network to get started. You can develop a prototype using predefined representative (or “dummy”) data. It’s easier to fine-tune the front end if you don’t have to simultaneously modify your backend too. Once you get the app’s look-and-feel right, then make those backend connections.

Once you’ve got the overall concept for your app, the next step is to express that design in terms of the iOS app architecture. That archi-tecture is the model for what parts an iOS app can contain and how those parts fit together. It’s a well thought-out approach for translat-ing a product concept into actual code you can deploy on a device.

WHY iOS?Besides the features and design of your first app, there’s one more decision you need to make before you start actual development. That’s whether to deploy on Apple’s iOS platform or on Google’s Android platform. (Some of this is also covered in our ebook, How to Make an App: Android Edition.) Reasons to develop for iOS include:

Customers more willing to pay. Perhaps it’s because of Android’s open source heritage, but whatever the reason, Android apps gener-ate less than 10% of the total dollars spent on mobile apps, despite having 75% of the smartphone market itself — and despite the fact that the average selling price of an app in the Google Play is $3.79 versus Apple App Store’s $2.01. In other words, Apple users are much more willing to spend money on apps.

The Apple Ecosystem. Some developers and users prefer Apple’s closed and more tightly controlled environment. Apple’s ecosystem, consisting of Xcode, iCloud, iTunes, the App Store, the iPad, the iPhone, Mac computers, etc., offers a very holistic user experience with the ability to share data seamlessly across devices plus the

assurance of having applications pre-approved for quality and content prior to going on sale.

Xcode. Apple’s all-in-one IDE offers state-of-the-art offers features like a graphical interface builder and a syntax-aware and compiler-aware source editor.

The Apple Experience. From the fit and finish of its hardware to the customer service in its retail stores, to the way its hardware and software work flawlessly together, Apple has created the premium brand in consumer electronics. iOS developers share the benefits — so when someone downloads your iOS app, they already expect it’s a great product. And that it will also work flawlessly on their device.

Tablets. iOS has a clear advantage over Android in terms of tablet market adoption. Using Xcode, it’s also much easier to migrate an app from a phone to a tablet and vice versa than it is when develop-ing for Android.

Why Not iOS?Although iOS offers many compelling advantages as a platform for your mobile app, it also comes with some disadvantages. Here are three:

Closed Platform. iOS apps only run on Apple products so you can’t take advantage of features (like NFC) available only on non-iOS devices or market growth of non-iOS devices.

Market Growth. Today, iOS represents less than 15% of the total smartphone market, Although the total market (“the whole pie”) is still increasing at a fast rate, Android market growth outpaces iOS growth.

Approvals. The App Store’s app approval process is notoriously more time consuming than Google Play’s process.

The iOS app architectureAs noted earlier, a key reason why there are so many apps for iOS is because developing highly functional, polished apps for the platform is relatively easy. That’s mainly because of: 1) the design of the development tools, and 2) the key architectural features most iOS apps have in common. So let’s start with some concepts since it helps to know what goes into an app before trying to create one. We’ll begin with:

• Design patterns• Frameworks• Delegation• Storyboard• Windows• Outlets• Supporting files• Products

Design patterns. iOS apps implement what is known as a Mod-el-View-Controller (MVC) pattern. A pattern is a common way to structure code that solves a particular design problem. The MVC pattern separates application code in a way that allows you to easily change one part of an app without having to change other parts. An MVC pattern consists of three components:

• The Model is the logic that acts on the data, such as to store or retrieve data from a database, compute the distance between two cities on a map, etc. An example of a model is the Kinvey backend that stores your data in the Cloud as a service.

• The View provides the interface to the user; it displays the data and widgets (e.g., buttons and text fields) that allow the user to interact with the data. An iPhone app may have more than one view, as in the Contacts app, which displays a list view of all contacts or alternatively a view of each individual contact.

• The Controller is between the model and the view — i.e., it responds to user requests (made in a view) and retrieves results

(produced in a model). This is where developers spend most of their time — constructing the View Controller — by defining and attaching actions (or behaviors) to onscreen widgets. When the user taps a button, for example, it is the View Controller that determines what action will occur, such as retrieve stored data from your Kinvey-based data store. The link between a view object (like a button) to a controller action is called a connection.

Frameworks. You don’t actually have to write most of an app’s logic. It already exists as frameworks. A framework is a collection of classes that implements some function — such as connecting to the Internet, drawing a button, etc. Rather than write the code from scratch, you just use the frameworks supplied by iOS. Some frameworks are automatically present when you start a new project while others may need to be added (done via a drop down menu in Xcode’s Project Editor).

Delegation. Say, you want to customize the behavior of a framework’s object. You can’t actually modify the code of the framework class itself (prohibited since other apps may also use the framework). But what you can do is provide app-specific behavior in an application delegate object. If a delegate implements a method, it will be called by the delegating class to modify its behavior. In the Kinvey sample app (one of two examples we will be describing below), the AppDele-gate.h and AppDelegate.m — the header and implementation files for the UIApplicationDelegate, respectively — contain the code that authenticates an app to the Kinvey backend service.

Storyboards and XIBs. The MainStoryboard.storyboard file (or a .xib file, if you did not click on the “Use Storyboard” option when starting your project) contains the view information needed to implement the overall flow and display of your application and the user interface elements.

Windows. Each view (e.g., the contact list and individual contact details in the Contacts app) exists within a window. The window represents the entire device screen and is where all your views are presented.

Outlets. A variable by which a view object can be referenced in a controller. (For example, if you place a text field to capture a user's name, you might create an outlet called UITextField* nameField.)

Supporting files. These are files that provide resources (like PNG images and other static data) that your app needs as well as files that configure how the app will run. Other examples:

.pch files — precompiled headers used for the code files in your project.

.plist files — property lists that are small amounts of persistent data (like your app’s default user settings) consisting primarily of strings and numbers that you want your app to be able to access, modify if needed, and write back into the property list.

main.m file — your app’s main function. This is needed to launch the app, but you will not need to modify this file.

InfoPlist.strings file — used for localization.

Products. This is the file for your app (i.e., YourProduct.app) that is built when you click Xcode’s “run” button.

“Making an iOS app” involves working with these features in the typical, straightforward workflow:

• Storyboard your views by dragging and configuring graphicalobjects on a template

• Adding behaviors to the various widgets• Writing the classes as to define those behaviors (including

delegates)• Adding needed support files• Building and running the app• Iterating until you are satisfied with your app

This is all done within Xcode.

What’s Xcode?You can start developing functional, good-looking apps almost from the moment you download Xcode, Apple’s integrated development environment (IDE) for making iOS and Macintosh apps. Among other features, Xcode includes a source code editor, graphical user inter-face (GUI) editor (sometimes called Interface Builder), source code repository manager, compiler, and much more. iOS applications are typically developed by manipulating views graphically and by typing Objective-C code for the models and controllers.

To get Xcode, simply go to the App Store and download the applica-tion (it’s free). To do this, click on the App Store icon in your Mac’s dock, or visit https://itunes.apple.com/us/genre/ios/id36?mt=8

The app store will download and install Xcode in your Application folder. From Applications, double-click the Xcode icon to launch Xcode and you’ll see its splash screen (Figure 1). From there you can click on “Create a new Xcode project” to take you to a menu of several templates on which to base your application. Selecting a template opens an Xcode workspace pre-populated with frameworks and other files Xcode thinks you will need using that template.

Although you can develop, build and simulate your app on your computer in Xcode, you can’t run your app on a target device (even your own iPhone) until you become a registered iOS developer and join the iOS Developer Program. To do that, go to develop-er.app.com/ and navigate to the iOS Dev Center. While there, you will also find documentation, sample code and other useful resources such as information on how to submit your app to the iOS App Store.

Everything you do in Xcode is done in a window, called a workspace (Figure 2), consisting of multiple work areas, some of which are also divided into panes. All the files needed to build your app belong to a project, and the Navigator area (far left) lists all your projects (there can be several in a workspace) and all files for each project. Clicking on a file in the Navigator area shows its contents in the Editor area and invokes the appropriate editor. Clicking on a .h or .m file, for example, shows the file’s source code and invokes the Source editor, so you can edit the code. Clicking on .storyboard or .xib (sometimes called a “nib”) file shows the app’s storyboard and invokes the Inter-face Builder, so you can design a view using the Builder’s drag and drop features.

An especially handy feature is that the Editor area can have both a right and a left pane — with each pane aware of your edits in the other. So, for example, you can simultaneously edit an object’s .h

header file in the left pane and its corresponding .m in the right pane. Or you might click on a button object (displayed graphically) in the left pane and edit its method’s source code in the right pane. To toggle between a single pane (the “Standard Editor”) and double pane view (the “Assistant Editor”), use the Editor selector button on the right of the toolbar. You can option+command+click a symbol in the editor to open the definition in the opposite editor pane.

You can also resize the entire Editor area simply by dragging its borders. For even more editing space, you can also remove the Debug area or both the Debug and Utility areas using the View Selector button on the far right of the toolbar.

As its name suggests, the Debug area shows information, like variable state and console logs, helpful in debugging code.

The Utility area has two panes: the Inspector and Quick Help pane (top) and the Library pane (bottom). Although there are five inspectors — File, Help, Identity, Attributes, Size and Connec-tions — only the inspectors that are currently relevant appear in the Inspec-tor list at the top of the pane. (To see the name of an inspector, move the cursor over its icon in the Inspector selector bar.)

You will use inspectors to add and modify object attributes for views in the Interface Builder. For example, if you click on a UILabel in the Editor area of a storyboard, you can use the Attributes inspector to change the label’s color and use the Size inspector to change the label’s size.

The Help inspector shows help information about a selected class. Use the Identity inspector to view and manage an object’s metadata such as its class, runtime attributes, label and so forth. Use the

Connections inspector to view the outlets and actions of an interface object, to make new connections and to delete existing connections.

The Library pane has libraries of resources (like file templates, code snippets, interface objects and media files) that are prebuilt and ready to insert into your project. Use the Library selector to select which of these libraries (e.g., code snippets or interface objects) you wish to insert. To insert one, drag it directly into your storyboard while using the Interface Builder editor.

These are basics you need to know to get started using Xcode to build your first app. But to really understand how it’s done, it helps to walk through an actual app or two. Let’s start with a simple “Hello World” app that does not employ a backend connection, and then look at a somewhat more functional app that does.

“Hello World!” sample appThis app displays a button (“Press Me”) and a label (“Label”) so that when the user presses the button the text of the label changes to “Hello World!” as in Figure 3:

To get started, launch Xcode and select “Create a New Xcode Project.” From the iOS Application templates, select “Single View Application” and click “Next.” Fill in your product’s name and a company identifier, typically “com.yourCompanyName.” Deselect “Use Storyboards” and leave “Use Automatic Reference Counting” selected. Then click “Next” and select a destination for your projects files.

Follow these steps to make your app:

1. Select your project’s ViewController.xib file in the Navigator(Figure 4), to open the Interface Builder editor.

2. Drag a “Round Rect Button” from the Objects library (lowerright) onto the view in the Editor area; select the button’s textand type “Press Me.”

3. Drag a Label from the objects library onto the view, as well.4. Select and drag the Label sizing handles, centering the object

and making it wide enough to hold the “Hello World!” text; then,

5. With the “Hello World!” label still selected, click on centeralignment in the Attributes inspector.

6. Open the Assistant Editor (Figure 5), exposing the source codeheader file (ViewController.h) of the view controller you justbuilt graphically.

7. Select the button and control-drag from the button to justbelow the ViewController definition in the Assistant panel. Inthe form that opens, select “Action” for the connection type,type in a name (“showText”) and click “Connect.” This creates aninterface builder (IB) action as highlighted in Figure 6.

8. Next step is to create an outlet for the label. To do this, selectthe label object and control-drag from the label to just belowthe IB action you just created. Select “Outlet” as the connectiontype and enter a name “label” and click “Connect.” This createsan interface builder (IB) outlet as shown in Figure 7.

9. Finally, it’s time to add some logic to the view controller so itknows what to do when the button is pressed. To do this, select “ViewController.m” in the project navigator to show the code editor. Find the button’s IBAction you just created (near the bottom), place your cursor between the { } brackets and hit the return key a few times to create some extra space. Then in that space type the method for how you want the label you speci-fied to respond: _label.text=”Hello World!”; as highlighted in Figure 8.

Congratulations! Your app is done. To build and run your new app in the simulator, click the Xcode Run button in the left corner of the toolbar. When you click the button, the text will update.

Sample app with a backend This second app (named “Kinvey Test Drive”) lets the user type text on an iPhone and save the text to a backend service, like Kinvey. It also lets the user load text on the iPhone from their Kinvey backend. Reading about this app will help you learn:

• How to set up Kinvey’s library in an iOS project• Additional Interface Builder techniques you can use to story-board an application• How to add view controller logic to interact with the backend service, allowing you to save and retrieve data

We will first present the app as a running application and then take it apart so you can see how it was made. To make the app yourself, you can review the various sections below and replicate the steps in your copy of Xcode.

First, to see the app in action, you should download the app and run it on your system. To do that, sign up for Kinvey, then navigate to “Dev Center”, “Samples,” find the “Test Drive” app, and click on its icon. (If you can’t find it right away, make sure you select iOS as your platform on the right side of the menu bar.) Click the download button to download the app’s project files to your computer. Then launch Xcode — just double click on the .xcodeproj file in the project folder.

But before you can run the app, you need to set up the app’s Kinvey backend.

Set Up Kinvey as a Backend Data StoreTest Drive’s project files include all the code the sample app needs in order to talk to Kinvey. However, that would not be the case if you were to build an app from scratch — so you would have to go through an initial Kinvey setup procedure. This involves downloading the Kinvey library files from the downloads section of devcenter.kin-vey.com and dragging them to the Navigator’s Frameworks folder in Xcode. You also need to tell Xcode to link your project with additional iOS frameworks. To find these frameworks, click on the Project folder

at the very top of the Navigator pane — which displays the Project editor — and then select the “Build Settings” tab. For detailed instruc-tions, complete the “Getting Started” page under “Guides” on the Kinvey website. But again, you can skip this setup procedure for now in order to run the downloaded Kinvey Test Drive app.

But you must still do this step: To run any app that uses Kinvey (including Test Drive) you need to do the “Create an App” step on the Kinvey website. Click on “My Apps” in the Kinvey menu bar and then click on “Add an App,” which will open an “Add” page. Type in a name for your app and click on the Apple logo and then click “Create.” The page that opens shows your App’s credentials. Copy and paste the App Key and App Secret into the AppDelegate.m file of the download-ed Test Drive project:

You are now ready to run the app — click on the Xcode run button and wait for the simulator to open and the app to appear (Figure 9).

Clicking the “+” toolbar button opens an alert (Figure 10) with an empty field into which the user can type some text (e.g., “some new data”). Clicking “save” uploads the data to Kinvey and displays text on the screen (a table view) and also displays an alert that the save worked (Figure 11).

To test the load function, enter some data (e.g., “some data to load”) in the “name” field of the Kinvey collection. To see the load, the swipe down on the table on the phone until the refresh spinner starts, and then the new data will appear in the table (Figure 12).

Figure 13 shows the Kinvey collection after the save that Figure 10 depicts on the iPhone. Figure 14 shows the Kinvey collection after the user adds a new row to the testObjects collection using the web browser. Note that every time a save is done on the iPhone, Kinvey automatically adds a new row (displayed on a collection refresh). To add a new row manually in the browser, click “+ row,” and type some descriptive text in the “name” column. That data will now load on the iPhone when the user pulls down on the table.

Storyboard the Test Drive AppMost of the Test Drive user interface objects visible in the simulation are available in Xcode’s Object Library and can therefore be added to the view graphically. The UI objects consist of a:

• Table view• Toolbar• Tool Bar Button item – flexible space• Tool Bar Button item – Add• Table view cell• Label – Title• Refresh Control

To create this app yourself, you would follow these steps:

• Launch Xcode and select the “Single View Application” template• Select the “Use Storyboard” option• Replace the default UIviewcontroller object with a UITableView-Controller • Drag and drop the other objects, in the order listed, onto the UIviewcontroller

Also note:

• The Flexible Space Bar Button item fills up the space on the toolbar so the add button is at the right. This is a standard pattern in table-based iPhone apps.• The add button shows the system “+” sign. That is done by dragging a bar button item onto the toolbar, clicking on the Identifier drop down menu in the Attributes inspector; and then selecting the “Add” option.

As with the “Hello World!” app, once your app’s view is complete (Figure 15), you would still have to create the various methods and connections that bring them to life. This is done using the Source editor while working with the ViewController.m file.

Add View Controller LogicSince the app performs two basic operations (save data to Kinvey and load data from Kinvey) these two methods must be added to the ViewController header file. That’s done with a control-drag from the “+” bar button over to just under the “@ interface ViewController” line in ViewController.h. (Open the Assistant editor to see both the storyboard and the file source.)

During the drag, the popup appears, asking for the name and type of connection. Enter “action” for the connection type and “add” for the name. Then repeat the drag, this time from the refresh control and using “add” for the name (Figure 16).

Note: to follow this discussion it will help to have the referenced files open in your Xcode Source editor.

In ViewController.m, you will see the implementation code associated with each of the two Interface Builder methods, whose names Xcode added automatically to the .m file:

- (IBAction)add:(id)sender- (IBAction)load:(id)sender

You will also see a third section of code not associated with these methods, which starts with the line: “#pragma mark - Table View Stuff.” These methods support the table view and are part of UITableViewD-elegate and UITableViewDataSource. They handle controlling the

display of the table, and respond to user gestures. For example, swiping a table cell will show the delete button because tableView:-canEditRowAtIndexPath: returns YES and tableView:editingStyleForRowA-tIndexPath: returns UITableViewCellEditingStyleDelete. If you tap the delete button, the delegate method tableView:commitEditingStyle:for-RowAtIndexPath: is called. The code of this method deletes the data for the row and removes it from Kinvey’s data store. When the backend delete is completed, the app displays an alert describing the success or failure.

The way that all three sections (and all Kinvey-enabled apps) move data in and out of a Kinvey collection is by getting a reference to the app’s backend collection (named “testObjects”), which is filled with instances (each named “TestObject”) of the data the app wants to move. That’s why you’ll find the following code repeated three times in Test Drive’s View Controller (once for the add, once for the load, and once for the delete):

To support these statements it is required to have a data object class (TestObject). To see how these files are written in the sample project, click on TestObject.h file and TestObject.m in the Navigator pane. If you were to supply these files in your own app, you would click File > New File, and specify Objective-C class, which would be a subclass of NSObject. Then you would type in the code, with a property for each column in the Kinvey backend collection (including one for the object’s id).

As mentioned earlier, your app also needs to authenticate itself to Kinvey, which is handled by AppDelegate.h and AppDelgate.m. These files are created by Xcode when you create a new project, and start out with just a stub implementation. Look in the sample app source

files for code to copy and paste.

For both the save and load operations, however, moving the data in and out of a backend collection is only part of the work. Table 1 lists all the functions that implements the save and load in the ViewCon-troller.m file, along with pointers to its corresponding block of imple-mentation source code. (For each function, its corresponding code begins with the “Starts at” line and ends with the “Ends at” line.) Refer to Appendix 1 to find the actual source code.

Say Hello To Our WorldThe key takeaway from all this is that “making an app” is a worthwhile thing to do for anyone with a clever idea and a working knowledge of Objective-C. The proof is in the hundreds of apps succeeding in the market every day, many written by people working on their own and who never wrote an app before in their lives. As with anything else, practice does make perfect. But hopefully with all the resources available, and the knowledge gained from this ebook, you have already started down the path toward joining the growing legions of iOS app developers. If so, we welcome you!

Appendix 1 — Test Drive Sample App ViewController.m Source Code

23

The iOS revolutionIt’s a story that never gets old. The weekend that iPad Minis and the fourth generation iPads went on sale (November 2-5, 2012) Apple sold over 3 million of the devices — a record for first-weekend iPad sales. Two months earlier the company had set another record: first weekend sales of over 5 million for the iPhone 5. Since the introduc-tion of the first iPhone back in 2007,

iOS-based devices (iPhone, iPad, iPad Mini and iPod Touch) continue to rewrite the definition of what constitutes a successful product. By the end of 2012, over 400 million iOS devices had been sold.

What makes iOS devices so successful? Innovation and product features are clearly a big part. Before the iPhone most people had not interacted with a multi-touch interface. They had never zoomed with a pinch or switched between portrait and landscape by merely rotating a device in their hand. Carrying a phone that knew where they were, could suggest places to eat, and could offer directions on how to get there was also a novel experience.

But features like multi-touch, accelerometers and GPS are only part of the appeal. Even with all its innovations, iOS still might not have taken off the way it has if the only people figuring out ways to use those innovations worked at Apple. Most of the capabilities available in an iPhone or iPad in fact don’t come from Apple at all. They come from legions of third-party developers who work in a vast ecosystem that is also an Apple innovation. That ecosystem includes the iPhone, iPad, iPad Mini, iPods, App Store, iTunes, ad networks — and that’s just on the consumer side. On the developer side, you have Xcode, App Loader, testing tools, iTunes Connect — the list goes on.

As of September 2012, the App Store hosted over 700,000 apps that have collectively been downloaded over 30 billion times. Apple reported for October 2012 that App Store monthly revenues were

running at $333 million — a rate of about $4 billion per year — remarkable for a store that only opened in July 2008.

Another innovation that has spurred iOS app development is “The Cloud.” Cloud services make it easier for independent developers to create, support and make money from their apps. The Cloud solves data storage and cross-device and user-to-user sharing problems. If an app stores data in the Cloud, that part of the application is called the “backend,” while the part of the app that runs on the phone and interacts with the user is called the “front end.”

A cloud may be “private” — i.e., the services belong to an organization for the benefit of its employees and business partners. Or a cloud may be “public” — i.e., a company (such as Amazon or Kinvey) owns the services, which developers can then integrate into their own apps. If you are a developer and want to build your own backend, you certainly can do that. Whether you want to or not depends on whether your backend provides functionality common to many different apps. If it does (as in a shopping cart or user authenti-cation) then perhaps that time and money would be better spent on features that offer unique value to your customer. You may be better off hooking into a commercial backend provider via an API. Then you can focus on what counts most — a unique user experience and application-specific functionality. That brings us to the first step in making an app.

Define your appMost unsuccessful apps fail for any of four reasons:

1. the app was a solution in search of a problem (i.e., no real need existed) 2. the implementation was poor 3. the app tried to do too much; or 4. the Apple App Store rejected the app (either because the implementation was poor or it violated Apple’s content policies)

Keeping the app as simple as possible is the best way to avoid these pitfalls. Most successful apps (indeed, most successful consumer tech products) are based on what is called an MVP, or minimum viable product. It’s the product with the smallest feature set that can deliver the core function without any distracting “bells and whistles.” You know you have an MVP if the product would no longer function if you removed any single feature.

But what should that core feature be? One of the best examples of an MVP is Mail. Version 1 (on the Mac) offered a clear, limited and intuitive feature set whose usefulness was immediately obvious to anyone. Today’s iPhone version integrates seamlessly with your phone, contacts and calendaring. It auto-matically corrects spelling as you type, lets you email photos directly from your photos app, and does much more. But all that came later and was built on top of a basic core function. And that’s how your first app should be built. The key is to come up with something with a clear value that changes people’s lives.

So, in drawing up your MVP feature list, ask yourself what features are key to the experience. Some basic market research is probably in order, starting with a visit to the App Store to see what already exists (possibly to be improved upon and/or to compete with you). Likely

must-have core capabilities include:

• Performance (e.g., fast screen refresh)• Offline capability (i.e., ability to work when not connected to the Internet)• Location awareness (e.g., the data/experience will change with the user’s location)• Cloud syncing (e.g., users see the same data on multiple devices)• Push notifications (i.e., sending updated information to devices as soon as it is available)

When you have a handle on what your app does, the next step is to design it. Designing your app involves making choices of how infor-mation and controls are presented to the user as well as how to implement app logic, and figuring out what data lives locally and what belongs in the Cloud.

Design your appUser experience decisions determine the app’s look and feel. They answer questions such as: What does the app look like? What screens does it have? In the software development world, onscreen objects like buttons, sliders, and fill-in boxes are called widgets. So you need to decide which types of widgets will reside on which screens. And what actions will occur as a result of the user interacting with those widgets?

Keep in mind that users will expect to interact differently with a mobile device than they do with a PC because the screens on mobile devices are much smaller. They’ll expect to use their fingers instead of a mouse or a track pad. Ideally, your app can even be used with one hand holding the device while using just a thumb for scrolling andworking the app’s other controls— the Path app is a good example, and increasingly, so is Facebook.

Your app’s features will inform its architecture, which is how you’ll divide the code and data into functional parts. If your app requires interacting with other app users or networked services, you’ll need to figure out what piece of the logic lives in the app code and what comes from the backend. For example, your app might integrate with a restau-rant recommendation engine, share user location, or pull real-time traffic data. This is done using APIs provided by various service providers — but you don’t have to wire up your app to a network to get started. You can develop a prototype using predefined representative (or “dummy”) data. It’s easier to fine-tune the front end if you don’t have to simultaneously modify your backend too. Once you get the app’s look-and-feel right, then make those backend connections.

Once you’ve got the overall concept for your app, the next step is to express that design in terms of the iOS app architecture. That archi-tecture is the model for what parts an iOS app can contain and how those parts fit together. It’s a well thought-out approach for translat-ing a product concept into actual code you can deploy on a device.

WHY iOS?Besides the features and design of your first app, there’s one more decision you need to make before you start actual development. That’s whether to deploy on Apple’s iOS platform or on Google’s Android platform. (Some of this is also covered in our ebook, How to Make an App: Android Edition.) Reasons to develop for iOS include:

Customers more willing to pay. Perhaps it’s because of Android’s open source heritage, but whatever the reason, Android apps gener-ate less than 10% of the total dollars spent on mobile apps, despite having 75% of the smartphone market itself — and despite the fact that the average selling price of an app in the Google Play is $3.79 versus Apple App Store’s $2.01. In other words, Apple users are much more willing to spend money on apps.

The Apple Ecosystem. Some developers and users prefer Apple’s closed and more tightly controlled environment. Apple’s ecosystem, consisting of Xcode, iCloud, iTunes, the App Store, the iPad, the iPhone, Mac computers, etc., offers a very holistic user experience with the ability to share data seamlessly across devices plus the

assurance of having applications pre-approved for quality and content prior to going on sale.

Xcode. Apple’s all-in-one IDE offers state-of-the-art offers features like a graphical interface builder and a syntax-aware and compiler-aware source editor.

The Apple Experience. From the fit and finish of its hardware to the customer service in its retail stores, to the way its hardware and software work flawlessly together, Apple has created the premium brand in consumer electronics. iOS developers share the benefits — so when someone downloads your iOS app, they already expect it’s a great product. And that it will also work flawlessly on their device.

Tablets. iOS has a clear advantage over Android in terms of tablet market adoption. Using Xcode, it’s also much easier to migrate an app from a phone to a tablet and vice versa than it is when develop-ing for Android.

Why Not iOS?Although iOS offers many compelling advantages as a platform for your mobile app, it also comes with some disadvantages. Here are three:

Closed Platform. iOS apps only run on Apple products so you can’t take advantage of features (like NFC) available only on non-iOS devices or market growth of non-iOS devices.

Market Growth. Today, iOS represents less than 15% of the total smartphone market, Although the total market (“the whole pie”) is still increasing at a fast rate, Android market growth outpaces iOS growth.

Approvals. The App Store’s app approval process is notoriously more time consuming than Google Play’s process.

The iOS app architectureAs noted earlier, a key reason why there are so many apps for iOS is because developing highly functional, polished apps for the platform is relatively easy. That’s mainly because of: 1) the design of the development tools, and 2) the key architectural features most iOS apps have in common. So let’s start with some concepts since it helps to know what goes into an app before trying to create one. We’ll begin with:

• Design patterns• Frameworks• Delegation• Storyboard• Windows• Outlets• Supporting files• Products

Design patterns. iOS apps implement what is known as a Mod-el-View-Controller (MVC) pattern. A pattern is a common way to structure code that solves a particular design problem. The MVC pattern separates application code in a way that allows you to easily change one part of an app without having to change other parts. An MVC pattern consists of three components:

• The Model is the logic that acts on the data, such as to store or retrieve data from a database, compute the distance between two cities on a map, etc. An example of a model is the Kinvey backend that stores your data in the Cloud as a service.

• The View provides the interface to the user; it displays the data and widgets (e.g., buttons and text fields) that allow the user to interact with the data. An iPhone app may have more than one view, as in the Contacts app, which displays a list view of all contacts or alternatively a view of each individual contact.

• The Controller is between the model and the view — i.e., it responds to user requests (made in a view) and retrieves results

(produced in a model). This is where developers spend most of their time — constructing the View Controller — by defining and attaching actions (or behaviors) to onscreen widgets. When the user taps a button, for example, it is the View Controller that determines what action will occur, such as retrieve stored data from your Kinvey-based data store. The link between a view object (like a button) to a controller action is called a connection.

Frameworks. You don’t actually have to write most of an app’s logic. It already exists as frameworks. A framework is a collection of classes that implements some function — such as connecting to the Internet, drawing a button, etc. Rather than write the code from scratch, you just use the frameworks supplied by iOS. Some frameworks are automatically present when you start a new project while others may need to be added (done via a drop down menu in Xcode’s Project Editor).

Delegation. Say, you want to customize the behavior of a framework’s object. You can’t actually modify the code of the framework class itself (prohibited since other apps may also use the framework). But what you can do is provide app-specific behavior in an application delegate object. If a delegate implements a method, it will be called by the delegating class to modify its behavior. In the Kinvey sample app (one of two examples we will be describing below), the AppDele-gate.h and AppDelegate.m — the header and implementation files for the UIApplicationDelegate, respectively — contain the code that authenticates an app to the Kinvey backend service.

Storyboards and XIBs. The MainStoryboard.storyboard file (or a .xib file, if you did not click on the “Use Storyboard” option when starting your project) contains the view information needed to implement the overall flow and display of your application and the user interface elements.

Windows. Each view (e.g., the contact list and individual contact details in the Contacts app) exists within a window. The window represents the entire device screen and is where all your views are presented.

Outlets. A variable by which a view object can be referenced in a controller. (For example, if you place a text field to capture a user's name, you might create an outlet called UITextField* nameField.)

Supporting files. These are files that provide resources (like PNG images and other static data) that your app needs as well as files that configure how the app will run. Other examples:

.pch files — precompiled headers used for the code files in your project.

.plist files — property lists that are small amounts of persistent data (like your app’s default user settings) consisting primarily of strings and numbers that you want your app to be able to access, modify if needed, and write back into the property list.

main.m file — your app’s main function. This is needed to launch the app, but you will not need to modify this file.

InfoPlist.strings file — used for localization.

Products. This is the file for your app (i.e., YourProduct.app) that is built when you click Xcode’s “run” button.

“Making an iOS app” involves working with these features in the typical, straightforward workflow:

• Storyboard your views by dragging and configuring graphicalobjects on a template

• Adding behaviors to the various widgets• Writing the classes as to define those behaviors (including

delegates)• Adding needed support files• Building and running the app• Iterating until you are satisfied with your app

This is all done within Xcode.

What’s Xcode?You can start developing functional, good-looking apps almost from the moment you download Xcode, Apple’s integrated development environment (IDE) for making iOS and Macintosh apps. Among other features, Xcode includes a source code editor, graphical user inter-face (GUI) editor (sometimes called Interface Builder), source code repository manager, compiler, and much more. iOS applications are typically developed by manipulating views graphically and by typing Objective-C code for the models and controllers.

To get Xcode, simply go to the App Store and download the applica-tion (it’s free). To do this, click on the App Store icon in your Mac’s dock, or visit https://itunes.apple.com/us/genre/ios/id36?mt=8

The app store will download and install Xcode in your Application folder. From Applications, double-click the Xcode icon to launch Xcode and you’ll see its splash screen (Figure 1). From there you can click on “Create a new Xcode project” to take you to a menu of several templates on which to base your application. Selecting a template opens an Xcode workspace pre-populated with frameworks and other files Xcode thinks you will need using that template.

Although you can develop, build and simulate your app on your computer in Xcode, you can’t run your app on a target device (even your own iPhone) until you become a registered iOS developer and join the iOS Developer Program. To do that, go to develop-er.app.com/ and navigate to the iOS Dev Center. While there, you will also find documentation, sample code and other useful resources such as information on how to submit your app to the iOS App Store.

Everything you do in Xcode is done in a window, called a workspace (Figure 2), consisting of multiple work areas, some of which are also divided into panes. All the files needed to build your app belong to a project, and the Navigator area (far left) lists all your projects (there can be several in a workspace) and all files for each project. Clicking on a file in the Navigator area shows its contents in the Editor area and invokes the appropriate editor. Clicking on a .h or .m file, for example, shows the file’s source code and invokes the Source editor, so you can edit the code. Clicking on .storyboard or .xib (sometimes called a “nib”) file shows the app’s storyboard and invokes the Inter-face Builder, so you can design a view using the Builder’s drag and drop features.

An especially handy feature is that the Editor area can have both a right and a left pane — with each pane aware of your edits in the other. So, for example, you can simultaneously edit an object’s .h

header file in the left pane and its corresponding .m in the right pane. Or you might click on a button object (displayed graphically) in the left pane and edit its method’s source code in the right pane. To toggle between a single pane (the “Standard Editor”) and double pane view (the “Assistant Editor”), use the Editor selector button on the right of the toolbar. You can option+command+click a symbol in the editor to open the definition in the opposite editor pane.

You can also resize the entire Editor area simply by dragging its borders. For even more editing space, you can also remove the Debug area or both the Debug and Utility areas using the View Selector button on the far right of the toolbar.

As its name suggests, the Debug area shows information, like variable state and console logs, helpful in debugging code.

The Utility area has two panes: the Inspector and Quick Help pane (top) and the Library pane (bottom). Although there are five inspectors — File, Help, Identity, Attributes, Size and Connec-tions — only the inspectors that are currently relevant appear in the Inspec-tor list at the top of the pane. (To see the name of an inspector, move the cursor over its icon in the Inspector selector bar.)

You will use inspectors to add and modify object attributes for views in the Interface Builder. For example, if you click on a UILabel in the Editor area of a storyboard, you can use the Attributes inspector to change the label’s color and use the Size inspector to change the label’s size.

The Help inspector shows help information about a selected class. Use the Identity inspector to view and manage an object’s metadata such as its class, runtime attributes, label and so forth. Use the

Connections inspector to view the outlets and actions of an interface object, to make new connections and to delete existing connections.

The Library pane has libraries of resources (like file templates, code snippets, interface objects and media files) that are prebuilt and ready to insert into your project. Use the Library selector to select which of these libraries (e.g., code snippets or interface objects) you wish to insert. To insert one, drag it directly into your storyboard while using the Interface Builder editor.

These are basics you need to know to get started using Xcode to build your first app. But to really understand how it’s done, it helps to walk through an actual app or two. Let’s start with a simple “Hello World” app that does not employ a backend connection, and then look at a somewhat more functional app that does.

“Hello World!” sample appThis app displays a button (“Press Me”) and a label (“Label”) so that when the user presses the button the text of the label changes to “Hello World!” as in Figure 3:

To get started, launch Xcode and select “Create a New Xcode Project.” From the iOS Application templates, select “Single View Application” and click “Next.” Fill in your product’s name and a company identifier, typically “com.yourCompanyName.” Deselect “Use Storyboards” and leave “Use Automatic Reference Counting” selected. Then click “Next” and select a destination for your projects files.

fig. 4 Create a view with a label and a button

Follow these steps to make your app:

1. Select your project’s ViewController.xib file in the Navigator(Figure 4), to open the Interface Builder editor.

2. Drag a “Round Rect Button” from the Objects library (lowerright) onto the view in the Editor area; select the button’s textand type “Press Me.”

3. Drag a Label from the objects library onto the view, as well.4. Select and drag the Label sizing handles, centering the object

and making it wide enough to hold the “Hello World!” text; then,

5. With the “Hello World!” label still selected, click on centeralignment in the Attributes inspector.

6. Open the Assistant Editor (Figure 5), exposing the source codeheader file (ViewController.h) of the view controller you justbuilt graphically.

7. Select the button and control-drag from the button to justbelow the ViewController definition in the Assistant panel. Inthe form that opens, select “Action” for the connection type,type in a name (“showText”) and click “Connect.” This creates aninterface builder (IB) action as highlighted in Figure 6.

8. Next step is to create an outlet for the label. To do this, selectthe label object and control-drag from the label to just belowthe IB action you just created. Select “Outlet” as the connectiontype and enter a name “label” and click “Connect.” This createsan interface builder (IB) outlet as shown in Figure 7.

9. Finally, it’s time to add some logic to the view controller so itknows what to do when the button is pressed. To do this, select “ViewController.m” in the project navigator to show the code editor. Find the button’s IBAction you just created (near the bottom), place your cursor between the { } brackets and hit the return key a few times to create some extra space. Then in that space type the method for how you want the label you speci-fied to respond: _label.text=”Hello World!”; as highlighted in Figure 8.

Congratulations! Your app is done. To build and run your new app in the simulator, click the Xcode Run button in the left corner of the toolbar. When you click the button, the text will update.

Sample app with a backend This second app (named “Kinvey Test Drive”) lets the user type text on an iPhone and save the text to a backend service, like Kinvey. It also lets the user load text on the iPhone from their Kinvey backend. Reading about this app will help you learn:

• How to set up Kinvey’s library in an iOS project• Additional Interface Builder techniques you can use to story-board an application• How to add view controller logic to interact with the backend service, allowing you to save and retrieve data

We will first present the app as a running application and then take it apart so you can see how it was made. To make the app yourself, you can review the various sections below and replicate the steps in your copy of Xcode.

First, to see the app in action, you should download the app and run it on your system. To do that, sign up for Kinvey, then navigate to “Dev Center”, “Samples,” find the “Test Drive” app, and click on its icon. (If you can’t find it right away, make sure you select iOS as your platform on the right side of the menu bar.) Click the download button to download the app’s project files to your computer. Then launch Xcode — just double click on the .xcodeproj file in the project folder.

But before you can run the app, you need to set up the app’s Kinvey backend.

Set Up Kinvey as a Backend Data StoreTest Drive’s project files include all the code the sample app needs in order to talk to Kinvey. However, that would not be the case if you were to build an app from scratch — so you would have to go through an initial Kinvey setup procedure. This involves downloading the Kinvey library files from the downloads section of devcenter.kin-vey.com and dragging them to the Navigator’s Frameworks folder in Xcode. You also need to tell Xcode to link your project with additional iOS frameworks. To find these frameworks, click on the Project folder

at the very top of the Navigator pane — which displays the Project editor — and then select the “Build Settings” tab. For detailed instruc-tions, complete the “Getting Started” page under “Guides” on the Kinvey website. But again, you can skip this setup procedure for now in order to run the downloaded Kinvey Test Drive app.

But you must still do this step: To run any app that uses Kinvey (including Test Drive) you need to do the “Create an App” step on the Kinvey website. Click on “My Apps” in the Kinvey menu bar and then click on “Add an App,” which will open an “Add” page. Type in a name for your app and click on the Apple logo and then click “Create.” The page that opens shows your App’s credentials. Copy and paste the App Key and App Secret into the AppDelegate.m file of the download-ed Test Drive project:

You are now ready to run the app — click on the Xcode run button and wait for the simulator to open and the app to appear (Figure 9).

Clicking the “+” toolbar button opens an alert (Figure 10) with an empty field into which the user can type some text (e.g., “some new data”). Clicking “save” uploads the data to Kinvey and displays text on the screen (a table view) and also displays an alert that the save worked (Figure 11).

To test the load function, enter some data (e.g., “some data to load”) in the “name” field of the Kinvey collection. To see the load, the swipe down on the table on the phone until the refresh spinner starts, and then the new data will appear in the table (Figure 12).

Figure 13 shows the Kinvey collection after the save that Figure 10 depicts on the iPhone. Figure 14 shows the Kinvey collection after the user adds a new row to the testObjects collection using the web browser. Note that every time a save is done on the iPhone, Kinvey automatically adds a new row (displayed on a collection refresh). To add a new row manually in the browser, click “+ row,” and type some descriptive text in the “name” column. That data will now load on the iPhone when the user pulls down on the table.

Storyboard the Test Drive AppMost of the Test Drive user interface objects visible in the simulation are available in Xcode’s Object Library and can therefore be added to the view graphically. The UI objects consist of a:

• Table view• Toolbar• Tool Bar Button item – flexible space• Tool Bar Button item – Add• Table view cell• Label – Title• Refresh Control

To create this app yourself, you would follow these steps:

• Launch Xcode and select the “Single View Application” template• Select the “Use Storyboard” option• Replace the default UIviewcontroller object with a UITableView-Controller • Drag and drop the other objects, in the order listed, onto the UIviewcontroller

Also note:

• The Flexible Space Bar Button item fills up the space on the toolbar so the add button is at the right. This is a standard pattern in table-based iPhone apps.• The add button shows the system “+” sign. That is done by dragging a bar button item onto the toolbar, clicking on the Identifier drop down menu in the Attributes inspector; and then selecting the “Add” option.

As with the “Hello World!” app, once your app’s view is complete (Figure 15), you would still have to create the various methods and connections that bring them to life. This is done using the Source editor while working with the ViewController.m file.

Add View Controller LogicSince the app performs two basic operations (save data to Kinvey and load data from Kinvey) these two methods must be added to the ViewController header file. That’s done with a control-drag from the “+” bar button over to just under the “@ interface ViewController” line in ViewController.h. (Open the Assistant editor to see both the storyboard and the file source.)

During the drag, the popup appears, asking for the name and type of connection. Enter “action” for the connection type and “add” for the name. Then repeat the drag, this time from the refresh control and using “add” for the name (Figure 16).

Note: to follow this discussion it will help to have the referenced files open in your Xcode Source editor.

In ViewController.m, you will see the implementation code associated with each of the two Interface Builder methods, whose names Xcode added automatically to the .m file:

- (IBAction)add:(id)sender- (IBAction)load:(id)sender

You will also see a third section of code not associated with these methods, which starts with the line: “#pragma mark - Table View Stuff.” These methods support the table view and are part of UITableViewD-elegate and UITableViewDataSource. They handle controlling the

display of the table, and respond to user gestures. For example, swiping a table cell will show the delete button because tableView:-canEditRowAtIndexPath: returns YES and tableView:editingStyleForRowA-tIndexPath: returns UITableViewCellEditingStyleDelete. If you tap the delete button, the delegate method tableView:commitEditingStyle:for-RowAtIndexPath: is called. The code of this method deletes the data for the row and removes it from Kinvey’s data store. When the backend delete is completed, the app displays an alert describing the success or failure.

The way that all three sections (and all Kinvey-enabled apps) move data in and out of a Kinvey collection is by getting a reference to the app’s backend collection (named “testObjects”), which is filled with instances (each named “TestObject”) of the data the app wants to move. That’s why you’ll find the following code repeated three times in Test Drive’s View Controller (once for the add, once for the load, and once for the delete):

To support these statements it is required to have a data object class (TestObject). To see how these files are written in the sample project, click on TestObject.h file and TestObject.m in the Navigator pane. If you were to supply these files in your own app, you would click File > New File, and specify Objective-C class, which would be a subclass of NSObject. Then you would type in the code, with a property for each column in the Kinvey backend collection (including one for the object’s id).

As mentioned earlier, your app also needs to authenticate itself to Kinvey, which is handled by AppDelegate.h and AppDelgate.m. These files are created by Xcode when you create a new project, and start out with just a stub implementation. Look in the sample app source

files for code to copy and paste.

For both the save and load operations, however, moving the data in and out of a backend collection is only part of the work. Table 1 lists all the functions that implements the save and load in the ViewCon-troller.m file, along with pointers to its corresponding block of imple-mentation source code. (For each function, its corresponding code begins with the “Starts at” line and ends with the “Ends at” line.) Refer to Appendix 1 to find the actual source code.

Say Hello To Our WorldThe key takeaway from all this is that “making an app” is a worthwhile thing to do for anyone with a clever idea and a working knowledge of Objective-C. The proof is in the hundreds of apps succeeding in the market every day, many written by people working on their own and who never wrote an app before in their lives. As with anything else, practice does make perfect. But hopefully with all the resources available, and the knowledge gained from this ebook, you have already started down the path toward joining the growing legions of iOS app developers. If so, we welcome you!

Appendix 1 — Test Drive Sample App ViewController.m Source Code

fig. 3 Clicking on the “Press Me” button displays “Hello World!”

124

The iOS revolutionIt’s a story that never gets old. The weekend that iPad Minis and the fourth generation iPads went on sale (November 2-5, 2012) Apple sold over 3 million of the devices — a record for first-weekend iPad sales. Two months earlier the company had set another record: first weekend sales of over 5 million for the iPhone 5. Since the introduc-tion of the first iPhone back in 2007,

iOS-based devices (iPhone, iPad, iPad Mini and iPod Touch) continue to rewrite the definition of what constitutes a successful product. By the end of 2012, over 400 million iOS devices had been sold.

What makes iOS devices so successful? Innovation and product features are clearly a big part. Before the iPhone most people had not interacted with a multi-touch interface. They had never zoomed with a pinch or switched between portrait and landscape by merely rotating a device in their hand. Carrying a phone that knew where they were, could suggest places to eat, and could offer directions on how to get there was also a novel experience.

But features like multi-touch, accelerometers and GPS are only part of the appeal. Even with all its innovations, iOS still might not have taken off the way it has if the only people figuring out ways to use those innovations worked at Apple. Most of the capabilities available in an iPhone or iPad in fact don’t come from Apple at all. They come from legions of third-party developers who work in a vast ecosystem that is also an Apple innovation. That ecosystem includes the iPhone, iPad, iPad Mini, iPods, App Store, iTunes, ad networks — and that’s just on the consumer side. On the developer side, you have Xcode, App Loader, testing tools, iTunes Connect — the list goes on.

As of September 2012, the App Store hosted over 700,000 apps that have collectively been downloaded over 30 billion times. Apple reported for October 2012 that App Store monthly revenues were

running at $333 million — a rate of about $4 billion per year — remarkable for a store that only opened in July 2008.

Another innovation that has spurred iOS app development is “The Cloud.” Cloud services make it easier for independent developers to create, support and make money from their apps. The Cloud solves data storage and cross-device and user-to-user sharing problems. If an app stores data in the Cloud, that part of the application is called the “backend,” while the part of the app that runs on the phone and interacts with the user is called the “front end.”

A cloud may be “private” — i.e., the services belong to an organization for the benefit of its employees and business partners. Or a cloud may be “public” — i.e., a company (such as Amazon or Kinvey) owns the services, which developers can then integrate into their own apps. If you are a developer and want to build your own backend, you certainly can do that. Whether you want to or not depends on whether your backend provides functionality common to many different apps. If it does (as in a shopping cart or user authenti-cation) then perhaps that time and money would be better spent on features that offer unique value to your customer. You may be better off hooking into a commercial backend provider via an API. Then you can focus on what counts most — a unique user experience and application-specific functionality. That brings us to the first step in making an app.

Define your appMost unsuccessful apps fail for any of four reasons:

1. the app was a solution in search of a problem (i.e., no real need existed) 2. the implementation was poor 3. the app tried to do too much; or 4. the Apple App Store rejected the app (either because the implementation was poor or it violated Apple’s content policies)

Keeping the app as simple as possible is the best way to avoid these pitfalls. Most successful apps (indeed, most successful consumer tech products) are based on what is called an MVP, or minimum viable product. It’s the product with the smallest feature set that can deliver the core function without any distracting “bells and whistles.” You know you have an MVP if the product would no longer function if you removed any single feature.

But what should that core feature be? One of the best examples of an MVP is Mail. Version 1 (on the Mac) offered a clear, limited and intuitive feature set whose usefulness was immediately obvious to anyone. Today’s iPhone version integrates seamlessly with your phone, contacts and calendaring. It auto-matically corrects spelling as you type, lets you email photos directly from your photos app, and does much more. But all that came later and was built on top of a basic core function. And that’s how your first app should be built. The key is to come up with something with a clear value that changes people’s lives.

So, in drawing up your MVP feature list, ask yourself what features are key to the experience. Some basic market research is probably in order, starting with a visit to the App Store to see what already exists (possibly to be improved upon and/or to compete with you). Likely

must-have core capabilities include:

• Performance (e.g., fast screen refresh)• Offline capability (i.e., ability to work when not connected to the Internet)• Location awareness (e.g., the data/experience will change with the user’s location)• Cloud syncing (e.g., users see the same data on multiple devices)• Push notifications (i.e., sending updated information to devices as soon as it is available)

When you have a handle on what your app does, the next step is to design it. Designing your app involves making choices of how infor-mation and controls are presented to the user as well as how to implement app logic, and figuring out what data lives locally and what belongs in the Cloud.

Design your appUser experience decisions determine the app’s look and feel. They answer questions such as: What does the app look like? What screens does it have? In the software development world, onscreen objects like buttons, sliders, and fill-in boxes are called widgets. So you need to decide which types of widgets will reside on which screens. And what actions will occur as a result of the user interacting with those widgets?

Keep in mind that users will expect to interact differently with a mobile device than they do with a PC because the screens on mobile devices are much smaller. They’ll expect to use their fingers instead of a mouse or a track pad. Ideally, your app can even be used with one hand holding the device while using just a thumb for scrolling andworking the app’s other controls— the Path app is a good example, and increasingly, so is Facebook.

Your app’s features will inform its architecture, which is how you’ll divide the code and data into functional parts. If your app requires interacting with other app users or networked services, you’ll need to figure out what piece of the logic lives in the app code and what comes from the backend. For example, your app might integrate with a restau-rant recommendation engine, share user location, or pull real-time traffic data. This is done using APIs provided by various service providers — but you don’t have to wire up your app to a network to get started. You can develop a prototype using predefined representative (or “dummy”) data. It’s easier to fine-tune the front end if you don’t have to simultaneously modify your backend too. Once you get the app’s look-and-feel right, then make those backend connections.

Once you’ve got the overall concept for your app, the next step is to express that design in terms of the iOS app architecture. That archi-tecture is the model for what parts an iOS app can contain and how those parts fit together. It’s a well thought-out approach for translat-ing a product concept into actual code you can deploy on a device.

WHY iOS?Besides the features and design of your first app, there’s one more decision you need to make before you start actual development. That’s whether to deploy on Apple’s iOS platform or on Google’s Android platform. (Some of this is also covered in our ebook, How to Make an App: Android Edition.) Reasons to develop for iOS include:

Customers more willing to pay. Perhaps it’s because of Android’s open source heritage, but whatever the reason, Android apps gener-ate less than 10% of the total dollars spent on mobile apps, despite having 75% of the smartphone market itself — and despite the fact that the average selling price of an app in the Google Play is $3.79 versus Apple App Store’s $2.01. In other words, Apple users are much more willing to spend money on apps.

The Apple Ecosystem. Some developers and users prefer Apple’s closed and more tightly controlled environment. Apple’s ecosystem, consisting of Xcode, iCloud, iTunes, the App Store, the iPad, the iPhone, Mac computers, etc., offers a very holistic user experience with the ability to share data seamlessly across devices plus the

assurance of having applications pre-approved for quality and content prior to going on sale.

Xcode. Apple’s all-in-one IDE offers state-of-the-art offers features like a graphical interface builder and a syntax-aware and compiler-aware source editor.

The Apple Experience. From the fit and finish of its hardware to the customer service in its retail stores, to the way its hardware and software work flawlessly together, Apple has created the premium brand in consumer electronics. iOS developers share the benefits — so when someone downloads your iOS app, they already expect it’s a great product. And that it will also work flawlessly on their device.

Tablets. iOS has a clear advantage over Android in terms of tablet market adoption. Using Xcode, it’s also much easier to migrate an app from a phone to a tablet and vice versa than it is when develop-ing for Android.

Why Not iOS?Although iOS offers many compelling advantages as a platform for your mobile app, it also comes with some disadvantages. Here are three:

Closed Platform. iOS apps only run on Apple products so you can’t take advantage of features (like NFC) available only on non-iOS devices or market growth of non-iOS devices.

Market Growth. Today, iOS represents less than 15% of the total smartphone market, Although the total market (“the whole pie”) is still increasing at a fast rate, Android market growth outpaces iOS growth.

Approvals. The App Store’s app approval process is notoriously more time consuming than Google Play’s process.

The iOS app architectureAs noted earlier, a key reason why there are so many apps for iOS is because developing highly functional, polished apps for the platform is relatively easy. That’s mainly because of: 1) the design of the development tools, and 2) the key architectural features most iOS apps have in common. So let’s start with some concepts since it helps to know what goes into an app before trying to create one. We’ll begin with:

• Design patterns• Frameworks• Delegation• Storyboard• Windows• Outlets• Supporting files• Products

Design patterns. iOS apps implement what is known as a Mod-el-View-Controller (MVC) pattern. A pattern is a common way to structure code that solves a particular design problem. The MVC pattern separates application code in a way that allows you to easily change one part of an app without having to change other parts. An MVC pattern consists of three components:

• The Model is the logic that acts on the data, such as to store or retrieve data from a database, compute the distance between two cities on a map, etc. An example of a model is the Kinvey backend that stores your data in the Cloud as a service.

• The View provides the interface to the user; it displays the data and widgets (e.g., buttons and text fields) that allow the user to interact with the data. An iPhone app may have more than one view, as in the Contacts app, which displays a list view of all contacts or alternatively a view of each individual contact.

• The Controller is between the model and the view — i.e., it responds to user requests (made in a view) and retrieves results

(produced in a model). This is where developers spend most of their time — constructing the View Controller — by defining and attaching actions (or behaviors) to onscreen widgets. When the user taps a button, for example, it is the View Controller that determines what action will occur, such as retrieve stored data from your Kinvey-based data store. The link between a view object (like a button) to a controller action is called a connection.

Frameworks. You don’t actually have to write most of an app’s logic. It already exists as frameworks. A framework is a collection of classes that implements some function — such as connecting to the Internet, drawing a button, etc. Rather than write the code from scratch, you just use the frameworks supplied by iOS. Some frameworks are automatically present when you start a new project while others may need to be added (done via a drop down menu in Xcode’s Project Editor).

Delegation. Say, you want to customize the behavior of a framework’s object. You can’t actually modify the code of the framework class itself (prohibited since other apps may also use the framework). But what you can do is provide app-specific behavior in an application delegate object. If a delegate implements a method, it will be called by the delegating class to modify its behavior. In the Kinvey sample app (one of two examples we will be describing below), the AppDele-gate.h and AppDelegate.m — the header and implementation files for the UIApplicationDelegate, respectively — contain the code that authenticates an app to the Kinvey backend service.

Storyboards and XIBs. The MainStoryboard.storyboard file (or a .xib file, if you did not click on the “Use Storyboard” option when starting your project) contains the view information needed to implement the overall flow and display of your application and the user interface elements.

Windows. Each view (e.g., the contact list and individual contact details in the Contacts app) exists within a window. The window represents the entire device screen and is where all your views are presented.

Outlets. A variable by which a view object can be referenced in a controller. (For example, if you place a text field to capture a user's name, you might create an outlet called UITextField* nameField.)

Supporting files. These are files that provide resources (like PNG images and other static data) that your app needs as well as files that configure how the app will run. Other examples:

.pch files — precompiled headers used for the code files in your project.

.plist files — property lists that are small amounts of persistent data (like your app’s default user settings) consisting primarily of strings and numbers that you want your app to be able to access, modify if needed, and write back into the property list.

main.m file — your app’s main function. This is needed to launch the app, but you will not need to modify this file.

InfoPlist.strings file — used for localization.

Products. This is the file for your app (i.e., YourProduct.app) that is built when you click Xcode’s “run” button.

“Making an iOS app” involves working with these features in the typical, straightforward workflow:

• Storyboard your views by dragging and configuring graphicalobjects on a template

• Adding behaviors to the various widgets• Writing the classes as to define those behaviors (including

delegates)• Adding needed support files• Building and running the app• Iterating until you are satisfied with your app

This is all done within Xcode.

What’s Xcode?You can start developing functional, good-looking apps almost from the moment you download Xcode, Apple’s integrated development environment (IDE) for making iOS and Macintosh apps. Among other features, Xcode includes a source code editor, graphical user inter-face (GUI) editor (sometimes called Interface Builder), source code repository manager, compiler, and much more. iOS applications are typically developed by manipulating views graphically and by typing Objective-C code for the models and controllers.

To get Xcode, simply go to the App Store and download the applica-tion (it’s free). To do this, click on the App Store icon in your Mac’s dock, or visit https://itunes.apple.com/us/genre/ios/id36?mt=8

The app store will download and install Xcode in your Application folder. From Applications, double-click the Xcode icon to launch Xcode and you’ll see its splash screen (Figure 1). From there you can click on “Create a new Xcode project” to take you to a menu of several templates on which to base your application. Selecting a template opens an Xcode workspace pre-populated with frameworks and other files Xcode thinks you will need using that template.

Although you can develop, build and simulate your app on your computer in Xcode, you can’t run your app on a target device (even your own iPhone) until you become a registered iOS developer and join the iOS Developer Program. To do that, go to develop-er.app.com/ and navigate to the iOS Dev Center. While there, you will also find documentation, sample code and other useful resources such as information on how to submit your app to the iOS App Store.

Everything you do in Xcode is done in a window, called a workspace (Figure 2), consisting of multiple work areas, some of which are also divided into panes. All the files needed to build your app belong to a project, and the Navigator area (far left) lists all your projects (there can be several in a workspace) and all files for each project. Clicking on a file in the Navigator area shows its contents in the Editor area and invokes the appropriate editor. Clicking on a .h or .m file, for example, shows the file’s source code and invokes the Source editor, so you can edit the code. Clicking on .storyboard or .xib (sometimes called a “nib”) file shows the app’s storyboard and invokes the Inter-face Builder, so you can design a view using the Builder’s drag and drop features.

An especially handy feature is that the Editor area can have both a right and a left pane — with each pane aware of your edits in the other. So, for example, you can simultaneously edit an object’s .h

header file in the left pane and its corresponding .m in the right pane. Or you might click on a button object (displayed graphically) in the left pane and edit its method’s source code in the right pane. To toggle between a single pane (the “Standard Editor”) and double pane view (the “Assistant Editor”), use the Editor selector button on the right of the toolbar. You can option+command+click a symbol in the editor to open the definition in the opposite editor pane.

You can also resize the entire Editor area simply by dragging its borders. For even more editing space, you can also remove the Debug area or both the Debug and Utility areas using the View Selector button on the far right of the toolbar.

As its name suggests, the Debug area shows information, like variable state and console logs, helpful in debugging code.

The Utility area has two panes: the Inspector and Quick Help pane (top) and the Library pane (bottom). Although there are five inspectors — File, Help, Identity, Attributes, Size and Connec-tions — only the inspectors that are currently relevant appear in the Inspec-tor list at the top of the pane. (To see the name of an inspector, move the cursor over its icon in the Inspector selector bar.)

You will use inspectors to add and modify object attributes for views in the Interface Builder. For example, if you click on a UILabel in the Editor area of a storyboard, you can use the Attributes inspector to change the label’s color and use the Size inspector to change the label’s size.

The Help inspector shows help information about a selected class. Use the Identity inspector to view and manage an object’s metadata such as its class, runtime attributes, label and so forth. Use the

Connections inspector to view the outlets and actions of an interface object, to make new connections and to delete existing connections.

The Library pane has libraries of resources (like file templates, code snippets, interface objects and media files) that are prebuilt and ready to insert into your project. Use the Library selector to select which of these libraries (e.g., code snippets or interface objects) you wish to insert. To insert one, drag it directly into your storyboard while using the Interface Builder editor.

These are basics you need to know to get started using Xcode to build your first app. But to really understand how it’s done, it helps to walk through an actual app or two. Let’s start with a simple “Hello World” app that does not employ a backend connection, and then look at a somewhat more functional app that does.

“Hello World!” sample appThis app displays a button (“Press Me”) and a label (“Label”) so that when the user presses the button the text of the label changes to “Hello World!” as in Figure 3:

To get started, launch Xcode and select “Create a New Xcode Project.” From the iOS Application templates, select “Single View Application” and click “Next.” Fill in your product’s name and a company identifier, typically “com.yourCompanyName.” Deselect “Use Storyboards” and leave “Use Automatic Reference Counting” selected. Then click “Next” and select a destination for your projects files.

Follow these steps to make your app:

1. Select your project’s ViewController.xib file in the Navigator(Figure 4), to open the Interface Builder editor.

2. Drag a “Round Rect Button” from the Objects library (lowerright) onto the view in the Editor area; select the button’s textand type “Press Me.”

3. Drag a Label from the objects library onto the view, as well.4. Select and drag the Label sizing handles, centering the object

and making it wide enough to hold the “Hello World!” text; then,

5. With the “Hello World!” label still selected, click on centeralignment in the Attributes inspector.

6. Open the Assistant Editor (Figure 5), exposing the source codeheader file (ViewController.h) of the view controller you justbuilt graphically.

7. Select the button and control-drag from the button to justbelow the ViewController definition in the Assistant panel. Inthe form that opens, select “Action” for the connection type,type in a name (“showText”) and click “Connect.” This creates aninterface builder (IB) action as highlighted in Figure 6.

8. Next step is to create an outlet for the label. To do this, selectthe label object and control-drag from the label to just belowthe IB action you just created. Select “Outlet” as the connectiontype and enter a name “label” and click “Connect.” This createsan interface builder (IB) outlet as shown in Figure 7.

9. Finally, it’s time to add some logic to the view controller so itknows what to do when the button is pressed. To do this, select “ViewController.m” in the project navigator to show the code editor. Find the button’s IBAction you just created (near the bottom), place your cursor between the { } brackets and hit the return key a few times to create some extra space. Then in that space type the method for how you want the label you speci-fied to respond: _label.text=”Hello World!”; as highlighted in Figure 8.

Congratulations! Your app is done. To build and run your new app in the simulator, click the Xcode Run button in the left corner of the toolbar. When you click the button, the text will update.

Sample app with a backend This second app (named “Kinvey Test Drive”) lets the user type text on an iPhone and save the text to a backend service, like Kinvey. It also lets the user load text on the iPhone from their Kinvey backend. Reading about this app will help you learn:

• How to set up Kinvey’s library in an iOS project• Additional Interface Builder techniques you can use to story-board an application• How to add view controller logic to interact with the backend service, allowing you to save and retrieve data

We will first present the app as a running application and then take it apart so you can see how it was made. To make the app yourself, you can review the various sections below and replicate the steps in your copy of Xcode.

First, to see the app in action, you should download the app and run it on your system. To do that, sign up for Kinvey, then navigate to “Dev Center”, “Samples,” find the “Test Drive” app, and click on its icon. (If you can’t find it right away, make sure you select iOS as your platform on the right side of the menu bar.) Click the download button to download the app’s project files to your computer. Then launch Xcode — just double click on the .xcodeproj file in the project folder.

But before you can run the app, you need to set up the app’s Kinvey backend.

Set Up Kinvey as a Backend Data StoreTest Drive’s project files include all the code the sample app needs in order to talk to Kinvey. However, that would not be the case if you were to build an app from scratch — so you would have to go through an initial Kinvey setup procedure. This involves downloading the Kinvey library files from the downloads section of devcenter.kin-vey.com and dragging them to the Navigator’s Frameworks folder in Xcode. You also need to tell Xcode to link your project with additional iOS frameworks. To find these frameworks, click on the Project folder

at the very top of the Navigator pane — which displays the Project editor — and then select the “Build Settings” tab. For detailed instruc-tions, complete the “Getting Started” page under “Guides” on the Kinvey website. But again, you can skip this setup procedure for now in order to run the downloaded Kinvey Test Drive app.

But you must still do this step: To run any app that uses Kinvey (including Test Drive) you need to do the “Create an App” step on the Kinvey website. Click on “My Apps” in the Kinvey menu bar and then click on “Add an App,” which will open an “Add” page. Type in a name for your app and click on the Apple logo and then click “Create.” The page that opens shows your App’s credentials. Copy and paste the App Key and App Secret into the AppDelegate.m file of the download-ed Test Drive project:

You are now ready to run the app — click on the Xcode run button and wait for the simulator to open and the app to appear (Figure 9).

Clicking the “+” toolbar button opens an alert (Figure 10) with an empty field into which the user can type some text (e.g., “some new data”). Clicking “save” uploads the data to Kinvey and displays text on the screen (a table view) and also displays an alert that the save worked (Figure 11).

To test the load function, enter some data (e.g., “some data to load”) in the “name” field of the Kinvey collection. To see the load, the swipe down on the table on the phone until the refresh spinner starts, and then the new data will appear in the table (Figure 12).

Figure 13 shows the Kinvey collection after the save that Figure 10 depicts on the iPhone. Figure 14 shows the Kinvey collection after the user adds a new row to the testObjects collection using the web browser. Note that every time a save is done on the iPhone, Kinvey automatically adds a new row (displayed on a collection refresh). To add a new row manually in the browser, click “+ row,” and type some descriptive text in the “name” column. That data will now load on the iPhone when the user pulls down on the table.

Storyboard the Test Drive AppMost of the Test Drive user interface objects visible in the simulation are available in Xcode’s Object Library and can therefore be added to the view graphically. The UI objects consist of a:

• Table view• Toolbar• Tool Bar Button item – flexible space• Tool Bar Button item – Add• Table view cell• Label – Title• Refresh Control

To create this app yourself, you would follow these steps:

• Launch Xcode and select the “Single View Application” template• Select the “Use Storyboard” option• Replace the default UIviewcontroller object with a UITableView-Controller • Drag and drop the other objects, in the order listed, onto the UIviewcontroller

Also note:

• The Flexible Space Bar Button item fills up the space on the toolbar so the add button is at the right. This is a standard pattern in table-based iPhone apps.• The add button shows the system “+” sign. That is done by dragging a bar button item onto the toolbar, clicking on the Identifier drop down menu in the Attributes inspector; and then selecting the “Add” option.

As with the “Hello World!” app, once your app’s view is complete (Figure 15), you would still have to create the various methods and connections that bring them to life. This is done using the Source editor while working with the ViewController.m file.

Add View Controller LogicSince the app performs two basic operations (save data to Kinvey and load data from Kinvey) these two methods must be added to the ViewController header file. That’s done with a control-drag from the “+” bar button over to just under the “@ interface ViewController” line in ViewController.h. (Open the Assistant editor to see both the storyboard and the file source.)

During the drag, the popup appears, asking for the name and type of connection. Enter “action” for the connection type and “add” for the name. Then repeat the drag, this time from the refresh control and using “add” for the name (Figure 16).

Note: to follow this discussion it will help to have the referenced files open in your Xcode Source editor.

In ViewController.m, you will see the implementation code associated with each of the two Interface Builder methods, whose names Xcode added automatically to the .m file:

- (IBAction)add:(id)sender- (IBAction)load:(id)sender

You will also see a third section of code not associated with these methods, which starts with the line: “#pragma mark - Table View Stuff.” These methods support the table view and are part of UITableViewD-elegate and UITableViewDataSource. They handle controlling the

display of the table, and respond to user gestures. For example, swiping a table cell will show the delete button because tableView:-canEditRowAtIndexPath: returns YES and tableView:editingStyleForRowA-tIndexPath: returns UITableViewCellEditingStyleDelete. If you tap the delete button, the delegate method tableView:commitEditingStyle:for-RowAtIndexPath: is called. The code of this method deletes the data for the row and removes it from Kinvey’s data store. When the backend delete is completed, the app displays an alert describing the success or failure.

The way that all three sections (and all Kinvey-enabled apps) move data in and out of a Kinvey collection is by getting a reference to the app’s backend collection (named “testObjects”), which is filled with instances (each named “TestObject”) of the data the app wants to move. That’s why you’ll find the following code repeated three times in Test Drive’s View Controller (once for the add, once for the load, and once for the delete):

To support these statements it is required to have a data object class (TestObject). To see how these files are written in the sample project, click on TestObject.h file and TestObject.m in the Navigator pane. If you were to supply these files in your own app, you would click File > New File, and specify Objective-C class, which would be a subclass of NSObject. Then you would type in the code, with a property for each column in the Kinvey backend collection (including one for the object’s id).

As mentioned earlier, your app also needs to authenticate itself to Kinvey, which is handled by AppDelegate.h and AppDelgate.m. These files are created by Xcode when you create a new project, and start out with just a stub implementation. Look in the sample app source

files for code to copy and paste.

For both the save and load operations, however, moving the data in and out of a backend collection is only part of the work. Table 1 lists all the functions that implements the save and load in the ViewCon-troller.m file, along with pointers to its corresponding block of imple-mentation source code. (For each function, its corresponding code begins with the “Starts at” line and ends with the “Ends at” line.) Refer to Appendix 1 to find the actual source code.

Say Hello To Our WorldThe key takeaway from all this is that “making an app” is a worthwhile thing to do for anyone with a clever idea and a working knowledge of Objective-C. The proof is in the hundreds of apps succeeding in the market every day, many written by people working on their own and who never wrote an app before in their lives. As with anything else, practice does make perfect. But hopefully with all the resources available, and the knowledge gained from this ebook, you have already started down the path toward joining the growing legions of iOS app developers. If so, we welcome you!

Appendix 1 — Test Drive Sample App ViewController.m Source Code

fig. 5 Align a label in the attributes inspector

25

The iOS revolutionIt’s a story that never gets old. The weekend that iPad Minis and the fourth generation iPads went on sale (November 2-5, 2012) Apple sold over 3 million of the devices — a record for first-weekend iPad sales. Two months earlier the company had set another record: first weekend sales of over 5 million for the iPhone 5. Since the introduc-tion of the first iPhone back in 2007,

iOS-based devices (iPhone, iPad, iPad Mini and iPod Touch) continue to rewrite the definition of what constitutes a successful product. By the end of 2012, over 400 million iOS devices had been sold.

What makes iOS devices so successful? Innovation and product features are clearly a big part. Before the iPhone most people had not interacted with a multi-touch interface. They had never zoomed with a pinch or switched between portrait and landscape by merely rotating a device in their hand. Carrying a phone that knew where they were, could suggest places to eat, and could offer directions on how to get there was also a novel experience.

But features like multi-touch, accelerometers and GPS are only part of the appeal. Even with all its innovations, iOS still might not have taken off the way it has if the only people figuring out ways to use those innovations worked at Apple. Most of the capabilities available in an iPhone or iPad in fact don’t come from Apple at all. They come from legions of third-party developers who work in a vast ecosystem that is also an Apple innovation. That ecosystem includes the iPhone, iPad, iPad Mini, iPods, App Store, iTunes, ad networks — and that’s just on the consumer side. On the developer side, you have Xcode, App Loader, testing tools, iTunes Connect — the list goes on.

As of September 2012, the App Store hosted over 700,000 apps that have collectively been downloaded over 30 billion times. Apple reported for October 2012 that App Store monthly revenues were

running at $333 million — a rate of about $4 billion per year — remarkable for a store that only opened in July 2008.

Another innovation that has spurred iOS app development is “The Cloud.” Cloud services make it easier for independent developers to create, support and make money from their apps. The Cloud solves data storage and cross-device and user-to-user sharing problems. If an app stores data in the Cloud, that part of the application is called the “backend,” while the part of the app that runs on the phone and interacts with the user is called the “front end.”

A cloud may be “private” — i.e., the services belong to an organization for the benefit of its employees and business partners. Or a cloud may be “public” — i.e., a company (such as Amazon or Kinvey) owns the services, which developers can then integrate into their own apps. If you are a developer and want to build your own backend, you certainly can do that. Whether you want to or not depends on whether your backend provides functionality common to many different apps. If it does (as in a shopping cart or user authenti-cation) then perhaps that time and money would be better spent on features that offer unique value to your customer. You may be better off hooking into a commercial backend provider via an API. Then you can focus on what counts most — a unique user experience and application-specific functionality. That brings us to the first step in making an app.

Define your appMost unsuccessful apps fail for any of four reasons:

1. the app was a solution in search of a problem (i.e., no real need existed) 2. the implementation was poor 3. the app tried to do too much; or 4. the Apple App Store rejected the app (either because the implementation was poor or it violated Apple’s content policies)

Keeping the app as simple as possible is the best way to avoid these pitfalls. Most successful apps (indeed, most successful consumer tech products) are based on what is called an MVP, or minimum viable product. It’s the product with the smallest feature set that can deliver the core function without any distracting “bells and whistles.” You know you have an MVP if the product would no longer function if you removed any single feature.

But what should that core feature be? One of the best examples of an MVP is Mail. Version 1 (on the Mac) offered a clear, limited and intuitive feature set whose usefulness was immediately obvious to anyone. Today’s iPhone version integrates seamlessly with your phone, contacts and calendaring. It auto-matically corrects spelling as you type, lets you email photos directly from your photos app, and does much more. But all that came later and was built on top of a basic core function. And that’s how your first app should be built. The key is to come up with something with a clear value that changes people’s lives.

So, in drawing up your MVP feature list, ask yourself what features are key to the experience. Some basic market research is probably in order, starting with a visit to the App Store to see what already exists (possibly to be improved upon and/or to compete with you). Likely

must-have core capabilities include:

• Performance (e.g., fast screen refresh)• Offline capability (i.e., ability to work when not connected to the Internet)• Location awareness (e.g., the data/experience will change with the user’s location)• Cloud syncing (e.g., users see the same data on multiple devices)• Push notifications (i.e., sending updated information to devices as soon as it is available)

When you have a handle on what your app does, the next step is to design it. Designing your app involves making choices of how infor-mation and controls are presented to the user as well as how to implement app logic, and figuring out what data lives locally and what belongs in the Cloud.

Design your appUser experience decisions determine the app’s look and feel. They answer questions such as: What does the app look like? What screens does it have? In the software development world, onscreen objects like buttons, sliders, and fill-in boxes are called widgets. So you need to decide which types of widgets will reside on which screens. And what actions will occur as a result of the user interacting with those widgets?

Keep in mind that users will expect to interact differently with a mobile device than they do with a PC because the screens on mobile devices are much smaller. They’ll expect to use their fingers instead of a mouse or a track pad. Ideally, your app can even be used with one hand holding the device while using just a thumb for scrolling andworking the app’s other controls— the Path app is a good example, and increasingly, so is Facebook.

Your app’s features will inform its architecture, which is how you’ll divide the code and data into functional parts. If your app requires interacting with other app users or networked services, you’ll need to figure out what piece of the logic lives in the app code and what comes from the backend. For example, your app might integrate with a restau-rant recommendation engine, share user location, or pull real-time traffic data. This is done using APIs provided by various service providers — but you don’t have to wire up your app to a network to get started. You can develop a prototype using predefined representative (or “dummy”) data. It’s easier to fine-tune the front end if you don’t have to simultaneously modify your backend too. Once you get the app’s look-and-feel right, then make those backend connections.

Once you’ve got the overall concept for your app, the next step is to express that design in terms of the iOS app architecture. That archi-tecture is the model for what parts an iOS app can contain and how those parts fit together. It’s a well thought-out approach for translat-ing a product concept into actual code you can deploy on a device.

WHY iOS?Besides the features and design of your first app, there’s one more decision you need to make before you start actual development. That’s whether to deploy on Apple’s iOS platform or on Google’s Android platform. (Some of this is also covered in our ebook, How to Make an App: Android Edition.) Reasons to develop for iOS include:

Customers more willing to pay. Perhaps it’s because of Android’s open source heritage, but whatever the reason, Android apps gener-ate less than 10% of the total dollars spent on mobile apps, despite having 75% of the smartphone market itself — and despite the fact that the average selling price of an app in the Google Play is $3.79 versus Apple App Store’s $2.01. In other words, Apple users are much more willing to spend money on apps.

The Apple Ecosystem. Some developers and users prefer Apple’s closed and more tightly controlled environment. Apple’s ecosystem, consisting of Xcode, iCloud, iTunes, the App Store, the iPad, the iPhone, Mac computers, etc., offers a very holistic user experience with the ability to share data seamlessly across devices plus the

assurance of having applications pre-approved for quality and content prior to going on sale.

Xcode. Apple’s all-in-one IDE offers state-of-the-art offers features like a graphical interface builder and a syntax-aware and compiler-aware source editor.

The Apple Experience. From the fit and finish of its hardware to the customer service in its retail stores, to the way its hardware and software work flawlessly together, Apple has created the premium brand in consumer electronics. iOS developers share the benefits — so when someone downloads your iOS app, they already expect it’s a great product. And that it will also work flawlessly on their device.

Tablets. iOS has a clear advantage over Android in terms of tablet market adoption. Using Xcode, it’s also much easier to migrate an app from a phone to a tablet and vice versa than it is when develop-ing for Android.

Why Not iOS?Although iOS offers many compelling advantages as a platform for your mobile app, it also comes with some disadvantages. Here are three:

Closed Platform. iOS apps only run on Apple products so you can’t take advantage of features (like NFC) available only on non-iOS devices or market growth of non-iOS devices.

Market Growth. Today, iOS represents less than 15% of the total smartphone market, Although the total market (“the whole pie”) is still increasing at a fast rate, Android market growth outpaces iOS growth.

Approvals. The App Store’s app approval process is notoriously more time consuming than Google Play’s process.

The iOS app architectureAs noted earlier, a key reason why there are so many apps for iOS is because developing highly functional, polished apps for the platform is relatively easy. That’s mainly because of: 1) the design of the development tools, and 2) the key architectural features most iOS apps have in common. So let’s start with some concepts since it helps to know what goes into an app before trying to create one. We’ll begin with:

• Design patterns• Frameworks• Delegation• Storyboard• Windows• Outlets• Supporting files• Products

Design patterns. iOS apps implement what is known as a Mod-el-View-Controller (MVC) pattern. A pattern is a common way to structure code that solves a particular design problem. The MVC pattern separates application code in a way that allows you to easily change one part of an app without having to change other parts. An MVC pattern consists of three components:

• The Model is the logic that acts on the data, such as to store or retrieve data from a database, compute the distance between two cities on a map, etc. An example of a model is the Kinvey backend that stores your data in the Cloud as a service.

• The View provides the interface to the user; it displays the data and widgets (e.g., buttons and text fields) that allow the user to interact with the data. An iPhone app may have more than one view, as in the Contacts app, which displays a list view of all contacts or alternatively a view of each individual contact.

• The Controller is between the model and the view — i.e., it responds to user requests (made in a view) and retrieves results

(produced in a model). This is where developers spend most of their time — constructing the View Controller — by defining and attaching actions (or behaviors) to onscreen widgets. When the user taps a button, for example, it is the View Controller that determines what action will occur, such as retrieve stored data from your Kinvey-based data store. The link between a view object (like a button) to a controller action is called a connection.

Frameworks. You don’t actually have to write most of an app’s logic. It already exists as frameworks. A framework is a collection of classes that implements some function — such as connecting to the Internet, drawing a button, etc. Rather than write the code from scratch, you just use the frameworks supplied by iOS. Some frameworks are automatically present when you start a new project while others may need to be added (done via a drop down menu in Xcode’s Project Editor).

Delegation. Say, you want to customize the behavior of a framework’s object. You can’t actually modify the code of the framework class itself (prohibited since other apps may also use the framework). But what you can do is provide app-specific behavior in an application delegate object. If a delegate implements a method, it will be called by the delegating class to modify its behavior. In the Kinvey sample app (one of two examples we will be describing below), the AppDele-gate.h and AppDelegate.m — the header and implementation files for the UIApplicationDelegate, respectively — contain the code that authenticates an app to the Kinvey backend service.

Storyboards and XIBs. The MainStoryboard.storyboard file (or a .xib file, if you did not click on the “Use Storyboard” option when starting your project) contains the view information needed to implement the overall flow and display of your application and the user interface elements.

Windows. Each view (e.g., the contact list and individual contact details in the Contacts app) exists within a window. The window represents the entire device screen and is where all your views are presented.

Outlets. A variable by which a view object can be referenced in a controller. (For example, if you place a text field to capture a user's name, you might create an outlet called UITextField* nameField.)

Supporting files. These are files that provide resources (like PNG images and other static data) that your app needs as well as files that configure how the app will run. Other examples:

.pch files — precompiled headers used for the code files in your project.

.plist files — property lists that are small amounts of persistent data (like your app’s default user settings) consisting primarily of strings and numbers that you want your app to be able to access, modify if needed, and write back into the property list.

main.m file — your app’s main function. This is needed to launch the app, but you will not need to modify this file.

InfoPlist.strings file — used for localization.

Products. This is the file for your app (i.e., YourProduct.app) that is built when you click Xcode’s “run” button.

“Making an iOS app” involves working with these features in the typical, straightforward workflow:

• Storyboard your views by dragging and configuring graphicalobjects on a template

• Adding behaviors to the various widgets• Writing the classes as to define those behaviors (including

delegates)• Adding needed support files• Building and running the app• Iterating until you are satisfied with your app

This is all done within Xcode.

What’s Xcode?You can start developing functional, good-looking apps almost from the moment you download Xcode, Apple’s integrated development environment (IDE) for making iOS and Macintosh apps. Among other features, Xcode includes a source code editor, graphical user inter-face (GUI) editor (sometimes called Interface Builder), source code repository manager, compiler, and much more. iOS applications are typically developed by manipulating views graphically and by typing Objective-C code for the models and controllers.

To get Xcode, simply go to the App Store and download the applica-tion (it’s free). To do this, click on the App Store icon in your Mac’s dock, or visit https://itunes.apple.com/us/genre/ios/id36?mt=8

The app store will download and install Xcode in your Application folder. From Applications, double-click the Xcode icon to launch Xcode and you’ll see its splash screen (Figure 1). From there you can click on “Create a new Xcode project” to take you to a menu of several templates on which to base your application. Selecting a template opens an Xcode workspace pre-populated with frameworks and other files Xcode thinks you will need using that template.

Although you can develop, build and simulate your app on your computer in Xcode, you can’t run your app on a target device (even your own iPhone) until you become a registered iOS developer and join the iOS Developer Program. To do that, go to develop-er.app.com/ and navigate to the iOS Dev Center. While there, you will also find documentation, sample code and other useful resources such as information on how to submit your app to the iOS App Store.

Everything you do in Xcode is done in a window, called a workspace (Figure 2), consisting of multiple work areas, some of which are also divided into panes. All the files needed to build your app belong to a project, and the Navigator area (far left) lists all your projects (there can be several in a workspace) and all files for each project. Clicking on a file in the Navigator area shows its contents in the Editor area and invokes the appropriate editor. Clicking on a .h or .m file, for example, shows the file’s source code and invokes the Source editor, so you can edit the code. Clicking on .storyboard or .xib (sometimes called a “nib”) file shows the app’s storyboard and invokes the Inter-face Builder, so you can design a view using the Builder’s drag and drop features.

An especially handy feature is that the Editor area can have both a right and a left pane — with each pane aware of your edits in the other. So, for example, you can simultaneously edit an object’s .h

header file in the left pane and its corresponding .m in the right pane. Or you might click on a button object (displayed graphically) in the left pane and edit its method’s source code in the right pane. To toggle between a single pane (the “Standard Editor”) and double pane view (the “Assistant Editor”), use the Editor selector button on the right of the toolbar. You can option+command+click a symbol in the editor to open the definition in the opposite editor pane.

You can also resize the entire Editor area simply by dragging its borders. For even more editing space, you can also remove the Debug area or both the Debug and Utility areas using the View Selector button on the far right of the toolbar.

As its name suggests, the Debug area shows information, like variable state and console logs, helpful in debugging code.

The Utility area has two panes: the Inspector and Quick Help pane (top) and the Library pane (bottom). Although there are five inspectors — File, Help, Identity, Attributes, Size and Connec-tions — only the inspectors that are currently relevant appear in the Inspec-tor list at the top of the pane. (To see the name of an inspector, move the cursor over its icon in the Inspector selector bar.)

You will use inspectors to add and modify object attributes for views in the Interface Builder. For example, if you click on a UILabel in the Editor area of a storyboard, you can use the Attributes inspector to change the label’s color and use the Size inspector to change the label’s size.

The Help inspector shows help information about a selected class. Use the Identity inspector to view and manage an object’s metadata such as its class, runtime attributes, label and so forth. Use the

Connections inspector to view the outlets and actions of an interface object, to make new connections and to delete existing connections.

The Library pane has libraries of resources (like file templates, code snippets, interface objects and media files) that are prebuilt and ready to insert into your project. Use the Library selector to select which of these libraries (e.g., code snippets or interface objects) you wish to insert. To insert one, drag it directly into your storyboard while using the Interface Builder editor.

These are basics you need to know to get started using Xcode to build your first app. But to really understand how it’s done, it helps to walk through an actual app or two. Let’s start with a simple “Hello World” app that does not employ a backend connection, and then look at a somewhat more functional app that does.

“Hello World!” sample appThis app displays a button (“Press Me”) and a label (“Label”) so that when the user presses the button the text of the label changes to “Hello World!” as in Figure 3:

To get started, launch Xcode and select “Create a New Xcode Project.” From the iOS Application templates, select “Single View Application” and click “Next.” Fill in your product’s name and a company identifier, typically “com.yourCompanyName.” Deselect “Use Storyboards” and leave “Use Automatic Reference Counting” selected. Then click “Next” and select a destination for your projects files.

Follow these steps to make your app:

1. Select your project’s ViewController.xib file in the Navigator(Figure 4), to open the Interface Builder editor.

2. Drag a “Round Rect Button” from the Objects library (lowerright) onto the view in the Editor area; select the button’s textand type “Press Me.”

3. Drag a Label from the objects library onto the view, as well.4. Select and drag the Label sizing handles, centering the object

and making it wide enough to hold the “Hello World!” text; then,

5. With the “Hello World!” label still selected, click on centeralignment in the Attributes inspector.

6. Open the Assistant Editor (Figure 5), exposing the source codeheader file (ViewController.h) of the view controller you justbuilt graphically.

7. Select the button and control-drag from the button to justbelow the ViewController definition in the Assistant panel. Inthe form that opens, select “Action” for the connection type,type in a name (“showText”) and click “Connect.” This creates aninterface builder (IB) action as highlighted in Figure 6.

8. Next step is to create an outlet for the label. To do this, selectthe label object and control-drag from the label to just belowthe IB action you just created. Select “Outlet” as the connectiontype and enter a name “label” and click “Connect.” This createsan interface builder (IB) outlet as shown in Figure 7.

9. Finally, it’s time to add some logic to the view controller so itknows what to do when the button is pressed. To do this, select “ViewController.m” in the project navigator to show the code editor. Find the button’s IBAction you just created (near the bottom), place your cursor between the { } brackets and hit the return key a few times to create some extra space. Then in that space type the method for how you want the label you speci-fied to respond: _label.text=”Hello World!”; as highlighted in Figure 8.

Congratulations! Your app is done. To build and run your new app in the simulator, click the Xcode Run button in the left corner of the toolbar. When you click the button, the text will update.

Sample app with a backend This second app (named “Kinvey Test Drive”) lets the user type text on an iPhone and save the text to a backend service, like Kinvey. It also lets the user load text on the iPhone from their Kinvey backend. Reading about this app will help you learn:

• How to set up Kinvey’s library in an iOS project• Additional Interface Builder techniques you can use to story-board an application• How to add view controller logic to interact with the backend service, allowing you to save and retrieve data

We will first present the app as a running application and then take it apart so you can see how it was made. To make the app yourself, you can review the various sections below and replicate the steps in your copy of Xcode.

First, to see the app in action, you should download the app and run it on your system. To do that, sign up for Kinvey, then navigate to “Dev Center”, “Samples,” find the “Test Drive” app, and click on its icon. (If you can’t find it right away, make sure you select iOS as your platform on the right side of the menu bar.) Click the download button to download the app’s project files to your computer. Then launch Xcode — just double click on the .xcodeproj file in the project folder.

But before you can run the app, you need to set up the app’s Kinvey backend.

Set Up Kinvey as a Backend Data StoreTest Drive’s project files include all the code the sample app needs in order to talk to Kinvey. However, that would not be the case if you were to build an app from scratch — so you would have to go through an initial Kinvey setup procedure. This involves downloading the Kinvey library files from the downloads section of devcenter.kin-vey.com and dragging them to the Navigator’s Frameworks folder in Xcode. You also need to tell Xcode to link your project with additional iOS frameworks. To find these frameworks, click on the Project folder

at the very top of the Navigator pane — which displays the Project editor — and then select the “Build Settings” tab. For detailed instruc-tions, complete the “Getting Started” page under “Guides” on the Kinvey website. But again, you can skip this setup procedure for now in order to run the downloaded Kinvey Test Drive app.

But you must still do this step: To run any app that uses Kinvey (including Test Drive) you need to do the “Create an App” step on the Kinvey website. Click on “My Apps” in the Kinvey menu bar and then click on “Add an App,” which will open an “Add” page. Type in a name for your app and click on the Apple logo and then click “Create.” The page that opens shows your App’s credentials. Copy and paste the App Key and App Secret into the AppDelegate.m file of the download-ed Test Drive project:

You are now ready to run the app — click on the Xcode run button and wait for the simulator to open and the app to appear (Figure 9).

Clicking the “+” toolbar button opens an alert (Figure 10) with an empty field into which the user can type some text (e.g., “some new data”). Clicking “save” uploads the data to Kinvey and displays text on the screen (a table view) and also displays an alert that the save worked (Figure 11).

To test the load function, enter some data (e.g., “some data to load”) in the “name” field of the Kinvey collection. To see the load, the swipe down on the table on the phone until the refresh spinner starts, and then the new data will appear in the table (Figure 12).

Figure 13 shows the Kinvey collection after the save that Figure 10 depicts on the iPhone. Figure 14 shows the Kinvey collection after the user adds a new row to the testObjects collection using the web browser. Note that every time a save is done on the iPhone, Kinvey automatically adds a new row (displayed on a collection refresh). To add a new row manually in the browser, click “+ row,” and type some descriptive text in the “name” column. That data will now load on the iPhone when the user pulls down on the table.

Storyboard the Test Drive AppMost of the Test Drive user interface objects visible in the simulation are available in Xcode’s Object Library and can therefore be added to the view graphically. The UI objects consist of a:

• Table view• Toolbar• Tool Bar Button item – flexible space• Tool Bar Button item – Add• Table view cell• Label – Title• Refresh Control

To create this app yourself, you would follow these steps:

• Launch Xcode and select the “Single View Application” template• Select the “Use Storyboard” option• Replace the default UIviewcontroller object with a UITableView-Controller • Drag and drop the other objects, in the order listed, onto the UIviewcontroller

Also note:

• The Flexible Space Bar Button item fills up the space on the toolbar so the add button is at the right. This is a standard pattern in table-based iPhone apps.• The add button shows the system “+” sign. That is done by dragging a bar button item onto the toolbar, clicking on the Identifier drop down menu in the Attributes inspector; and then selecting the “Add” option.

As with the “Hello World!” app, once your app’s view is complete (Figure 15), you would still have to create the various methods and connections that bring them to life. This is done using the Source editor while working with the ViewController.m file.

Add View Controller LogicSince the app performs two basic operations (save data to Kinvey and load data from Kinvey) these two methods must be added to the ViewController header file. That’s done with a control-drag from the “+” bar button over to just under the “@ interface ViewController” line in ViewController.h. (Open the Assistant editor to see both the storyboard and the file source.)

During the drag, the popup appears, asking for the name and type of connection. Enter “action” for the connection type and “add” for the name. Then repeat the drag, this time from the refresh control and using “add” for the name (Figure 16).

Note: to follow this discussion it will help to have the referenced files open in your Xcode Source editor.

In ViewController.m, you will see the implementation code associated with each of the two Interface Builder methods, whose names Xcode added automatically to the .m file:

- (IBAction)add:(id)sender- (IBAction)load:(id)sender

You will also see a third section of code not associated with these methods, which starts with the line: “#pragma mark - Table View Stuff.” These methods support the table view and are part of UITableViewD-elegate and UITableViewDataSource. They handle controlling the

display of the table, and respond to user gestures. For example, swiping a table cell will show the delete button because tableView:-canEditRowAtIndexPath: returns YES and tableView:editingStyleForRowA-tIndexPath: returns UITableViewCellEditingStyleDelete. If you tap the delete button, the delegate method tableView:commitEditingStyle:for-RowAtIndexPath: is called. The code of this method deletes the data for the row and removes it from Kinvey’s data store. When the backend delete is completed, the app displays an alert describing the success or failure.

The way that all three sections (and all Kinvey-enabled apps) move data in and out of a Kinvey collection is by getting a reference to the app’s backend collection (named “testObjects”), which is filled with instances (each named “TestObject”) of the data the app wants to move. That’s why you’ll find the following code repeated three times in Test Drive’s View Controller (once for the add, once for the load, and once for the delete):

To support these statements it is required to have a data object class (TestObject). To see how these files are written in the sample project, click on TestObject.h file and TestObject.m in the Navigator pane. If you were to supply these files in your own app, you would click File > New File, and specify Objective-C class, which would be a subclass of NSObject. Then you would type in the code, with a property for each column in the Kinvey backend collection (including one for the object’s id).

As mentioned earlier, your app also needs to authenticate itself to Kinvey, which is handled by AppDelegate.h and AppDelgate.m. These files are created by Xcode when you create a new project, and start out with just a stub implementation. Look in the sample app source

files for code to copy and paste.

For both the save and load operations, however, moving the data in and out of a backend collection is only part of the work. Table 1 lists all the functions that implements the save and load in the ViewCon-troller.m file, along with pointers to its corresponding block of imple-mentation source code. (For each function, its corresponding code begins with the “Starts at” line and ends with the “Ends at” line.) Refer to Appendix 1 to find the actual source code.

Say Hello To Our WorldThe key takeaway from all this is that “making an app” is a worthwhile thing to do for anyone with a clever idea and a working knowledge of Objective-C. The proof is in the hundreds of apps succeeding in the market every day, many written by people working on their own and who never wrote an app before in their lives. As with anything else, practice does make perfect. But hopefully with all the resources available, and the knowledge gained from this ebook, you have already started down the path toward joining the growing legions of iOS app developers. If so, we welcome you!

Appendix 1 — Test Drive Sample App ViewController.m Source Code

fig. 6 Connect the button’s Touch Up Inside event to an action in the ViewController

fig. 7 Connect the label to the ViewController as an outlet

26

The iOS revolutionIt’s a story that never gets old. The weekend that iPad Minis and the fourth generation iPads went on sale (November 2-5, 2012) Apple sold over 3 million of the devices — a record for first-weekend iPad sales. Two months earlier the company had set another record: first weekend sales of over 5 million for the iPhone 5. Since the introduc-tion of the first iPhone back in 2007,

iOS-based devices (iPhone, iPad, iPad Mini and iPod Touch) continue to rewrite the definition of what constitutes a successful product. By the end of 2012, over 400 million iOS devices had been sold.

What makes iOS devices so successful? Innovation and product features are clearly a big part. Before the iPhone most people had not interacted with a multi-touch interface. They had never zoomed with a pinch or switched between portrait and landscape by merely rotating a device in their hand. Carrying a phone that knew where they were, could suggest places to eat, and could offer directions on how to get there was also a novel experience.

But features like multi-touch, accelerometers and GPS are only part of the appeal. Even with all its innovations, iOS still might not have taken off the way it has if the only people figuring out ways to use those innovations worked at Apple. Most of the capabilities available in an iPhone or iPad in fact don’t come from Apple at all. They come from legions of third-party developers who work in a vast ecosystem that is also an Apple innovation. That ecosystem includes the iPhone, iPad, iPad Mini, iPods, App Store, iTunes, ad networks — and that’s just on the consumer side. On the developer side, you have Xcode, App Loader, testing tools, iTunes Connect — the list goes on.

As of September 2012, the App Store hosted over 700,000 apps that have collectively been downloaded over 30 billion times. Apple reported for October 2012 that App Store monthly revenues were

running at $333 million — a rate of about $4 billion per year — remarkable for a store that only opened in July 2008.

Another innovation that has spurred iOS app development is “The Cloud.” Cloud services make it easier for independent developers to create, support and make money from their apps. The Cloud solves data storage and cross-device and user-to-user sharing problems. If an app stores data in the Cloud, that part of the application is called the “backend,” while the part of the app that runs on the phone and interacts with the user is called the “front end.”

A cloud may be “private” — i.e., the services belong to an organization for the benefit of its employees and business partners. Or a cloud may be “public” — i.e., a company (such as Amazon or Kinvey) owns the services, which developers can then integrate into their own apps. If you are a developer and want to build your own backend, you certainly can do that. Whether you want to or not depends on whether your backend provides functionality common to many different apps. If it does (as in a shopping cart or user authenti-cation) then perhaps that time and money would be better spent on features that offer unique value to your customer. You may be better off hooking into a commercial backend provider via an API. Then you can focus on what counts most — a unique user experience and application-specific functionality. That brings us to the first step in making an app.

Define your appMost unsuccessful apps fail for any of four reasons:

1. the app was a solution in search of a problem (i.e., no real need existed) 2. the implementation was poor 3. the app tried to do too much; or 4. the Apple App Store rejected the app (either because the implementation was poor or it violated Apple’s content policies)

Keeping the app as simple as possible is the best way to avoid these pitfalls. Most successful apps (indeed, most successful consumer tech products) are based on what is called an MVP, or minimum viable product. It’s the product with the smallest feature set that can deliver the core function without any distracting “bells and whistles.” You know you have an MVP if the product would no longer function if you removed any single feature.

But what should that core feature be? One of the best examples of an MVP is Mail. Version 1 (on the Mac) offered a clear, limited and intuitive feature set whose usefulness was immediately obvious to anyone. Today’s iPhone version integrates seamlessly with your phone, contacts and calendaring. It auto-matically corrects spelling as you type, lets you email photos directly from your photos app, and does much more. But all that came later and was built on top of a basic core function. And that’s how your first app should be built. The key is to come up with something with a clear value that changes people’s lives.

So, in drawing up your MVP feature list, ask yourself what features are key to the experience. Some basic market research is probably in order, starting with a visit to the App Store to see what already exists (possibly to be improved upon and/or to compete with you). Likely

must-have core capabilities include:

• Performance (e.g., fast screen refresh)• Offline capability (i.e., ability to work when not connected to the Internet)• Location awareness (e.g., the data/experience will change with the user’s location)• Cloud syncing (e.g., users see the same data on multiple devices)• Push notifications (i.e., sending updated information to devices as soon as it is available)

When you have a handle on what your app does, the next step is to design it. Designing your app involves making choices of how infor-mation and controls are presented to the user as well as how to implement app logic, and figuring out what data lives locally and what belongs in the Cloud.

Design your appUser experience decisions determine the app’s look and feel. They answer questions such as: What does the app look like? What screens does it have? In the software development world, onscreen objects like buttons, sliders, and fill-in boxes are called widgets. So you need to decide which types of widgets will reside on which screens. And what actions will occur as a result of the user interacting with those widgets?

Keep in mind that users will expect to interact differently with a mobile device than they do with a PC because the screens on mobile devices are much smaller. They’ll expect to use their fingers instead of a mouse or a track pad. Ideally, your app can even be used with one hand holding the device while using just a thumb for scrolling andworking the app’s other controls— the Path app is a good example, and increasingly, so is Facebook.

Your app’s features will inform its architecture, which is how you’ll divide the code and data into functional parts. If your app requires interacting with other app users or networked services, you’ll need to figure out what piece of the logic lives in the app code and what comes from the backend. For example, your app might integrate with a restau-rant recommendation engine, share user location, or pull real-time traffic data. This is done using APIs provided by various service providers — but you don’t have to wire up your app to a network to get started. You can develop a prototype using predefined representative (or “dummy”) data. It’s easier to fine-tune the front end if you don’t have to simultaneously modify your backend too. Once you get the app’s look-and-feel right, then make those backend connections.

Once you’ve got the overall concept for your app, the next step is to express that design in terms of the iOS app architecture. That archi-tecture is the model for what parts an iOS app can contain and how those parts fit together. It’s a well thought-out approach for translat-ing a product concept into actual code you can deploy on a device.

WHY iOS?Besides the features and design of your first app, there’s one more decision you need to make before you start actual development. That’s whether to deploy on Apple’s iOS platform or on Google’s Android platform. (Some of this is also covered in our ebook, How to Make an App: Android Edition.) Reasons to develop for iOS include:

Customers more willing to pay. Perhaps it’s because of Android’s open source heritage, but whatever the reason, Android apps gener-ate less than 10% of the total dollars spent on mobile apps, despite having 75% of the smartphone market itself — and despite the fact that the average selling price of an app in the Google Play is $3.79 versus Apple App Store’s $2.01. In other words, Apple users are much more willing to spend money on apps.

The Apple Ecosystem. Some developers and users prefer Apple’s closed and more tightly controlled environment. Apple’s ecosystem, consisting of Xcode, iCloud, iTunes, the App Store, the iPad, the iPhone, Mac computers, etc., offers a very holistic user experience with the ability to share data seamlessly across devices plus the

assurance of having applications pre-approved for quality and content prior to going on sale.

Xcode. Apple’s all-in-one IDE offers state-of-the-art offers features like a graphical interface builder and a syntax-aware and compiler-aware source editor.

The Apple Experience. From the fit and finish of its hardware to the customer service in its retail stores, to the way its hardware and software work flawlessly together, Apple has created the premium brand in consumer electronics. iOS developers share the benefits — so when someone downloads your iOS app, they already expect it’s a great product. And that it will also work flawlessly on their device.

Tablets. iOS has a clear advantage over Android in terms of tablet market adoption. Using Xcode, it’s also much easier to migrate an app from a phone to a tablet and vice versa than it is when develop-ing for Android.

Why Not iOS?Although iOS offers many compelling advantages as a platform for your mobile app, it also comes with some disadvantages. Here are three:

Closed Platform. iOS apps only run on Apple products so you can’t take advantage of features (like NFC) available only on non-iOS devices or market growth of non-iOS devices.

Market Growth. Today, iOS represents less than 15% of the total smartphone market, Although the total market (“the whole pie”) is still increasing at a fast rate, Android market growth outpaces iOS growth.

Approvals. The App Store’s app approval process is notoriously more time consuming than Google Play’s process.

The iOS app architectureAs noted earlier, a key reason why there are so many apps for iOS is because developing highly functional, polished apps for the platform is relatively easy. That’s mainly because of: 1) the design of the development tools, and 2) the key architectural features most iOS apps have in common. So let’s start with some concepts since it helps to know what goes into an app before trying to create one. We’ll begin with:

• Design patterns• Frameworks• Delegation• Storyboard• Windows• Outlets• Supporting files• Products

Design patterns. iOS apps implement what is known as a Mod-el-View-Controller (MVC) pattern. A pattern is a common way to structure code that solves a particular design problem. The MVC pattern separates application code in a way that allows you to easily change one part of an app without having to change other parts. An MVC pattern consists of three components:

• The Model is the logic that acts on the data, such as to store or retrieve data from a database, compute the distance between two cities on a map, etc. An example of a model is the Kinvey backend that stores your data in the Cloud as a service.

• The View provides the interface to the user; it displays the data and widgets (e.g., buttons and text fields) that allow the user to interact with the data. An iPhone app may have more than one view, as in the Contacts app, which displays a list view of all contacts or alternatively a view of each individual contact.

• The Controller is between the model and the view — i.e., it responds to user requests (made in a view) and retrieves results

(produced in a model). This is where developers spend most of their time — constructing the View Controller — by defining and attaching actions (or behaviors) to onscreen widgets. When the user taps a button, for example, it is the View Controller that determines what action will occur, such as retrieve stored data from your Kinvey-based data store. The link between a view object (like a button) to a controller action is called a connection.

Frameworks. You don’t actually have to write most of an app’s logic. It already exists as frameworks. A framework is a collection of classes that implements some function — such as connecting to the Internet, drawing a button, etc. Rather than write the code from scratch, you just use the frameworks supplied by iOS. Some frameworks are automatically present when you start a new project while others may need to be added (done via a drop down menu in Xcode’s Project Editor).

Delegation. Say, you want to customize the behavior of a framework’s object. You can’t actually modify the code of the framework class itself (prohibited since other apps may also use the framework). But what you can do is provide app-specific behavior in an application delegate object. If a delegate implements a method, it will be called by the delegating class to modify its behavior. In the Kinvey sample app (one of two examples we will be describing below), the AppDele-gate.h and AppDelegate.m — the header and implementation files for the UIApplicationDelegate, respectively — contain the code that authenticates an app to the Kinvey backend service.

Storyboards and XIBs. The MainStoryboard.storyboard file (or a .xib file, if you did not click on the “Use Storyboard” option when starting your project) contains the view information needed to implement the overall flow and display of your application and the user interface elements.

Windows. Each view (e.g., the contact list and individual contact details in the Contacts app) exists within a window. The window represents the entire device screen and is where all your views are presented.

Outlets. A variable by which a view object can be referenced in a controller. (For example, if you place a text field to capture a user's name, you might create an outlet called UITextField* nameField.)

Supporting files. These are files that provide resources (like PNG images and other static data) that your app needs as well as files that configure how the app will run. Other examples:

.pch files — precompiled headers used for the code files in your project.

.plist files — property lists that are small amounts of persistent data (like your app’s default user settings) consisting primarily of strings and numbers that you want your app to be able to access, modify if needed, and write back into the property list.

main.m file — your app’s main function. This is needed to launch the app, but you will not need to modify this file.

InfoPlist.strings file — used for localization.

Products. This is the file for your app (i.e., YourProduct.app) that is built when you click Xcode’s “run” button.

“Making an iOS app” involves working with these features in the typical, straightforward workflow:

• Storyboard your views by dragging and configuring graphicalobjects on a template

• Adding behaviors to the various widgets• Writing the classes as to define those behaviors (including

delegates)• Adding needed support files• Building and running the app• Iterating until you are satisfied with your app

This is all done within Xcode.

What’s Xcode?You can start developing functional, good-looking apps almost from the moment you download Xcode, Apple’s integrated development environment (IDE) for making iOS and Macintosh apps. Among other features, Xcode includes a source code editor, graphical user inter-face (GUI) editor (sometimes called Interface Builder), source code repository manager, compiler, and much more. iOS applications are typically developed by manipulating views graphically and by typing Objective-C code for the models and controllers.

To get Xcode, simply go to the App Store and download the applica-tion (it’s free). To do this, click on the App Store icon in your Mac’s dock, or visit https://itunes.apple.com/us/genre/ios/id36?mt=8

The app store will download and install Xcode in your Application folder. From Applications, double-click the Xcode icon to launch Xcode and you’ll see its splash screen (Figure 1). From there you can click on “Create a new Xcode project” to take you to a menu of several templates on which to base your application. Selecting a template opens an Xcode workspace pre-populated with frameworks and other files Xcode thinks you will need using that template.

Although you can develop, build and simulate your app on your computer in Xcode, you can’t run your app on a target device (even your own iPhone) until you become a registered iOS developer and join the iOS Developer Program. To do that, go to develop-er.app.com/ and navigate to the iOS Dev Center. While there, you will also find documentation, sample code and other useful resources such as information on how to submit your app to the iOS App Store.

Everything you do in Xcode is done in a window, called a workspace (Figure 2), consisting of multiple work areas, some of which are also divided into panes. All the files needed to build your app belong to a project, and the Navigator area (far left) lists all your projects (there can be several in a workspace) and all files for each project. Clicking on a file in the Navigator area shows its contents in the Editor area and invokes the appropriate editor. Clicking on a .h or .m file, for example, shows the file’s source code and invokes the Source editor, so you can edit the code. Clicking on .storyboard or .xib (sometimes called a “nib”) file shows the app’s storyboard and invokes the Inter-face Builder, so you can design a view using the Builder’s drag and drop features.

An especially handy feature is that the Editor area can have both a right and a left pane — with each pane aware of your edits in the other. So, for example, you can simultaneously edit an object’s .h

header file in the left pane and its corresponding .m in the right pane. Or you might click on a button object (displayed graphically) in the left pane and edit its method’s source code in the right pane. To toggle between a single pane (the “Standard Editor”) and double pane view (the “Assistant Editor”), use the Editor selector button on the right of the toolbar. You can option+command+click a symbol in the editor to open the definition in the opposite editor pane.

You can also resize the entire Editor area simply by dragging its borders. For even more editing space, you can also remove the Debug area or both the Debug and Utility areas using the View Selector button on the far right of the toolbar.

As its name suggests, the Debug area shows information, like variable state and console logs, helpful in debugging code.

The Utility area has two panes: the Inspector and Quick Help pane (top) and the Library pane (bottom). Although there are five inspectors — File, Help, Identity, Attributes, Size and Connec-tions — only the inspectors that are currently relevant appear in the Inspec-tor list at the top of the pane. (To see the name of an inspector, move the cursor over its icon in the Inspector selector bar.)

You will use inspectors to add and modify object attributes for views in the Interface Builder. For example, if you click on a UILabel in the Editor area of a storyboard, you can use the Attributes inspector to change the label’s color and use the Size inspector to change the label’s size.

The Help inspector shows help information about a selected class. Use the Identity inspector to view and manage an object’s metadata such as its class, runtime attributes, label and so forth. Use the

Connections inspector to view the outlets and actions of an interface object, to make new connections and to delete existing connections.

The Library pane has libraries of resources (like file templates, code snippets, interface objects and media files) that are prebuilt and ready to insert into your project. Use the Library selector to select which of these libraries (e.g., code snippets or interface objects) you wish to insert. To insert one, drag it directly into your storyboard while using the Interface Builder editor.

These are basics you need to know to get started using Xcode to build your first app. But to really understand how it’s done, it helps to walk through an actual app or two. Let’s start with a simple “Hello World” app that does not employ a backend connection, and then look at a somewhat more functional app that does.

“Hello World!” sample appThis app displays a button (“Press Me”) and a label (“Label”) so that when the user presses the button the text of the label changes to “Hello World!” as in Figure 3:

To get started, launch Xcode and select “Create a New Xcode Project.” From the iOS Application templates, select “Single View Application” and click “Next.” Fill in your product’s name and a company identifier, typically “com.yourCompanyName.” Deselect “Use Storyboards” and leave “Use Automatic Reference Counting” selected. Then click “Next” and select a destination for your projects files.

Follow these steps to make your app:

1. Select your project’s ViewController.xib file in the Navigator(Figure 4), to open the Interface Builder editor.

2. Drag a “Round Rect Button” from the Objects library (lowerright) onto the view in the Editor area; select the button’s textand type “Press Me.”

3. Drag a Label from the objects library onto the view, as well.4. Select and drag the Label sizing handles, centering the object

and making it wide enough to hold the “Hello World!” text; then,

5. With the “Hello World!” label still selected, click on centeralignment in the Attributes inspector.

6. Open the Assistant Editor (Figure 5), exposing the source codeheader file (ViewController.h) of the view controller you justbuilt graphically.

7. Select the button and control-drag from the button to justbelow the ViewController definition in the Assistant panel. Inthe form that opens, select “Action” for the connection type,type in a name (“showText”) and click “Connect.” This creates aninterface builder (IB) action as highlighted in Figure 6.

8. Next step is to create an outlet for the label. To do this, selectthe label object and control-drag from the label to just belowthe IB action you just created. Select “Outlet” as the connectiontype and enter a name “label” and click “Connect.” This createsan interface builder (IB) outlet as shown in Figure 7.

9. Finally, it’s time to add some logic to the view controller so itknows what to do when the button is pressed. To do this, select“ViewController.m” in the project navigator to show the codeeditor. Find the button’s IBAction you just created (near thebottom), place your cursor between the { } brackets and hit thereturn key a few times to create some extra space. Then in thatspace type the method for how you want the label you speci-fied to respond: _label.text=”Hello World!”; as highlightedin Figure 8.

Congratulations! Your app is done. To build and run your new app in the simulator, click the Xcode Run button in the left corner of the toolbar. When you click the button, the text will update.

fig. 8 _label.text = "Hello World"; will set the label text on the button press.

Sample app with a backend This second app (named “Kinvey Test Drive”) lets the user type text on an iPhone and save the text to a backend service, like Kinvey. It also lets the user load text on the iPhone from their Kinvey backend. Reading about this app will help you learn:

• How to set up Kinvey’s library in an iOS project• Additional Interface Builder techniques you can use to story-board an application• How to add view controller logic to interact with the backend service, allowing you to save and retrieve data

We will first present the app as a running application and then take it apart so you can see how it was made. To make the app yourself, you can review the various sections below and replicate the steps in your copy of Xcode.

First, to see the app in action, you should download the app and run it on your system. To do that, sign up for Kinvey, then navigate to “Dev Center”, “Samples,” find the “Test Drive” app, and click on its icon. (If you can’t find it right away, make sure you select iOS as your platform on the right side of the menu bar.) Click the download button to download the app’s project files to your computer. Then launch Xcode — just double click on the .xcodeproj file in the project folder.

But before you can run the app, you need to set up the app’s Kinvey backend.

Set Up Kinvey as a Backend Data StoreTest Drive’s project files include all the code the sample app needs in order to talk to Kinvey. However, that would not be the case if you were to build an app from scratch — so you would have to go through an initial Kinvey setup procedure. This involves downloading the Kinvey library files from the downloads section of devcenter.kin-vey.com and dragging them to the Navigator’s Frameworks folder in Xcode. You also need to tell Xcode to link your project with additional iOS frameworks. To find these frameworks, click on the Project folder

at the very top of the Navigator pane — which displays the Project editor — and then select the “Build Settings” tab. For detailed instruc-tions, complete the “Getting Started” page under “Guides” on the Kinvey website. But again, you can skip this setup procedure for now in order to run the downloaded Kinvey Test Drive app.

But you must still do this step: To run any app that uses Kinvey (including Test Drive) you need to do the “Create an App” step on the Kinvey website. Click on “My Apps” in the Kinvey menu bar and then click on “Add an App,” which will open an “Add” page. Type in a name for your app and click on the Apple logo and then click “Create.” The page that opens shows your App’s credentials. Copy and paste the App Key and App Secret into the AppDelegate.m file of the download-ed Test Drive project:

You are now ready to run the app — click on the Xcode run button and wait for the simulator to open and the app to appear (Figure 9).

Clicking the “+” toolbar button opens an alert (Figure 10) with an empty field into which the user can type some text (e.g., “some new data”). Clicking “save” uploads the data to Kinvey and displays text on the screen (a table view) and also displays an alert that the save worked (Figure 11).

To test the load function, enter some data (e.g., “some data to load”) in the “name” field of the Kinvey collection. To see the load, the swipe down on the table on the phone until the refresh spinner starts, and then the new data will appear in the table (Figure 12).

Figure 13 shows the Kinvey collection after the save that Figure 10 depicts on the iPhone. Figure 14 shows the Kinvey collection after the user adds a new row to the testObjects collection using the web browser. Note that every time a save is done on the iPhone, Kinvey automatically adds a new row (displayed on a collection refresh). To add a new row manually in the browser, click “+ row,” and type some descriptive text in the “name” column. That data will now load on the iPhone when the user pulls down on the table.

Storyboard the Test Drive AppMost of the Test Drive user interface objects visible in the simulation are available in Xcode’s Object Library and can therefore be added to the view graphically. The UI objects consist of a:

• Table view• Toolbar• Tool Bar Button item – flexible space• Tool Bar Button item – Add• Table view cell• Label – Title• Refresh Control

To create this app yourself, you would follow these steps:

• Launch Xcode and select the “Single View Application” template• Select the “Use Storyboard” option• Replace the default UIviewcontroller object with a UITableView-Controller • Drag and drop the other objects, in the order listed, onto the UIviewcontroller

Also note:

• The Flexible Space Bar Button item fills up the space on the toolbar so the add button is at the right. This is a standard pattern in table-based iPhone apps.• The add button shows the system “+” sign. That is done by dragging a bar button item onto the toolbar, clicking on the Identifier drop down menu in the Attributes inspector; and then selecting the “Add” option.

As with the “Hello World!” app, once your app’s view is complete (Figure 15), you would still have to create the various methods and connections that bring them to life. This is done using the Source editor while working with the ViewController.m file.

Add View Controller LogicSince the app performs two basic operations (save data to Kinvey and load data from Kinvey) these two methods must be added to the ViewController header file. That’s done with a control-drag from the “+” bar button over to just under the “@ interface ViewController” line in ViewController.h. (Open the Assistant editor to see both the storyboard and the file source.)

During the drag, the popup appears, asking for the name and type of connection. Enter “action” for the connection type and “add” for the name. Then repeat the drag, this time from the refresh control and using “add” for the name (Figure 16).

Note: to follow this discussion it will help to have the referenced files open in your Xcode Source editor.

In ViewController.m, you will see the implementation code associated with each of the two Interface Builder methods, whose names Xcode added automatically to the .m file:

- (IBAction)add:(id)sender- (IBAction)load:(id)sender

You will also see a third section of code not associated with these methods, which starts with the line: “#pragma mark - Table View Stuff.” These methods support the table view and are part of UITableViewD-elegate and UITableViewDataSource. They handle controlling the

display of the table, and respond to user gestures. For example, swiping a table cell will show the delete button because tableView:-canEditRowAtIndexPath: returns YES and tableView:editingStyleForRowA-tIndexPath: returns UITableViewCellEditingStyleDelete. If you tap the delete button, the delegate method tableView:commitEditingStyle:for-RowAtIndexPath: is called. The code of this method deletes the data for the row and removes it from Kinvey’s data store. When the backend delete is completed, the app displays an alert describing the success or failure.

The way that all three sections (and all Kinvey-enabled apps) move data in and out of a Kinvey collection is by getting a reference to the app’s backend collection (named “testObjects”), which is filled with instances (each named “TestObject”) of the data the app wants to move. That’s why you’ll find the following code repeated three times in Test Drive’s View Controller (once for the add, once for the load, and once for the delete):

To support these statements it is required to have a data object class (TestObject). To see how these files are written in the sample project, click on TestObject.h file and TestObject.m in the Navigator pane. If you were to supply these files in your own app, you would click File > New File, and specify Objective-C class, which would be a subclass of NSObject. Then you would type in the code, with a property for each column in the Kinvey backend collection (including one for the object’s id).

As mentioned earlier, your app also needs to authenticate itself to Kinvey, which is handled by AppDelegate.h and AppDelgate.m. These files are created by Xcode when you create a new project, and start out with just a stub implementation. Look in the sample app source

files for code to copy and paste.

For both the save and load operations, however, moving the data in and out of a backend collection is only part of the work. Table 1 lists all the functions that implements the save and load in the ViewCon-troller.m file, along with pointers to its corresponding block of imple-mentation source code. (For each function, its corresponding code begins with the “Starts at” line and ends with the “Ends at” line.) Refer to Appendix 1 to find the actual source code.

Say Hello To Our WorldThe key takeaway from all this is that “making an app” is a worthwhile thing to do for anyone with a clever idea and a working knowledge of Objective-C. The proof is in the hundreds of apps succeeding in the market every day, many written by people working on their own and who never wrote an app before in their lives. As with anything else, practice does make perfect. But hopefully with all the resources available, and the knowledge gained from this ebook, you have already started down the path toward joining the growing legions of iOS app developers. If so, we welcome you!

Appendix 1 — Test Drive Sample App ViewController.m Source Code

28

The iOS revolutionIt’s a story that never gets old. The weekend that iPad Minis and the fourth generation iPads went on sale (November 2-5, 2012) Apple sold over 3 million of the devices — a record for first-weekend iPad sales. Two months earlier the company had set another record: first weekend sales of over 5 million for the iPhone 5. Since the introduc-tion of the first iPhone back in 2007,

iOS-based devices (iPhone, iPad, iPad Mini and iPod Touch) continue to rewrite the definition of what constitutes a successful product. By the end of 2012, over 400 million iOS devices had been sold.

What makes iOS devices so successful? Innovation and product features are clearly a big part. Before the iPhone most people had not interacted with a multi-touch interface. They had never zoomed with a pinch or switched between portrait and landscape by merely rotating a device in their hand. Carrying a phone that knew where they were, could suggest places to eat, and could offer directions on how to get there was also a novel experience.

But features like multi-touch, accelerometers and GPS are only part of the appeal. Even with all its innovations, iOS still might not have taken off the way it has if the only people figuring out ways to use those innovations worked at Apple. Most of the capabilities available in an iPhone or iPad in fact don’t come from Apple at all. They come from legions of third-party developers who work in a vast ecosystem that is also an Apple innovation. That ecosystem includes the iPhone, iPad, iPad Mini, iPods, App Store, iTunes, ad networks — and that’s just on the consumer side. On the developer side, you have Xcode, App Loader, testing tools, iTunes Connect — the list goes on.

As of September 2012, the App Store hosted over 700,000 apps that have collectively been downloaded over 30 billion times. Apple reported for October 2012 that App Store monthly revenues were

running at $333 million — a rate of about $4 billion per year — remarkable for a store that only opened in July 2008.

Another innovation that has spurred iOS app development is “The Cloud.” Cloud services make it easier for independent developers to create, support and make money from their apps. The Cloud solves data storage and cross-device and user-to-user sharing problems. If an app stores data in the Cloud, that part of the application is called the “backend,” while the part of the app that runs on the phone and interacts with the user is called the “front end.”

A cloud may be “private” — i.e., the services belong to an organization for the benefit of its employees and business partners. Or a cloud may be “public” — i.e., a company (such as Amazon or Kinvey) owns the services, which developers can then integrate into their own apps. If you are a developer and want to build your own backend, you certainly can do that. Whether you want to or not depends on whether your backend provides functionality common to many different apps. If it does (as in a shopping cart or user authenti-cation) then perhaps that time and money would be better spent on features that offer unique value to your customer. You may be better off hooking into a commercial backend provider via an API. Then you can focus on what counts most — a unique user experience and application-specific functionality. That brings us to the first step in making an app.

Define your appMost unsuccessful apps fail for any of four reasons:

1. the app was a solution in search of a problem (i.e., no real need existed) 2. the implementation was poor 3. the app tried to do too much; or 4. the Apple App Store rejected the app (either because the implementation was poor or it violated Apple’s content policies)

Keeping the app as simple as possible is the best way to avoid these pitfalls. Most successful apps (indeed, most successful consumer tech products) are based on what is called an MVP, or minimum viable product. It’s the product with the smallest feature set that can deliver the core function without any distracting “bells and whistles.” You know you have an MVP if the product would no longer function if you removed any single feature.

But what should that core feature be? One of the best examples of an MVP is Mail. Version 1 (on the Mac) offered a clear, limited and intuitive feature set whose usefulness was immediately obvious to anyone. Today’s iPhone version integrates seamlessly with your phone, contacts and calendaring. It auto-matically corrects spelling as you type, lets you email photos directly from your photos app, and does much more. But all that came later and was built on top of a basic core function. And that’s how your first app should be built. The key is to come up with something with a clear value that changes people’s lives.

So, in drawing up your MVP feature list, ask yourself what features are key to the experience. Some basic market research is probably in order, starting with a visit to the App Store to see what already exists (possibly to be improved upon and/or to compete with you). Likely

must-have core capabilities include:

• Performance (e.g., fast screen refresh)• Offline capability (i.e., ability to work when not connected to the Internet)• Location awareness (e.g., the data/experience will change with the user’s location)• Cloud syncing (e.g., users see the same data on multiple devices)• Push notifications (i.e., sending updated information to devices as soon as it is available)

When you have a handle on what your app does, the next step is to design it. Designing your app involves making choices of how infor-mation and controls are presented to the user as well as how to implement app logic, and figuring out what data lives locally and what belongs in the Cloud.

Design your appUser experience decisions determine the app’s look and feel. They answer questions such as: What does the app look like? What screens does it have? In the software development world, onscreen objects like buttons, sliders, and fill-in boxes are called widgets. So you need to decide which types of widgets will reside on which screens. And what actions will occur as a result of the user interacting with those widgets?

Keep in mind that users will expect to interact differently with a mobile device than they do with a PC because the screens on mobile devices are much smaller. They’ll expect to use their fingers instead of a mouse or a track pad. Ideally, your app can even be used with one hand holding the device while using just a thumb for scrolling andworking the app’s other controls— the Path app is a good example, and increasingly, so is Facebook.

Your app’s features will inform its architecture, which is how you’ll divide the code and data into functional parts. If your app requires interacting with other app users or networked services, you’ll need to figure out what piece of the logic lives in the app code and what comes from the backend. For example, your app might integrate with a restau-rant recommendation engine, share user location, or pull real-time traffic data. This is done using APIs provided by various service providers — but you don’t have to wire up your app to a network to get started. You can develop a prototype using predefined representative (or “dummy”) data. It’s easier to fine-tune the front end if you don’t have to simultaneously modify your backend too. Once you get the app’s look-and-feel right, then make those backend connections.

Once you’ve got the overall concept for your app, the next step is to express that design in terms of the iOS app architecture. That archi-tecture is the model for what parts an iOS app can contain and how those parts fit together. It’s a well thought-out approach for translat-ing a product concept into actual code you can deploy on a device.

WHY iOS?Besides the features and design of your first app, there’s one more decision you need to make before you start actual development. That’s whether to deploy on Apple’s iOS platform or on Google’s Android platform. (Some of this is also covered in our ebook, How to Make an App: Android Edition.) Reasons to develop for iOS include:

Customers more willing to pay. Perhaps it’s because of Android’s open source heritage, but whatever the reason, Android apps gener-ate less than 10% of the total dollars spent on mobile apps, despite having 75% of the smartphone market itself — and despite the fact that the average selling price of an app in the Google Play is $3.79 versus Apple App Store’s $2.01. In other words, Apple users are much more willing to spend money on apps.

The Apple Ecosystem. Some developers and users prefer Apple’s closed and more tightly controlled environment. Apple’s ecosystem, consisting of Xcode, iCloud, iTunes, the App Store, the iPad, the iPhone, Mac computers, etc., offers a very holistic user experience with the ability to share data seamlessly across devices plus the

assurance of having applications pre-approved for quality and content prior to going on sale.

Xcode. Apple’s all-in-one IDE offers state-of-the-art offers features like a graphical interface builder and a syntax-aware and compiler-aware source editor.

The Apple Experience. From the fit and finish of its hardware to the customer service in its retail stores, to the way its hardware and software work flawlessly together, Apple has created the premium brand in consumer electronics. iOS developers share the benefits — so when someone downloads your iOS app, they already expect it’s a great product. And that it will also work flawlessly on their device.

Tablets. iOS has a clear advantage over Android in terms of tablet market adoption. Using Xcode, it’s also much easier to migrate an app from a phone to a tablet and vice versa than it is when develop-ing for Android.

Why Not iOS?Although iOS offers many compelling advantages as a platform for your mobile app, it also comes with some disadvantages. Here are three:

Closed Platform. iOS apps only run on Apple products so you can’t take advantage of features (like NFC) available only on non-iOS devices or market growth of non-iOS devices.

Market Growth. Today, iOS represents less than 15% of the total smartphone market, Although the total market (“the whole pie”) is still increasing at a fast rate, Android market growth outpaces iOS growth.

Approvals. The App Store’s app approval process is notoriously more time consuming than Google Play’s process.

The iOS app architectureAs noted earlier, a key reason why there are so many apps for iOS is because developing highly functional, polished apps for the platform is relatively easy. That’s mainly because of: 1) the design of the development tools, and 2) the key architectural features most iOS apps have in common. So let’s start with some concepts since it helps to know what goes into an app before trying to create one. We’ll begin with:

• Design patterns• Frameworks• Delegation• Storyboard• Windows• Outlets• Supporting files• Products

Design patterns. iOS apps implement what is known as a Mod-el-View-Controller (MVC) pattern. A pattern is a common way to structure code that solves a particular design problem. The MVC pattern separates application code in a way that allows you to easily change one part of an app without having to change other parts. An MVC pattern consists of three components:

• The Model is the logic that acts on the data, such as to store or retrieve data from a database, compute the distance between two cities on a map, etc. An example of a model is the Kinvey backend that stores your data in the Cloud as a service.

• The View provides the interface to the user; it displays the data and widgets (e.g., buttons and text fields) that allow the user to interact with the data. An iPhone app may have more than one view, as in the Contacts app, which displays a list view of all contacts or alternatively a view of each individual contact.

• The Controller is between the model and the view — i.e., it responds to user requests (made in a view) and retrieves results

(produced in a model). This is where developers spend most of their time — constructing the View Controller — by defining and attaching actions (or behaviors) to onscreen widgets. When the user taps a button, for example, it is the View Controller that determines what action will occur, such as retrieve stored data from your Kinvey-based data store. The link between a view object (like a button) to a controller action is called a connection.

Frameworks. You don’t actually have to write most of an app’s logic. It already exists as frameworks. A framework is a collection of classes that implements some function — such as connecting to the Internet, drawing a button, etc. Rather than write the code from scratch, you just use the frameworks supplied by iOS. Some frameworks are automatically present when you start a new project while others may need to be added (done via a drop down menu in Xcode’s Project Editor).

Delegation. Say, you want to customize the behavior of a framework’s object. You can’t actually modify the code of the framework class itself (prohibited since other apps may also use the framework). But what you can do is provide app-specific behavior in an application delegate object. If a delegate implements a method, it will be called by the delegating class to modify its behavior. In the Kinvey sample app (one of two examples we will be describing below), the AppDele-gate.h and AppDelegate.m — the header and implementation files for the UIApplicationDelegate, respectively — contain the code that authenticates an app to the Kinvey backend service.

Storyboards and XIBs. The MainStoryboard.storyboard file (or a .xib file, if you did not click on the “Use Storyboard” option when starting your project) contains the view information needed to implement the overall flow and display of your application and the user interface elements.

Windows. Each view (e.g., the contact list and individual contact details in the Contacts app) exists within a window. The window represents the entire device screen and is where all your views are presented.

Outlets. A variable by which a view object can be referenced in a controller. (For example, if you place a text field to capture a user's name, you might create an outlet called UITextField* nameField.)

Supporting files. These are files that provide resources (like PNG images and other static data) that your app needs as well as files that configure how the app will run. Other examples:

.pch files — precompiled headers used for the code files in your project.

.plist files — property lists that are small amounts of persistent data (like your app’s default user settings) consisting primarily of strings and numbers that you want your app to be able to access, modify if needed, and write back into the property list.

main.m file — your app’s main function. This is needed to launch the app, but you will not need to modify this file.

InfoPlist.strings file — used for localization.

Products. This is the file for your app (i.e., YourProduct.app) that is built when you click Xcode’s “run” button.

“Making an iOS app” involves working with these features in the typical, straightforward workflow:

• Storyboard your views by dragging and configuring graphicalobjects on a template

• Adding behaviors to the various widgets• Writing the classes as to define those behaviors (including

delegates)• Adding needed support files• Building and running the app• Iterating until you are satisfied with your app

This is all done within Xcode.

What’s Xcode?You can start developing functional, good-looking apps almost from the moment you download Xcode, Apple’s integrated development environment (IDE) for making iOS and Macintosh apps. Among other features, Xcode includes a source code editor, graphical user inter-face (GUI) editor (sometimes called Interface Builder), source code repository manager, compiler, and much more. iOS applications are typically developed by manipulating views graphically and by typing Objective-C code for the models and controllers.

To get Xcode, simply go to the App Store and download the applica-tion (it’s free). To do this, click on the App Store icon in your Mac’s dock, or visit https://itunes.apple.com/us/genre/ios/id36?mt=8

The app store will download and install Xcode in your Application folder. From Applications, double-click the Xcode icon to launch Xcode and you’ll see its splash screen (Figure 1). From there you can click on “Create a new Xcode project” to take you to a menu of several templates on which to base your application. Selecting a template opens an Xcode workspace pre-populated with frameworks and other files Xcode thinks you will need using that template.

Although you can develop, build and simulate your app on your computer in Xcode, you can’t run your app on a target device (even your own iPhone) until you become a registered iOS developer and join the iOS Developer Program. To do that, go to develop-er.app.com/ and navigate to the iOS Dev Center. While there, you will also find documentation, sample code and other useful resources such as information on how to submit your app to the iOS App Store.

Everything you do in Xcode is done in a window, called a workspace (Figure 2), consisting of multiple work areas, some of which are also divided into panes. All the files needed to build your app belong to a project, and the Navigator area (far left) lists all your projects (there can be several in a workspace) and all files for each project. Clicking on a file in the Navigator area shows its contents in the Editor area and invokes the appropriate editor. Clicking on a .h or .m file, for example, shows the file’s source code and invokes the Source editor, so you can edit the code. Clicking on .storyboard or .xib (sometimes called a “nib”) file shows the app’s storyboard and invokes the Inter-face Builder, so you can design a view using the Builder’s drag and drop features.

An especially handy feature is that the Editor area can have both a right and a left pane — with each pane aware of your edits in the other. So, for example, you can simultaneously edit an object’s .h

header file in the left pane and its corresponding .m in the right pane. Or you might click on a button object (displayed graphically) in the left pane and edit its method’s source code in the right pane. To toggle between a single pane (the “Standard Editor”) and double pane view (the “Assistant Editor”), use the Editor selector button on the right of the toolbar. You can option+command+click a symbol in the editor to open the definition in the opposite editor pane.

You can also resize the entire Editor area simply by dragging its borders. For even more editing space, you can also remove the Debug area or both the Debug and Utility areas using the View Selector button on the far right of the toolbar.

As its name suggests, the Debug area shows information, like variable state and console logs, helpful in debugging code.

The Utility area has two panes: the Inspector and Quick Help pane (top) and the Library pane (bottom). Although there are five inspectors — File, Help, Identity, Attributes, Size and Connec-tions — only the inspectors that are currently relevant appear in the Inspec-tor list at the top of the pane. (To see the name of an inspector, move the cursor over its icon in the Inspector selector bar.)

You will use inspectors to add and modify object attributes for views in the Interface Builder. For example, if you click on a UILabel in the Editor area of a storyboard, you can use the Attributes inspector to change the label’s color and use the Size inspector to change the label’s size.

The Help inspector shows help information about a selected class. Use the Identity inspector to view and manage an object’s metadata such as its class, runtime attributes, label and so forth. Use the

Connections inspector to view the outlets and actions of an interface object, to make new connections and to delete existing connections.

The Library pane has libraries of resources (like file templates, code snippets, interface objects and media files) that are prebuilt and ready to insert into your project. Use the Library selector to select which of these libraries (e.g., code snippets or interface objects) you wish to insert. To insert one, drag it directly into your storyboard while using the Interface Builder editor.

These are basics you need to know to get started using Xcode to build your first app. But to really understand how it’s done, it helps to walk through an actual app or two. Let’s start with a simple “Hello World” app that does not employ a backend connection, and then look at a somewhat more functional app that does.

“Hello World!” sample appThis app displays a button (“Press Me”) and a label (“Label”) so that when the user presses the button the text of the label changes to “Hello World!” as in Figure 3:

To get started, launch Xcode and select “Create a New Xcode Project.” From the iOS Application templates, select “Single View Application” and click “Next.” Fill in your product’s name and a company identifier, typically “com.yourCompanyName.” Deselect “Use Storyboards” and leave “Use Automatic Reference Counting” selected. Then click “Next” and select a destination for your projects files.

Follow these steps to make your app:

1. Select your project’s ViewController.xib file in the Navigator(Figure 4), to open the Interface Builder editor.

2. Drag a “Round Rect Button” from the Objects library (lowerright) onto the view in the Editor area; select the button’s textand type “Press Me.”

3. Drag a Label from the objects library onto the view, as well.4. Select and drag the Label sizing handles, centering the object

and making it wide enough to hold the “Hello World!” text; then,

5. With the “Hello World!” label still selected, click on centeralignment in the Attributes inspector.

6. Open the Assistant Editor (Figure 5), exposing the source codeheader file (ViewController.h) of the view controller you justbuilt graphically.

7. Select the button and control-drag from the button to justbelow the ViewController definition in the Assistant panel. Inthe form that opens, select “Action” for the connection type,type in a name (“showText”) and click “Connect.” This creates aninterface builder (IB) action as highlighted in Figure 6.

8. Next step is to create an outlet for the label. To do this, selectthe label object and control-drag from the label to just belowthe IB action you just created. Select “Outlet” as the connectiontype and enter a name “label” and click “Connect.” This createsan interface builder (IB) outlet as shown in Figure 7.

9. Finally, it’s time to add some logic to the view controller so itknows what to do when the button is pressed. To do this, select “ViewController.m” in the project navigator to show the code editor. Find the button’s IBAction you just created (near the bottom), place your cursor between the { } brackets and hit the return key a few times to create some extra space. Then in that space type the method for how you want the label you speci-fied to respond: _label.text=”Hello World!”; as highlighted in Figure 8.

Congratulations! Your app is done. To build and run your new app in the simulator, click the Xcode Run button in the left corner of the toolbar. When you click the button, the text will update.

Sample app with a backend This second app (named “Kinvey Test Drive”) lets the user type text on an iPhone and save the text to a backend service, like Kinvey. It also lets the user load text on the iPhone from their Kinvey backend. Reading about this app will help you learn:

• How to set up Kinvey’s library in an iOS project• Additional Interface Builder techniques you can use to story-board an application• How to add view controller logic to interact with the backendservice, allowing you to save and retrieve data

We will first present the app as a running application and then take it apart so you can see how it was made. To make the app yourself, you can review the various sections below and replicate the steps in your copy of Xcode.

First, to see the app in action, you should download the app and run it on your system. To do that, sign up for Kinvey, then navigate to “Dev Center”, “Samples,” find the “Test Drive” app, and click on its icon. (If you can’t find it right away, make sure you select iOS as your platform on the right side of the menu bar.) Click the download button to download the app’s project files to your computer. Then launch Xcode — just double click on the .xcodeproj file in the project folder.

But before you can run the app, you need to set up the app’s Kinvey backend.

Set Up Kinvey as a Backend Data StoreTest Drive’s project files include all the code the sample app needs in order to talk to Kinvey. However, that would not be the case if you were to build an app from scratch — so you would have to go through an initial Kinvey setup procedure. This involves downloading the Kinvey library files from the downloads section of devcenter.kin-vey.com and dragging them to the Navigator’s Frameworks folder in Xcode. You also need to tell Xcode to link your project with additional iOS frameworks. To find these frameworks, click on the Project folder

at the very top of the Navigator pane — which displays the Project editor — and then select the “Build Settings” tab. For detailed instruc-tions, complete the “Getting Started” page under “Guides” on the Kinvey website. But again, you can skip this setup procedure for now in order to run the downloaded Kinvey Test Drive app.

But you must still do this step: To run any app that uses Kinvey (including Test Drive) you need to do the “Create an App” step on the Kinvey website. Click on “My Apps” in the Kinvey menu bar and then click on “Add an App,” which will open an “Add” page. Type in a name for your app and click on the Apple logo and then click “Create.” The page that opens shows your App’s credentials. Copy and paste the App Key and App Secret into the AppDelegate.m file of the download-ed Test Drive project:

You are now ready to run the app — click on the Xcode run button and wait for the simulator to open and the app to appear (Figure 9).

Clicking the “+” toolbar button opens an alert (Figure 10) with an empty field into which the user can type some text (e.g., “some new data”). Clicking “save” uploads the data to Kinvey and displays text on the screen (a table view) and also displays an alert that the save worked (Figure 11).

To test the load function, enter some data (e.g., “some data to load”) in the “name” field of the Kinvey collection. To see the load, the swipe down on the table on the phone until the refresh spinner starts, and then the new data will appear in the table (Figure 12).

Figure 13 shows the Kinvey collection after the save that Figure 10 depicts on the iPhone. Figure 14 shows the Kinvey collection after the user adds a new row to the testObjects collection using the web browser. Note that every time a save is done on the iPhone, Kinvey automatically adds a new row (displayed on a collection refresh). To add a new row manually in the browser, click “+ row,” and type some descriptive text in the “name” column. That data will now load on the iPhone when the user pulls down on the table.

Storyboard the Test Drive AppMost of the Test Drive user interface objects visible in the simulation are available in Xcode’s Object Library and can therefore be added to the view graphically. The UI objects consist of a:

• Table view• Toolbar• Tool Bar Button item – flexible space• Tool Bar Button item – Add• Table view cell• Label – Title• Refresh Control

To create this app yourself, you would follow these steps:

• Launch Xcode and select the “Single View Application” template• Select the “Use Storyboard” option• Replace the default UIviewcontroller object with a UITableView-Controller • Drag and drop the other objects, in the order listed, onto the UIviewcontroller

Also note:

• The Flexible Space Bar Button item fills up the space on the toolbar so the add button is at the right. This is a standard pattern in table-based iPhone apps.• The add button shows the system “+” sign. That is done by dragging a bar button item onto the toolbar, clicking on the Identifier drop down menu in the Attributes inspector; and then selecting the “Add” option.

As with the “Hello World!” app, once your app’s view is complete (Figure 15), you would still have to create the various methods and connections that bring them to life. This is done using the Source editor while working with the ViewController.m file.

Add View Controller LogicSince the app performs two basic operations (save data to Kinvey and load data from Kinvey) these two methods must be added to the ViewController header file. That’s done with a control-drag from the “+” bar button over to just under the “@ interface ViewController” line in ViewController.h. (Open the Assistant editor to see both the storyboard and the file source.)

During the drag, the popup appears, asking for the name and type of connection. Enter “action” for the connection type and “add” for the name. Then repeat the drag, this time from the refresh control and using “add” for the name (Figure 16).

Note: to follow this discussion it will help to have the referenced files open in your Xcode Source editor.

In ViewController.m, you will see the implementation code associated with each of the two Interface Builder methods, whose names Xcode added automatically to the .m file:

- (IBAction)add:(id)sender- (IBAction)load:(id)sender

You will also see a third section of code not associated with these methods, which starts with the line: “#pragma mark - Table View Stuff.” These methods support the table view and are part of UITableViewD-elegate and UITableViewDataSource. They handle controlling the

display of the table, and respond to user gestures. For example, swiping a table cell will show the delete button because tableView:-canEditRowAtIndexPath: returns YES and tableView:editingStyleForRowA-tIndexPath: returns UITableViewCellEditingStyleDelete. If you tap the delete button, the delegate method tableView:commitEditingStyle:for-RowAtIndexPath: is called. The code of this method deletes the data for the row and removes it from Kinvey’s data store. When the backend delete is completed, the app displays an alert describing the success or failure.

The way that all three sections (and all Kinvey-enabled apps) move data in and out of a Kinvey collection is by getting a reference to the app’s backend collection (named “testObjects”), which is filled with instances (each named “TestObject”) of the data the app wants to move. That’s why you’ll find the following code repeated three times in Test Drive’s View Controller (once for the add, once for the load, and once for the delete):

To support these statements it is required to have a data object class (TestObject). To see how these files are written in the sample project, click on TestObject.h file and TestObject.m in the Navigator pane. If you were to supply these files in your own app, you would click File > New File, and specify Objective-C class, which would be a subclass of NSObject. Then you would type in the code, with a property for each column in the Kinvey backend collection (including one for the object’s id).

As mentioned earlier, your app also needs to authenticate itself to Kinvey, which is handled by AppDelegate.h and AppDelgate.m. These files are created by Xcode when you create a new project, and start out with just a stub implementation. Look in the sample app source

files for code to copy and paste.

For both the save and load operations, however, moving the data in and out of a backend collection is only part of the work. Table 1 lists all the functions that implements the save and load in the ViewCon-troller.m file, along with pointers to its corresponding block of imple-mentation source code. (For each function, its corresponding code begins with the “Starts at” line and ends with the “Ends at” line.) Refer to Appendix 1 to find the actual source code.

Say Hello To Our WorldThe key takeaway from all this is that “making an app” is a worthwhile thing to do for anyone with a clever idea and a working knowledge of Objective-C. The proof is in the hundreds of apps succeeding in the market every day, many written by people working on their own and who never wrote an app before in their lives. As with anything else, practice does make perfect. But hopefully with all the resources available, and the knowledge gained from this ebook, you have already started down the path toward joining the growing legions of iOS app developers. If so, we welcome you!

Appendix 1 — Test Drive Sample App ViewController.m Source Code

29

The iOS revolutionIt’s a story that never gets old. The weekend that iPad Minis and the fourth generation iPads went on sale (November 2-5, 2012) Apple sold over 3 million of the devices — a record for first-weekend iPad sales. Two months earlier the company had set another record: first weekend sales of over 5 million for the iPhone 5. Since the introduc-tion of the first iPhone back in 2007,

iOS-based devices (iPhone, iPad, iPad Mini and iPod Touch) continue to rewrite the definition of what constitutes a successful product. By the end of 2012, over 400 million iOS devices had been sold.

What makes iOS devices so successful? Innovation and product features are clearly a big part. Before the iPhone most people had not interacted with a multi-touch interface. They had never zoomed with a pinch or switched between portrait and landscape by merely rotating a device in their hand. Carrying a phone that knew where they were, could suggest places to eat, and could offer directions on how to get there was also a novel experience.

But features like multi-touch, accelerometers and GPS are only part of the appeal. Even with all its innovations, iOS still might not have taken off the way it has if the only people figuring out ways to use those innovations worked at Apple. Most of the capabilities available in an iPhone or iPad in fact don’t come from Apple at all. They come from legions of third-party developers who work in a vast ecosystem that is also an Apple innovation. That ecosystem includes the iPhone, iPad, iPad Mini, iPods, App Store, iTunes, ad networks — and that’s just on the consumer side. On the developer side, you have Xcode, App Loader, testing tools, iTunes Connect — the list goes on.

As of September 2012, the App Store hosted over 700,000 apps that have collectively been downloaded over 30 billion times. Apple reported for October 2012 that App Store monthly revenues were

running at $333 million — a rate of about $4 billion per year — remarkable for a store that only opened in July 2008.

Another innovation that has spurred iOS app development is “The Cloud.” Cloud services make it easier for independent developers to create, support and make money from their apps. The Cloud solves data storage and cross-device and user-to-user sharing problems. If an app stores data in the Cloud, that part of the application is called the “backend,” while the part of the app that runs on the phone and interacts with the user is called the “front end.”

A cloud may be “private” — i.e., the services belong to an organization for the benefit of its employees and business partners. Or a cloud may be “public” — i.e., a company (such as Amazon or Kinvey) owns the services, which developers can then integrate into their own apps. If you are a developer and want to build your own backend, you certainly can do that. Whether you want to or not depends on whether your backend provides functionality common to many different apps. If it does (as in a shopping cart or user authenti-cation) then perhaps that time and money would be better spent on features that offer unique value to your customer. You may be better off hooking into a commercial backend provider via an API. Then you can focus on what counts most — a unique user experience and application-specific functionality. That brings us to the first step in making an app.

Define your appMost unsuccessful apps fail for any of four reasons:

1. the app was a solution in search of a problem (i.e., no real need existed) 2. the implementation was poor 3. the app tried to do too much; or 4. the Apple App Store rejected the app (either because the implementation was poor or it violated Apple’s content policies)

Keeping the app as simple as possible is the best way to avoid these pitfalls. Most successful apps (indeed, most successful consumer tech products) are based on what is called an MVP, or minimum viable product. It’s the product with the smallest feature set that can deliver the core function without any distracting “bells and whistles.” You know you have an MVP if the product would no longer function if you removed any single feature.

But what should that core feature be? One of the best examples of an MVP is Mail. Version 1 (on the Mac) offered a clear, limited and intuitive feature set whose usefulness was immediately obvious to anyone. Today’s iPhone version integrates seamlessly with your phone, contacts and calendaring. It auto-matically corrects spelling as you type, lets you email photos directly from your photos app, and does much more. But all that came later and was built on top of a basic core function. And that’s how your first app should be built. The key is to come up with something with a clear value that changes people’s lives.

So, in drawing up your MVP feature list, ask yourself what features are key to the experience. Some basic market research is probably in order, starting with a visit to the App Store to see what already exists (possibly to be improved upon and/or to compete with you). Likely

must-have core capabilities include:

• Performance (e.g., fast screen refresh)• Offline capability (i.e., ability to work when not connected to the Internet)• Location awareness (e.g., the data/experience will change with the user’s location)• Cloud syncing (e.g., users see the same data on multiple devices)• Push notifications (i.e., sending updated information to devices as soon as it is available)

When you have a handle on what your app does, the next step is to design it. Designing your app involves making choices of how infor-mation and controls are presented to the user as well as how to implement app logic, and figuring out what data lives locally and what belongs in the Cloud.

Design your appUser experience decisions determine the app’s look and feel. They answer questions such as: What does the app look like? What screens does it have? In the software development world, onscreen objects like buttons, sliders, and fill-in boxes are called widgets. So you need to decide which types of widgets will reside on which screens. And what actions will occur as a result of the user interacting with those widgets?

Keep in mind that users will expect to interact differently with a mobile device than they do with a PC because the screens on mobile devices are much smaller. They’ll expect to use their fingers instead of a mouse or a track pad. Ideally, your app can even be used with one hand holding the device while using just a thumb for scrolling andworking the app’s other controls— the Path app is a good example, and increasingly, so is Facebook.

Your app’s features will inform its architecture, which is how you’ll divide the code and data into functional parts. If your app requires interacting with other app users or networked services, you’ll need to figure out what piece of the logic lives in the app code and what comes from the backend. For example, your app might integrate with a restau-rant recommendation engine, share user location, or pull real-time traffic data. This is done using APIs provided by various service providers — but you don’t have to wire up your app to a network to get started. You can develop a prototype using predefined representative (or “dummy”) data. It’s easier to fine-tune the front end if you don’t have to simultaneously modify your backend too. Once you get the app’s look-and-feel right, then make those backend connections.

Once you’ve got the overall concept for your app, the next step is to express that design in terms of the iOS app architecture. That archi-tecture is the model for what parts an iOS app can contain and how those parts fit together. It’s a well thought-out approach for translat-ing a product concept into actual code you can deploy on a device.

WHY iOS?Besides the features and design of your first app, there’s one more decision you need to make before you start actual development. That’s whether to deploy on Apple’s iOS platform or on Google’s Android platform. (Some of this is also covered in our ebook, How to Make an App: Android Edition.) Reasons to develop for iOS include:

Customers more willing to pay. Perhaps it’s because of Android’s open source heritage, but whatever the reason, Android apps gener-ate less than 10% of the total dollars spent on mobile apps, despite having 75% of the smartphone market itself — and despite the fact that the average selling price of an app in the Google Play is $3.79 versus Apple App Store’s $2.01. In other words, Apple users are much more willing to spend money on apps.

The Apple Ecosystem. Some developers and users prefer Apple’s closed and more tightly controlled environment. Apple’s ecosystem, consisting of Xcode, iCloud, iTunes, the App Store, the iPad, the iPhone, Mac computers, etc., offers a very holistic user experience with the ability to share data seamlessly across devices plus the

assurance of having applications pre-approved for quality and content prior to going on sale.

Xcode. Apple’s all-in-one IDE offers state-of-the-art offers features like a graphical interface builder and a syntax-aware and compiler-aware source editor.

The Apple Experience. From the fit and finish of its hardware to the customer service in its retail stores, to the way its hardware and software work flawlessly together, Apple has created the premium brand in consumer electronics. iOS developers share the benefits — so when someone downloads your iOS app, they already expect it’s a great product. And that it will also work flawlessly on their device.

Tablets. iOS has a clear advantage over Android in terms of tablet market adoption. Using Xcode, it’s also much easier to migrate an app from a phone to a tablet and vice versa than it is when develop-ing for Android.

Why Not iOS?Although iOS offers many compelling advantages as a platform for your mobile app, it also comes with some disadvantages. Here are three:

Closed Platform. iOS apps only run on Apple products so you can’t take advantage of features (like NFC) available only on non-iOS devices or market growth of non-iOS devices.

Market Growth. Today, iOS represents less than 15% of the total smartphone market, Although the total market (“the whole pie”) is still increasing at a fast rate, Android market growth outpaces iOS growth.

Approvals. The App Store’s app approval process is notoriously more time consuming than Google Play’s process.

The iOS app architectureAs noted earlier, a key reason why there are so many apps for iOS is because developing highly functional, polished apps for the platform is relatively easy. That’s mainly because of: 1) the design of the development tools, and 2) the key architectural features most iOS apps have in common. So let’s start with some concepts since it helps to know what goes into an app before trying to create one. We’ll begin with:

• Design patterns• Frameworks• Delegation• Storyboard• Windows• Outlets• Supporting files• Products

Design patterns. iOS apps implement what is known as a Mod-el-View-Controller (MVC) pattern. A pattern is a common way to structure code that solves a particular design problem. The MVC pattern separates application code in a way that allows you to easily change one part of an app without having to change other parts. An MVC pattern consists of three components:

• The Model is the logic that acts on the data, such as to store or retrieve data from a database, compute the distance between two cities on a map, etc. An example of a model is the Kinvey backend that stores your data in the Cloud as a service.

• The View provides the interface to the user; it displays the data and widgets (e.g., buttons and text fields) that allow the user to interact with the data. An iPhone app may have more than one view, as in the Contacts app, which displays a list view of all contacts or alternatively a view of each individual contact.

• The Controller is between the model and the view — i.e., it responds to user requests (made in a view) and retrieves results

(produced in a model). This is where developers spend most of their time — constructing the View Controller — by defining and attaching actions (or behaviors) to onscreen widgets. When the user taps a button, for example, it is the View Controller that determines what action will occur, such as retrieve stored data from your Kinvey-based data store. The link between a view object (like a button) to a controller action is called a connection.

Frameworks. You don’t actually have to write most of an app’s logic. It already exists as frameworks. A framework is a collection of classes that implements some function — such as connecting to the Internet, drawing a button, etc. Rather than write the code from scratch, you just use the frameworks supplied by iOS. Some frameworks are automatically present when you start a new project while others may need to be added (done via a drop down menu in Xcode’s Project Editor).

Delegation. Say, you want to customize the behavior of a framework’s object. You can’t actually modify the code of the framework class itself (prohibited since other apps may also use the framework). But what you can do is provide app-specific behavior in an application delegate object. If a delegate implements a method, it will be called by the delegating class to modify its behavior. In the Kinvey sample app (one of two examples we will be describing below), the AppDele-gate.h and AppDelegate.m — the header and implementation files for the UIApplicationDelegate, respectively — contain the code that authenticates an app to the Kinvey backend service.

Storyboards and XIBs. The MainStoryboard.storyboard file (or a .xib file, if you did not click on the “Use Storyboard” option when starting your project) contains the view information needed to implement the overall flow and display of your application and the user interface elements.

Windows. Each view (e.g., the contact list and individual contact details in the Contacts app) exists within a window. The window represents the entire device screen and is where all your views are presented.

Outlets. A variable by which a view object can be referenced in a controller. (For example, if you place a text field to capture a user's name, you might create an outlet called UITextField* nameField.)

Supporting files. These are files that provide resources (like PNG images and other static data) that your app needs as well as files that configure how the app will run. Other examples:

.pch files — precompiled headers used for the code files in your project.

.plist files — property lists that are small amounts of persistent data (like your app’s default user settings) consisting primarily of strings and numbers that you want your app to be able to access, modify if needed, and write back into the property list.

main.m file — your app’s main function. This is needed to launch the app, but you will not need to modify this file.

InfoPlist.strings file — used for localization.

Products. This is the file for your app (i.e., YourProduct.app) that is built when you click Xcode’s “run” button.

“Making an iOS app” involves working with these features in the typical, straightforward workflow:

• Storyboard your views by dragging and configuring graphicalobjects on a template

• Adding behaviors to the various widgets• Writing the classes as to define those behaviors (including

delegates)• Adding needed support files• Building and running the app• Iterating until you are satisfied with your app

This is all done within Xcode.

What’s Xcode?You can start developing functional, good-looking apps almost from the moment you download Xcode, Apple’s integrated development environment (IDE) for making iOS and Macintosh apps. Among other features, Xcode includes a source code editor, graphical user inter-face (GUI) editor (sometimes called Interface Builder), source code repository manager, compiler, and much more. iOS applications are typically developed by manipulating views graphically and by typing Objective-C code for the models and controllers.

To get Xcode, simply go to the App Store and download the applica-tion (it’s free). To do this, click on the App Store icon in your Mac’s dock, or visit https://itunes.apple.com/us/genre/ios/id36?mt=8

The app store will download and install Xcode in your Application folder. From Applications, double-click the Xcode icon to launch Xcode and you’ll see its splash screen (Figure 1). From there you can click on “Create a new Xcode project” to take you to a menu of several templates on which to base your application. Selecting a template opens an Xcode workspace pre-populated with frameworks and other files Xcode thinks you will need using that template.

Although you can develop, build and simulate your app on your computer in Xcode, you can’t run your app on a target device (even your own iPhone) until you become a registered iOS developer and join the iOS Developer Program. To do that, go to develop-er.app.com/ and navigate to the iOS Dev Center. While there, you will also find documentation, sample code and other useful resources such as information on how to submit your app to the iOS App Store.

Everything you do in Xcode is done in a window, called a workspace (Figure 2), consisting of multiple work areas, some of which are also divided into panes. All the files needed to build your app belong to a project, and the Navigator area (far left) lists all your projects (there can be several in a workspace) and all files for each project. Clicking on a file in the Navigator area shows its contents in the Editor area and invokes the appropriate editor. Clicking on a .h or .m file, for example, shows the file’s source code and invokes the Source editor, so you can edit the code. Clicking on .storyboard or .xib (sometimes called a “nib”) file shows the app’s storyboard and invokes the Inter-face Builder, so you can design a view using the Builder’s drag and drop features.

An especially handy feature is that the Editor area can have both a right and a left pane — with each pane aware of your edits in the other. So, for example, you can simultaneously edit an object’s .h

header file in the left pane and its corresponding .m in the right pane. Or you might click on a button object (displayed graphically) in the left pane and edit its method’s source code in the right pane. To toggle between a single pane (the “Standard Editor”) and double pane view (the “Assistant Editor”), use the Editor selector button on the right of the toolbar. You can option+command+click a symbol in the editor to open the definition in the opposite editor pane.

You can also resize the entire Editor area simply by dragging its borders. For even more editing space, you can also remove the Debug area or both the Debug and Utility areas using the View Selector button on the far right of the toolbar.

As its name suggests, the Debug area shows information, like variable state and console logs, helpful in debugging code.

The Utility area has two panes: the Inspector and Quick Help pane (top) and the Library pane (bottom). Although there are five inspectors — File, Help, Identity, Attributes, Size and Connec-tions — only the inspectors that are currently relevant appear in the Inspec-tor list at the top of the pane. (To see the name of an inspector, move the cursor over its icon in the Inspector selector bar.)

You will use inspectors to add and modify object attributes for views in the Interface Builder. For example, if you click on a UILabel in the Editor area of a storyboard, you can use the Attributes inspector to change the label’s color and use the Size inspector to change the label’s size.

The Help inspector shows help information about a selected class. Use the Identity inspector to view and manage an object’s metadata such as its class, runtime attributes, label and so forth. Use the

Connections inspector to view the outlets and actions of an interface object, to make new connections and to delete existing connections.

The Library pane has libraries of resources (like file templates, code snippets, interface objects and media files) that are prebuilt and ready to insert into your project. Use the Library selector to select which of these libraries (e.g., code snippets or interface objects) you wish to insert. To insert one, drag it directly into your storyboard while using the Interface Builder editor.

These are basics you need to know to get started using Xcode to build your first app. But to really understand how it’s done, it helps to walk through an actual app or two. Let’s start with a simple “Hello World” app that does not employ a backend connection, and then look at a somewhat more functional app that does.

“Hello World!” sample appThis app displays a button (“Press Me”) and a label (“Label”) so that when the user presses the button the text of the label changes to “Hello World!” as in Figure 3:

To get started, launch Xcode and select “Create a New Xcode Project.” From the iOS Application templates, select “Single View Application” and click “Next.” Fill in your product’s name and a company identifier, typically “com.yourCompanyName.” Deselect “Use Storyboards” and leave “Use Automatic Reference Counting” selected. Then click “Next” and select a destination for your projects files.

Follow these steps to make your app:

1. Select your project’s ViewController.xib file in the Navigator(Figure 4), to open the Interface Builder editor.

2. Drag a “Round Rect Button” from the Objects library (lowerright) onto the view in the Editor area; select the button’s textand type “Press Me.”

3. Drag a Label from the objects library onto the view, as well.4. Select and drag the Label sizing handles, centering the object

and making it wide enough to hold the “Hello World!” text; then,

5. With the “Hello World!” label still selected, click on centeralignment in the Attributes inspector.

6. Open the Assistant Editor (Figure 5), exposing the source codeheader file (ViewController.h) of the view controller you justbuilt graphically.

7. Select the button and control-drag from the button to justbelow the ViewController definition in the Assistant panel. Inthe form that opens, select “Action” for the connection type,type in a name (“showText”) and click “Connect.” This creates aninterface builder (IB) action as highlighted in Figure 6.

8. Next step is to create an outlet for the label. To do this, selectthe label object and control-drag from the label to just belowthe IB action you just created. Select “Outlet” as the connectiontype and enter a name “label” and click “Connect.” This createsan interface builder (IB) outlet as shown in Figure 7.

9. Finally, it’s time to add some logic to the view controller so itknows what to do when the button is pressed. To do this, select “ViewController.m” in the project navigator to show the code editor. Find the button’s IBAction you just created (near the bottom), place your cursor between the { } brackets and hit the return key a few times to create some extra space. Then in that space type the method for how you want the label you speci-fied to respond: _label.text=”Hello World!”; as highlighted in Figure 8.

Congratulations! Your app is done. To build and run your new app in the simulator, click the Xcode Run button in the left corner of the toolbar. When you click the button, the text will update.

Sample app with a backend This second app (named “Kinvey Test Drive”) lets the user type text on an iPhone and save the text to a backend service, like Kinvey. It also lets the user load text on the iPhone from their Kinvey backend. Reading about this app will help you learn:

• How to set up Kinvey’s library in an iOS project• Additional Interface Builder techniques you can use to story-board an application• How to add view controller logic to interact with the backend service, allowing you to save and retrieve data

We will first present the app as a running application and then take it apart so you can see how it was made. To make the app yourself, you can review the various sections below and replicate the steps in your copy of Xcode.

First, to see the app in action, you should download the app and run it on your system. To do that, sign up for Kinvey, then navigate to “Dev Center”, “Samples,” find the “Test Drive” app, and click on its icon. (If you can’t find it right away, make sure you select iOS as your platform on the right side of the menu bar.) Click the download button to download the app’s project files to your computer. Then launch Xcode — just double click on the .xcodeproj file in the project folder.

But before you can run the app, you need to set up the app’s Kinvey backend.

Set Up Kinvey as a Backend Data StoreTest Drive’s project files include all the code the sample app needs in order to talk to Kinvey. However, that would not be the case if you were to build an app from scratch — so you would have to go through an initial Kinvey setup procedure. This involves downloading the Kinvey library files from the downloads section of devcenter.kin-vey.com and dragging them to the Navigator’s Frameworks folder in Xcode. You also need to tell Xcode to link your project with additional iOS frameworks. To find these frameworks, click on the Project folder

at the very top of the Navigator pane — which displays the Project editor — and then select the “Build Settings” tab. For detailed instruc-tions, complete the “Getting Started” page under “Guides” on the Kinvey website. But again, you can skip this setup procedure for now in order to run the downloaded Kinvey Test Drive app.

But you must still do this step: To run any app that uses Kinvey (including Test Drive) you need to do the “Create an App” step on the Kinvey website. Click on “My Apps” in the Kinvey menu bar and then click on “Add an App,” which will open an “Add” page. Type in a name for your app and click on the Apple logo and then click “Create.” The page that opens shows your App’s credentials. Copy and paste the App Key and App Secret into the AppDelegate.m file of the download-ed Test Drive project:

You are now ready to run the app — click on the Xcode run button and wait for the simulator to open and the app to appear (Figure 9).

Clicking the “+” toolbar button opens an alert (Figure 10) with an empty field into which the user can type some text (e.g., “some new data”). Clicking “save” uploads the data to Kinvey and displays text on the screen (a table view) and also displays an alert that the save worked (Figure 11).

To test the load function, enter some data (e.g., “some data to load”) in the “name” field of the Kinvey collection. To see the load, the swipe down on the table on the phone until the refresh spinner starts, and then the new data will appear in the table (Figure 12).

Figure 13 shows the Kinvey collection after the save that Figure 10 depicts on the iPhone. Figure 14 shows the Kinvey collection after the user adds a new row to the testObjects collection using the web browser. Note that every time a save is done on the iPhone, Kinvey automatically adds a new row (displayed on a collection refresh). To add a new row manually in the browser, click “+ row,” and type some descriptive text in the “name” column. That data will now load on the iPhone when the user pulls down on the table.

Storyboard the Test Drive AppMost of the Test Drive user interface objects visible in the simulation are available in Xcode’s Object Library and can therefore be added to the view graphically. The UI objects consist of a:

• Table view• Toolbar• Tool Bar Button item – flexible space• Tool Bar Button item – Add• Table view cell• Label – Title• Refresh Control

To create this app yourself, you would follow these steps:

• Launch Xcode and select the “Single View Application” template• Select the “Use Storyboard” option• Replace the default UIviewcontroller object with a UITableView-Controller • Drag and drop the other objects, in the order listed, onto the UIviewcontroller

Also note:

• The Flexible Space Bar Button item fills up the space on the toolbar so the add button is at the right. This is a standard pattern in table-based iPhone apps.• The add button shows the system “+” sign. That is done by dragging a bar button item onto the toolbar, clicking on the Identifier drop down menu in the Attributes inspector; and then selecting the “Add” option.

As with the “Hello World!” app, once your app’s view is complete (Figure 15), you would still have to create the various methods and connections that bring them to life. This is done using the Source editor while working with the ViewController.m file.

Add View Controller LogicSince the app performs two basic operations (save data to Kinvey and load data from Kinvey) these two methods must be added to the ViewController header file. That’s done with a control-drag from the “+” bar button over to just under the “@ interface ViewController” line in ViewController.h. (Open the Assistant editor to see both the storyboard and the file source.)

During the drag, the popup appears, asking for the name and type of connection. Enter “action” for the connection type and “add” for the name. Then repeat the drag, this time from the refresh control and using “add” for the name (Figure 16).

Note: to follow this discussion it will help to have the referenced files open in your Xcode Source editor.

In ViewController.m, you will see the implementation code associated with each of the two Interface Builder methods, whose names Xcode added automatically to the .m file:

- (IBAction)add:(id)sender- (IBAction)load:(id)sender

You will also see a third section of code not associated with these methods, which starts with the line: “#pragma mark - Table View Stuff.” These methods support the table view and are part of UITableViewD-elegate and UITableViewDataSource. They handle controlling the

display of the table, and respond to user gestures. For example, swiping a table cell will show the delete button because tableView:-canEditRowAtIndexPath: returns YES and tableView:editingStyleForRowA-tIndexPath: returns UITableViewCellEditingStyleDelete. If you tap the delete button, the delegate method tableView:commitEditingStyle:for-RowAtIndexPath: is called. The code of this method deletes the data for the row and removes it from Kinvey’s data store. When the backend delete is completed, the app displays an alert describing the success or failure.

The way that all three sections (and all Kinvey-enabled apps) move data in and out of a Kinvey collection is by getting a reference to the app’s backend collection (named “testObjects”), which is filled with instances (each named “TestObject”) of the data the app wants to move. That’s why you’ll find the following code repeated three times in Test Drive’s View Controller (once for the add, once for the load, and once for the delete):

To support these statements it is required to have a data object class (TestObject). To see how these files are written in the sample project, click on TestObject.h file and TestObject.m in the Navigator pane. If you were to supply these files in your own app, you would click File > New File, and specify Objective-C class, which would be a subclass of NSObject. Then you would type in the code, with a property for each column in the Kinvey backend collection (including one for the object’s id).

As mentioned earlier, your app also needs to authenticate itself to Kinvey, which is handled by AppDelegate.h and AppDelgate.m. These files are created by Xcode when you create a new project, and start out with just a stub implementation. Look in the sample app source

files for code to copy and paste.

For both the save and load operations, however, moving the data in and out of a backend collection is only part of the work. Table 1 lists all the functions that implements the save and load in the ViewCon-troller.m file, along with pointers to its corresponding block of imple-mentation source code. (For each function, its corresponding code begins with the “Starts at” line and ends with the “Ends at” line.) Refer to Appendix 1 to find the actual source code.

Say Hello To Our WorldThe key takeaway from all this is that “making an app” is a worthwhile thing to do for anyone with a clever idea and a working knowledge of Objective-C. The proof is in the hundreds of apps succeeding in the market every day, many written by people working on their own and who never wrote an app before in their lives. As with anything else, practice does make perfect. But hopefully with all the resources available, and the knowledge gained from this ebook, you have already started down the path toward joining the growing legions of iOS app developers. If so, we welcome you!

Appendix 1 — Test Drive Sample App ViewController.m Source Code

#import "AppDelegate.h"#import <KinveyKit/KinveyKit.h>

@implementation AppDelegate

- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions{ (void) [[KCSClient sharedClient] initializeKinveyServiceForAppKey:@"<#My App Key#>"

withAppSecret:@"<#My App Secret#>"usingOptions:nil];

return YES;}

30

The iOS revolutionIt’s a story that never gets old. The weekend that iPad Minis and the fourth generation iPads went on sale (November 2-5, 2012) Apple sold over 3 million of the devices — a record for first-weekend iPad sales. Two months earlier the company had set another record: first weekend sales of over 5 million for the iPhone 5. Since the introduc-tion of the first iPhone back in 2007,

iOS-based devices (iPhone, iPad, iPad Mini and iPod Touch) continue to rewrite the definition of what constitutes a successful product. By the end of 2012, over 400 million iOS devices had been sold.

What makes iOS devices so successful? Innovation and product features are clearly a big part. Before the iPhone most people had not interacted with a multi-touch interface. They had never zoomed with a pinch or switched between portrait and landscape by merely rotating a device in their hand. Carrying a phone that knew where they were, could suggest places to eat, and could offer directions on how to get there was also a novel experience.

But features like multi-touch, accelerometers and GPS are only part of the appeal. Even with all its innovations, iOS still might not have taken off the way it has if the only people figuring out ways to use those innovations worked at Apple. Most of the capabilities available in an iPhone or iPad in fact don’t come from Apple at all. They come from legions of third-party developers who work in a vast ecosystem that is also an Apple innovation. That ecosystem includes the iPhone, iPad, iPad Mini, iPods, App Store, iTunes, ad networks — and that’s just on the consumer side. On the developer side, you have Xcode, App Loader, testing tools, iTunes Connect — the list goes on.

As of September 2012, the App Store hosted over 700,000 apps that have collectively been downloaded over 30 billion times. Apple reported for October 2012 that App Store monthly revenues were

running at $333 million — a rate of about $4 billion per year — remarkable for a store that only opened in July 2008.

Another innovation that has spurred iOS app development is “The Cloud.” Cloud services make it easier for independent developers to create, support and make money from their apps. The Cloud solves data storage and cross-device and user-to-user sharing problems. If an app stores data in the Cloud, that part of the application is called the “backend,” while the part of the app that runs on the phone and interacts with the user is called the “front end.”

A cloud may be “private” — i.e., the services belong to an organization for the benefit of its employees and business partners. Or a cloud may be “public” — i.e., a company (such as Amazon or Kinvey) owns the services, which developers can then integrate into their own apps. If you are a developer and want to build your own backend, you certainly can do that. Whether you want to or not depends on whether your backend provides functionality common to many different apps. If it does (as in a shopping cart or user authenti-cation) then perhaps that time and money would be better spent on features that offer unique value to your customer. You may be better off hooking into a commercial backend provider via an API. Then you can focus on what counts most — a unique user experience and application-specific functionality. That brings us to the first step in making an app.

Define your appMost unsuccessful apps fail for any of four reasons:

1. the app was a solution in search of a problem (i.e., no real need existed) 2. the implementation was poor 3. the app tried to do too much; or 4. the Apple App Store rejected the app (either because the implementation was poor or it violated Apple’s content policies)

Keeping the app as simple as possible is the best way to avoid these pitfalls. Most successful apps (indeed, most successful consumer tech products) are based on what is called an MVP, or minimum viable product. It’s the product with the smallest feature set that can deliver the core function without any distracting “bells and whistles.” You know you have an MVP if the product would no longer function if you removed any single feature.

But what should that core feature be? One of the best examples of an MVP is Mail. Version 1 (on the Mac) offered a clear, limited and intuitive feature set whose usefulness was immediately obvious to anyone. Today’s iPhone version integrates seamlessly with your phone, contacts and calendaring. It auto-matically corrects spelling as you type, lets you email photos directly from your photos app, and does much more. But all that came later and was built on top of a basic core function. And that’s how your first app should be built. The key is to come up with something with a clear value that changes people’s lives.

So, in drawing up your MVP feature list, ask yourself what features are key to the experience. Some basic market research is probably in order, starting with a visit to the App Store to see what already exists (possibly to be improved upon and/or to compete with you). Likely

must-have core capabilities include:

• Performance (e.g., fast screen refresh)• Offline capability (i.e., ability to work when not connected to the Internet)• Location awareness (e.g., the data/experience will change with the user’s location)• Cloud syncing (e.g., users see the same data on multiple devices)• Push notifications (i.e., sending updated information to devices as soon as it is available)

When you have a handle on what your app does, the next step is to design it. Designing your app involves making choices of how infor-mation and controls are presented to the user as well as how to implement app logic, and figuring out what data lives locally and what belongs in the Cloud.

Design your appUser experience decisions determine the app’s look and feel. They answer questions such as: What does the app look like? What screens does it have? In the software development world, onscreen objects like buttons, sliders, and fill-in boxes are called widgets. So you need to decide which types of widgets will reside on which screens. And what actions will occur as a result of the user interacting with those widgets?

Keep in mind that users will expect to interact differently with a mobile device than they do with a PC because the screens on mobile devices are much smaller. They’ll expect to use their fingers instead of a mouse or a track pad. Ideally, your app can even be used with one hand holding the device while using just a thumb for scrolling andworking the app’s other controls— the Path app is a good example, and increasingly, so is Facebook.

Your app’s features will inform its architecture, which is how you’ll divide the code and data into functional parts. If your app requires interacting with other app users or networked services, you’ll need to figure out what piece of the logic lives in the app code and what comes from the backend. For example, your app might integrate with a restau-rant recommendation engine, share user location, or pull real-time traffic data. This is done using APIs provided by various service providers — but you don’t have to wire up your app to a network to get started. You can develop a prototype using predefined representative (or “dummy”) data. It’s easier to fine-tune the front end if you don’t have to simultaneously modify your backend too. Once you get the app’s look-and-feel right, then make those backend connections.

Once you’ve got the overall concept for your app, the next step is to express that design in terms of the iOS app architecture. That archi-tecture is the model for what parts an iOS app can contain and how those parts fit together. It’s a well thought-out approach for translat-ing a product concept into actual code you can deploy on a device.

WHY iOS?Besides the features and design of your first app, there’s one more decision you need to make before you start actual development. That’s whether to deploy on Apple’s iOS platform or on Google’s Android platform. (Some of this is also covered in our ebook, How to Make an App: Android Edition.) Reasons to develop for iOS include:

Customers more willing to pay. Perhaps it’s because of Android’s open source heritage, but whatever the reason, Android apps gener-ate less than 10% of the total dollars spent on mobile apps, despite having 75% of the smartphone market itself — and despite the fact that the average selling price of an app in the Google Play is $3.79 versus Apple App Store’s $2.01. In other words, Apple users are much more willing to spend money on apps.

The Apple Ecosystem. Some developers and users prefer Apple’s closed and more tightly controlled environment. Apple’s ecosystem, consisting of Xcode, iCloud, iTunes, the App Store, the iPad, the iPhone, Mac computers, etc., offers a very holistic user experience with the ability to share data seamlessly across devices plus the

assurance of having applications pre-approved for quality and content prior to going on sale.

Xcode. Apple’s all-in-one IDE offers state-of-the-art offers features like a graphical interface builder and a syntax-aware and compiler-aware source editor.

The Apple Experience. From the fit and finish of its hardware to the customer service in its retail stores, to the way its hardware and software work flawlessly together, Apple has created the premium brand in consumer electronics. iOS developers share the benefits — so when someone downloads your iOS app, they already expect it’s a great product. And that it will also work flawlessly on their device.

Tablets. iOS has a clear advantage over Android in terms of tablet market adoption. Using Xcode, it’s also much easier to migrate an app from a phone to a tablet and vice versa than it is when develop-ing for Android.

Why Not iOS?Although iOS offers many compelling advantages as a platform for your mobile app, it also comes with some disadvantages. Here are three:

Closed Platform. iOS apps only run on Apple products so you can’t take advantage of features (like NFC) available only on non-iOS devices or market growth of non-iOS devices.

Market Growth. Today, iOS represents less than 15% of the total smartphone market, Although the total market (“the whole pie”) is still increasing at a fast rate, Android market growth outpaces iOS growth.

Approvals. The App Store’s app approval process is notoriously more time consuming than Google Play’s process.

The iOS app architectureAs noted earlier, a key reason why there are so many apps for iOS is because developing highly functional, polished apps for the platform is relatively easy. That’s mainly because of: 1) the design of the development tools, and 2) the key architectural features most iOS apps have in common. So let’s start with some concepts since it helps to know what goes into an app before trying to create one. We’ll begin with:

• Design patterns• Frameworks• Delegation• Storyboard• Windows• Outlets• Supporting files• Products

Design patterns. iOS apps implement what is known as a Mod-el-View-Controller (MVC) pattern. A pattern is a common way to structure code that solves a particular design problem. The MVC pattern separates application code in a way that allows you to easily change one part of an app without having to change other parts. An MVC pattern consists of three components:

• The Model is the logic that acts on the data, such as to store or retrieve data from a database, compute the distance between two cities on a map, etc. An example of a model is the Kinvey backend that stores your data in the Cloud as a service.

• The View provides the interface to the user; it displays the data and widgets (e.g., buttons and text fields) that allow the user to interact with the data. An iPhone app may have more than one view, as in the Contacts app, which displays a list view of all contacts or alternatively a view of each individual contact.

• The Controller is between the model and the view — i.e., it responds to user requests (made in a view) and retrieves results

(produced in a model). This is where developers spend most of their time — constructing the View Controller — by defining and attaching actions (or behaviors) to onscreen widgets. When the user taps a button, for example, it is the View Controller that determines what action will occur, such as retrieve stored data from your Kinvey-based data store. The link between a view object (like a button) to a controller action is called a connection.

Frameworks. You don’t actually have to write most of an app’s logic. It already exists as frameworks. A framework is a collection of classes that implements some function — such as connecting to the Internet, drawing a button, etc. Rather than write the code from scratch, you just use the frameworks supplied by iOS. Some frameworks are automatically present when you start a new project while others may need to be added (done via a drop down menu in Xcode’s Project Editor).

Delegation. Say, you want to customize the behavior of a framework’s object. You can’t actually modify the code of the framework class itself (prohibited since other apps may also use the framework). But what you can do is provide app-specific behavior in an application delegate object. If a delegate implements a method, it will be called by the delegating class to modify its behavior. In the Kinvey sample app (one of two examples we will be describing below), the AppDele-gate.h and AppDelegate.m — the header and implementation files for the UIApplicationDelegate, respectively — contain the code that authenticates an app to the Kinvey backend service.

Storyboards and XIBs. The MainStoryboard.storyboard file (or a .xib file, if you did not click on the “Use Storyboard” option when starting your project) contains the view information needed to implement the overall flow and display of your application and the user interface elements.

Windows. Each view (e.g., the contact list and individual contact details in the Contacts app) exists within a window. The window represents the entire device screen and is where all your views are presented.

Outlets. A variable by which a view object can be referenced in a controller. (For example, if you place a text field to capture a user's name, you might create an outlet called UITextField* nameField.)

Supporting files. These are files that provide resources (like PNG images and other static data) that your app needs as well as files that configure how the app will run. Other examples:

.pch files — precompiled headers used for the code files in your project.

.plist files — property lists that are small amounts of persistent data (like your app’s default user settings) consisting primarily of strings and numbers that you want your app to be able to access, modify if needed, and write back into the property list.

main.m file — your app’s main function. This is needed to launch the app, but you will not need to modify this file.

InfoPlist.strings file — used for localization.

Products. This is the file for your app (i.e., YourProduct.app) that is built when you click Xcode’s “run” button.

“Making an iOS app” involves working with these features in the typical, straightforward workflow:

• Storyboard your views by dragging and configuring graphicalobjects on a template

• Adding behaviors to the various widgets• Writing the classes as to define those behaviors (including

delegates)• Adding needed support files• Building and running the app• Iterating until you are satisfied with your app

This is all done within Xcode.

What’s Xcode?You can start developing functional, good-looking apps almost from the moment you download Xcode, Apple’s integrated development environment (IDE) for making iOS and Macintosh apps. Among other features, Xcode includes a source code editor, graphical user inter-face (GUI) editor (sometimes called Interface Builder), source code repository manager, compiler, and much more. iOS applications are typically developed by manipulating views graphically and by typing Objective-C code for the models and controllers.

To get Xcode, simply go to the App Store and download the applica-tion (it’s free). To do this, click on the App Store icon in your Mac’s dock, or visit https://itunes.apple.com/us/genre/ios/id36?mt=8

The app store will download and install Xcode in your Application folder. From Applications, double-click the Xcode icon to launch Xcode and you’ll see its splash screen (Figure 1). From there you can click on “Create a new Xcode project” to take you to a menu of several templates on which to base your application. Selecting a template opens an Xcode workspace pre-populated with frameworks and other files Xcode thinks you will need using that template.

Although you can develop, build and simulate your app on your computer in Xcode, you can’t run your app on a target device (even your own iPhone) until you become a registered iOS developer and join the iOS Developer Program. To do that, go to develop-er.app.com/ and navigate to the iOS Dev Center. While there, you will also find documentation, sample code and other useful resources such as information on how to submit your app to the iOS App Store.

Everything you do in Xcode is done in a window, called a workspace (Figure 2), consisting of multiple work areas, some of which are also divided into panes. All the files needed to build your app belong to a project, and the Navigator area (far left) lists all your projects (there can be several in a workspace) and all files for each project. Clicking on a file in the Navigator area shows its contents in the Editor area and invokes the appropriate editor. Clicking on a .h or .m file, for example, shows the file’s source code and invokes the Source editor, so you can edit the code. Clicking on .storyboard or .xib (sometimes called a “nib”) file shows the app’s storyboard and invokes the Inter-face Builder, so you can design a view using the Builder’s drag and drop features.

An especially handy feature is that the Editor area can have both a right and a left pane — with each pane aware of your edits in the other. So, for example, you can simultaneously edit an object’s .h

header file in the left pane and its corresponding .m in the right pane. Or you might click on a button object (displayed graphically) in the left pane and edit its method’s source code in the right pane. To toggle between a single pane (the “Standard Editor”) and double pane view (the “Assistant Editor”), use the Editor selector button on the right of the toolbar. You can option+command+click a symbol in the editor to open the definition in the opposite editor pane.

You can also resize the entire Editor area simply by dragging its borders. For even more editing space, you can also remove the Debug area or both the Debug and Utility areas using the View Selector button on the far right of the toolbar.

As its name suggests, the Debug area shows information, like variable state and console logs, helpful in debugging code.

The Utility area has two panes: the Inspector and Quick Help pane (top) and the Library pane (bottom). Although there are five inspectors — File, Help, Identity, Attributes, Size and Connec-tions — only the inspectors that are currently relevant appear in the Inspec-tor list at the top of the pane. (To see the name of an inspector, move the cursor over its icon in the Inspector selector bar.)

You will use inspectors to add and modify object attributes for views in the Interface Builder. For example, if you click on a UILabel in the Editor area of a storyboard, you can use the Attributes inspector to change the label’s color and use the Size inspector to change the label’s size.

The Help inspector shows help information about a selected class. Use the Identity inspector to view and manage an object’s metadata such as its class, runtime attributes, label and so forth. Use the

Connections inspector to view the outlets and actions of an interface object, to make new connections and to delete existing connections.

The Library pane has libraries of resources (like file templates, code snippets, interface objects and media files) that are prebuilt and ready to insert into your project. Use the Library selector to select which of these libraries (e.g., code snippets or interface objects) you wish to insert. To insert one, drag it directly into your storyboard while using the Interface Builder editor.

These are basics you need to know to get started using Xcode to build your first app. But to really understand how it’s done, it helps to walk through an actual app or two. Let’s start with a simple “Hello World” app that does not employ a backend connection, and then look at a somewhat more functional app that does.

“Hello World!” sample appThis app displays a button (“Press Me”) and a label (“Label”) so that when the user presses the button the text of the label changes to “Hello World!” as in Figure 3:

To get started, launch Xcode and select “Create a New Xcode Project.” From the iOS Application templates, select “Single View Application” and click “Next.” Fill in your product’s name and a company identifier, typically “com.yourCompanyName.” Deselect “Use Storyboards” and leave “Use Automatic Reference Counting” selected. Then click “Next” and select a destination for your projects files.

Follow these steps to make your app:

1. Select your project’s ViewController.xib file in the Navigator(Figure 4), to open the Interface Builder editor.

2. Drag a “Round Rect Button” from the Objects library (lowerright) onto the view in the Editor area; select the button’s textand type “Press Me.”

3. Drag a Label from the objects library onto the view, as well.4. Select and drag the Label sizing handles, centering the object

and making it wide enough to hold the “Hello World!” text; then,

5. With the “Hello World!” label still selected, click on centeralignment in the Attributes inspector.

6. Open the Assistant Editor (Figure 5), exposing the source codeheader file (ViewController.h) of the view controller you justbuilt graphically.

7. Select the button and control-drag from the button to justbelow the ViewController definition in the Assistant panel. Inthe form that opens, select “Action” for the connection type,type in a name (“showText”) and click “Connect.” This creates aninterface builder (IB) action as highlighted in Figure 6.

8. Next step is to create an outlet for the label. To do this, selectthe label object and control-drag from the label to just belowthe IB action you just created. Select “Outlet” as the connectiontype and enter a name “label” and click “Connect.” This createsan interface builder (IB) outlet as shown in Figure 7.

9. Finally, it’s time to add some logic to the view controller so itknows what to do when the button is pressed. To do this, select “ViewController.m” in the project navigator to show the code editor. Find the button’s IBAction you just created (near the bottom), place your cursor between the { } brackets and hit the return key a few times to create some extra space. Then in that space type the method for how you want the label you speci-fied to respond: _label.text=”Hello World!”; as highlighted in Figure 8.

Congratulations! Your app is done. To build and run your new app in the simulator, click the Xcode Run button in the left corner of the toolbar. When you click the button, the text will update.

Sample app with a backend This second app (named “Kinvey Test Drive”) lets the user type text on an iPhone and save the text to a backend service, like Kinvey. It also lets the user load text on the iPhone from their Kinvey backend. Reading about this app will help you learn:

• How to set up Kinvey’s library in an iOS project• Additional Interface Builder techniques you can use to story-board an application• How to add view controller logic to interact with the backend service, allowing you to save and retrieve data

We will first present the app as a running application and then take it apart so you can see how it was made. To make the app yourself, you can review the various sections below and replicate the steps in your copy of Xcode.

First, to see the app in action, you should download the app and run it on your system. To do that, sign up for Kinvey, then navigate to “Dev Center”, “Samples,” find the “Test Drive” app, and click on its icon. (If you can’t find it right away, make sure you select iOS as your platform on the right side of the menu bar.) Click the download button to download the app’s project files to your computer. Then launch Xcode — just double click on the .xcodeproj file in the project folder.

But before you can run the app, you need to set up the app’s Kinvey backend.

Set Up Kinvey as a Backend Data StoreTest Drive’s project files include all the code the sample app needs in order to talk to Kinvey. However, that would not be the case if you were to build an app from scratch — so you would have to go through an initial Kinvey setup procedure. This involves downloading the Kinvey library files from the downloads section of devcenter.kin-vey.com and dragging them to the Navigator’s Frameworks folder in Xcode. You also need to tell Xcode to link your project with additional iOS frameworks. To find these frameworks, click on the Project folder

at the very top of the Navigator pane — which displays the Project editor — and then select the “Build Settings” tab. For detailed instruc-tions, complete the “Getting Started” page under “Guides” on the Kinvey website. But again, you can skip this setup procedure for now in order to run the downloaded Kinvey Test Drive app.

But you must still do this step: To run any app that uses Kinvey (including Test Drive) you need to do the “Create an App” step on the Kinvey website. Click on “My Apps” in the Kinvey menu bar and then click on “Add an App,” which will open an “Add” page. Type in a name for your app and click on the Apple logo and then click “Create.” The page that opens shows your App’s credentials. Copy and paste the App Key and App Secret into the AppDelegate.m file of the download-ed Test Drive project:

You are now ready to run the app — click on the Xcode run button and wait for the simulator to open and the app to appear (Figure 9).

Clicking the “+” toolbar button opens an alert (Figure 10) with an empty field into which the user can type some text (e.g., “some new data”). Clicking “save” uploads the data to Kinvey and displays text on the screen (a table view) and also displays an alert that the save worked (Figure 11).

To test the load function, enter some data (e.g., “some data to load”) in the “name” field of the Kinvey collection. To see the load, the swipe down on the table on the phone until the refresh spinner starts, and then the new data will appear in the table (Figure 12).

Figure 13 shows the Kinvey collection after the save that Figure 10 depicts on the iPhone. Figure 14 shows the Kinvey collection after the user adds a new row to the testObjects collection using the web browser. Note that every time a save is done on the iPhone, Kinvey automatically adds a new row (displayed on a collection refresh). To add a new row manually in the browser, click “+ row,” and type some descriptive text in the “name” column. That data will now load on the iPhone when the user pulls down on the table.

Storyboard the Test Drive AppMost of the Test Drive user interface objects visible in the simulation are available in Xcode’s Object Library and can therefore be added to the view graphically. The UI objects consist of a:

• Table view• Toolbar• Tool Bar Button item – flexible space• Tool Bar Button item – Add• Table view cell• Label – Title• Refresh Control

To create this app yourself, you would follow these steps:

• Launch Xcode and select the “Single View Application” template• Select the “Use Storyboard” option• Replace the default UIviewcontroller object with a UITableView-Controller • Drag and drop the other objects, in the order listed, onto the UIviewcontroller

Also note:

• The Flexible Space Bar Button item fills up the space on the toolbar so the add button is at the right. This is a standard pattern in table-based iPhone apps.• The add button shows the system “+” sign. That is done by dragging a bar button item onto the toolbar, clicking on the Identifier drop down menu in the Attributes inspector; and then selecting the “Add” option.

As with the “Hello World!” app, once your app’s view is complete (Figure 15), you would still have to create the various methods and connections that bring them to life. This is done using the Source editor while working with the ViewController.m file.

Add View Controller LogicSince the app performs two basic operations (save data to Kinvey and load data from Kinvey) these two methods must be added to the ViewController header file. That’s done with a control-drag from the “+” bar button over to just under the “@ interface ViewController” line in ViewController.h. (Open the Assistant editor to see both the storyboard and the file source.)

During the drag, the popup appears, asking for the name and type of connection. Enter “action” for the connection type and “add” for the name. Then repeat the drag, this time from the refresh control and using “add” for the name (Figure 16).

Note: to follow this discussion it will help to have the referenced files open in your Xcode Source editor.

In ViewController.m, you will see the implementation code associated with each of the two Interface Builder methods, whose names Xcode added automatically to the .m file:

- (IBAction)add:(id)sender- (IBAction)load:(id)sender

You will also see a third section of code not associated with these methods, which starts with the line: “#pragma mark - Table View Stuff.” These methods support the table view and are part of UITableViewD-elegate and UITableViewDataSource. They handle controlling the

display of the table, and respond to user gestures. For example, swiping a table cell will show the delete button because tableView:-canEditRowAtIndexPath: returns YES and tableView:editingStyleForRowA-tIndexPath: returns UITableViewCellEditingStyleDelete. If you tap the delete button, the delegate method tableView:commitEditingStyle:for-RowAtIndexPath: is called. The code of this method deletes the data for the row and removes it from Kinvey’s data store. When the backend delete is completed, the app displays an alert describing the success or failure.

The way that all three sections (and all Kinvey-enabled apps) move data in and out of a Kinvey collection is by getting a reference to the app’s backend collection (named “testObjects”), which is filled with instances (each named “TestObject”) of the data the app wants to move. That’s why you’ll find the following code repeated three times in Test Drive’s View Controller (once for the add, once for the load, and once for the delete):

To support these statements it is required to have a data object class (TestObject). To see how these files are written in the sample project, click on TestObject.h file and TestObject.m in the Navigator pane. If you were to supply these files in your own app, you would click File > New File, and specify Objective-C class, which would be a subclass of NSObject. Then you would type in the code, with a property for each column in the Kinvey backend collection (including one for the object’s id).

As mentioned earlier, your app also needs to authenticate itself to Kinvey, which is handled by AppDelegate.h and AppDelgate.m. These files are created by Xcode when you create a new project, and start out with just a stub implementation. Look in the sample app source

files for code to copy and paste.

For both the save and load operations, however, moving the data in and out of a backend collection is only part of the work. Table 1 lists all the functions that implements the save and load in the ViewCon-troller.m file, along with pointers to its corresponding block of imple-mentation source code. (For each function, its corresponding code begins with the “Starts at” line and ends with the “Ends at” line.) Refer to Appendix 1 to find the actual source code.

Say Hello To Our WorldThe key takeaway from all this is that “making an app” is a worthwhile thing to do for anyone with a clever idea and a working knowledge of Objective-C. The proof is in the hundreds of apps succeeding in the market every day, many written by people working on their own and who never wrote an app before in their lives. As with anything else, practice does make perfect. But hopefully with all the resources available, and the knowledge gained from this ebook, you have already started down the path toward joining the growing legions of iOS app developers. If so, we welcome you!

Appendix 1 — Test Drive Sample App ViewController.m Source Code

fig. 9 fig. 10 fig. 11 fig. 12

Test Drive App views

31

The iOS revolutionIt’s a story that never gets old. The weekend that iPad Minis and the fourth generation iPads went on sale (November 2-5, 2012) Apple sold over 3 million of the devices — a record for first-weekend iPad sales. Two months earlier the company had set another record: first weekend sales of over 5 million for the iPhone 5. Since the introduc-tion of the first iPhone back in 2007,

iOS-based devices (iPhone, iPad, iPad Mini and iPod Touch) continue to rewrite the definition of what constitutes a successful product. By the end of 2012, over 400 million iOS devices had been sold.

What makes iOS devices so successful? Innovation and product features are clearly a big part. Before the iPhone most people had not interacted with a multi-touch interface. They had never zoomed with a pinch or switched between portrait and landscape by merely rotating a device in their hand. Carrying a phone that knew where they were, could suggest places to eat, and could offer directions on how to get there was also a novel experience.

But features like multi-touch, accelerometers and GPS are only part of the appeal. Even with all its innovations, iOS still might not have taken off the way it has if the only people figuring out ways to use those innovations worked at Apple. Most of the capabilities available in an iPhone or iPad in fact don’t come from Apple at all. They come from legions of third-party developers who work in a vast ecosystem that is also an Apple innovation. That ecosystem includes the iPhone, iPad, iPad Mini, iPods, App Store, iTunes, ad networks — and that’s just on the consumer side. On the developer side, you have Xcode, App Loader, testing tools, iTunes Connect — the list goes on.

As of September 2012, the App Store hosted over 700,000 apps that have collectively been downloaded over 30 billion times. Apple reported for October 2012 that App Store monthly revenues were

running at $333 million — a rate of about $4 billion per year — remarkable for a store that only opened in July 2008.

Another innovation that has spurred iOS app development is “The Cloud.” Cloud services make it easier for independent developers to create, support and make money from their apps. The Cloud solves data storage and cross-device and user-to-user sharing problems. If an app stores data in the Cloud, that part of the application is called the “backend,” while the part of the app that runs on the phone and interacts with the user is called the “front end.”

A cloud may be “private” — i.e., the services belong to an organization for the benefit of its employees and business partners. Or a cloud may be “public” — i.e., a company (such as Amazon or Kinvey) owns the services, which developers can then integrate into their own apps. If you are a developer and want to build your own backend, you certainly can do that. Whether you want to or not depends on whether your backend provides functionality common to many different apps. If it does (as in a shopping cart or user authenti-cation) then perhaps that time and money would be better spent on features that offer unique value to your customer. You may be better off hooking into a commercial backend provider via an API. Then you can focus on what counts most — a unique user experience and application-specific functionality. That brings us to the first step in making an app.

Define your appMost unsuccessful apps fail for any of four reasons:

1. the app was a solution in search of a problem (i.e., no real need existed) 2. the implementation was poor 3. the app tried to do too much; or 4. the Apple App Store rejected the app (either because the implementation was poor or it violated Apple’s content policies)

Keeping the app as simple as possible is the best way to avoid these pitfalls. Most successful apps (indeed, most successful consumer tech products) are based on what is called an MVP, or minimum viable product. It’s the product with the smallest feature set that can deliver the core function without any distracting “bells and whistles.” You know you have an MVP if the product would no longer function if you removed any single feature.

But what should that core feature be? One of the best examples of an MVP is Mail. Version 1 (on the Mac) offered a clear, limited and intuitive feature set whose usefulness was immediately obvious to anyone. Today’s iPhone version integrates seamlessly with your phone, contacts and calendaring. It auto-matically corrects spelling as you type, lets you email photos directly from your photos app, and does much more. But all that came later and was built on top of a basic core function. And that’s how your first app should be built. The key is to come up with something with a clear value that changes people’s lives.

So, in drawing up your MVP feature list, ask yourself what features are key to the experience. Some basic market research is probably in order, starting with a visit to the App Store to see what already exists (possibly to be improved upon and/or to compete with you). Likely

must-have core capabilities include:

• Performance (e.g., fast screen refresh)• Offline capability (i.e., ability to work when not connected to the Internet)• Location awareness (e.g., the data/experience will change with the user’s location)• Cloud syncing (e.g., users see the same data on multiple devices)• Push notifications (i.e., sending updated information to devices as soon as it is available)

When you have a handle on what your app does, the next step is to design it. Designing your app involves making choices of how infor-mation and controls are presented to the user as well as how to implement app logic, and figuring out what data lives locally and what belongs in the Cloud.

Design your appUser experience decisions determine the app’s look and feel. They answer questions such as: What does the app look like? What screens does it have? In the software development world, onscreen objects like buttons, sliders, and fill-in boxes are called widgets. So you need to decide which types of widgets will reside on which screens. And what actions will occur as a result of the user interacting with those widgets?

Keep in mind that users will expect to interact differently with a mobile device than they do with a PC because the screens on mobile devices are much smaller. They’ll expect to use their fingers instead of a mouse or a track pad. Ideally, your app can even be used with one hand holding the device while using just a thumb for scrolling andworking the app’s other controls— the Path app is a good example, and increasingly, so is Facebook.

Your app’s features will inform its architecture, which is how you’ll divide the code and data into functional parts. If your app requires interacting with other app users or networked services, you’ll need to figure out what piece of the logic lives in the app code and what comes from the backend. For example, your app might integrate with a restau-rant recommendation engine, share user location, or pull real-time traffic data. This is done using APIs provided by various service providers — but you don’t have to wire up your app to a network to get started. You can develop a prototype using predefined representative (or “dummy”) data. It’s easier to fine-tune the front end if you don’t have to simultaneously modify your backend too. Once you get the app’s look-and-feel right, then make those backend connections.

Once you’ve got the overall concept for your app, the next step is to express that design in terms of the iOS app architecture. That archi-tecture is the model for what parts an iOS app can contain and how those parts fit together. It’s a well thought-out approach for translat-ing a product concept into actual code you can deploy on a device.

WHY iOS?Besides the features and design of your first app, there’s one more decision you need to make before you start actual development. That’s whether to deploy on Apple’s iOS platform or on Google’s Android platform. (Some of this is also covered in our ebook, How to Make an App: Android Edition.) Reasons to develop for iOS include:

Customers more willing to pay. Perhaps it’s because of Android’s open source heritage, but whatever the reason, Android apps gener-ate less than 10% of the total dollars spent on mobile apps, despite having 75% of the smartphone market itself — and despite the fact that the average selling price of an app in the Google Play is $3.79 versus Apple App Store’s $2.01. In other words, Apple users are much more willing to spend money on apps.

The Apple Ecosystem. Some developers and users prefer Apple’s closed and more tightly controlled environment. Apple’s ecosystem, consisting of Xcode, iCloud, iTunes, the App Store, the iPad, the iPhone, Mac computers, etc., offers a very holistic user experience with the ability to share data seamlessly across devices plus the

assurance of having applications pre-approved for quality and content prior to going on sale.

Xcode. Apple’s all-in-one IDE offers state-of-the-art offers features like a graphical interface builder and a syntax-aware and compiler-aware source editor.

The Apple Experience. From the fit and finish of its hardware to the customer service in its retail stores, to the way its hardware and software work flawlessly together, Apple has created the premium brand in consumer electronics. iOS developers share the benefits — so when someone downloads your iOS app, they already expect it’s a great product. And that it will also work flawlessly on their device.

Tablets. iOS has a clear advantage over Android in terms of tablet market adoption. Using Xcode, it’s also much easier to migrate an app from a phone to a tablet and vice versa than it is when develop-ing for Android.

Why Not iOS?Although iOS offers many compelling advantages as a platform for your mobile app, it also comes with some disadvantages. Here are three:

Closed Platform. iOS apps only run on Apple products so you can’t take advantage of features (like NFC) available only on non-iOS devices or market growth of non-iOS devices.

Market Growth. Today, iOS represents less than 15% of the total smartphone market, Although the total market (“the whole pie”) is still increasing at a fast rate, Android market growth outpaces iOS growth.

Approvals. The App Store’s app approval process is notoriously more time consuming than Google Play’s process.

The iOS app architectureAs noted earlier, a key reason why there are so many apps for iOS is because developing highly functional, polished apps for the platform is relatively easy. That’s mainly because of: 1) the design of the development tools, and 2) the key architectural features most iOS apps have in common. So let’s start with some concepts since it helps to know what goes into an app before trying to create one. We’ll begin with:

• Design patterns• Frameworks• Delegation• Storyboard• Windows• Outlets• Supporting files• Products

Design patterns. iOS apps implement what is known as a Mod-el-View-Controller (MVC) pattern. A pattern is a common way to structure code that solves a particular design problem. The MVC pattern separates application code in a way that allows you to easily change one part of an app without having to change other parts. An MVC pattern consists of three components:

• The Model is the logic that acts on the data, such as to store or retrieve data from a database, compute the distance between two cities on a map, etc. An example of a model is the Kinvey backend that stores your data in the Cloud as a service.

• The View provides the interface to the user; it displays the data and widgets (e.g., buttons and text fields) that allow the user to interact with the data. An iPhone app may have more than one view, as in the Contacts app, which displays a list view of all contacts or alternatively a view of each individual contact.

• The Controller is between the model and the view — i.e., it responds to user requests (made in a view) and retrieves results

(produced in a model). This is where developers spend most of their time — constructing the View Controller — by defining and attaching actions (or behaviors) to onscreen widgets. When the user taps a button, for example, it is the View Controller that determines what action will occur, such as retrieve stored data from your Kinvey-based data store. The link between a view object (like a button) to a controller action is called a connection.

Frameworks. You don’t actually have to write most of an app’s logic. It already exists as frameworks. A framework is a collection of classes that implements some function — such as connecting to the Internet, drawing a button, etc. Rather than write the code from scratch, you just use the frameworks supplied by iOS. Some frameworks are automatically present when you start a new project while others may need to be added (done via a drop down menu in Xcode’s Project Editor).

Delegation. Say, you want to customize the behavior of a framework’s object. You can’t actually modify the code of the framework class itself (prohibited since other apps may also use the framework). But what you can do is provide app-specific behavior in an application delegate object. If a delegate implements a method, it will be called by the delegating class to modify its behavior. In the Kinvey sample app (one of two examples we will be describing below), the AppDele-gate.h and AppDelegate.m — the header and implementation files for the UIApplicationDelegate, respectively — contain the code that authenticates an app to the Kinvey backend service.

Storyboards and XIBs. The MainStoryboard.storyboard file (or a .xib file, if you did not click on the “Use Storyboard” option when starting your project) contains the view information needed to implement the overall flow and display of your application and the user interface elements.

Windows. Each view (e.g., the contact list and individual contact details in the Contacts app) exists within a window. The window represents the entire device screen and is where all your views are presented.

Outlets. A variable by which a view object can be referenced in a controller. (For example, if you place a text field to capture a user's name, you might create an outlet called UITextField* nameField.)

Supporting files. These are files that provide resources (like PNG images and other static data) that your app needs as well as files that configure how the app will run. Other examples:

.pch files — precompiled headers used for the code files in your project.

.plist files — property lists that are small amounts of persistent data (like your app’s default user settings) consisting primarily of strings and numbers that you want your app to be able to access, modify if needed, and write back into the property list.

main.m file — your app’s main function. This is needed to launch the app, but you will not need to modify this file.

InfoPlist.strings file — used for localization.

Products. This is the file for your app (i.e., YourProduct.app) that is built when you click Xcode’s “run” button.

“Making an iOS app” involves working with these features in the typical, straightforward workflow:

• Storyboard your views by dragging and configuring graphicalobjects on a template

• Adding behaviors to the various widgets• Writing the classes as to define those behaviors (including

delegates)• Adding needed support files• Building and running the app• Iterating until you are satisfied with your app

This is all done within Xcode.

What’s Xcode?You can start developing functional, good-looking apps almost from the moment you download Xcode, Apple’s integrated development environment (IDE) for making iOS and Macintosh apps. Among other features, Xcode includes a source code editor, graphical user inter-face (GUI) editor (sometimes called Interface Builder), source code repository manager, compiler, and much more. iOS applications are typically developed by manipulating views graphically and by typing Objective-C code for the models and controllers.

To get Xcode, simply go to the App Store and download the applica-tion (it’s free). To do this, click on the App Store icon in your Mac’s dock, or visit https://itunes.apple.com/us/genre/ios/id36?mt=8

The app store will download and install Xcode in your Application folder. From Applications, double-click the Xcode icon to launch Xcode and you’ll see its splash screen (Figure 1). From there you can click on “Create a new Xcode project” to take you to a menu of several templates on which to base your application. Selecting a template opens an Xcode workspace pre-populated with frameworks and other files Xcode thinks you will need using that template.

Although you can develop, build and simulate your app on your computer in Xcode, you can’t run your app on a target device (even your own iPhone) until you become a registered iOS developer and join the iOS Developer Program. To do that, go to develop-er.app.com/ and navigate to the iOS Dev Center. While there, you will also find documentation, sample code and other useful resources such as information on how to submit your app to the iOS App Store.

Everything you do in Xcode is done in a window, called a workspace (Figure 2), consisting of multiple work areas, some of which are also divided into panes. All the files needed to build your app belong to a project, and the Navigator area (far left) lists all your projects (there can be several in a workspace) and all files for each project. Clicking on a file in the Navigator area shows its contents in the Editor area and invokes the appropriate editor. Clicking on a .h or .m file, for example, shows the file’s source code and invokes the Source editor, so you can edit the code. Clicking on .storyboard or .xib (sometimes called a “nib”) file shows the app’s storyboard and invokes the Inter-face Builder, so you can design a view using the Builder’s drag and drop features.

An especially handy feature is that the Editor area can have both a right and a left pane — with each pane aware of your edits in the other. So, for example, you can simultaneously edit an object’s .h

header file in the left pane and its corresponding .m in the right pane. Or you might click on a button object (displayed graphically) in the left pane and edit its method’s source code in the right pane. To toggle between a single pane (the “Standard Editor”) and double pane view (the “Assistant Editor”), use the Editor selector button on the right of the toolbar. You can option+command+click a symbol in the editor to open the definition in the opposite editor pane.

You can also resize the entire Editor area simply by dragging its borders. For even more editing space, you can also remove the Debug area or both the Debug and Utility areas using the View Selector button on the far right of the toolbar.

As its name suggests, the Debug area shows information, like variable state and console logs, helpful in debugging code.

The Utility area has two panes: the Inspector and Quick Help pane (top) and the Library pane (bottom). Although there are five inspectors — File, Help, Identity, Attributes, Size and Connec-tions — only the inspectors that are currently relevant appear in the Inspec-tor list at the top of the pane. (To see the name of an inspector, move the cursor over its icon in the Inspector selector bar.)

You will use inspectors to add and modify object attributes for views in the Interface Builder. For example, if you click on a UILabel in the Editor area of a storyboard, you can use the Attributes inspector to change the label’s color and use the Size inspector to change the label’s size.

The Help inspector shows help information about a selected class. Use the Identity inspector to view and manage an object’s metadata such as its class, runtime attributes, label and so forth. Use the

Connections inspector to view the outlets and actions of an interface object, to make new connections and to delete existing connections.

The Library pane has libraries of resources (like file templates, code snippets, interface objects and media files) that are prebuilt and ready to insert into your project. Use the Library selector to select which of these libraries (e.g., code snippets or interface objects) you wish to insert. To insert one, drag it directly into your storyboard while using the Interface Builder editor.

These are basics you need to know to get started using Xcode to build your first app. But to really understand how it’s done, it helps to walk through an actual app or two. Let’s start with a simple “Hello World” app that does not employ a backend connection, and then look at a somewhat more functional app that does.

“Hello World!” sample appThis app displays a button (“Press Me”) and a label (“Label”) so that when the user presses the button the text of the label changes to “Hello World!” as in Figure 3:

To get started, launch Xcode and select “Create a New Xcode Project.” From the iOS Application templates, select “Single View Application” and click “Next.” Fill in your product’s name and a company identifier, typically “com.yourCompanyName.” Deselect “Use Storyboards” and leave “Use Automatic Reference Counting” selected. Then click “Next” and select a destination for your projects files.

Follow these steps to make your app:

1. Select your project’s ViewController.xib file in the Navigator(Figure 4), to open the Interface Builder editor.

2. Drag a “Round Rect Button” from the Objects library (lowerright) onto the view in the Editor area; select the button’s textand type “Press Me.”

3. Drag a Label from the objects library onto the view, as well.4. Select and drag the Label sizing handles, centering the object

and making it wide enough to hold the “Hello World!” text; then,

5. With the “Hello World!” label still selected, click on centeralignment in the Attributes inspector.

6. Open the Assistant Editor (Figure 5), exposing the source codeheader file (ViewController.h) of the view controller you justbuilt graphically.

7. Select the button and control-drag from the button to justbelow the ViewController definition in the Assistant panel. Inthe form that opens, select “Action” for the connection type,type in a name (“showText”) and click “Connect.” This creates aninterface builder (IB) action as highlighted in Figure 6.

8. Next step is to create an outlet for the label. To do this, selectthe label object and control-drag from the label to just belowthe IB action you just created. Select “Outlet” as the connectiontype and enter a name “label” and click “Connect.” This createsan interface builder (IB) outlet as shown in Figure 7.

9. Finally, it’s time to add some logic to the view controller so itknows what to do when the button is pressed. To do this, select “ViewController.m” in the project navigator to show the code editor. Find the button’s IBAction you just created (near the bottom), place your cursor between the { } brackets and hit the return key a few times to create some extra space. Then in that space type the method for how you want the label you speci-fied to respond: _label.text=”Hello World!”; as highlighted in Figure 8.

Congratulations! Your app is done. To build and run your new app in the simulator, click the Xcode Run button in the left corner of the toolbar. When you click the button, the text will update.

Sample app with a backend This second app (named “Kinvey Test Drive”) lets the user type text on an iPhone and save the text to a backend service, like Kinvey. It also lets the user load text on the iPhone from their Kinvey backend. Reading about this app will help you learn:

• How to set up Kinvey’s library in an iOS project• Additional Interface Builder techniques you can use to story-board an application• How to add view controller logic to interact with the backend service, allowing you to save and retrieve data

We will first present the app as a running application and then take it apart so you can see how it was made. To make the app yourself, you can review the various sections below and replicate the steps in your copy of Xcode.

First, to see the app in action, you should download the app and run it on your system. To do that, sign up for Kinvey, then navigate to “Dev Center”, “Samples,” find the “Test Drive” app, and click on its icon. (If you can’t find it right away, make sure you select iOS as your platform on the right side of the menu bar.) Click the download button to download the app’s project files to your computer. Then launch Xcode — just double click on the .xcodeproj file in the project folder.

But before you can run the app, you need to set up the app’s Kinvey backend.

Set Up Kinvey as a Backend Data StoreTest Drive’s project files include all the code the sample app needs in order to talk to Kinvey. However, that would not be the case if you were to build an app from scratch — so you would have to go through an initial Kinvey setup procedure. This involves downloading the Kinvey library files from the downloads section of devcenter.kin-vey.com and dragging them to the Navigator’s Frameworks folder in Xcode. You also need to tell Xcode to link your project with additional iOS frameworks. To find these frameworks, click on the Project folder

at the very top of the Navigator pane — which displays the Project editor — and then select the “Build Settings” tab. For detailed instruc-tions, complete the “Getting Started” page under “Guides” on the Kinvey website. But again, you can skip this setup procedure for now in order to run the downloaded Kinvey Test Drive app.

But you must still do this step: To run any app that uses Kinvey (including Test Drive) you need to do the “Create an App” step on the Kinvey website. Click on “My Apps” in the Kinvey menu bar and then click on “Add an App,” which will open an “Add” page. Type in a name for your app and click on the Apple logo and then click “Create.” The page that opens shows your App’s credentials. Copy and paste the App Key and App Secret into the AppDelegate.m file of the download-ed Test Drive project:

You are now ready to run the app — click on the Xcode run button and wait for the simulator to open and the app to appear (Figure 9).

Clicking the “+” toolbar button opens an alert (Figure 10) with an empty field into which the user can type some text (e.g., “some new data”). Clicking “save” uploads the data to Kinvey and displays text on the screen (a table view) and also displays an alert that the save worked (Figure 11).

To test the load function, enter some data (e.g., “some data to load”) in the “name” field of the Kinvey collection. To see the load, the swipe down on the table on the phone until the refresh spinner starts, and then the new data will appear in the table (Figure 12).

Figure 13 shows the Kinvey collection after the save that Figure 10 depicts on the iPhone. Figure 14 shows the Kinvey collection after the user adds a new row to the testObjects collection using the web browser. Note that every time a save is done on the iPhone, Kinvey automatically adds a new row (displayed on a collection refresh). To add a new row manually in the browser, click “+ row,” and type some descriptive text in the “name” column. That data will now load on the iPhone when the user pulls down on the table.

Storyboard the Test Drive AppMost of the Test Drive user interface objects visible in the simulation are available in Xcode’s Object Library and can therefore be added to the view graphically. The UI objects consist of a:

• Table view• Toolbar• Tool Bar Button item – flexible space• Tool Bar Button item – Add• Table view cell• Label – Title• Refresh Control

To create this app yourself, you would follow these steps:

• Launch Xcode and select the “Single View Application” template• Select the “Use Storyboard” option• Replace the default UIviewcontroller object with a UITableView-Controller • Drag and drop the other objects, in the order listed, onto the UIviewcontroller

Also note:

• The Flexible Space Bar Button item fills up the space on the toolbar so the add button is at the right. This is a standard pattern in table-based iPhone apps.• The add button shows the system “+” sign. That is done by dragging a bar button item onto the toolbar, clicking on the Identifier drop down menu in the Attributes inspector; and then selecting the “Add” option.

As with the “Hello World!” app, once your app’s view is complete (Figure 15), you would still have to create the various methods and connections that bring them to life. This is done using the Source editor while working with the ViewController.m file.

Add View Controller LogicSince the app performs two basic operations (save data to Kinvey and load data from Kinvey) these two methods must be added to the ViewController header file. That’s done with a control-drag from the “+” bar button over to just under the “@ interface ViewController” line in ViewController.h. (Open the Assistant editor to see both the storyboard and the file source.)

During the drag, the popup appears, asking for the name and type of connection. Enter “action” for the connection type and “add” for the name. Then repeat the drag, this time from the refresh control and using “add” for the name (Figure 16).

Note: to follow this discussion it will help to have the referenced files open in your Xcode Source editor.

In ViewController.m, you will see the implementation code associated with each of the two Interface Builder methods, whose names Xcode added automatically to the .m file:

- (IBAction)add:(id)sender- (IBAction)load:(id)sender

You will also see a third section of code not associated with these methods, which starts with the line: “#pragma mark - Table View Stuff.” These methods support the table view and are part of UITableViewD-elegate and UITableViewDataSource. They handle controlling the

display of the table, and respond to user gestures. For example, swiping a table cell will show the delete button because tableView:-canEditRowAtIndexPath: returns YES and tableView:editingStyleForRowA-tIndexPath: returns UITableViewCellEditingStyleDelete. If you tap the delete button, the delegate method tableView:commitEditingStyle:for-RowAtIndexPath: is called. The code of this method deletes the data for the row and removes it from Kinvey’s data store. When the backend delete is completed, the app displays an alert describing the success or failure.

The way that all three sections (and all Kinvey-enabled apps) move data in and out of a Kinvey collection is by getting a reference to the app’s backend collection (named “testObjects”), which is filled with instances (each named “TestObject”) of the data the app wants to move. That’s why you’ll find the following code repeated three times in Test Drive’s View Controller (once for the add, once for the load, and once for the delete):

To support these statements it is required to have a data object class (TestObject). To see how these files are written in the sample project, click on TestObject.h file and TestObject.m in the Navigator pane. If you were to supply these files in your own app, you would click File > New File, and specify Objective-C class, which would be a subclass of NSObject. Then you would type in the code, with a property for each column in the Kinvey backend collection (including one for the object’s id).

As mentioned earlier, your app also needs to authenticate itself to Kinvey, which is handled by AppDelegate.h and AppDelgate.m. These files are created by Xcode when you create a new project, and start out with just a stub implementation. Look in the sample app source

files for code to copy and paste.

For both the save and load operations, however, moving the data in and out of a backend collection is only part of the work. Table 1 lists all the functions that implements the save and load in the ViewCon-troller.m file, along with pointers to its corresponding block of imple-mentation source code. (For each function, its corresponding code begins with the “Starts at” line and ends with the “Ends at” line.) Refer to Appendix 1 to find the actual source code.

Say Hello To Our WorldThe key takeaway from all this is that “making an app” is a worthwhile thing to do for anyone with a clever idea and a working knowledge of Objective-C. The proof is in the hundreds of apps succeeding in the market every day, many written by people working on their own and who never wrote an app before in their lives. As with anything else, practice does make perfect. But hopefully with all the resources available, and the knowledge gained from this ebook, you have already started down the path toward joining the growing legions of iOS app developers. If so, we welcome you!

Appendix 1 — Test Drive Sample App ViewController.m Source Code

fig. 13 Backend collection after saving from the app

fig. 14 Backend collection after adding a new row directly.

32

The iOS revolutionIt’s a story that never gets old. The weekend that iPad Minis and the fourth generation iPads went on sale (November 2-5, 2012) Apple sold over 3 million of the devices — a record for first-weekend iPad sales. Two months earlier the company had set another record: first weekend sales of over 5 million for the iPhone 5. Since the introduc-tion of the first iPhone back in 2007,

iOS-based devices (iPhone, iPad, iPad Mini and iPod Touch) continue to rewrite the definition of what constitutes a successful product. By the end of 2012, over 400 million iOS devices had been sold.

What makes iOS devices so successful? Innovation and product features are clearly a big part. Before the iPhone most people had not interacted with a multi-touch interface. They had never zoomed with a pinch or switched between portrait and landscape by merely rotating a device in their hand. Carrying a phone that knew where they were, could suggest places to eat, and could offer directions on how to get there was also a novel experience.

But features like multi-touch, accelerometers and GPS are only part of the appeal. Even with all its innovations, iOS still might not have taken off the way it has if the only people figuring out ways to use those innovations worked at Apple. Most of the capabilities available in an iPhone or iPad in fact don’t come from Apple at all. They come from legions of third-party developers who work in a vast ecosystem that is also an Apple innovation. That ecosystem includes the iPhone, iPad, iPad Mini, iPods, App Store, iTunes, ad networks — and that’s just on the consumer side. On the developer side, you have Xcode, App Loader, testing tools, iTunes Connect — the list goes on.

As of September 2012, the App Store hosted over 700,000 apps that have collectively been downloaded over 30 billion times. Apple reported for October 2012 that App Store monthly revenues were

running at $333 million — a rate of about $4 billion per year — remarkable for a store that only opened in July 2008.

Another innovation that has spurred iOS app development is “The Cloud.” Cloud services make it easier for independent developers to create, support and make money from their apps. The Cloud solves data storage and cross-device and user-to-user sharing problems. If an app stores data in the Cloud, that part of the application is called the “backend,” while the part of the app that runs on the phone and interacts with the user is called the “front end.”

A cloud may be “private” — i.e., the services belong to an organization for the benefit of its employees and business partners. Or a cloud may be “public” — i.e., a company (such as Amazon or Kinvey) owns the services, which developers can then integrate into their own apps. If you are a developer and want to build your own backend, you certainly can do that. Whether you want to or not depends on whether your backend provides functionality common to many different apps. If it does (as in a shopping cart or user authenti-cation) then perhaps that time and money would be better spent on features that offer unique value to your customer. You may be better off hooking into a commercial backend provider via an API. Then you can focus on what counts most — a unique user experience and application-specific functionality. That brings us to the first step in making an app.

Define your appMost unsuccessful apps fail for any of four reasons:

1. the app was a solution in search of a problem (i.e., no real need existed) 2. the implementation was poor 3. the app tried to do too much; or 4. the Apple App Store rejected the app (either because the implementation was poor or it violated Apple’s content policies)

Keeping the app as simple as possible is the best way to avoid these pitfalls. Most successful apps (indeed, most successful consumer tech products) are based on what is called an MVP, or minimum viable product. It’s the product with the smallest feature set that can deliver the core function without any distracting “bells and whistles.” You know you have an MVP if the product would no longer function if you removed any single feature.

But what should that core feature be? One of the best examples of an MVP is Mail. Version 1 (on the Mac) offered a clear, limited and intuitive feature set whose usefulness was immediately obvious to anyone. Today’s iPhone version integrates seamlessly with your phone, contacts and calendaring. It auto-matically corrects spelling as you type, lets you email photos directly from your photos app, and does much more. But all that came later and was built on top of a basic core function. And that’s how your first app should be built. The key is to come up with something with a clear value that changes people’s lives.

So, in drawing up your MVP feature list, ask yourself what features are key to the experience. Some basic market research is probably in order, starting with a visit to the App Store to see what already exists (possibly to be improved upon and/or to compete with you). Likely

must-have core capabilities include:

• Performance (e.g., fast screen refresh)• Offline capability (i.e., ability to work when not connected to the Internet)• Location awareness (e.g., the data/experience will change with the user’s location)• Cloud syncing (e.g., users see the same data on multiple devices)• Push notifications (i.e., sending updated information to devices as soon as it is available)

When you have a handle on what your app does, the next step is to design it. Designing your app involves making choices of how infor-mation and controls are presented to the user as well as how to implement app logic, and figuring out what data lives locally and what belongs in the Cloud.

Design your appUser experience decisions determine the app’s look and feel. They answer questions such as: What does the app look like? What screens does it have? In the software development world, onscreen objects like buttons, sliders, and fill-in boxes are called widgets. So you need to decide which types of widgets will reside on which screens. And what actions will occur as a result of the user interacting with those widgets?

Keep in mind that users will expect to interact differently with a mobile device than they do with a PC because the screens on mobile devices are much smaller. They’ll expect to use their fingers instead of a mouse or a track pad. Ideally, your app can even be used with one hand holding the device while using just a thumb for scrolling andworking the app’s other controls— the Path app is a good example, and increasingly, so is Facebook.

Your app’s features will inform its architecture, which is how you’ll divide the code and data into functional parts. If your app requires interacting with other app users or networked services, you’ll need to figure out what piece of the logic lives in the app code and what comes from the backend. For example, your app might integrate with a restau-rant recommendation engine, share user location, or pull real-time traffic data. This is done using APIs provided by various service providers — but you don’t have to wire up your app to a network to get started. You can develop a prototype using predefined representative (or “dummy”) data. It’s easier to fine-tune the front end if you don’t have to simultaneously modify your backend too. Once you get the app’s look-and-feel right, then make those backend connections.

Once you’ve got the overall concept for your app, the next step is to express that design in terms of the iOS app architecture. That archi-tecture is the model for what parts an iOS app can contain and how those parts fit together. It’s a well thought-out approach for translat-ing a product concept into actual code you can deploy on a device.

WHY iOS?Besides the features and design of your first app, there’s one more decision you need to make before you start actual development. That’s whether to deploy on Apple’s iOS platform or on Google’s Android platform. (Some of this is also covered in our ebook, How to Make an App: Android Edition.) Reasons to develop for iOS include:

Customers more willing to pay. Perhaps it’s because of Android’s open source heritage, but whatever the reason, Android apps gener-ate less than 10% of the total dollars spent on mobile apps, despite having 75% of the smartphone market itself — and despite the fact that the average selling price of an app in the Google Play is $3.79 versus Apple App Store’s $2.01. In other words, Apple users are much more willing to spend money on apps.

The Apple Ecosystem. Some developers and users prefer Apple’s closed and more tightly controlled environment. Apple’s ecosystem, consisting of Xcode, iCloud, iTunes, the App Store, the iPad, the iPhone, Mac computers, etc., offers a very holistic user experience with the ability to share data seamlessly across devices plus the

assurance of having applications pre-approved for quality and content prior to going on sale.

Xcode. Apple’s all-in-one IDE offers state-of-the-art offers features like a graphical interface builder and a syntax-aware and compiler-aware source editor.

The Apple Experience. From the fit and finish of its hardware to the customer service in its retail stores, to the way its hardware and software work flawlessly together, Apple has created the premium brand in consumer electronics. iOS developers share the benefits — so when someone downloads your iOS app, they already expect it’s a great product. And that it will also work flawlessly on their device.

Tablets. iOS has a clear advantage over Android in terms of tablet market adoption. Using Xcode, it’s also much easier to migrate an app from a phone to a tablet and vice versa than it is when develop-ing for Android.

Why Not iOS?Although iOS offers many compelling advantages as a platform for your mobile app, it also comes with some disadvantages. Here are three:

Closed Platform. iOS apps only run on Apple products so you can’t take advantage of features (like NFC) available only on non-iOS devices or market growth of non-iOS devices.

Market Growth. Today, iOS represents less than 15% of the total smartphone market, Although the total market (“the whole pie”) is still increasing at a fast rate, Android market growth outpaces iOS growth.

Approvals. The App Store’s app approval process is notoriously more time consuming than Google Play’s process.

The iOS app architectureAs noted earlier, a key reason why there are so many apps for iOS is because developing highly functional, polished apps for the platform is relatively easy. That’s mainly because of: 1) the design of the development tools, and 2) the key architectural features most iOS apps have in common. So let’s start with some concepts since it helps to know what goes into an app before trying to create one. We’ll begin with:

• Design patterns• Frameworks• Delegation• Storyboard• Windows• Outlets• Supporting files• Products

Design patterns. iOS apps implement what is known as a Mod-el-View-Controller (MVC) pattern. A pattern is a common way to structure code that solves a particular design problem. The MVC pattern separates application code in a way that allows you to easily change one part of an app without having to change other parts. An MVC pattern consists of three components:

• The Model is the logic that acts on the data, such as to store or retrieve data from a database, compute the distance between two cities on a map, etc. An example of a model is the Kinvey backend that stores your data in the Cloud as a service.

• The View provides the interface to the user; it displays the data and widgets (e.g., buttons and text fields) that allow the user to interact with the data. An iPhone app may have more than one view, as in the Contacts app, which displays a list view of all contacts or alternatively a view of each individual contact.

• The Controller is between the model and the view — i.e., it responds to user requests (made in a view) and retrieves results

(produced in a model). This is where developers spend most of their time — constructing the View Controller — by defining and attaching actions (or behaviors) to onscreen widgets. When the user taps a button, for example, it is the View Controller that determines what action will occur, such as retrieve stored data from your Kinvey-based data store. The link between a view object (like a button) to a controller action is called a connection.

Frameworks. You don’t actually have to write most of an app’s logic. It already exists as frameworks. A framework is a collection of classes that implements some function — such as connecting to the Internet, drawing a button, etc. Rather than write the code from scratch, you just use the frameworks supplied by iOS. Some frameworks are automatically present when you start a new project while others may need to be added (done via a drop down menu in Xcode’s Project Editor).

Delegation. Say, you want to customize the behavior of a framework’s object. You can’t actually modify the code of the framework class itself (prohibited since other apps may also use the framework). But what you can do is provide app-specific behavior in an application delegate object. If a delegate implements a method, it will be called by the delegating class to modify its behavior. In the Kinvey sample app (one of two examples we will be describing below), the AppDele-gate.h and AppDelegate.m — the header and implementation files for the UIApplicationDelegate, respectively — contain the code that authenticates an app to the Kinvey backend service.

Storyboards and XIBs. The MainStoryboard.storyboard file (or a .xib file, if you did not click on the “Use Storyboard” option when starting your project) contains the view information needed to implement the overall flow and display of your application and the user interface elements.

Windows. Each view (e.g., the contact list and individual contact details in the Contacts app) exists within a window. The window represents the entire device screen and is where all your views are presented.

Outlets. A variable by which a view object can be referenced in a controller. (For example, if you place a text field to capture a user's name, you might create an outlet called UITextField* nameField.)

Supporting files. These are files that provide resources (like PNG images and other static data) that your app needs as well as files that configure how the app will run. Other examples:

.pch files — precompiled headers used for the code files in your project.

.plist files — property lists that are small amounts of persistent data (like your app’s default user settings) consisting primarily of strings and numbers that you want your app to be able to access, modify if needed, and write back into the property list.

main.m file — your app’s main function. This is needed to launch the app, but you will not need to modify this file.

InfoPlist.strings file — used for localization.

Products. This is the file for your app (i.e., YourProduct.app) that is built when you click Xcode’s “run” button.

“Making an iOS app” involves working with these features in the typical, straightforward workflow:

• Storyboard your views by dragging and configuring graphicalobjects on a template

• Adding behaviors to the various widgets• Writing the classes as to define those behaviors (including

delegates)• Adding needed support files• Building and running the app• Iterating until you are satisfied with your app

This is all done within Xcode.

What’s Xcode?You can start developing functional, good-looking apps almost from the moment you download Xcode, Apple’s integrated development environment (IDE) for making iOS and Macintosh apps. Among other features, Xcode includes a source code editor, graphical user inter-face (GUI) editor (sometimes called Interface Builder), source code repository manager, compiler, and much more. iOS applications are typically developed by manipulating views graphically and by typing Objective-C code for the models and controllers.

To get Xcode, simply go to the App Store and download the applica-tion (it’s free). To do this, click on the App Store icon in your Mac’s dock, or visit https://itunes.apple.com/us/genre/ios/id36?mt=8

The app store will download and install Xcode in your Application folder. From Applications, double-click the Xcode icon to launch Xcode and you’ll see its splash screen (Figure 1). From there you can click on “Create a new Xcode project” to take you to a menu of several templates on which to base your application. Selecting a template opens an Xcode workspace pre-populated with frameworks and other files Xcode thinks you will need using that template.

Although you can develop, build and simulate your app on your computer in Xcode, you can’t run your app on a target device (even your own iPhone) until you become a registered iOS developer and join the iOS Developer Program. To do that, go to develop-er.app.com/ and navigate to the iOS Dev Center. While there, you will also find documentation, sample code and other useful resources such as information on how to submit your app to the iOS App Store.

Everything you do in Xcode is done in a window, called a workspace (Figure 2), consisting of multiple work areas, some of which are also divided into panes. All the files needed to build your app belong to a project, and the Navigator area (far left) lists all your projects (there can be several in a workspace) and all files for each project. Clicking on a file in the Navigator area shows its contents in the Editor area and invokes the appropriate editor. Clicking on a .h or .m file, for example, shows the file’s source code and invokes the Source editor, so you can edit the code. Clicking on .storyboard or .xib (sometimes called a “nib”) file shows the app’s storyboard and invokes the Inter-face Builder, so you can design a view using the Builder’s drag and drop features.

An especially handy feature is that the Editor area can have both a right and a left pane — with each pane aware of your edits in the other. So, for example, you can simultaneously edit an object’s .h

header file in the left pane and its corresponding .m in the right pane. Or you might click on a button object (displayed graphically) in the left pane and edit its method’s source code in the right pane. To toggle between a single pane (the “Standard Editor”) and double pane view (the “Assistant Editor”), use the Editor selector button on the right of the toolbar. You can option+command+click a symbol in the editor to open the definition in the opposite editor pane.

You can also resize the entire Editor area simply by dragging its borders. For even more editing space, you can also remove the Debug area or both the Debug and Utility areas using the View Selector button on the far right of the toolbar.

As its name suggests, the Debug area shows information, like variable state and console logs, helpful in debugging code.

The Utility area has two panes: the Inspector and Quick Help pane (top) and the Library pane (bottom). Although there are five inspectors — File, Help, Identity, Attributes, Size and Connec-tions — only the inspectors that are currently relevant appear in the Inspec-tor list at the top of the pane. (To see the name of an inspector, move the cursor over its icon in the Inspector selector bar.)

You will use inspectors to add and modify object attributes for views in the Interface Builder. For example, if you click on a UILabel in the Editor area of a storyboard, you can use the Attributes inspector to change the label’s color and use the Size inspector to change the label’s size.

The Help inspector shows help information about a selected class. Use the Identity inspector to view and manage an object’s metadata such as its class, runtime attributes, label and so forth. Use the

Connections inspector to view the outlets and actions of an interface object, to make new connections and to delete existing connections.

The Library pane has libraries of resources (like file templates, code snippets, interface objects and media files) that are prebuilt and ready to insert into your project. Use the Library selector to select which of these libraries (e.g., code snippets or interface objects) you wish to insert. To insert one, drag it directly into your storyboard while using the Interface Builder editor.

These are basics you need to know to get started using Xcode to build your first app. But to really understand how it’s done, it helps to walk through an actual app or two. Let’s start with a simple “Hello World” app that does not employ a backend connection, and then look at a somewhat more functional app that does.

“Hello World!” sample appThis app displays a button (“Press Me”) and a label (“Label”) so that when the user presses the button the text of the label changes to “Hello World!” as in Figure 3:

To get started, launch Xcode and select “Create a New Xcode Project.” From the iOS Application templates, select “Single View Application” and click “Next.” Fill in your product’s name and a company identifier, typically “com.yourCompanyName.” Deselect “Use Storyboards” and leave “Use Automatic Reference Counting” selected. Then click “Next” and select a destination for your projects files.

Follow these steps to make your app:

1. Select your project’s ViewController.xib file in the Navigator(Figure 4), to open the Interface Builder editor.

2. Drag a “Round Rect Button” from the Objects library (lowerright) onto the view in the Editor area; select the button’s textand type “Press Me.”

3. Drag a Label from the objects library onto the view, as well.4. Select and drag the Label sizing handles, centering the object

and making it wide enough to hold the “Hello World!” text; then,

5. With the “Hello World!” label still selected, click on centeralignment in the Attributes inspector.

6. Open the Assistant Editor (Figure 5), exposing the source codeheader file (ViewController.h) of the view controller you justbuilt graphically.

7. Select the button and control-drag from the button to justbelow the ViewController definition in the Assistant panel. Inthe form that opens, select “Action” for the connection type,type in a name (“showText”) and click “Connect.” This creates aninterface builder (IB) action as highlighted in Figure 6.

8. Next step is to create an outlet for the label. To do this, selectthe label object and control-drag from the label to just belowthe IB action you just created. Select “Outlet” as the connectiontype and enter a name “label” and click “Connect.” This createsan interface builder (IB) outlet as shown in Figure 7.

9. Finally, it’s time to add some logic to the view controller so itknows what to do when the button is pressed. To do this, select “ViewController.m” in the project navigator to show the code editor. Find the button’s IBAction you just created (near the bottom), place your cursor between the { } brackets and hit the return key a few times to create some extra space. Then in that space type the method for how you want the label you speci-fied to respond: _label.text=”Hello World!”; as highlighted in Figure 8.

Congratulations! Your app is done. To build and run your new app in the simulator, click the Xcode Run button in the left corner of the toolbar. When you click the button, the text will update.

Sample app with a backend This second app (named “Kinvey Test Drive”) lets the user type text on an iPhone and save the text to a backend service, like Kinvey. It also lets the user load text on the iPhone from their Kinvey backend. Reading about this app will help you learn:

• How to set up Kinvey’s library in an iOS project• Additional Interface Builder techniques you can use to story-board an application• How to add view controller logic to interact with the backend service, allowing you to save and retrieve data

We will first present the app as a running application and then take it apart so you can see how it was made. To make the app yourself, you can review the various sections below and replicate the steps in your copy of Xcode.

First, to see the app in action, you should download the app and run it on your system. To do that, sign up for Kinvey, then navigate to “Dev Center”, “Samples,” find the “Test Drive” app, and click on its icon. (If you can’t find it right away, make sure you select iOS as your platform on the right side of the menu bar.) Click the download button to download the app’s project files to your computer. Then launch Xcode — just double click on the .xcodeproj file in the project folder.

But before you can run the app, you need to set up the app’s Kinvey backend.

Set Up Kinvey as a Backend Data StoreTest Drive’s project files include all the code the sample app needs in order to talk to Kinvey. However, that would not be the case if you were to build an app from scratch — so you would have to go through an initial Kinvey setup procedure. This involves downloading the Kinvey library files from the downloads section of devcenter.kin-vey.com and dragging them to the Navigator’s Frameworks folder in Xcode. You also need to tell Xcode to link your project with additional iOS frameworks. To find these frameworks, click on the Project folder

at the very top of the Navigator pane — which displays the Project editor — and then select the “Build Settings” tab. For detailed instruc-tions, complete the “Getting Started” page under “Guides” on the Kinvey website. But again, you can skip this setup procedure for now in order to run the downloaded Kinvey Test Drive app.

But you must still do this step: To run any app that uses Kinvey (including Test Drive) you need to do the “Create an App” step on the Kinvey website. Click on “My Apps” in the Kinvey menu bar and then click on “Add an App,” which will open an “Add” page. Type in a name for your app and click on the Apple logo and then click “Create.” The page that opens shows your App’s credentials. Copy and paste the App Key and App Secret into the AppDelegate.m file of the download-ed Test Drive project:

You are now ready to run the app — click on the Xcode run button and wait for the simulator to open and the app to appear (Figure 9).

Clicking the “+” toolbar button opens an alert (Figure 10) with an empty field into which the user can type some text (e.g., “some new data”). Clicking “save” uploads the data to Kinvey and displays text on the screen (a table view) and also displays an alert that the save worked (Figure 11).

To test the load function, enter some data (e.g., “some data to load”) in the “name” field of the Kinvey collection. To see the load, the swipe down on the table on the phone until the refresh spinner starts, and then the new data will appear in the table (Figure 12).

Figure 13 shows the Kinvey collection after the save that Figure 10 depicts on the iPhone. Figure 14 shows the Kinvey collection after the user adds a new row to the testObjects collection using the web browser. Note that every time a save is done on the iPhone, Kinvey automatically adds a new row (displayed on a collection refresh). To add a new row manually in the browser, click “+ row,” and type some descriptive text in the “name” column. That data will now load on the iPhone when the user pulls down on the table.

Storyboard the Test Drive AppMost of the Test Drive user interface objects visible in the simulation are available in Xcode’s Object Library and can therefore be added to the view graphically. The UI objects consist of a:

• Table view• Toolbar• Tool Bar Button item – flexible space• Tool Bar Button item – Add• Table view cell• Label – Title• Refresh Control

To create this app yourself, you would follow these steps:

• Launch Xcode and select the “Single View Application” template• Select the “Use Storyboard” option• Replace the default UIviewController object with a UITableView-Controller • Drag and drop the other objects, in the order listed, onto theUIviewcontroller

Also note:

• The Flexible Space Bar Button item fills up the space on thetoolbar so the add button is at the right. This is a standard pattern in table-based iPhone apps.• The add button shows the system “+” sign. That is done bydragging a bar button item onto the toolbar, clicking on the Identifier drop down menu in the Attributes inspector; and then selecting the “Add” option.

As with the “Hello World!” app, once your app’s view is complete (Figure 15), you would still have to create the various methods and connections that bring them to life. This is done using the Source editor while working with the ViewController.m file.

Add View Controller LogicSince the app performs two basic operations (save data to Kinvey and load data from Kinvey) these two methods must be added to the ViewController header file. That’s done with a control-drag from the “+” bar button over to just under the “@ interface ViewController” line in ViewController.h. (Open the Assistant editor to see both the storyboard and the file source.)

During the drag, the popup appears, asking for the name and type of connection. Enter “action” for the connection type and “add” for the name. Then repeat the drag, this time from the refresh control and using “add” for the name (Figure 16).

Note: to follow this discussion it will help to have the referenced files open in your Xcode Source editor.

In ViewController.m, you will see the implementation code associated with each of the two Interface Builder methods, whose names Xcode added automatically to the .m file:

- (IBAction)add:(id)sender- (IBAction)load:(id)sender

You will also see a third section of code not associated with these methods, which starts with the line: “#pragma mark - Table View Stuff.” These methods support the table view and are part of UITableViewD-elegate and UITableViewDataSource. They handle controlling the

display of the table, and respond to user gestures. For example, swiping a table cell will show the delete button because tableView:-canEditRowAtIndexPath: returns YES and tableView:editingStyleForRowA-tIndexPath: returns UITableViewCellEditingStyleDelete. If you tap the delete button, the delegate method tableView:commitEditingStyle:for-RowAtIndexPath: is called. The code of this method deletes the data for the row and removes it from Kinvey’s data store. When the backend delete is completed, the app displays an alert describing the success or failure.

The way that all three sections (and all Kinvey-enabled apps) move data in and out of a Kinvey collection is by getting a reference to the app’s backend collection (named “testObjects”), which is filled with instances (each named “TestObject”) of the data the app wants to move. That’s why you’ll find the following code repeated three times in Test Drive’s View Controller (once for the add, once for the load, and once for the delete):

To support these statements it is required to have a data object class (TestObject). To see how these files are written in the sample project, click on TestObject.h file and TestObject.m in the Navigator pane. If you were to supply these files in your own app, you would click File > New File, and specify Objective-C class, which would be a subclass of NSObject. Then you would type in the code, with a property for each column in the Kinvey backend collection (including one for the object’s id).

As mentioned earlier, your app also needs to authenticate itself to Kinvey, which is handled by AppDelegate.h and AppDelgate.m. These files are created by Xcode when you create a new project, and start out with just a stub implementation. Look in the sample app source

files for code to copy and paste.

For both the save and load operations, however, moving the data in and out of a backend collection is only part of the work. Table 1 lists all the functions that implements the save and load in the ViewCon-troller.m file, along with pointers to its corresponding block of imple-mentation source code. (For each function, its corresponding code begins with the “Starts at” line and ends with the “Ends at” line.) Refer to Appendix 1 to find the actual source code.

Say Hello To Our WorldThe key takeaway from all this is that “making an app” is a worthwhile thing to do for anyone with a clever idea and a working knowledge of Objective-C. The proof is in the hundreds of apps succeeding in the market every day, many written by people working on their own and who never wrote an app before in their lives. As with anything else, practice does make perfect. But hopefully with all the resources available, and the knowledge gained from this ebook, you have already started down the path toward joining the growing legions of iOS app developers. If so, we welcome you!

Appendix 1 — Test Drive Sample App ViewController.m Source Code

fig. 15 Editing a table in Interface Builder.

33

The iOS revolutionIt’s a story that never gets old. The weekend that iPad Minis and the fourth generation iPads went on sale (November 2-5, 2012) Apple sold over 3 million of the devices — a record for first-weekend iPad sales. Two months earlier the company had set another record: first weekend sales of over 5 million for the iPhone 5. Since the introduc-tion of the first iPhone back in 2007,

iOS-based devices (iPhone, iPad, iPad Mini and iPod Touch) continue to rewrite the definition of what constitutes a successful product. By the end of 2012, over 400 million iOS devices had been sold.

What makes iOS devices so successful? Innovation and product features are clearly a big part. Before the iPhone most people had not interacted with a multi-touch interface. They had never zoomed with a pinch or switched between portrait and landscape by merely rotating a device in their hand. Carrying a phone that knew where they were, could suggest places to eat, and could offer directions on how to get there was also a novel experience.

But features like multi-touch, accelerometers and GPS are only part of the appeal. Even with all its innovations, iOS still might not have taken off the way it has if the only people figuring out ways to use those innovations worked at Apple. Most of the capabilities available in an iPhone or iPad in fact don’t come from Apple at all. They come from legions of third-party developers who work in a vast ecosystem that is also an Apple innovation. That ecosystem includes the iPhone, iPad, iPad Mini, iPods, App Store, iTunes, ad networks — and that’s just on the consumer side. On the developer side, you have Xcode, App Loader, testing tools, iTunes Connect — the list goes on.

As of September 2012, the App Store hosted over 700,000 apps that have collectively been downloaded over 30 billion times. Apple reported for October 2012 that App Store monthly revenues were

running at $333 million — a rate of about $4 billion per year — remarkable for a store that only opened in July 2008.

Another innovation that has spurred iOS app development is “The Cloud.” Cloud services make it easier for independent developers to create, support and make money from their apps. The Cloud solves data storage and cross-device and user-to-user sharing problems. If an app stores data in the Cloud, that part of the application is called the “backend,” while the part of the app that runs on the phone and interacts with the user is called the “front end.”

A cloud may be “private” — i.e., the services belong to an organization for the benefit of its employees and business partners. Or a cloud may be “public” — i.e., a company (such as Amazon or Kinvey) owns the services, which developers can then integrate into their own apps. If you are a developer and want to build your own backend, you certainly can do that. Whether you want to or not depends on whether your backend provides functionality common to many different apps. If it does (as in a shopping cart or user authenti-cation) then perhaps that time and money would be better spent on features that offer unique value to your customer. You may be better off hooking into a commercial backend provider via an API. Then you can focus on what counts most — a unique user experience and application-specific functionality. That brings us to the first step in making an app.

Define your appMost unsuccessful apps fail for any of four reasons:

1. the app was a solution in search of a problem (i.e., no real need existed) 2. the implementation was poor 3. the app tried to do too much; or 4. the Apple App Store rejected the app (either because the implementation was poor or it violated Apple’s content policies)

Keeping the app as simple as possible is the best way to avoid these pitfalls. Most successful apps (indeed, most successful consumer tech products) are based on what is called an MVP, or minimum viable product. It’s the product with the smallest feature set that can deliver the core function without any distracting “bells and whistles.” You know you have an MVP if the product would no longer function if you removed any single feature.

But what should that core feature be? One of the best examples of an MVP is Mail. Version 1 (on the Mac) offered a clear, limited and intuitive feature set whose usefulness was immediately obvious to anyone. Today’s iPhone version integrates seamlessly with your phone, contacts and calendaring. It auto-matically corrects spelling as you type, lets you email photos directly from your photos app, and does much more. But all that came later and was built on top of a basic core function. And that’s how your first app should be built. The key is to come up with something with a clear value that changes people’s lives.

So, in drawing up your MVP feature list, ask yourself what features are key to the experience. Some basic market research is probably in order, starting with a visit to the App Store to see what already exists (possibly to be improved upon and/or to compete with you). Likely

must-have core capabilities include:

• Performance (e.g., fast screen refresh)• Offline capability (i.e., ability to work when not connected to the Internet)• Location awareness (e.g., the data/experience will change with the user’s location)• Cloud syncing (e.g., users see the same data on multiple devices)• Push notifications (i.e., sending updated information to devices as soon as it is available)

When you have a handle on what your app does, the next step is to design it. Designing your app involves making choices of how infor-mation and controls are presented to the user as well as how to implement app logic, and figuring out what data lives locally and what belongs in the Cloud.

Design your appUser experience decisions determine the app’s look and feel. They answer questions such as: What does the app look like? What screens does it have? In the software development world, onscreen objects like buttons, sliders, and fill-in boxes are called widgets. So you need to decide which types of widgets will reside on which screens. And what actions will occur as a result of the user interacting with those widgets?

Keep in mind that users will expect to interact differently with a mobile device than they do with a PC because the screens on mobile devices are much smaller. They’ll expect to use their fingers instead of a mouse or a track pad. Ideally, your app can even be used with one hand holding the device while using just a thumb for scrolling andworking the app’s other controls— the Path app is a good example, and increasingly, so is Facebook.

Your app’s features will inform its architecture, which is how you’ll divide the code and data into functional parts. If your app requires interacting with other app users or networked services, you’ll need to figure out what piece of the logic lives in the app code and what comes from the backend. For example, your app might integrate with a restau-rant recommendation engine, share user location, or pull real-time traffic data. This is done using APIs provided by various service providers — but you don’t have to wire up your app to a network to get started. You can develop a prototype using predefined representative (or “dummy”) data. It’s easier to fine-tune the front end if you don’t have to simultaneously modify your backend too. Once you get the app’s look-and-feel right, then make those backend connections.

Once you’ve got the overall concept for your app, the next step is to express that design in terms of the iOS app architecture. That archi-tecture is the model for what parts an iOS app can contain and how those parts fit together. It’s a well thought-out approach for translat-ing a product concept into actual code you can deploy on a device.

WHY iOS?Besides the features and design of your first app, there’s one more decision you need to make before you start actual development. That’s whether to deploy on Apple’s iOS platform or on Google’s Android platform. (Some of this is also covered in our ebook, How to Make an App: Android Edition.) Reasons to develop for iOS include:

Customers more willing to pay. Perhaps it’s because of Android’s open source heritage, but whatever the reason, Android apps gener-ate less than 10% of the total dollars spent on mobile apps, despite having 75% of the smartphone market itself — and despite the fact that the average selling price of an app in the Google Play is $3.79 versus Apple App Store’s $2.01. In other words, Apple users are much more willing to spend money on apps.

The Apple Ecosystem. Some developers and users prefer Apple’s closed and more tightly controlled environment. Apple’s ecosystem, consisting of Xcode, iCloud, iTunes, the App Store, the iPad, the iPhone, Mac computers, etc., offers a very holistic user experience with the ability to share data seamlessly across devices plus the

assurance of having applications pre-approved for quality and content prior to going on sale.

Xcode. Apple’s all-in-one IDE offers state-of-the-art offers features like a graphical interface builder and a syntax-aware and compiler-aware source editor.

The Apple Experience. From the fit and finish of its hardware to the customer service in its retail stores, to the way its hardware and software work flawlessly together, Apple has created the premium brand in consumer electronics. iOS developers share the benefits — so when someone downloads your iOS app, they already expect it’s a great product. And that it will also work flawlessly on their device.

Tablets. iOS has a clear advantage over Android in terms of tablet market adoption. Using Xcode, it’s also much easier to migrate an app from a phone to a tablet and vice versa than it is when develop-ing for Android.

Why Not iOS?Although iOS offers many compelling advantages as a platform for your mobile app, it also comes with some disadvantages. Here are three:

Closed Platform. iOS apps only run on Apple products so you can’t take advantage of features (like NFC) available only on non-iOS devices or market growth of non-iOS devices.

Market Growth. Today, iOS represents less than 15% of the total smartphone market, Although the total market (“the whole pie”) is still increasing at a fast rate, Android market growth outpaces iOS growth.

Approvals. The App Store’s app approval process is notoriously more time consuming than Google Play’s process.

The iOS app architectureAs noted earlier, a key reason why there are so many apps for iOS is because developing highly functional, polished apps for the platform is relatively easy. That’s mainly because of: 1) the design of the development tools, and 2) the key architectural features most iOS apps have in common. So let’s start with some concepts since it helps to know what goes into an app before trying to create one. We’ll begin with:

• Design patterns• Frameworks• Delegation• Storyboard• Windows• Outlets• Supporting files• Products

Design patterns. iOS apps implement what is known as a Mod-el-View-Controller (MVC) pattern. A pattern is a common way to structure code that solves a particular design problem. The MVC pattern separates application code in a way that allows you to easily change one part of an app without having to change other parts. An MVC pattern consists of three components:

• The Model is the logic that acts on the data, such as to store or retrieve data from a database, compute the distance between two cities on a map, etc. An example of a model is the Kinvey backend that stores your data in the Cloud as a service.

• The View provides the interface to the user; it displays the data and widgets (e.g., buttons and text fields) that allow the user to interact with the data. An iPhone app may have more than one view, as in the Contacts app, which displays a list view of all contacts or alternatively a view of each individual contact.

• The Controller is between the model and the view — i.e., it responds to user requests (made in a view) and retrieves results

(produced in a model). This is where developers spend most of their time — constructing the View Controller — by defining and attaching actions (or behaviors) to onscreen widgets. When the user taps a button, for example, it is the View Controller that determines what action will occur, such as retrieve stored data from your Kinvey-based data store. The link between a view object (like a button) to a controller action is called a connection.

Frameworks. You don’t actually have to write most of an app’s logic. It already exists as frameworks. A framework is a collection of classes that implements some function — such as connecting to the Internet, drawing a button, etc. Rather than write the code from scratch, you just use the frameworks supplied by iOS. Some frameworks are automatically present when you start a new project while others may need to be added (done via a drop down menu in Xcode’s Project Editor).

Delegation. Say, you want to customize the behavior of a framework’s object. You can’t actually modify the code of the framework class itself (prohibited since other apps may also use the framework). But what you can do is provide app-specific behavior in an application delegate object. If a delegate implements a method, it will be called by the delegating class to modify its behavior. In the Kinvey sample app (one of two examples we will be describing below), the AppDele-gate.h and AppDelegate.m — the header and implementation files for the UIApplicationDelegate, respectively — contain the code that authenticates an app to the Kinvey backend service.

Storyboards and XIBs. The MainStoryboard.storyboard file (or a .xib file, if you did not click on the “Use Storyboard” option when starting your project) contains the view information needed to implement the overall flow and display of your application and the user interface elements.

Windows. Each view (e.g., the contact list and individual contact details in the Contacts app) exists within a window. The window represents the entire device screen and is where all your views are presented.

Outlets. A variable by which a view object can be referenced in a controller. (For example, if you place a text field to capture a user's name, you might create an outlet called UITextField* nameField.)

Supporting files. These are files that provide resources (like PNG images and other static data) that your app needs as well as files that configure how the app will run. Other examples:

.pch files — precompiled headers used for the code files in your project.

.plist files — property lists that are small amounts of persistent data (like your app’s default user settings) consisting primarily of strings and numbers that you want your app to be able to access, modify if needed, and write back into the property list.

main.m file — your app’s main function. This is needed to launch the app, but you will not need to modify this file.

InfoPlist.strings file — used for localization.

Products. This is the file for your app (i.e., YourProduct.app) that is built when you click Xcode’s “run” button.

“Making an iOS app” involves working with these features in the typical, straightforward workflow:

• Storyboard your views by dragging and configuring graphicalobjects on a template

• Adding behaviors to the various widgets• Writing the classes as to define those behaviors (including

delegates)• Adding needed support files• Building and running the app• Iterating until you are satisfied with your app

This is all done within Xcode.

What’s Xcode?You can start developing functional, good-looking apps almost from the moment you download Xcode, Apple’s integrated development environment (IDE) for making iOS and Macintosh apps. Among other features, Xcode includes a source code editor, graphical user inter-face (GUI) editor (sometimes called Interface Builder), source code repository manager, compiler, and much more. iOS applications are typically developed by manipulating views graphically and by typing Objective-C code for the models and controllers.

To get Xcode, simply go to the App Store and download the applica-tion (it’s free). To do this, click on the App Store icon in your Mac’s dock, or visit https://itunes.apple.com/us/genre/ios/id36?mt=8

The app store will download and install Xcode in your Application folder. From Applications, double-click the Xcode icon to launch Xcode and you’ll see its splash screen (Figure 1). From there you can click on “Create a new Xcode project” to take you to a menu of several templates on which to base your application. Selecting a template opens an Xcode workspace pre-populated with frameworks and other files Xcode thinks you will need using that template.

Although you can develop, build and simulate your app on your computer in Xcode, you can’t run your app on a target device (even your own iPhone) until you become a registered iOS developer and join the iOS Developer Program. To do that, go to develop-er.app.com/ and navigate to the iOS Dev Center. While there, you will also find documentation, sample code and other useful resources such as information on how to submit your app to the iOS App Store.

Everything you do in Xcode is done in a window, called a workspace (Figure 2), consisting of multiple work areas, some of which are also divided into panes. All the files needed to build your app belong to a project, and the Navigator area (far left) lists all your projects (there can be several in a workspace) and all files for each project. Clicking on a file in the Navigator area shows its contents in the Editor area and invokes the appropriate editor. Clicking on a .h or .m file, for example, shows the file’s source code and invokes the Source editor, so you can edit the code. Clicking on .storyboard or .xib (sometimes called a “nib”) file shows the app’s storyboard and invokes the Inter-face Builder, so you can design a view using the Builder’s drag and drop features.

An especially handy feature is that the Editor area can have both a right and a left pane — with each pane aware of your edits in the other. So, for example, you can simultaneously edit an object’s .h

header file in the left pane and its corresponding .m in the right pane. Or you might click on a button object (displayed graphically) in the left pane and edit its method’s source code in the right pane. To toggle between a single pane (the “Standard Editor”) and double pane view (the “Assistant Editor”), use the Editor selector button on the right of the toolbar. You can option+command+click a symbol in the editor to open the definition in the opposite editor pane.

You can also resize the entire Editor area simply by dragging its borders. For even more editing space, you can also remove the Debug area or both the Debug and Utility areas using the View Selector button on the far right of the toolbar.

As its name suggests, the Debug area shows information, like variable state and console logs, helpful in debugging code.

The Utility area has two panes: the Inspector and Quick Help pane (top) and the Library pane (bottom). Although there are five inspectors — File, Help, Identity, Attributes, Size and Connec-tions — only the inspectors that are currently relevant appear in the Inspec-tor list at the top of the pane. (To see the name of an inspector, move the cursor over its icon in the Inspector selector bar.)

You will use inspectors to add and modify object attributes for views in the Interface Builder. For example, if you click on a UILabel in the Editor area of a storyboard, you can use the Attributes inspector to change the label’s color and use the Size inspector to change the label’s size.

The Help inspector shows help information about a selected class. Use the Identity inspector to view and manage an object’s metadata such as its class, runtime attributes, label and so forth. Use the

Connections inspector to view the outlets and actions of an interface object, to make new connections and to delete existing connections.

The Library pane has libraries of resources (like file templates, code snippets, interface objects and media files) that are prebuilt and ready to insert into your project. Use the Library selector to select which of these libraries (e.g., code snippets or interface objects) you wish to insert. To insert one, drag it directly into your storyboard while using the Interface Builder editor.

These are basics you need to know to get started using Xcode to build your first app. But to really understand how it’s done, it helps to walk through an actual app or two. Let’s start with a simple “Hello World” app that does not employ a backend connection, and then look at a somewhat more functional app that does.

“Hello World!” sample appThis app displays a button (“Press Me”) and a label (“Label”) so that when the user presses the button the text of the label changes to “Hello World!” as in Figure 3:

To get started, launch Xcode and select “Create a New Xcode Project.” From the iOS Application templates, select “Single View Application” and click “Next.” Fill in your product’s name and a company identifier, typically “com.yourCompanyName.” Deselect “Use Storyboards” and leave “Use Automatic Reference Counting” selected. Then click “Next” and select a destination for your projects files.

Follow these steps to make your app:

1. Select your project’s ViewController.xib file in the Navigator(Figure 4), to open the Interface Builder editor.

2. Drag a “Round Rect Button” from the Objects library (lowerright) onto the view in the Editor area; select the button’s textand type “Press Me.”

3. Drag a Label from the objects library onto the view, as well.4. Select and drag the Label sizing handles, centering the object

and making it wide enough to hold the “Hello World!” text; then,

5. With the “Hello World!” label still selected, click on centeralignment in the Attributes inspector.

6. Open the Assistant Editor (Figure 5), exposing the source codeheader file (ViewController.h) of the view controller you justbuilt graphically.

7. Select the button and control-drag from the button to justbelow the ViewController definition in the Assistant panel. Inthe form that opens, select “Action” for the connection type,type in a name (“showText”) and click “Connect.” This creates aninterface builder (IB) action as highlighted in Figure 6.

8. Next step is to create an outlet for the label. To do this, selectthe label object and control-drag from the label to just belowthe IB action you just created. Select “Outlet” as the connectiontype and enter a name “label” and click “Connect.” This createsan interface builder (IB) outlet as shown in Figure 7.

9. Finally, it’s time to add some logic to the view controller so itknows what to do when the button is pressed. To do this, select “ViewController.m” in the project navigator to show the code editor. Find the button’s IBAction you just created (near the bottom), place your cursor between the { } brackets and hit the return key a few times to create some extra space. Then in that space type the method for how you want the label you speci-fied to respond: _label.text=”Hello World!”; as highlighted in Figure 8.

Congratulations! Your app is done. To build and run your new app in the simulator, click the Xcode Run button in the left corner of the toolbar. When you click the button, the text will update.

Sample app with a backend This second app (named “Kinvey Test Drive”) lets the user type text on an iPhone and save the text to a backend service, like Kinvey. It also lets the user load text on the iPhone from their Kinvey backend. Reading about this app will help you learn:

• How to set up Kinvey’s library in an iOS project• Additional Interface Builder techniques you can use to story-board an application• How to add view controller logic to interact with the backend service, allowing you to save and retrieve data

We will first present the app as a running application and then take it apart so you can see how it was made. To make the app yourself, you can review the various sections below and replicate the steps in your copy of Xcode.

First, to see the app in action, you should download the app and run it on your system. To do that, sign up for Kinvey, then navigate to “Dev Center”, “Samples,” find the “Test Drive” app, and click on its icon. (If you can’t find it right away, make sure you select iOS as your platform on the right side of the menu bar.) Click the download button to download the app’s project files to your computer. Then launch Xcode — just double click on the .xcodeproj file in the project folder.

But before you can run the app, you need to set up the app’s Kinvey backend.

Set Up Kinvey as a Backend Data StoreTest Drive’s project files include all the code the sample app needs in order to talk to Kinvey. However, that would not be the case if you were to build an app from scratch — so you would have to go through an initial Kinvey setup procedure. This involves downloading the Kinvey library files from the downloads section of devcenter.kin-vey.com and dragging them to the Navigator’s Frameworks folder in Xcode. You also need to tell Xcode to link your project with additional iOS frameworks. To find these frameworks, click on the Project folder

at the very top of the Navigator pane — which displays the Project editor — and then select the “Build Settings” tab. For detailed instruc-tions, complete the “Getting Started” page under “Guides” on the Kinvey website. But again, you can skip this setup procedure for now in order to run the downloaded Kinvey Test Drive app.

But you must still do this step: To run any app that uses Kinvey (including Test Drive) you need to do the “Create an App” step on the Kinvey website. Click on “My Apps” in the Kinvey menu bar and then click on “Add an App,” which will open an “Add” page. Type in a name for your app and click on the Apple logo and then click “Create.” The page that opens shows your App’s credentials. Copy and paste the App Key and App Secret into the AppDelegate.m file of the download-ed Test Drive project:

You are now ready to run the app — click on the Xcode run button and wait for the simulator to open and the app to appear (Figure 9).

Clicking the “+” toolbar button opens an alert (Figure 10) with an empty field into which the user can type some text (e.g., “some new data”). Clicking “save” uploads the data to Kinvey and displays text on the screen (a table view) and also displays an alert that the save worked (Figure 11).

To test the load function, enter some data (e.g., “some data to load”) in the “name” field of the Kinvey collection. To see the load, the swipe down on the table on the phone until the refresh spinner starts, and then the new data will appear in the table (Figure 12).

Figure 13 shows the Kinvey collection after the save that Figure 10 depicts on the iPhone. Figure 14 shows the Kinvey collection after the user adds a new row to the testObjects collection using the web browser. Note that every time a save is done on the iPhone, Kinvey automatically adds a new row (displayed on a collection refresh). To add a new row manually in the browser, click “+ row,” and type some descriptive text in the “name” column. That data will now load on the iPhone when the user pulls down on the table.

Storyboard the Test Drive AppMost of the Test Drive user interface objects visible in the simulation are available in Xcode’s Object Library and can therefore be added to the view graphically. The UI objects consist of a:

• Table view• Toolbar• Tool Bar Button item – flexible space• Tool Bar Button item – Add• Table view cell• Label – Title• Refresh Control

To create this app yourself, you would follow these steps:

• Launch Xcode and select the “Single View Application” template• Select the “Use Storyboard” option• Replace the default UIviewcontroller object with a UITableView-Controller • Drag and drop the other objects, in the order listed, onto the UIviewcontroller

Also note:

• The Flexible Space Bar Button item fills up the space on the toolbar so the add button is at the right. This is a standard pattern in table-based iPhone apps.• The add button shows the system “+” sign. That is done by dragging a bar button item onto the toolbar, clicking on the Identifier drop down menu in the Attributes inspector; and then selecting the “Add” option.

As with the “Hello World!” app, once your app’s view is complete (Figure 15), you would still have to create the various methods and connections that bring them to life. This is done using the Source editor while working with the ViewController.m file.

Add View Controller LogicSince the app performs two basic operations (save data to Kinvey and load data from Kinvey) these two methods must be added to the ViewController header file. That’s done with a control-drag from the “+” bar button over to just under the “@interface ViewController” line in ViewController.h. (Open the Assistant editor to see both the storyboard and the file source.)

During the drag, the popup appears, asking for the name and type of connection. Enter “action” for the connection type and “add” for the name. Then repeat the drag, this time from the refresh control and using “load” for the name (Figure 16).

Note: to follow this discussion it will help to have the referenced files open in your Xcode Source editor.

In ViewController.m, you will see the implementation code associated with each of the two Interface Builder methods, whose names Xcode added automatically to the .m file:

- (IBAction)add:(id)sender- (IBAction)load:(id)sender

You will also see a third section of code not associated with these methods, which starts with the line: “#pragma mark - Table View Stuff” These methods support the table view and are part of UITableViewD-elegate and UITableViewDataSource. They handle controlling the

display of the table, and respond to user gestures. For example, swiping a table cell will show the delete button because tableView:-canEditRowAtIndexPath: returns YES and tableView:editingStyleForRowA-tIndexPath: returns UITableViewCellEditingStyleDelete. If you tap the delete button, the delegate method tableView:commitEditingStyle:for-RowAtIndexPath: is called. The code of this method deletes the data for the row and removes it from Kinvey’s data store. When the backend delete is completed, the app displays an alert describing the success or failure.

The way that all three sections (and all Kinvey-enabled apps) move data in and out of a Kinvey collection is by getting a reference to the app’s backend collection (named “testObjects”), which is filled with instances (each named “TestObject”) of the data the app wants to move. That’s why you’ll find the following code repeated three times in Test Drive’s View Controller (once for the add, once for the load, and once for the delete):

To support these statements it is required to have a data object class (TestObject). To see how these files are written in the sample project, click on TestObject.h file and TestObject.m in the Navigator pane. If you were to supply these files in your own app, you would click File > New File, and specify Objective-C class, which would be a subclass of NSObject. Then you would type in the code, with a property for each column in the Kinvey backend collection (including one for the object’s id).

As mentioned earlier, your app also needs to authenticate itself to Kinvey, which is handled by AppDelegate.h and AppDelgate.m. These files are created by Xcode when you create a new project, and start out with just a stub implementation. Look in the sample app source

files for code to copy and paste.

For both the save and load operations, however, moving the data in and out of a backend collection is only part of the work. Table 1 lists all the functions that implements the save and load in the ViewCon-troller.m file, along with pointers to its corresponding block of imple-mentation source code. (For each function, its corresponding code begins with the “Starts at” line and ends with the “Ends at” line.) Refer to Appendix 1 to find the actual source code.

Say Hello To Our WorldThe key takeaway from all this is that “making an app” is a worthwhile thing to do for anyone with a clever idea and a working knowledge of Objective-C. The proof is in the hundreds of apps succeeding in the market every day, many written by people working on their own and who never wrote an app before in their lives. As with anything else, practice does make perfect. But hopefully with all the resources available, and the knowledge gained from this ebook, you have already started down the path toward joining the growing legions of iOS app developers. If so, we welcome you!

Appendix 1 — Test Drive Sample App ViewController.m Source Code

fig. 16 Drag an add: action from the button bar to the ViewController header file

The iOS revolutionIt’s a story that never gets old. The weekend that iPad Minis and the fourth generation iPads went on sale (November 2-5, 2012) Apple sold over 3 million of the devices — a record for first-weekend iPad sales. Two months earlier the company had set another record: first weekend sales of over 5 million for the iPhone 5. Since the introduc-tion of the first iPhone back in 2007,

iOS-based devices (iPhone, iPad, iPad Mini and iPod Touch) continue to rewrite the definition of what constitutes a successful product. By the end of 2012, over 400 million iOS devices had been sold.

What makes iOS devices so successful? Innovation and product features are clearly a big part. Before the iPhone most people had not interacted with a multi-touch interface. They had never zoomed with a pinch or switched between portrait and landscape by merely rotating a device in their hand. Carrying a phone that knew where they were, could suggest places to eat, and could offer directions on how to get there was also a novel experience.

But features like multi-touch, accelerometers and GPS are only part of the appeal. Even with all its innovations, iOS still might not have taken off the way it has if the only people figuring out ways to use those innovations worked at Apple. Most of the capabilities available in an iPhone or iPad in fact don’t come from Apple at all. They come from legions of third-party developers who work in a vast ecosystem that is also an Apple innovation. That ecosystem includes the iPhone, iPad, iPad Mini, iPods, App Store, iTunes, ad networks — and that’s just on the consumer side. On the developer side, you have Xcode, App Loader, testing tools, iTunes Connect — the list goes on.

As of September 2012, the App Store hosted over 700,000 apps that have collectively been downloaded over 30 billion times. Apple reported for October 2012 that App Store monthly revenues were

running at $333 million — a rate of about $4 billion per year — remarkable for a store that only opened in July 2008.

Another innovation that has spurred iOS app development is “The Cloud.” Cloud services make it easier for independent developers to create, support and make money from their apps. The Cloud solves data storage and cross-device and user-to-user sharing problems. If an app stores data in the Cloud, that part of the application is called the “backend,” while the part of the app that runs on the phone and interacts with the user is called the “front end.”

A cloud may be “private” — i.e., the services belong to an organization for the benefit of its employees and business partners. Or a cloud may be “public” — i.e., a company (such as Amazon or Kinvey) owns the services, which developers can then integrate into their own apps. If you are a developer and want to build your own backend, you certainly can do that. Whether you want to or not depends on whether your backend provides functionality common to many different apps. If it does (as in a shopping cart or user authenti-cation) then perhaps that time and money would be better spent on features that offer unique value to your customer. You may be better off hooking into a commercial backend provider via an API. Then you can focus on what counts most — a unique user experience and application-specific functionality. That brings us to the first step in making an app.

Define your appMost unsuccessful apps fail for any of four reasons:

1. the app was a solution in search of a problem (i.e., no real need existed) 2. the implementation was poor 3. the app tried to do too much; or 4. the Apple App Store rejected the app (either because the implementation was poor or it violated Apple’s content policies)

Keeping the app as simple as possible is the best way to avoid these pitfalls. Most successful apps (indeed, most successful consumer tech products) are based on what is called an MVP, or minimum viable product. It’s the product with the smallest feature set that can deliver the core function without any distracting “bells and whistles.” You know you have an MVP if the product would no longer function if you removed any single feature.

But what should that core feature be? One of the best examples of an MVP is Mail. Version 1 (on the Mac) offered a clear, limited and intuitive feature set whose usefulness was immediately obvious to anyone. Today’s iPhone version integrates seamlessly with your phone, contacts and calendaring. It auto-matically corrects spelling as you type, lets you email photos directly from your photos app, and does much more. But all that came later and was built on top of a basic core function. And that’s how your first app should be built. The key is to come up with something with a clear value that changes people’s lives.

So, in drawing up your MVP feature list, ask yourself what features are key to the experience. Some basic market research is probably in order, starting with a visit to the App Store to see what already exists (possibly to be improved upon and/or to compete with you). Likely

must-have core capabilities include:

• Performance (e.g., fast screen refresh)• Offline capability (i.e., ability to work when not connected to the Internet)• Location awareness (e.g., the data/experience will change with the user’s location)• Cloud syncing (e.g., users see the same data on multiple devices)• Push notifications (i.e., sending updated information to devices as soon as it is available)

When you have a handle on what your app does, the next step is to design it. Designing your app involves making choices of how infor-mation and controls are presented to the user as well as how to implement app logic, and figuring out what data lives locally and what belongs in the Cloud.

Design your appUser experience decisions determine the app’s look and feel. They answer questions such as: What does the app look like? What screens does it have? In the software development world, onscreen objects like buttons, sliders, and fill-in boxes are called widgets. So you need to decide which types of widgets will reside on which screens. And what actions will occur as a result of the user interacting with those widgets?

Keep in mind that users will expect to interact differently with a mobile device than they do with a PC because the screens on mobile devices are much smaller. They’ll expect to use their fingers instead of a mouse or a track pad. Ideally, your app can even be used with one hand holding the device while using just a thumb for scrolling andworking the app’s other controls— the Path app is a good example, and increasingly, so is Facebook.

Your app’s features will inform its architecture, which is how you’ll divide the code and data into functional parts. If your app requires interacting with other app users or networked services, you’ll need to figure out what piece of the logic lives in the app code and what comes from the backend. For example, your app might integrate with a restau-rant recommendation engine, share user location, or pull real-time traffic data. This is done using APIs provided by various service providers — but you don’t have to wire up your app to a network to get started. You can develop a prototype using predefined representative (or “dummy”) data. It’s easier to fine-tune the front end if you don’t have to simultaneously modify your backend too. Once you get the app’s look-and-feel right, then make those backend connections.

Once you’ve got the overall concept for your app, the next step is to express that design in terms of the iOS app architecture. That archi-tecture is the model for what parts an iOS app can contain and how those parts fit together. It’s a well thought-out approach for translat-ing a product concept into actual code you can deploy on a device.

WHY iOS?Besides the features and design of your first app, there’s one more decision you need to make before you start actual development. That’s whether to deploy on Apple’s iOS platform or on Google’s Android platform. (Some of this is also covered in our ebook, How to Make an App: Android Edition.) Reasons to develop for iOS include:

Customers more willing to pay. Perhaps it’s because of Android’s open source heritage, but whatever the reason, Android apps gener-ate less than 10% of the total dollars spent on mobile apps, despite having 75% of the smartphone market itself — and despite the fact that the average selling price of an app in the Google Play is $3.79 versus Apple App Store’s $2.01. In other words, Apple users are much more willing to spend money on apps.

The Apple Ecosystem. Some developers and users prefer Apple’s closed and more tightly controlled environment. Apple’s ecosystem, consisting of Xcode, iCloud, iTunes, the App Store, the iPad, the iPhone, Mac computers, etc., offers a very holistic user experience with the ability to share data seamlessly across devices plus the

assurance of having applications pre-approved for quality and content prior to going on sale.

Xcode. Apple’s all-in-one IDE offers state-of-the-art offers features like a graphical interface builder and a syntax-aware and compiler-aware source editor.

The Apple Experience. From the fit and finish of its hardware to the customer service in its retail stores, to the way its hardware and software work flawlessly together, Apple has created the premium brand in consumer electronics. iOS developers share the benefits — so when someone downloads your iOS app, they already expect it’s a great product. And that it will also work flawlessly on their device.

Tablets. iOS has a clear advantage over Android in terms of tablet market adoption. Using Xcode, it’s also much easier to migrate an app from a phone to a tablet and vice versa than it is when develop-ing for Android.

Why Not iOS?Although iOS offers many compelling advantages as a platform for your mobile app, it also comes with some disadvantages. Here are three:

Closed Platform. iOS apps only run on Apple products so you can’t take advantage of features (like NFC) available only on non-iOS devices or market growth of non-iOS devices.

Market Growth. Today, iOS represents less than 15% of the total smartphone market, Although the total market (“the whole pie”) is still increasing at a fast rate, Android market growth outpaces iOS growth.

Approvals. The App Store’s app approval process is notoriously more time consuming than Google Play’s process.

The iOS app architectureAs noted earlier, a key reason why there are so many apps for iOS is because developing highly functional, polished apps for the platform is relatively easy. That’s mainly because of: 1) the design of the development tools, and 2) the key architectural features most iOS apps have in common. So let’s start with some concepts since it helps to know what goes into an app before trying to create one. We’ll begin with:

• Design patterns• Frameworks• Delegation• Storyboard• Windows• Outlets• Supporting files• Products

Design patterns. iOS apps implement what is known as a Mod-el-View-Controller (MVC) pattern. A pattern is a common way to structure code that solves a particular design problem. The MVC pattern separates application code in a way that allows you to easily change one part of an app without having to change other parts. An MVC pattern consists of three components:

• The Model is the logic that acts on the data, such as to store or retrieve data from a database, compute the distance between two cities on a map, etc. An example of a model is the Kinvey backend that stores your data in the Cloud as a service.

• The View provides the interface to the user; it displays the data and widgets (e.g., buttons and text fields) that allow the user to interact with the data. An iPhone app may have more than one view, as in the Contacts app, which displays a list view of all contacts or alternatively a view of each individual contact.

• The Controller is between the model and the view — i.e., it responds to user requests (made in a view) and retrieves results

(produced in a model). This is where developers spend most of their time — constructing the View Controller — by defining and attaching actions (or behaviors) to onscreen widgets. When the user taps a button, for example, it is the View Controller that determines what action will occur, such as retrieve stored data from your Kinvey-based data store. The link between a view object (like a button) to a controller action is called a connection.

Frameworks. You don’t actually have to write most of an app’s logic. It already exists as frameworks. A framework is a collection of classes that implements some function — such as connecting to the Internet, drawing a button, etc. Rather than write the code from scratch, you just use the frameworks supplied by iOS. Some frameworks are automatically present when you start a new project while others may need to be added (done via a drop down menu in Xcode’s Project Editor).

Delegation. Say, you want to customize the behavior of a framework’s object. You can’t actually modify the code of the framework class itself (prohibited since other apps may also use the framework). But what you can do is provide app-specific behavior in an application delegate object. If a delegate implements a method, it will be called by the delegating class to modify its behavior. In the Kinvey sample app (one of two examples we will be describing below), the AppDele-gate.h and AppDelegate.m — the header and implementation files for the UIApplicationDelegate, respectively — contain the code that authenticates an app to the Kinvey backend service.

Storyboards and XIBs. The MainStoryboard.storyboard file (or a .xib file, if you did not click on the “Use Storyboard” option when starting your project) contains the view information needed to implement the overall flow and display of your application and the user interface elements.

Windows. Each view (e.g., the contact list and individual contact details in the Contacts app) exists within a window. The window represents the entire device screen and is where all your views are presented.

Outlets. A variable by which a view object can be referenced in a controller. (For example, if you place a text field to capture a user's name, you might create an outlet called UITextField* nameField.)

Supporting files. These are files that provide resources (like PNG images and other static data) that your app needs as well as files that configure how the app will run. Other examples:

.pch files — precompiled headers used for the code files in your project.

.plist files — property lists that are small amounts of persistent data (like your app’s default user settings) consisting primarily of strings and numbers that you want your app to be able to access, modify if needed, and write back into the property list.

main.m file — your app’s main function. This is needed to launch the app, but you will not need to modify this file.

InfoPlist.strings file — used for localization.

Products. This is the file for your app (i.e., YourProduct.app) that is built when you click Xcode’s “run” button.

“Making an iOS app” involves working with these features in the typical, straightforward workflow:

• Storyboard your views by dragging and configuring graphicalobjects on a template

• Adding behaviors to the various widgets• Writing the classes as to define those behaviors (including

delegates)• Adding needed support files• Building and running the app• Iterating until you are satisfied with your app

This is all done within Xcode.

What’s Xcode?You can start developing functional, good-looking apps almost from the moment you download Xcode, Apple’s integrated development environment (IDE) for making iOS and Macintosh apps. Among other features, Xcode includes a source code editor, graphical user inter-face (GUI) editor (sometimes called Interface Builder), source code repository manager, compiler, and much more. iOS applications are typically developed by manipulating views graphically and by typing Objective-C code for the models and controllers.

To get Xcode, simply go to the App Store and download the applica-tion (it’s free). To do this, click on the App Store icon in your Mac’s dock, or visit https://itunes.apple.com/us/genre/ios/id36?mt=8

The app store will download and install Xcode in your Application folder. From Applications, double-click the Xcode icon to launch Xcode and you’ll see its splash screen (Figure 1). From there you can click on “Create a new Xcode project” to take you to a menu of several templates on which to base your application. Selecting a template opens an Xcode workspace pre-populated with frameworks and other files Xcode thinks you will need using that template.

Although you can develop, build and simulate your app on your computer in Xcode, you can’t run your app on a target device (even your own iPhone) until you become a registered iOS developer and join the iOS Developer Program. To do that, go to develop-er.app.com/ and navigate to the iOS Dev Center. While there, you will also find documentation, sample code and other useful resources such as information on how to submit your app to the iOS App Store.

Everything you do in Xcode is done in a window, called a workspace (Figure 2), consisting of multiple work areas, some of which are also divided into panes. All the files needed to build your app belong to a project, and the Navigator area (far left) lists all your projects (there can be several in a workspace) and all files for each project. Clicking on a file in the Navigator area shows its contents in the Editor area and invokes the appropriate editor. Clicking on a .h or .m file, for example, shows the file’s source code and invokes the Source editor, so you can edit the code. Clicking on .storyboard or .xib (sometimes called a “nib”) file shows the app’s storyboard and invokes the Inter-face Builder, so you can design a view using the Builder’s drag and drop features.

An especially handy feature is that the Editor area can have both a right and a left pane — with each pane aware of your edits in the other. So, for example, you can simultaneously edit an object’s .h

header file in the left pane and its corresponding .m in the right pane. Or you might click on a button object (displayed graphically) in the left pane and edit its method’s source code in the right pane. To toggle between a single pane (the “Standard Editor”) and double pane view (the “Assistant Editor”), use the Editor selector button on the right of the toolbar. You can option+command+click a symbol in the editor to open the definition in the opposite editor pane.

You can also resize the entire Editor area simply by dragging its borders. For even more editing space, you can also remove the Debug area or both the Debug and Utility areas using the View Selector button on the far right of the toolbar.

As its name suggests, the Debug area shows information, like variable state and console logs, helpful in debugging code.

The Utility area has two panes: the Inspector and Quick Help pane (top) and the Library pane (bottom). Although there are five inspectors — File, Help, Identity, Attributes, Size and Connec-tions — only the inspectors that are currently relevant appear in the Inspec-tor list at the top of the pane. (To see the name of an inspector, move the cursor over its icon in the Inspector selector bar.)

You will use inspectors to add and modify object attributes for views in the Interface Builder. For example, if you click on a UILabel in the Editor area of a storyboard, you can use the Attributes inspector to change the label’s color and use the Size inspector to change the label’s size.

The Help inspector shows help information about a selected class. Use the Identity inspector to view and manage an object’s metadata such as its class, runtime attributes, label and so forth. Use the

Connections inspector to view the outlets and actions of an interface object, to make new connections and to delete existing connections.

The Library pane has libraries of resources (like file templates, code snippets, interface objects and media files) that are prebuilt and ready to insert into your project. Use the Library selector to select which of these libraries (e.g., code snippets or interface objects) you wish to insert. To insert one, drag it directly into your storyboard while using the Interface Builder editor.

These are basics you need to know to get started using Xcode to build your first app. But to really understand how it’s done, it helps to walk through an actual app or two. Let’s start with a simple “Hello World” app that does not employ a backend connection, and then look at a somewhat more functional app that does.

“Hello World!” sample appThis app displays a button (“Press Me”) and a label (“Label”) so that when the user presses the button the text of the label changes to “Hello World!” as in Figure 3:

To get started, launch Xcode and select “Create a New Xcode Project.” From the iOS Application templates, select “Single View Application” and click “Next.” Fill in your product’s name and a company identifier, typically “com.yourCompanyName.” Deselect “Use Storyboards” and leave “Use Automatic Reference Counting” selected. Then click “Next” and select a destination for your projects files.

Follow these steps to make your app:

1. Select your project’s ViewController.xib file in the Navigator(Figure 4), to open the Interface Builder editor.

2. Drag a “Round Rect Button” from the Objects library (lowerright) onto the view in the Editor area; select the button’s textand type “Press Me.”

3. Drag a Label from the objects library onto the view, as well.4. Select and drag the Label sizing handles, centering the object

and making it wide enough to hold the “Hello World!” text; then,

5. With the “Hello World!” label still selected, click on centeralignment in the Attributes inspector.

6. Open the Assistant Editor (Figure 5), exposing the source codeheader file (ViewController.h) of the view controller you justbuilt graphically.

7. Select the button and control-drag from the button to justbelow the ViewController definition in the Assistant panel. Inthe form that opens, select “Action” for the connection type,type in a name (“showText”) and click “Connect.” This creates aninterface builder (IB) action as highlighted in Figure 6.

8. Next step is to create an outlet for the label. To do this, selectthe label object and control-drag from the label to just belowthe IB action you just created. Select “Outlet” as the connectiontype and enter a name “label” and click “Connect.” This createsan interface builder (IB) outlet as shown in Figure 7.

9. Finally, it’s time to add some logic to the view controller so itknows what to do when the button is pressed. To do this, select “ViewController.m” in the project navigator to show the code editor. Find the button’s IBAction you just created (near the bottom), place your cursor between the { } brackets and hit the return key a few times to create some extra space. Then in that space type the method for how you want the label you speci-fied to respond: _label.text=”Hello World!”; as highlighted in Figure 8.

Congratulations! Your app is done. To build and run your new app in the simulator, click the Xcode Run button in the left corner of the toolbar. When you click the button, the text will update.

Sample app with a backend This second app (named “Kinvey Test Drive”) lets the user type text on an iPhone and save the text to a backend service, like Kinvey. It also lets the user load text on the iPhone from their Kinvey backend. Reading about this app will help you learn:

• How to set up Kinvey’s library in an iOS project• Additional Interface Builder techniques you can use to story-board an application• How to add view controller logic to interact with the backend service, allowing you to save and retrieve data

We will first present the app as a running application and then take it apart so you can see how it was made. To make the app yourself, you can review the various sections below and replicate the steps in your copy of Xcode.

First, to see the app in action, you should download the app and run it on your system. To do that, sign up for Kinvey, then navigate to “Dev Center”, “Samples,” find the “Test Drive” app, and click on its icon. (If you can’t find it right away, make sure you select iOS as your platform on the right side of the menu bar.) Click the download button to download the app’s project files to your computer. Then launch Xcode — just double click on the .xcodeproj file in the project folder.

But before you can run the app, you need to set up the app’s Kinvey backend.

Set Up Kinvey as a Backend Data StoreTest Drive’s project files include all the code the sample app needs in order to talk to Kinvey. However, that would not be the case if you were to build an app from scratch — so you would have to go through an initial Kinvey setup procedure. This involves downloading the Kinvey library files from the downloads section of devcenter.kin-vey.com and dragging them to the Navigator’s Frameworks folder in Xcode. You also need to tell Xcode to link your project with additional iOS frameworks. To find these frameworks, click on the Project folder

at the very top of the Navigator pane — which displays the Project editor — and then select the “Build Settings” tab. For detailed instruc-tions, complete the “Getting Started” page under “Guides” on the Kinvey website. But again, you can skip this setup procedure for now in order to run the downloaded Kinvey Test Drive app.

But you must still do this step: To run any app that uses Kinvey (including Test Drive) you need to do the “Create an App” step on the Kinvey website. Click on “My Apps” in the Kinvey menu bar and then click on “Add an App,” which will open an “Add” page. Type in a name for your app and click on the Apple logo and then click “Create.” The page that opens shows your App’s credentials. Copy and paste the App Key and App Secret into the AppDelegate.m file of the download-ed Test Drive project:

You are now ready to run the app — click on the Xcode run button and wait for the simulator to open and the app to appear (Figure 9).

Clicking the “+” toolbar button opens an alert (Figure 10) with an empty field into which the user can type some text (e.g., “some new data”). Clicking “save” uploads the data to Kinvey and displays text on the screen (a table view) and also displays an alert that the save worked (Figure 11).

To test the load function, enter some data (e.g., “some data to load”) in the “name” field of the Kinvey collection. To see the load, the swipe down on the table on the phone until the refresh spinner starts, and then the new data will appear in the table (Figure 12).

Figure 13 shows the Kinvey collection after the save that Figure 10 depicts on the iPhone. Figure 14 shows the Kinvey collection after the user adds a new row to the testObjects collection using the web browser. Note that every time a save is done on the iPhone, Kinvey automatically adds a new row (displayed on a collection refresh). To add a new row manually in the browser, click “+ row,” and type some descriptive text in the “name” column. That data will now load on the iPhone when the user pulls down on the table.

Storyboard the Test Drive AppMost of the Test Drive user interface objects visible in the simulation are available in Xcode’s Object Library and can therefore be added to the view graphically. The UI objects consist of a:

• Table view• Toolbar• Tool Bar Button item – flexible space• Tool Bar Button item – Add• Table view cell• Label – Title• Refresh Control

To create this app yourself, you would follow these steps:

• Launch Xcode and select the “Single View Application” template• Select the “Use Storyboard” option• Replace the default UIviewcontroller object with a UITableView-Controller • Drag and drop the other objects, in the order listed, onto the UIviewcontroller

Also note:

• The Flexible Space Bar Button item fills up the space on the toolbar so the add button is at the right. This is a standard pattern in table-based iPhone apps.• The add button shows the system “+” sign. That is done by dragging a bar button item onto the toolbar, clicking on the Identifier drop down menu in the Attributes inspector; and then selecting the “Add” option.

As with the “Hello World!” app, once your app’s view is complete (Figure 15), you would still have to create the various methods and connections that bring them to life. This is done using the Source editor while working with the ViewController.m file.

Add View Controller LogicSince the app performs two basic operations (save data to Kinvey and load data from Kinvey) these two methods must be added to the ViewController header file. That’s done with a control-drag from the “+” bar button over to just under the “@ interface ViewController” line in ViewController.h. (Open the Assistant editor to see both the storyboard and the file source.)

During the drag, the popup appears, asking for the name and type of connection. Enter “action” for the connection type and “add” for the name. Then repeat the drag, this time from the refresh control and using “add” for the name (Figure 16).

Note: to follow this discussion it will help to have the referenced files open in your Xcode Source editor.

In ViewController.m, you will see the implementation code associated with each of the two Interface Builder methods, whose names Xcode added automatically to the .m file:

- (IBAction)add:(id)sender- (IBAction)load:(id)sender

You will also see a third section of code not associated with these methods, which starts with the line: “#pragma mark - Table View Stuff.” These methods support the table view and are part of UITableViewD-elegate and UITableViewDataSource. They handle controlling the

display of the table, and respond to user gestures. For example, swiping a table cell will show the delete button because tableView:-canEditRowAtIndexPath: returns YES and tableView:editingStyleForRowA-tIndexPath: returns UITableViewCellEditingStyleDelete. If you tap the delete button, the delegate method tableView:commitEditingStyle:for-RowAtIndexPath: is called. The code of this method deletes the data for the row and removes it from Kinvey’s data store. When the backend delete is completed, the app displays an alert describing the success or failure.

The way that all three sections (and all Kinvey-enabled apps) move data in and out of a Kinvey collection is by getting a reference to the app’s backend collection (named “testObjects”), which is filled with instances (each named “TestObject”) of the data the app wants to move. That’s why you’ll find the following code repeated three times in Test Drive’s View Controller (once for the add, once for the load, and once for the delete):

To support these statements it is required to have a data object class (TestObject). To see how these files are written in the sample project, click on TestObject.h file and TestObject.m in the Navigator pane. If you were to supply these files in your own app, you would click File > New File, and specify Objective-C class, which would be a subclass of NSObject. Then you would type in the code, with a property for each column in the Kinvey backend collection (including one for the object’s id).

As mentioned earlier, your app also needs to authenticate itself to Kinvey, which is handled by AppDelegate.h and AppDelgate.m. These files are created by Xcode when you create a new project, and start out with just a stub implementation. Look in the sample app source

files for code to copy and paste.

For both the save and load operations, however, moving the data in and out of a backend collection is only part of the work. Table 1 lists all the functions that implements the save and load in the ViewCon-troller.m file, along with pointers to its corresponding block of imple-mentation source code. (For each function, its corresponding code begins with the “Starts at” line and ends with the “Ends at” line.) Refer to Appendix 1 to find the actual source code.

Say Hello To Our WorldThe key takeaway from all this is that “making an app” is a worthwhile thing to do for anyone with a clever idea and a working knowledge of Objective-C. The proof is in the hundreds of apps succeeding in the market every day, many written by people working on their own and who never wrote an app before in their lives. As with anything else, practice does make perfect. But hopefully with all the resources available, and the knowledge gained from this ebook, you have already started down the path toward joining the growing legions of iOS app developers. If so, we welcome you!

Appendix 1 — Test Drive Sample App ViewController.m Source Code

34

KCSCollection *testObjects = [KCSCollectioncollectionFromString:@"testObjects"

ofClass:[TestObject class]];KCSAppdataStore *store = [KCSAppdataStore

storeWithCollection:testObjectsoptions:nil];

The iOS revolutionIt’s a story that never gets old. The weekend that iPad Minis and the fourth generation iPads went on sale (November 2-5, 2012) Apple sold over 3 million of the devices — a record for first-weekend iPad sales. Two months earlier the company had set another record: first weekend sales of over 5 million for the iPhone 5. Since the introduc-tion of the first iPhone back in 2007,

iOS-based devices (iPhone, iPad, iPad Mini and iPod Touch) continue to rewrite the definition of what constitutes a successful product. By the end of 2012, over 400 million iOS devices had been sold.

What makes iOS devices so successful? Innovation and product features are clearly a big part. Before the iPhone most people had not interacted with a multi-touch interface. They had never zoomed with a pinch or switched between portrait and landscape by merely rotating a device in their hand. Carrying a phone that knew where they were, could suggest places to eat, and could offer directions on how to get there was also a novel experience.

But features like multi-touch, accelerometers and GPS are only part of the appeal. Even with all its innovations, iOS still might not have taken off the way it has if the only people figuring out ways to use those innovations worked at Apple. Most of the capabilities available in an iPhone or iPad in fact don’t come from Apple at all. They come from legions of third-party developers who work in a vast ecosystem that is also an Apple innovation. That ecosystem includes the iPhone, iPad, iPad Mini, iPods, App Store, iTunes, ad networks — and that’s just on the consumer side. On the developer side, you have Xcode, App Loader, testing tools, iTunes Connect — the list goes on.

As of September 2012, the App Store hosted over 700,000 apps that have collectively been downloaded over 30 billion times. Apple reported for October 2012 that App Store monthly revenues were

running at $333 million — a rate of about $4 billion per year — remarkable for a store that only opened in July 2008.

Another innovation that has spurred iOS app development is “The Cloud.” Cloud services make it easier for independent developers to create, support and make money from their apps. The Cloud solves data storage and cross-device and user-to-user sharing problems. If an app stores data in the Cloud, that part of the application is called the “backend,” while the part of the app that runs on the phone and interacts with the user is called the “front end.”

A cloud may be “private” — i.e., the services belong to an organization for the benefit of its employees and business partners. Or a cloud may be “public” — i.e., a company (such as Amazon or Kinvey) owns the services, which developers can then integrate into their own apps. If you are a developer and want to build your own backend, you certainly can do that. Whether you want to or not depends on whether your backend provides functionality common to many different apps. If it does (as in a shopping cart or user authenti-cation) then perhaps that time and money would be better spent on features that offer unique value to your customer. You may be better off hooking into a commercial backend provider via an API. Then you can focus on what counts most — a unique user experience and application-specific functionality. That brings us to the first step in making an app.

Define your appMost unsuccessful apps fail for any of four reasons:

1. the app was a solution in search of a problem (i.e., no real need existed) 2. the implementation was poor 3. the app tried to do too much; or 4. the Apple App Store rejected the app (either because the implementation was poor or it violated Apple’s content policies)

Keeping the app as simple as possible is the best way to avoid these pitfalls. Most successful apps (indeed, most successful consumer tech products) are based on what is called an MVP, or minimum viable product. It’s the product with the smallest feature set that can deliver the core function without any distracting “bells and whistles.” You know you have an MVP if the product would no longer function if you removed any single feature.

But what should that core feature be? One of the best examples of an MVP is Mail. Version 1 (on the Mac) offered a clear, limited and intuitive feature set whose usefulness was immediately obvious to anyone. Today’s iPhone version integrates seamlessly with your phone, contacts and calendaring. It auto-matically corrects spelling as you type, lets you email photos directly from your photos app, and does much more. But all that came later and was built on top of a basic core function. And that’s how your first app should be built. The key is to come up with something with a clear value that changes people’s lives.

So, in drawing up your MVP feature list, ask yourself what features are key to the experience. Some basic market research is probably in order, starting with a visit to the App Store to see what already exists (possibly to be improved upon and/or to compete with you). Likely

must-have core capabilities include:

• Performance (e.g., fast screen refresh)• Offline capability (i.e., ability to work when not connected to the Internet)• Location awareness (e.g., the data/experience will change with the user’s location)• Cloud syncing (e.g., users see the same data on multiple devices)• Push notifications (i.e., sending updated information to devices as soon as it is available)

When you have a handle on what your app does, the next step is to design it. Designing your app involves making choices of how infor-mation and controls are presented to the user as well as how to implement app logic, and figuring out what data lives locally and what belongs in the Cloud.

Design your appUser experience decisions determine the app’s look and feel. They answer questions such as: What does the app look like? What screens does it have? In the software development world, onscreen objects like buttons, sliders, and fill-in boxes are called widgets. So you need to decide which types of widgets will reside on which screens. And what actions will occur as a result of the user interacting with those widgets?

Keep in mind that users will expect to interact differently with a mobile device than they do with a PC because the screens on mobile devices are much smaller. They’ll expect to use their fingers instead of a mouse or a track pad. Ideally, your app can even be used with one hand holding the device while using just a thumb for scrolling andworking the app’s other controls— the Path app is a good example, and increasingly, so is Facebook.

Your app’s features will inform its architecture, which is how you’ll divide the code and data into functional parts. If your app requires interacting with other app users or networked services, you’ll need to figure out what piece of the logic lives in the app code and what comes from the backend. For example, your app might integrate with a restau-rant recommendation engine, share user location, or pull real-time traffic data. This is done using APIs provided by various service providers — but you don’t have to wire up your app to a network to get started. You can develop a prototype using predefined representative (or “dummy”) data. It’s easier to fine-tune the front end if you don’t have to simultaneously modify your backend too. Once you get the app’s look-and-feel right, then make those backend connections.

Once you’ve got the overall concept for your app, the next step is to express that design in terms of the iOS app architecture. That archi-tecture is the model for what parts an iOS app can contain and how those parts fit together. It’s a well thought-out approach for translat-ing a product concept into actual code you can deploy on a device.

WHY iOS?Besides the features and design of your first app, there’s one more decision you need to make before you start actual development. That’s whether to deploy on Apple’s iOS platform or on Google’s Android platform. (Some of this is also covered in our ebook, How to Make an App: Android Edition.) Reasons to develop for iOS include:

Customers more willing to pay. Perhaps it’s because of Android’s open source heritage, but whatever the reason, Android apps gener-ate less than 10% of the total dollars spent on mobile apps, despite having 75% of the smartphone market itself — and despite the fact that the average selling price of an app in the Google Play is $3.79 versus Apple App Store’s $2.01. In other words, Apple users are much more willing to spend money on apps.

The Apple Ecosystem. Some developers and users prefer Apple’s closed and more tightly controlled environment. Apple’s ecosystem, consisting of Xcode, iCloud, iTunes, the App Store, the iPad, the iPhone, Mac computers, etc., offers a very holistic user experience with the ability to share data seamlessly across devices plus the

assurance of having applications pre-approved for quality and content prior to going on sale.

Xcode. Apple’s all-in-one IDE offers state-of-the-art offers features like a graphical interface builder and a syntax-aware and compiler-aware source editor.

The Apple Experience. From the fit and finish of its hardware to the customer service in its retail stores, to the way its hardware and software work flawlessly together, Apple has created the premium brand in consumer electronics. iOS developers share the benefits — so when someone downloads your iOS app, they already expect it’s a great product. And that it will also work flawlessly on their device.

Tablets. iOS has a clear advantage over Android in terms of tablet market adoption. Using Xcode, it’s also much easier to migrate an app from a phone to a tablet and vice versa than it is when develop-ing for Android.

Why Not iOS?Although iOS offers many compelling advantages as a platform for your mobile app, it also comes with some disadvantages. Here are three:

Closed Platform. iOS apps only run on Apple products so you can’t take advantage of features (like NFC) available only on non-iOS devices or market growth of non-iOS devices.

Market Growth. Today, iOS represents less than 15% of the total smartphone market, Although the total market (“the whole pie”) is still increasing at a fast rate, Android market growth outpaces iOS growth.

Approvals. The App Store’s app approval process is notoriously more time consuming than Google Play’s process.

The iOS app architectureAs noted earlier, a key reason why there are so many apps for iOS is because developing highly functional, polished apps for the platform is relatively easy. That’s mainly because of: 1) the design of the development tools, and 2) the key architectural features most iOS apps have in common. So let’s start with some concepts since it helps to know what goes into an app before trying to create one. We’ll begin with:

• Design patterns• Frameworks• Delegation• Storyboard• Windows• Outlets• Supporting files• Products

Design patterns. iOS apps implement what is known as a Mod-el-View-Controller (MVC) pattern. A pattern is a common way to structure code that solves a particular design problem. The MVC pattern separates application code in a way that allows you to easily change one part of an app without having to change other parts. An MVC pattern consists of three components:

• The Model is the logic that acts on the data, such as to store or retrieve data from a database, compute the distance between two cities on a map, etc. An example of a model is the Kinvey backend that stores your data in the Cloud as a service.

• The View provides the interface to the user; it displays the data and widgets (e.g., buttons and text fields) that allow the user to interact with the data. An iPhone app may have more than one view, as in the Contacts app, which displays a list view of all contacts or alternatively a view of each individual contact.

• The Controller is between the model and the view — i.e., it responds to user requests (made in a view) and retrieves results

(produced in a model). This is where developers spend most of their time — constructing the View Controller — by defining and attaching actions (or behaviors) to onscreen widgets. When the user taps a button, for example, it is the View Controller that determines what action will occur, such as retrieve stored data from your Kinvey-based data store. The link between a view object (like a button) to a controller action is called a connection.

Frameworks. You don’t actually have to write most of an app’s logic. It already exists as frameworks. A framework is a collection of classes that implements some function — such as connecting to the Internet, drawing a button, etc. Rather than write the code from scratch, you just use the frameworks supplied by iOS. Some frameworks are automatically present when you start a new project while others may need to be added (done via a drop down menu in Xcode’s Project Editor).

Delegation. Say, you want to customize the behavior of a framework’s object. You can’t actually modify the code of the framework class itself (prohibited since other apps may also use the framework). But what you can do is provide app-specific behavior in an application delegate object. If a delegate implements a method, it will be called by the delegating class to modify its behavior. In the Kinvey sample app (one of two examples we will be describing below), the AppDele-gate.h and AppDelegate.m — the header and implementation files for the UIApplicationDelegate, respectively — contain the code that authenticates an app to the Kinvey backend service.

Storyboards and XIBs. The MainStoryboard.storyboard file (or a .xib file, if you did not click on the “Use Storyboard” option when starting your project) contains the view information needed to implement the overall flow and display of your application and the user interface elements.

Windows. Each view (e.g., the contact list and individual contact details in the Contacts app) exists within a window. The window represents the entire device screen and is where all your views are presented.

Outlets. A variable by which a view object can be referenced in a controller. (For example, if you place a text field to capture a user's name, you might create an outlet called UITextField* nameField.)

Supporting files. These are files that provide resources (like PNG images and other static data) that your app needs as well as files that configure how the app will run. Other examples:

.pch files — precompiled headers used for the code files in your project.

.plist files — property lists that are small amounts of persistent data (like your app’s default user settings) consisting primarily of strings and numbers that you want your app to be able to access, modify if needed, and write back into the property list.

main.m file — your app’s main function. This is needed to launch the app, but you will not need to modify this file.

InfoPlist.strings file — used for localization.

Products. This is the file for your app (i.e., YourProduct.app) that is built when you click Xcode’s “run” button.

“Making an iOS app” involves working with these features in the typical, straightforward workflow:

• Storyboard your views by dragging and configuring graphicalobjects on a template

• Adding behaviors to the various widgets• Writing the classes as to define those behaviors (including

delegates)• Adding needed support files• Building and running the app• Iterating until you are satisfied with your app

This is all done within Xcode.

What’s Xcode?You can start developing functional, good-looking apps almost from the moment you download Xcode, Apple’s integrated development environment (IDE) for making iOS and Macintosh apps. Among other features, Xcode includes a source code editor, graphical user inter-face (GUI) editor (sometimes called Interface Builder), source code repository manager, compiler, and much more. iOS applications are typically developed by manipulating views graphically and by typing Objective-C code for the models and controllers.

To get Xcode, simply go to the App Store and download the applica-tion (it’s free). To do this, click on the App Store icon in your Mac’s dock, or visit https://itunes.apple.com/us/genre/ios/id36?mt=8

The app store will download and install Xcode in your Application folder. From Applications, double-click the Xcode icon to launch Xcode and you’ll see its splash screen (Figure 1). From there you can click on “Create a new Xcode project” to take you to a menu of several templates on which to base your application. Selecting a template opens an Xcode workspace pre-populated with frameworks and other files Xcode thinks you will need using that template.

Although you can develop, build and simulate your app on your computer in Xcode, you can’t run your app on a target device (even your own iPhone) until you become a registered iOS developer and join the iOS Developer Program. To do that, go to develop-er.app.com/ and navigate to the iOS Dev Center. While there, you will also find documentation, sample code and other useful resources such as information on how to submit your app to the iOS App Store.

Everything you do in Xcode is done in a window, called a workspace (Figure 2), consisting of multiple work areas, some of which are also divided into panes. All the files needed to build your app belong to a project, and the Navigator area (far left) lists all your projects (there can be several in a workspace) and all files for each project. Clicking on a file in the Navigator area shows its contents in the Editor area and invokes the appropriate editor. Clicking on a .h or .m file, for example, shows the file’s source code and invokes the Source editor, so you can edit the code. Clicking on .storyboard or .xib (sometimes called a “nib”) file shows the app’s storyboard and invokes the Inter-face Builder, so you can design a view using the Builder’s drag and drop features.

An especially handy feature is that the Editor area can have both a right and a left pane — with each pane aware of your edits in the other. So, for example, you can simultaneously edit an object’s .h

header file in the left pane and its corresponding .m in the right pane. Or you might click on a button object (displayed graphically) in the left pane and edit its method’s source code in the right pane. To toggle between a single pane (the “Standard Editor”) and double pane view (the “Assistant Editor”), use the Editor selector button on the right of the toolbar. You can option+command+click a symbol in the editor to open the definition in the opposite editor pane.

You can also resize the entire Editor area simply by dragging its borders. For even more editing space, you can also remove the Debug area or both the Debug and Utility areas using the View Selector button on the far right of the toolbar.

As its name suggests, the Debug area shows information, like variable state and console logs, helpful in debugging code.

The Utility area has two panes: the Inspector and Quick Help pane (top) and the Library pane (bottom). Although there are five inspectors — File, Help, Identity, Attributes, Size and Connec-tions — only the inspectors that are currently relevant appear in the Inspec-tor list at the top of the pane. (To see the name of an inspector, move the cursor over its icon in the Inspector selector bar.)

You will use inspectors to add and modify object attributes for views in the Interface Builder. For example, if you click on a UILabel in the Editor area of a storyboard, you can use the Attributes inspector to change the label’s color and use the Size inspector to change the label’s size.

The Help inspector shows help information about a selected class. Use the Identity inspector to view and manage an object’s metadata such as its class, runtime attributes, label and so forth. Use the

Connections inspector to view the outlets and actions of an interface object, to make new connections and to delete existing connections.

The Library pane has libraries of resources (like file templates, code snippets, interface objects and media files) that are prebuilt and ready to insert into your project. Use the Library selector to select which of these libraries (e.g., code snippets or interface objects) you wish to insert. To insert one, drag it directly into your storyboard while using the Interface Builder editor.

These are basics you need to know to get started using Xcode to build your first app. But to really understand how it’s done, it helps to walk through an actual app or two. Let’s start with a simple “Hello World” app that does not employ a backend connection, and then look at a somewhat more functional app that does.

“Hello World!” sample appThis app displays a button (“Press Me”) and a label (“Label”) so that when the user presses the button the text of the label changes to “Hello World!” as in Figure 3:

To get started, launch Xcode and select “Create a New Xcode Project.” From the iOS Application templates, select “Single View Application” and click “Next.” Fill in your product’s name and a company identifier, typically “com.yourCompanyName.” Deselect “Use Storyboards” and leave “Use Automatic Reference Counting” selected. Then click “Next” and select a destination for your projects files.

Follow these steps to make your app:

1. Select your project’s ViewController.xib file in the Navigator(Figure 4), to open the Interface Builder editor.

2. Drag a “Round Rect Button” from the Objects library (lowerright) onto the view in the Editor area; select the button’s textand type “Press Me.”

3. Drag a Label from the objects library onto the view, as well.4. Select and drag the Label sizing handles, centering the object

and making it wide enough to hold the “Hello World!” text; then,

5. With the “Hello World!” label still selected, click on centeralignment in the Attributes inspector.

6. Open the Assistant Editor (Figure 5), exposing the source codeheader file (ViewController.h) of the view controller you justbuilt graphically.

7. Select the button and control-drag from the button to justbelow the ViewController definition in the Assistant panel. Inthe form that opens, select “Action” for the connection type,type in a name (“showText”) and click “Connect.” This creates aninterface builder (IB) action as highlighted in Figure 6.

8. Next step is to create an outlet for the label. To do this, selectthe label object and control-drag from the label to just belowthe IB action you just created. Select “Outlet” as the connectiontype and enter a name “label” and click “Connect.” This createsan interface builder (IB) outlet as shown in Figure 7.

9. Finally, it’s time to add some logic to the view controller so itknows what to do when the button is pressed. To do this, select “ViewController.m” in the project navigator to show the code editor. Find the button’s IBAction you just created (near the bottom), place your cursor between the { } brackets and hit the return key a few times to create some extra space. Then in that space type the method for how you want the label you speci-fied to respond: _label.text=”Hello World!”; as highlighted in Figure 8.

Congratulations! Your app is done. To build and run your new app in the simulator, click the Xcode Run button in the left corner of the toolbar. When you click the button, the text will update.

Sample app with a backend This second app (named “Kinvey Test Drive”) lets the user type text on an iPhone and save the text to a backend service, like Kinvey. It also lets the user load text on the iPhone from their Kinvey backend. Reading about this app will help you learn:

• How to set up Kinvey’s library in an iOS project• Additional Interface Builder techniques you can use to story-board an application• How to add view controller logic to interact with the backend service, allowing you to save and retrieve data

We will first present the app as a running application and then take it apart so you can see how it was made. To make the app yourself, you can review the various sections below and replicate the steps in your copy of Xcode.

First, to see the app in action, you should download the app and run it on your system. To do that, sign up for Kinvey, then navigate to “Dev Center”, “Samples,” find the “Test Drive” app, and click on its icon. (If you can’t find it right away, make sure you select iOS as your platform on the right side of the menu bar.) Click the download button to download the app’s project files to your computer. Then launch Xcode — just double click on the .xcodeproj file in the project folder.

But before you can run the app, you need to set up the app’s Kinvey backend.

Set Up Kinvey as a Backend Data StoreTest Drive’s project files include all the code the sample app needs in order to talk to Kinvey. However, that would not be the case if you were to build an app from scratch — so you would have to go through an initial Kinvey setup procedure. This involves downloading the Kinvey library files from the downloads section of devcenter.kin-vey.com and dragging them to the Navigator’s Frameworks folder in Xcode. You also need to tell Xcode to link your project with additional iOS frameworks. To find these frameworks, click on the Project folder

at the very top of the Navigator pane — which displays the Project editor — and then select the “Build Settings” tab. For detailed instruc-tions, complete the “Getting Started” page under “Guides” on the Kinvey website. But again, you can skip this setup procedure for now in order to run the downloaded Kinvey Test Drive app.

But you must still do this step: To run any app that uses Kinvey (including Test Drive) you need to do the “Create an App” step on the Kinvey website. Click on “My Apps” in the Kinvey menu bar and then click on “Add an App,” which will open an “Add” page. Type in a name for your app and click on the Apple logo and then click “Create.” The page that opens shows your App’s credentials. Copy and paste the App Key and App Secret into the AppDelegate.m file of the download-ed Test Drive project:

You are now ready to run the app — click on the Xcode run button and wait for the simulator to open and the app to appear (Figure 9).

Clicking the “+” toolbar button opens an alert (Figure 10) with an empty field into which the user can type some text (e.g., “some new data”). Clicking “save” uploads the data to Kinvey and displays text on the screen (a table view) and also displays an alert that the save worked (Figure 11).

To test the load function, enter some data (e.g., “some data to load”) in the “name” field of the Kinvey collection. To see the load, the swipe down on the table on the phone until the refresh spinner starts, and then the new data will appear in the table (Figure 12).

Figure 13 shows the Kinvey collection after the save that Figure 10 depicts on the iPhone. Figure 14 shows the Kinvey collection after the user adds a new row to the testObjects collection using the web browser. Note that every time a save is done on the iPhone, Kinvey automatically adds a new row (displayed on a collection refresh). To add a new row manually in the browser, click “+ row,” and type some descriptive text in the “name” column. That data will now load on the iPhone when the user pulls down on the table.

Storyboard the Test Drive AppMost of the Test Drive user interface objects visible in the simulation are available in Xcode’s Object Library and can therefore be added to the view graphically. The UI objects consist of a:

• Table view• Toolbar• Tool Bar Button item – flexible space• Tool Bar Button item – Add• Table view cell• Label – Title• Refresh Control

To create this app yourself, you would follow these steps:

• Launch Xcode and select the “Single View Application” template• Select the “Use Storyboard” option• Replace the default UIviewcontroller object with a UITableView-Controller • Drag and drop the other objects, in the order listed, onto the UIviewcontroller

Also note:

• The Flexible Space Bar Button item fills up the space on the toolbar so the add button is at the right. This is a standard pattern in table-based iPhone apps.• The add button shows the system “+” sign. That is done by dragging a bar button item onto the toolbar, clicking on the Identifier drop down menu in the Attributes inspector; and then selecting the “Add” option.

As with the “Hello World!” app, once your app’s view is complete (Figure 15), you would still have to create the various methods and connections that bring them to life. This is done using the Source editor while working with the ViewController.m file.

Add View Controller LogicSince the app performs two basic operations (save data to Kinvey and load data from Kinvey) these two methods must be added to the ViewController header file. That’s done with a control-drag from the “+” bar button over to just under the “@ interface ViewController” line in ViewController.h. (Open the Assistant editor to see both the storyboard and the file source.)

During the drag, the popup appears, asking for the name and type of connection. Enter “action” for the connection type and “add” for the name. Then repeat the drag, this time from the refresh control and using “add” for the name (Figure 16).

Note: to follow this discussion it will help to have the referenced files open in your Xcode Source editor.

In ViewController.m, you will see the implementation code associated with each of the two Interface Builder methods, whose names Xcode added automatically to the .m file:

- (IBAction)add:(id)sender- (IBAction)load:(id)sender

You will also see a third section of code not associated with these methods, which starts with the line: “#pragma mark - Table View Stuff.” These methods support the table view and are part of UITableViewD-elegate and UITableViewDataSource. They handle controlling the

display of the table, and respond to user gestures. For example, swiping a table cell will show the delete button because tableView:-canEditRowAtIndexPath: returns YES and tableView:editingStyleForRowA-tIndexPath: returns UITableViewCellEditingStyleDelete. If you tap the delete button, the delegate method tableView:commitEditingStyle:for-RowAtIndexPath: is called. The code of this method deletes the data for the row and removes it from Kinvey’s data store. When the backend delete is completed, the app displays an alert describing the success or failure.

The way that all three sections (and all Kinvey-enabled apps) move data in and out of a Kinvey collection is by getting a reference to the app’s backend collection (named “testObjects”), which is filled with instances (each named “TestObject”) of the data the app wants to move. That’s why you’ll find the following code repeated three times in Test Drive’s View Controller (once for the add, once for the load, and once for the delete):

To support these statements it is required to have a data object class (TestObject). To see how these files are written in the sample project, click on TestObject.h file and TestObject.m in the Navigator pane. If you were to supply these files in your own app, you would click File > New File, and specify Objective-C class, which would be a subclass of NSObject. Then you would type in the code, with a property for each column in the Kinvey backend collection (including one for the object’s id).

As mentioned earlier, your app also needs to authenticate itself to Kinvey, which is handled by AppDelegate.h and AppDelgate.m. These files are created by Xcode when you create a new project, and start out with just a stub implementation. Look in the sample app source

files for code to copy and paste.

For both the save and load operations, however, moving the data in and out of a backend collection is only part of the work. Table 1 lists all the functions that implements the save and load in the ViewCon-troller.m file, along with pointers to its corresponding block of imple-mentation source code. (For each function, its corresponding code begins with the “Starts at” line and ends with the “Ends at” line.) Refer to Appendix 1 to find the actual source code.

Say Hello To Our WorldThe key takeaway from all this is that “making an app” is a worthwhile thing to do for anyone with a clever idea and a working knowledge of Objective-C. The proof is in the hundreds of apps succeeding in the market every day, many written by people working on their own and who never wrote an app before in their lives. As with anything else, practice does make perfect. But hopefully with all the resources available, and the knowledge gained from this ebook, you have already started down the path toward joining the growing legions of iOS app developers. If so, we welcome you!

Appendix 1 — Test Drive Sample App ViewController.m Source Code

35

Table 1: Save and Load Implementation Details of Kinvey Test Drive Sample App

The iOS revolutionIt’s a story that never gets old. The weekend that iPad Minis and the fourth generation iPads went on sale (November 2-5, 2012) Apple sold over 3 million of the devices — a record for first-weekend iPad sales. Two months earlier the company had set another record: first weekend sales of over 5 million for the iPhone 5. Since the introduc-tion of the first iPhone back in 2007,

iOS-based devices (iPhone, iPad, iPad Mini and iPod Touch) continue to rewrite the definition of what constitutes a successful product. By the end of 2012, over 400 million iOS devices had been sold.

What makes iOS devices so successful? Innovation and product features are clearly a big part. Before the iPhone most people had not interacted with a multi-touch interface. They had never zoomed with a pinch or switched between portrait and landscape by merely rotating a device in their hand. Carrying a phone that knew where they were, could suggest places to eat, and could offer directions on how to get there was also a novel experience.

But features like multi-touch, accelerometers and GPS are only part of the appeal. Even with all its innovations, iOS still might not have taken off the way it has if the only people figuring out ways to use those innovations worked at Apple. Most of the capabilities available in an iPhone or iPad in fact don’t come from Apple at all. They come from legions of third-party developers who work in a vast ecosystem that is also an Apple innovation. That ecosystem includes the iPhone, iPad, iPad Mini, iPods, App Store, iTunes, ad networks — and that’s just on the consumer side. On the developer side, you have Xcode, App Loader, testing tools, iTunes Connect — the list goes on.

As of September 2012, the App Store hosted over 700,000 apps that have collectively been downloaded over 30 billion times. Apple reported for October 2012 that App Store monthly revenues were

running at $333 million — a rate of about $4 billion per year — remarkable for a store that only opened in July 2008.

Another innovation that has spurred iOS app development is “The Cloud.” Cloud services make it easier for independent developers to create, support and make money from their apps. The Cloud solves data storage and cross-device and user-to-user sharing problems. If an app stores data in the Cloud, that part of the application is called the “backend,” while the part of the app that runs on the phone and interacts with the user is called the “front end.”

A cloud may be “private” — i.e., the services belong to an organization for the benefit of its employees and business partners. Or a cloud may be “public” — i.e., a company (such as Amazon or Kinvey) owns the services, which developers can then integrate into their own apps. If you are a developer and want to build your own backend, you certainly can do that. Whether you want to or not depends on whether your backend provides functionality common to many different apps. If it does (as in a shopping cart or user authenti-cation) then perhaps that time and money would be better spent on features that offer unique value to your customer. You may be better off hooking into a commercial backend provider via an API. Then you can focus on what counts most — a unique user experience and application-specific functionality. That brings us to the first step in making an app.

Define your appMost unsuccessful apps fail for any of four reasons:

1. the app was a solution in search of a problem (i.e., no real need existed) 2. the implementation was poor 3. the app tried to do too much; or 4. the Apple App Store rejected the app (either because the implementation was poor or it violated Apple’s content policies)

Keeping the app as simple as possible is the best way to avoid these pitfalls. Most successful apps (indeed, most successful consumer tech products) are based on what is called an MVP, or minimum viable product. It’s the product with the smallest feature set that can deliver the core function without any distracting “bells and whistles.” You know you have an MVP if the product would no longer function if you removed any single feature.

But what should that core feature be? One of the best examples of an MVP is Mail. Version 1 (on the Mac) offered a clear, limited and intuitive feature set whose usefulness was immediately obvious to anyone. Today’s iPhone version integrates seamlessly with your phone, contacts and calendaring. It auto-matically corrects spelling as you type, lets you email photos directly from your photos app, and does much more. But all that came later and was built on top of a basic core function. And that’s how your first app should be built. The key is to come up with something with a clear value that changes people’s lives.

So, in drawing up your MVP feature list, ask yourself what features are key to the experience. Some basic market research is probably in order, starting with a visit to the App Store to see what already exists (possibly to be improved upon and/or to compete with you). Likely

must-have core capabilities include:

• Performance (e.g., fast screen refresh)• Offline capability (i.e., ability to work when not connected to the Internet)• Location awareness (e.g., the data/experience will change with the user’s location)• Cloud syncing (e.g., users see the same data on multiple devices)• Push notifications (i.e., sending updated information to devices as soon as it is available)

When you have a handle on what your app does, the next step is to design it. Designing your app involves making choices of how infor-mation and controls are presented to the user as well as how to implement app logic, and figuring out what data lives locally and what belongs in the Cloud.

Design your appUser experience decisions determine the app’s look and feel. They answer questions such as: What does the app look like? What screens does it have? In the software development world, onscreen objects like buttons, sliders, and fill-in boxes are called widgets. So you need to decide which types of widgets will reside on which screens. And what actions will occur as a result of the user interacting with those widgets?

Keep in mind that users will expect to interact differently with a mobile device than they do with a PC because the screens on mobile devices are much smaller. They’ll expect to use their fingers instead of a mouse or a track pad. Ideally, your app can even be used with one hand holding the device while using just a thumb for scrolling andworking the app’s other controls— the Path app is a good example, and increasingly, so is Facebook.

Your app’s features will inform its architecture, which is how you’ll divide the code and data into functional parts. If your app requires interacting with other app users or networked services, you’ll need to figure out what piece of the logic lives in the app code and what comes from the backend. For example, your app might integrate with a restau-rant recommendation engine, share user location, or pull real-time traffic data. This is done using APIs provided by various service providers — but you don’t have to wire up your app to a network to get started. You can develop a prototype using predefined representative (or “dummy”) data. It’s easier to fine-tune the front end if you don’t have to simultaneously modify your backend too. Once you get the app’s look-and-feel right, then make those backend connections.

Once you’ve got the overall concept for your app, the next step is to express that design in terms of the iOS app architecture. That archi-tecture is the model for what parts an iOS app can contain and how those parts fit together. It’s a well thought-out approach for translat-ing a product concept into actual code you can deploy on a device.

WHY iOS?Besides the features and design of your first app, there’s one more decision you need to make before you start actual development. That’s whether to deploy on Apple’s iOS platform or on Google’s Android platform. (Some of this is also covered in our ebook, How to Make an App: Android Edition.) Reasons to develop for iOS include:

Customers more willing to pay. Perhaps it’s because of Android’s open source heritage, but whatever the reason, Android apps gener-ate less than 10% of the total dollars spent on mobile apps, despite having 75% of the smartphone market itself — and despite the fact that the average selling price of an app in the Google Play is $3.79 versus Apple App Store’s $2.01. In other words, Apple users are much more willing to spend money on apps.

The Apple Ecosystem. Some developers and users prefer Apple’s closed and more tightly controlled environment. Apple’s ecosystem, consisting of Xcode, iCloud, iTunes, the App Store, the iPad, the iPhone, Mac computers, etc., offers a very holistic user experience with the ability to share data seamlessly across devices plus the

assurance of having applications pre-approved for quality and content prior to going on sale.

Xcode. Apple’s all-in-one IDE offers state-of-the-art offers features like a graphical interface builder and a syntax-aware and compiler-aware source editor.

The Apple Experience. From the fit and finish of its hardware to the customer service in its retail stores, to the way its hardware and software work flawlessly together, Apple has created the premium brand in consumer electronics. iOS developers share the benefits — so when someone downloads your iOS app, they already expect it’s a great product. And that it will also work flawlessly on their device.

Tablets. iOS has a clear advantage over Android in terms of tablet market adoption. Using Xcode, it’s also much easier to migrate an app from a phone to a tablet and vice versa than it is when develop-ing for Android.

Why Not iOS?Although iOS offers many compelling advantages as a platform for your mobile app, it also comes with some disadvantages. Here are three:

Closed Platform. iOS apps only run on Apple products so you can’t take advantage of features (like NFC) available only on non-iOS devices or market growth of non-iOS devices.

Market Growth. Today, iOS represents less than 15% of the total smartphone market, Although the total market (“the whole pie”) is still increasing at a fast rate, Android market growth outpaces iOS growth.

Approvals. The App Store’s app approval process is notoriously more time consuming than Google Play’s process.

The iOS app architectureAs noted earlier, a key reason why there are so many apps for iOS is because developing highly functional, polished apps for the platform is relatively easy. That’s mainly because of: 1) the design of the development tools, and 2) the key architectural features most iOS apps have in common. So let’s start with some concepts since it helps to know what goes into an app before trying to create one. We’ll begin with:

• Design patterns• Frameworks• Delegation• Storyboard• Windows• Outlets• Supporting files• Products

Design patterns. iOS apps implement what is known as a Mod-el-View-Controller (MVC) pattern. A pattern is a common way to structure code that solves a particular design problem. The MVC pattern separates application code in a way that allows you to easily change one part of an app without having to change other parts. An MVC pattern consists of three components:

• The Model is the logic that acts on the data, such as to store or retrieve data from a database, compute the distance between two cities on a map, etc. An example of a model is the Kinvey backend that stores your data in the Cloud as a service.

• The View provides the interface to the user; it displays the data and widgets (e.g., buttons and text fields) that allow the user to interact with the data. An iPhone app may have more than one view, as in the Contacts app, which displays a list view of all contacts or alternatively a view of each individual contact.

• The Controller is between the model and the view — i.e., it responds to user requests (made in a view) and retrieves results

(produced in a model). This is where developers spend most of their time — constructing the View Controller — by defining and attaching actions (or behaviors) to onscreen widgets. When the user taps a button, for example, it is the View Controller that determines what action will occur, such as retrieve stored data from your Kinvey-based data store. The link between a view object (like a button) to a controller action is called a connection.

Frameworks. You don’t actually have to write most of an app’s logic. It already exists as frameworks. A framework is a collection of classes that implements some function — such as connecting to the Internet, drawing a button, etc. Rather than write the code from scratch, you just use the frameworks supplied by iOS. Some frameworks are automatically present when you start a new project while others may need to be added (done via a drop down menu in Xcode’s Project Editor).

Delegation. Say, you want to customize the behavior of a framework’s object. You can’t actually modify the code of the framework class itself (prohibited since other apps may also use the framework). But what you can do is provide app-specific behavior in an application delegate object. If a delegate implements a method, it will be called by the delegating class to modify its behavior. In the Kinvey sample app (one of two examples we will be describing below), the AppDele-gate.h and AppDelegate.m — the header and implementation files for the UIApplicationDelegate, respectively — contain the code that authenticates an app to the Kinvey backend service.

Storyboards and XIBs. The MainStoryboard.storyboard file (or a .xib file, if you did not click on the “Use Storyboard” option when starting your project) contains the view information needed to implement the overall flow and display of your application and the user interface elements.

Windows. Each view (e.g., the contact list and individual contact details in the Contacts app) exists within a window. The window represents the entire device screen and is where all your views are presented.

Outlets. A variable by which a view object can be referenced in a controller. (For example, if you place a text field to capture a user's name, you might create an outlet called UITextField* nameField.)

Supporting files. These are files that provide resources (like PNG images and other static data) that your app needs as well as files that configure how the app will run. Other examples:

.pch files — precompiled headers used for the code files in your project.

.plist files — property lists that are small amounts of persistent data (like your app’s default user settings) consisting primarily of strings and numbers that you want your app to be able to access, modify if needed, and write back into the property list.

main.m file — your app’s main function. This is needed to launch the app, but you will not need to modify this file.

InfoPlist.strings file — used for localization.

Products. This is the file for your app (i.e., YourProduct.app) that is built when you click Xcode’s “run” button.

“Making an iOS app” involves working with these features in the typical, straightforward workflow:

• Storyboard your views by dragging and configuring graphicalobjects on a template

• Adding behaviors to the various widgets• Writing the classes as to define those behaviors (including

delegates)• Adding needed support files• Building and running the app• Iterating until you are satisfied with your app

This is all done within Xcode.

What’s Xcode?You can start developing functional, good-looking apps almost from the moment you download Xcode, Apple’s integrated development environment (IDE) for making iOS and Macintosh apps. Among other features, Xcode includes a source code editor, graphical user inter-face (GUI) editor (sometimes called Interface Builder), source code repository manager, compiler, and much more. iOS applications are typically developed by manipulating views graphically and by typing Objective-C code for the models and controllers.

To get Xcode, simply go to the App Store and download the applica-tion (it’s free). To do this, click on the App Store icon in your Mac’s dock, or visit https://itunes.apple.com/us/genre/ios/id36?mt=8

The app store will download and install Xcode in your Application folder. From Applications, double-click the Xcode icon to launch Xcode and you’ll see its splash screen (Figure 1). From there you can click on “Create a new Xcode project” to take you to a menu of several templates on which to base your application. Selecting a template opens an Xcode workspace pre-populated with frameworks and other files Xcode thinks you will need using that template.

Although you can develop, build and simulate your app on your computer in Xcode, you can’t run your app on a target device (even your own iPhone) until you become a registered iOS developer and join the iOS Developer Program. To do that, go to develop-er.app.com/ and navigate to the iOS Dev Center. While there, you will also find documentation, sample code and other useful resources such as information on how to submit your app to the iOS App Store.

Everything you do in Xcode is done in a window, called a workspace (Figure 2), consisting of multiple work areas, some of which are also divided into panes. All the files needed to build your app belong to a project, and the Navigator area (far left) lists all your projects (there can be several in a workspace) and all files for each project. Clicking on a file in the Navigator area shows its contents in the Editor area and invokes the appropriate editor. Clicking on a .h or .m file, for example, shows the file’s source code and invokes the Source editor, so you can edit the code. Clicking on .storyboard or .xib (sometimes called a “nib”) file shows the app’s storyboard and invokes the Inter-face Builder, so you can design a view using the Builder’s drag and drop features.

An especially handy feature is that the Editor area can have both a right and a left pane — with each pane aware of your edits in the other. So, for example, you can simultaneously edit an object’s .h

header file in the left pane and its corresponding .m in the right pane. Or you might click on a button object (displayed graphically) in the left pane and edit its method’s source code in the right pane. To toggle between a single pane (the “Standard Editor”) and double pane view (the “Assistant Editor”), use the Editor selector button on the right of the toolbar. You can option+command+click a symbol in the editor to open the definition in the opposite editor pane.

You can also resize the entire Editor area simply by dragging its borders. For even more editing space, you can also remove the Debug area or both the Debug and Utility areas using the View Selector button on the far right of the toolbar.

As its name suggests, the Debug area shows information, like variable state and console logs, helpful in debugging code.

The Utility area has two panes: the Inspector and Quick Help pane (top) and the Library pane (bottom). Although there are five inspectors — File, Help, Identity, Attributes, Size and Connec-tions — only the inspectors that are currently relevant appear in the Inspec-tor list at the top of the pane. (To see the name of an inspector, move the cursor over its icon in the Inspector selector bar.)

You will use inspectors to add and modify object attributes for views in the Interface Builder. For example, if you click on a UILabel in the Editor area of a storyboard, you can use the Attributes inspector to change the label’s color and use the Size inspector to change the label’s size.

The Help inspector shows help information about a selected class. Use the Identity inspector to view and manage an object’s metadata such as its class, runtime attributes, label and so forth. Use the

Connections inspector to view the outlets and actions of an interface object, to make new connections and to delete existing connections.

The Library pane has libraries of resources (like file templates, code snippets, interface objects and media files) that are prebuilt and ready to insert into your project. Use the Library selector to select which of these libraries (e.g., code snippets or interface objects) you wish to insert. To insert one, drag it directly into your storyboard while using the Interface Builder editor.

These are basics you need to know to get started using Xcode to build your first app. But to really understand how it’s done, it helps to walk through an actual app or two. Let’s start with a simple “Hello World” app that does not employ a backend connection, and then look at a somewhat more functional app that does.

“Hello World!” sample appThis app displays a button (“Press Me”) and a label (“Label”) so that when the user presses the button the text of the label changes to “Hello World!” as in Figure 3:

To get started, launch Xcode and select “Create a New Xcode Project.” From the iOS Application templates, select “Single View Application” and click “Next.” Fill in your product’s name and a company identifier, typically “com.yourCompanyName.” Deselect “Use Storyboards” and leave “Use Automatic Reference Counting” selected. Then click “Next” and select a destination for your projects files.

Follow these steps to make your app:

1. Select your project’s ViewController.xib file in the Navigator(Figure 4), to open the Interface Builder editor.

2. Drag a “Round Rect Button” from the Objects library (lowerright) onto the view in the Editor area; select the button’s textand type “Press Me.”

3. Drag a Label from the objects library onto the view, as well.4. Select and drag the Label sizing handles, centering the object

and making it wide enough to hold the “Hello World!” text; then,

5. With the “Hello World!” label still selected, click on centeralignment in the Attributes inspector.

6. Open the Assistant Editor (Figure 5), exposing the source codeheader file (ViewController.h) of the view controller you justbuilt graphically.

7. Select the button and control-drag from the button to justbelow the ViewController definition in the Assistant panel. Inthe form that opens, select “Action” for the connection type,type in a name (“showText”) and click “Connect.” This creates aninterface builder (IB) action as highlighted in Figure 6.

8. Next step is to create an outlet for the label. To do this, selectthe label object and control-drag from the label to just belowthe IB action you just created. Select “Outlet” as the connectiontype and enter a name “label” and click “Connect.” This createsan interface builder (IB) outlet as shown in Figure 7.

9. Finally, it’s time to add some logic to the view controller so itknows what to do when the button is pressed. To do this, select “ViewController.m” in the project navigator to show the code editor. Find the button’s IBAction you just created (near the bottom), place your cursor between the { } brackets and hit the return key a few times to create some extra space. Then in that space type the method for how you want the label you speci-fied to respond: _label.text=”Hello World!”; as highlighted in Figure 8.

Congratulations! Your app is done. To build and run your new app in the simulator, click the Xcode Run button in the left corner of the toolbar. When you click the button, the text will update.

Sample app with a backend This second app (named “Kinvey Test Drive”) lets the user type text on an iPhone and save the text to a backend service, like Kinvey. It also lets the user load text on the iPhone from their Kinvey backend. Reading about this app will help you learn:

• How to set up Kinvey’s library in an iOS project• Additional Interface Builder techniques you can use to story-board an application• How to add view controller logic to interact with the backend service, allowing you to save and retrieve data

We will first present the app as a running application and then take it apart so you can see how it was made. To make the app yourself, you can review the various sections below and replicate the steps in your copy of Xcode.

First, to see the app in action, you should download the app and run it on your system. To do that, sign up for Kinvey, then navigate to “Dev Center”, “Samples,” find the “Test Drive” app, and click on its icon. (If you can’t find it right away, make sure you select iOS as your platform on the right side of the menu bar.) Click the download button to download the app’s project files to your computer. Then launch Xcode — just double click on the .xcodeproj file in the project folder.

But before you can run the app, you need to set up the app’s Kinvey backend.

Set Up Kinvey as a Backend Data StoreTest Drive’s project files include all the code the sample app needs in order to talk to Kinvey. However, that would not be the case if you were to build an app from scratch — so you would have to go through an initial Kinvey setup procedure. This involves downloading the Kinvey library files from the downloads section of devcenter.kin-vey.com and dragging them to the Navigator’s Frameworks folder in Xcode. You also need to tell Xcode to link your project with additional iOS frameworks. To find these frameworks, click on the Project folder

at the very top of the Navigator pane — which displays the Project editor — and then select the “Build Settings” tab. For detailed instruc-tions, complete the “Getting Started” page under “Guides” on the Kinvey website. But again, you can skip this setup procedure for now in order to run the downloaded Kinvey Test Drive app.

But you must still do this step: To run any app that uses Kinvey (including Test Drive) you need to do the “Create an App” step on the Kinvey website. Click on “My Apps” in the Kinvey menu bar and then click on “Add an App,” which will open an “Add” page. Type in a name for your app and click on the Apple logo and then click “Create.” The page that opens shows your App’s credentials. Copy and paste the App Key and App Secret into the AppDelegate.m file of the download-ed Test Drive project:

You are now ready to run the app — click on the Xcode run button and wait for the simulator to open and the app to appear (Figure 9).

Clicking the “+” toolbar button opens an alert (Figure 10) with an empty field into which the user can type some text (e.g., “some new data”). Clicking “save” uploads the data to Kinvey and displays text on the screen (a table view) and also displays an alert that the save worked (Figure 11).

To test the load function, enter some data (e.g., “some data to load”) in the “name” field of the Kinvey collection. To see the load, the swipe down on the table on the phone until the refresh spinner starts, and then the new data will appear in the table (Figure 12).

Figure 13 shows the Kinvey collection after the save that Figure 10 depicts on the iPhone. Figure 14 shows the Kinvey collection after the user adds a new row to the testObjects collection using the web browser. Note that every time a save is done on the iPhone, Kinvey automatically adds a new row (displayed on a collection refresh). To add a new row manually in the browser, click “+ row,” and type some descriptive text in the “name” column. That data will now load on the iPhone when the user pulls down on the table.

Storyboard the Test Drive AppMost of the Test Drive user interface objects visible in the simulation are available in Xcode’s Object Library and can therefore be added to the view graphically. The UI objects consist of a:

• Table view• Toolbar• Tool Bar Button item – flexible space• Tool Bar Button item – Add• Table view cell• Label – Title• Refresh Control

To create this app yourself, you would follow these steps:

• Launch Xcode and select the “Single View Application” template• Select the “Use Storyboard” option• Replace the default UIviewcontroller object with a UITableView-Controller • Drag and drop the other objects, in the order listed, onto the UIviewcontroller

Also note:

• The Flexible Space Bar Button item fills up the space on the toolbar so the add button is at the right. This is a standard pattern in table-based iPhone apps.• The add button shows the system “+” sign. That is done by dragging a bar button item onto the toolbar, clicking on the Identifier drop down menu in the Attributes inspector; and then selecting the “Add” option.

As with the “Hello World!” app, once your app’s view is complete (Figure 15), you would still have to create the various methods and connections that bring them to life. This is done using the Source editor while working with the ViewController.m file.

Add View Controller LogicSince the app performs two basic operations (save data to Kinvey and load data from Kinvey) these two methods must be added to the ViewController header file. That’s done with a control-drag from the “+” bar button over to just under the “@ interface ViewController” line in ViewController.h. (Open the Assistant editor to see both the storyboard and the file source.)

During the drag, the popup appears, asking for the name and type of connection. Enter “action” for the connection type and “add” for the name. Then repeat the drag, this time from the refresh control and using “add” for the name (Figure 16).

Note: to follow this discussion it will help to have the referenced files open in your Xcode Source editor.

In ViewController.m, you will see the implementation code associated with each of the two Interface Builder methods, whose names Xcode added automatically to the .m file:

- (IBAction)add:(id)sender- (IBAction)load:(id)sender

You will also see a third section of code not associated with these methods, which starts with the line: “#pragma mark - Table View Stuff.” These methods support the table view and are part of UITableViewD-elegate and UITableViewDataSource. They handle controlling the

display of the table, and respond to user gestures. For example, swiping a table cell will show the delete button because tableView:-canEditRowAtIndexPath: returns YES and tableView:editingStyleForRowA-tIndexPath: returns UITableViewCellEditingStyleDelete. If you tap the delete button, the delegate method tableView:commitEditingStyle:for-RowAtIndexPath: is called. The code of this method deletes the data for the row and removes it from Kinvey’s data store. When the backend delete is completed, the app displays an alert describing the success or failure.

The way that all three sections (and all Kinvey-enabled apps) move data in and out of a Kinvey collection is by getting a reference to the app’s backend collection (named “testObjects”), which is filled with instances (each named “TestObject”) of the data the app wants to move. That’s why you’ll find the following code repeated three times in Test Drive’s View Controller (once for the add, once for the load, and once for the delete):

To support these statements it is required to have a data object class (TestObject). To see how these files are written in the sample project, click on TestObject.h file and TestObject.m in the Navigator pane. If you were to supply these files in your own app, you would click File > New File, and specify Objective-C class, which would be a subclass of NSObject. Then you would type in the code, with a property for each column in the Kinvey backend collection (including one for the object’s id).

As mentioned earlier, your app also needs to authenticate itself to Kinvey, which is handled by AppDelegate.h and AppDelgate.m. These files are created by Xcode when you create a new project, and start out with just a stub implementation. Look in the sample app source

files for code to copy and paste.

For both the save and load operations, however, moving the data in and out of a backend collection is only part of the work. Table 1 lists all the functions that implements the save and load in the ViewCon-troller.m file, along with pointers to its corresponding block of imple-mentation source code. (For each function, its corresponding code begins with the “Starts at” line and ends with the “Ends at” line.) Refer to Appendix 1 to find the actual source code.

Say Hello To Our WorldThe key takeaway from all this is that “making an app” is a worthwhile thing to do for anyone with a clever idea and a working knowledge of Objective-C. The proof is in the hundreds of apps succeeding in the market every day, many written by people working on their own and who never wrote an app before in their lives. As with anything else, practice does make perfect. But hopefully with all the resources available, and the knowledge gained from this ebook, you have already started down the path toward joining the growing legions of iOS app developers. If so, we welcome you!

Appendix 1 — Test Drive Sample App ViewController.m Source Code

136

//

// ViewController.m

// Kinvey Quickstart

//

// Created by Michael Katz on 11/12/12.

// Copyright (c) 2012-2013 Kinvey. All rights reserved.

//

#import "ViewController.h"

#import "TestObject.h"

#define CREATE_NEW_ENTITY_ALERT_VIEW 100

@interface ViewController ()

@property (nonatomic, strong) NSArray* objects;

@end

@implementation ViewController

- (IBAction)add:(id)sender

{

UIAlertView* alert = [[UIAlertView alloc] initWithTitle:@"Create a New Entity"

message:@"Enter a title for the

new entity"

delegate:self

cancelButtonTitle:@"Cancel"

otherButtonTitles:@"Save", nil];

alert.alertViewStyle = UIAlertViewStylePlainTextInput;

alert.tag = CREATE_NEW_ENTITY_ALERT_VIEW;

[alert show];

}

- (void)alertView:(UIAlertView *)alertView clickedButtonAtIndex:(NSInteger)but-

tonIndex

{

if (alertView.tag == CREATE_NEW_ENTITY_ALERT_VIEW) {

if (buttonIndex == alertView.firstOtherButtonIndex) {

// Define an instance of our test object

TestObject *testObject = [[TestObject alloc] init];

// This is the data we'll save

testObject.name = [[alertView textFieldAtIndex:0] text];

// Get a reference to a backend collection called "testObjects", which

is filled with

// instances of TestObject

KCSCollection *testObjects = [KCSCollection collectionFromString:@"tes-

tObjects" ofClass:[TestObject class]];

// Create a data store connected to the collection, in order to save

and load TestObjects

KCSAppdataStore *store = [KCSAppdataStore storeWithCollection:testOb-

jects options:nil];

// Save our instance to the store

[store saveObject:testObject withCompletionBlock:^(NSArray *objectsOr-

Nil, NSError *errorOrNil) {

// Right now just pop-up an alert about what we got back from

Kinvey during

// the save. Normally you would want to implement more code here

if (errorOrNil == nil && objectsOrNil != nil) {

//save is successful!

UIAlertView *alert = [[UIAlertView alloc] initWithTitle:@"Save

worked!"

message:[NS-

String stringWithFormat:@"Saved: '%@'",[objectsOrNil[0] name]]

delegate:nil

cancelButtonTitle:@"Ok"

otherButtonTitles:nil];

[alert show];

self.objects = [@[testObject] arrayByAddingObjectsFromArray:_-

objects];

[self.tableView insertRowsAtIndexPaths:@[[NSIndexPath indexPa-

thForRow:0 inSection:0]] withRowAnimation:UITableViewRowAnimationAutomatic];

} else {

//save failed

UIAlertView *alert = [[UIAlertView alloc] initWithTitle:@"Save

failed"

message:[erro-

rOrNil localizedDescription]

delegate:self

cancelButtonTitle:@"Ok"

otherButtonTitles:nil];

[alert show];

}

} withProgressBlock:nil];

}

}

}

- (IBAction)load:(id)sender

{

// Get a reference to a backend collection called "testObjects", which is

filled with

// instances of TestObject

KCSCollection *testObjects = [KCSCollection collectionFromString:@"testObjects"

ofClass:[TestObject class]];

// Create a data store connected to the collection, in order to save and load

TestObjects

KCSAppdataStore *store = [KCSAppdataStore storeWithCollection:testObjects

options:nil];

KCSQuery* query = [KCSQuery query];

[query addSortModifier:[[KCSQuerySortModifier alloc] initWithField:KCSMetadata-

FieldLastModifiedTime inDirection:kKCSDescending]];

// This will load the saved 12345 item from the backend

[store queryWithQuery:query withCompletionBlock:^(NSArray *objectsOrNil,

NSError *errorOrNil) {

[sender endRefreshing];

// Right now just pop-up an alert about what we got back from Kinvey during

// the load. Normally you would want to implement more code here

if (errorOrNil == nil && objectsOrNil != nil) {

//load is successful!

_objects = objectsOrNil;

[self.tableView reloadData];

} else {

//load failed

UIAlertView *alert = [[UIAlertView alloc] initWithTitle:@"Load failed"

message:[errorOrNil

localizedDescription]

delegate:self

cancelButtonTitle:@"Ok"

otherButtonTitles:nil];

[alert show];

}

} withProgressBlock:nil];

}

#pragma mark - View Controller

- (void)viewDidLoad

{

[super viewDidLoad];

_objects = @[];

[self.refreshControl addTarget:self

action:@selector(load:)

forControlEvents:UIControlEventValueChanged];

}

- (void)viewWillAppear:(BOOL)animated

{

[super viewWillAppear:animated];

[self load:nil];

}

#pragma mark - Table View Stuff

- (NSInteger)numberOfSectionsInTableView:(UITableView *)tableView

{

return 1;

}

- (NSInteger)tableView:(UITableView *)tableView numberOfRowsIn

Section:(NSInteger)section

{

return _objects.count;

}

- (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(N-

SIndexPath *)indexPath

{

UITableViewCell* cell = [tableView dequeueReusableCellWithIdentifier:@"aCell"];

cell.textLabel.text = [_objects[indexPath.row] name];

return cell;

}

- (BOOL)tableView:(UITableView *)tableView canEditRowAtIndexPath:(NSIndexPath

*)indexPath

{

return YES;

}

- (UITableViewCellEditingStyle)tableView:(UITableView *)tableView editingStyleFor-

RowAtIndexPath:(NSIndexPath *)indexPath

{

return UITableViewCellEditingStyleDelete;

}

- (void)tableView:(UITableView *)tableView commitEditingStyle:(UITableViewCellEdit-

ingStyle)editingStyle forRowAtIndexPath:(NSIndexPath *)indexPath

{

if (editingStyle == UITableViewCellEditingStyleDelete) {

TestObject* objToDelete = [_objects objectAtIndex:indexPath.row];

NSMutableArray* newObjects = [_objects mutableCopy];

[newObjects removeObjectAtIndex:indexPath.row];

self.objects = newObjects;

[tableView deleteRowsAtIndexPaths:@[indexPath] withRowAnimation:UI-

TableViewRowAnimationAutomatic];

// Get a reference to a backend collection called "testObjects", which is

filled with

// instances of TestObject

KCSCollection *testObjects = [KCSCollection collectionFromString:@"testOb-

jects" ofClass:[TestObject class]];

// Create a data store connected to the collection, in order to save and

load TestObjects

KCSAppdataStore *store = [KCSAppdataStore storeWithCollection:testObjects

options:nil];

// Remove our instance from the store

[store removeObject:objToDelete withCompletionBlock:^(NSArray *objectsOr-

Nil, NSError *errorOrNil) {

if (errorOrNil == nil && objectsOrNil != nil) {

//delete is successful!

UIAlertView *alert = [[UIAlertView alloc] initWithTitle:@"Delete

successful!"

message:nil

delegate:nil

cancelButtonTitle:@"Ok"

otherButtonTitles:nil];

[alert show];

} else {

//delete failed

UIAlertView *alert = [[UIAlertView alloc]

initWithTitle:@"Delete failed"

message:[errorOrNil

localizedDescription]

delegate:self

cancelButtonTitle:@"Ok"

otherButtonTitles:nil];

[alert show];

}

} withProgressBlock:nil];

}

}

@end

The iOS revolutionIt’s a story that never gets old. The weekend that iPad Minis and the fourth generation iPads went on sale (November 2-5, 2012) Apple sold over 3 million of the devices — a record for first-weekend iPad sales. Two months earlier the company had set another record: first weekend sales of over 5 million for the iPhone 5. Since the introduc-tion of the first iPhone back in 2007,

iOS-based devices (iPhone, iPad, iPad Mini and iPod Touch) continue to rewrite the definition of what constitutes a successful product. By the end of 2012, over 400 million iOS devices had been sold.

What makes iOS devices so successful? Innovation and product features are clearly a big part. Before the iPhone most people had not interacted with a multi-touch interface. They had never zoomed with a pinch or switched between portrait and landscape by merely rotating a device in their hand. Carrying a phone that knew where they were, could suggest places to eat, and could offer directions on how to get there was also a novel experience.

But features like multi-touch, accelerometers and GPS are only part of the appeal. Even with all its innovations, iOS still might not have taken off the way it has if the only people figuring out ways to use those innovations worked at Apple. Most of the capabilities available in an iPhone or iPad in fact don’t come from Apple at all. They come from legions of third-party developers who work in a vast ecosystem that is also an Apple innovation. That ecosystem includes the iPhone, iPad, iPad Mini, iPods, App Store, iTunes, ad networks — and that’s just on the consumer side. On the developer side, you have Xcode, App Loader, testing tools, iTunes Connect — the list goes on.

As of September 2012, the App Store hosted over 700,000 apps that have collectively been downloaded over 30 billion times. Apple reported for October 2012 that App Store monthly revenues were

running at $333 million — a rate of about $4 billion per year — remarkable for a store that only opened in July 2008.

Another innovation that has spurred iOS app development is “The Cloud.” Cloud services make it easier for independent developers to create, support and make money from their apps. The Cloud solves data storage and cross-device and user-to-user sharing problems. If an app stores data in the Cloud, that part of the application is called the “backend,” while the part of the app that runs on the phone and interacts with the user is called the “front end.”

A cloud may be “private” — i.e., the services belong to an organization for the benefit of its employees and business partners. Or a cloud may be “public” — i.e., a company (such as Amazon or Kinvey) owns the services, which developers can then integrate into their own apps. If you are a developer and want to build your own backend, you certainly can do that. Whether you want to or not depends on whether your backend provides functionality common to many different apps. If it does (as in a shopping cart or user authenti-cation) then perhaps that time and money would be better spent on features that offer unique value to your customer. You may be better off hooking into a commercial backend provider via an API. Then you can focus on what counts most — a unique user experience and application-specific functionality. That brings us to the first step in making an app.

Define your appMost unsuccessful apps fail for any of four reasons:

1. the app was a solution in search of a problem (i.e., no real need existed) 2. the implementation was poor 3. the app tried to do too much; or 4. the Apple App Store rejected the app (either because the implementation was poor or it violated Apple’s content policies)

Keeping the app as simple as possible is the best way to avoid these pitfalls. Most successful apps (indeed, most successful consumer tech products) are based on what is called an MVP, or minimum viable product. It’s the product with the smallest feature set that can deliver the core function without any distracting “bells and whistles.” You know you have an MVP if the product would no longer function if you removed any single feature.

But what should that core feature be? One of the best examples of an MVP is Mail. Version 1 (on the Mac) offered a clear, limited and intuitive feature set whose usefulness was immediately obvious to anyone. Today’s iPhone version integrates seamlessly with your phone, contacts and calendaring. It auto-matically corrects spelling as you type, lets you email photos directly from your photos app, and does much more. But all that came later and was built on top of a basic core function. And that’s how your first app should be built. The key is to come up with something with a clear value that changes people’s lives.

So, in drawing up your MVP feature list, ask yourself what features are key to the experience. Some basic market research is probably in order, starting with a visit to the App Store to see what already exists (possibly to be improved upon and/or to compete with you). Likely

must-have core capabilities include:

• Performance (e.g., fast screen refresh)• Offline capability (i.e., ability to work when not connected to the Internet)• Location awareness (e.g., the data/experience will change with the user’s location)• Cloud syncing (e.g., users see the same data on multiple devices)• Push notifications (i.e., sending updated information to devices as soon as it is available)

When you have a handle on what your app does, the next step is to design it. Designing your app involves making choices of how infor-mation and controls are presented to the user as well as how to implement app logic, and figuring out what data lives locally and what belongs in the Cloud.

Design your appUser experience decisions determine the app’s look and feel. They answer questions such as: What does the app look like? What screens does it have? In the software development world, onscreen objects like buttons, sliders, and fill-in boxes are called widgets. So you need to decide which types of widgets will reside on which screens. And what actions will occur as a result of the user interacting with those widgets?

Keep in mind that users will expect to interact differently with a mobile device than they do with a PC because the screens on mobile devices are much smaller. They’ll expect to use their fingers instead of a mouse or a track pad. Ideally, your app can even be used with one hand holding the device while using just a thumb for scrolling andworking the app’s other controls— the Path app is a good example, and increasingly, so is Facebook.

Your app’s features will inform its architecture, which is how you’ll divide the code and data into functional parts. If your app requires interacting with other app users or networked services, you’ll need to figure out what piece of the logic lives in the app code and what comes from the backend. For example, your app might integrate with a restau-rant recommendation engine, share user location, or pull real-time traffic data. This is done using APIs provided by various service providers — but you don’t have to wire up your app to a network to get started. You can develop a prototype using predefined representative (or “dummy”) data. It’s easier to fine-tune the front end if you don’t have to simultaneously modify your backend too. Once you get the app’s look-and-feel right, then make those backend connections.

Once you’ve got the overall concept for your app, the next step is to express that design in terms of the iOS app architecture. That archi-tecture is the model for what parts an iOS app can contain and how those parts fit together. It’s a well thought-out approach for translat-ing a product concept into actual code you can deploy on a device.

WHY iOS?Besides the features and design of your first app, there’s one more decision you need to make before you start actual development. That’s whether to deploy on Apple’s iOS platform or on Google’s Android platform. (Some of this is also covered in our ebook, How to Make an App: Android Edition.) Reasons to develop for iOS include:

Customers more willing to pay. Perhaps it’s because of Android’s open source heritage, but whatever the reason, Android apps gener-ate less than 10% of the total dollars spent on mobile apps, despite having 75% of the smartphone market itself — and despite the fact that the average selling price of an app in the Google Play is $3.79 versus Apple App Store’s $2.01. In other words, Apple users are much more willing to spend money on apps.

The Apple Ecosystem. Some developers and users prefer Apple’s closed and more tightly controlled environment. Apple’s ecosystem, consisting of Xcode, iCloud, iTunes, the App Store, the iPad, the iPhone, Mac computers, etc., offers a very holistic user experience with the ability to share data seamlessly across devices plus the

assurance of having applications pre-approved for quality and content prior to going on sale.

Xcode. Apple’s all-in-one IDE offers state-of-the-art offers features like a graphical interface builder and a syntax-aware and compiler-aware source editor.

The Apple Experience. From the fit and finish of its hardware to the customer service in its retail stores, to the way its hardware and software work flawlessly together, Apple has created the premium brand in consumer electronics. iOS developers share the benefits — so when someone downloads your iOS app, they already expect it’s a great product. And that it will also work flawlessly on their device.

Tablets. iOS has a clear advantage over Android in terms of tablet market adoption. Using Xcode, it’s also much easier to migrate an app from a phone to a tablet and vice versa than it is when develop-ing for Android.

Why Not iOS?Although iOS offers many compelling advantages as a platform for your mobile app, it also comes with some disadvantages. Here are three:

Closed Platform. iOS apps only run on Apple products so you can’t take advantage of features (like NFC) available only on non-iOS devices or market growth of non-iOS devices.

Market Growth. Today, iOS represents less than 15% of the total smartphone market, Although the total market (“the whole pie”) is still increasing at a fast rate, Android market growth outpaces iOS growth.

Approvals. The App Store’s app approval process is notoriously more time consuming than Google Play’s process.

The iOS app architectureAs noted earlier, a key reason why there are so many apps for iOS is because developing highly functional, polished apps for the platform is relatively easy. That’s mainly because of: 1) the design of the development tools, and 2) the key architectural features most iOS apps have in common. So let’s start with some concepts since it helps to know what goes into an app before trying to create one. We’ll begin with:

• Design patterns• Frameworks• Delegation• Storyboard• Windows• Outlets• Supporting files• Products

Design patterns. iOS apps implement what is known as a Mod-el-View-Controller (MVC) pattern. A pattern is a common way to structure code that solves a particular design problem. The MVC pattern separates application code in a way that allows you to easily change one part of an app without having to change other parts. An MVC pattern consists of three components:

• The Model is the logic that acts on the data, such as to store or retrieve data from a database, compute the distance between two cities on a map, etc. An example of a model is the Kinvey backend that stores your data in the Cloud as a service.

• The View provides the interface to the user; it displays the data and widgets (e.g., buttons and text fields) that allow the user to interact with the data. An iPhone app may have more than one view, as in the Contacts app, which displays a list view of all contacts or alternatively a view of each individual contact.

• The Controller is between the model and the view — i.e., it responds to user requests (made in a view) and retrieves results

(produced in a model). This is where developers spend most of their time — constructing the View Controller — by defining and attaching actions (or behaviors) to onscreen widgets. When the user taps a button, for example, it is the View Controller that determines what action will occur, such as retrieve stored data from your Kinvey-based data store. The link between a view object (like a button) to a controller action is called a connection.

Frameworks. You don’t actually have to write most of an app’s logic. It already exists as frameworks. A framework is a collection of classes that implements some function — such as connecting to the Internet, drawing a button, etc. Rather than write the code from scratch, you just use the frameworks supplied by iOS. Some frameworks are automatically present when you start a new project while others may need to be added (done via a drop down menu in Xcode’s Project Editor).

Delegation. Say, you want to customize the behavior of a framework’s object. You can’t actually modify the code of the framework class itself (prohibited since other apps may also use the framework). But what you can do is provide app-specific behavior in an application delegate object. If a delegate implements a method, it will be called by the delegating class to modify its behavior. In the Kinvey sample app (one of two examples we will be describing below), the AppDele-gate.h and AppDelegate.m — the header and implementation files for the UIApplicationDelegate, respectively — contain the code that authenticates an app to the Kinvey backend service.

Storyboards and XIBs. The MainStoryboard.storyboard file (or a .xib file, if you did not click on the “Use Storyboard” option when starting your project) contains the view information needed to implement the overall flow and display of your application and the user interface elements.

Windows. Each view (e.g., the contact list and individual contact details in the Contacts app) exists within a window. The window represents the entire device screen and is where all your views are presented.

Outlets. A variable by which a view object can be referenced in a controller. (For example, if you place a text field to capture a user's name, you might create an outlet called UITextField* nameField.)

Supporting files. These are files that provide resources (like PNG images and other static data) that your app needs as well as files that configure how the app will run. Other examples:

.pch files — precompiled headers used for the code files in your project.

.plist files — property lists that are small amounts of persistent data (like your app’s default user settings) consisting primarily of strings and numbers that you want your app to be able to access, modify if needed, and write back into the property list.

main.m file — your app’s main function. This is needed to launch the app, but you will not need to modify this file.

InfoPlist.strings file — used for localization.

Products. This is the file for your app (i.e., YourProduct.app) that is built when you click Xcode’s “run” button.

“Making an iOS app” involves working with these features in the typical, straightforward workflow:

• Storyboard your views by dragging and configuring graphicalobjects on a template

• Adding behaviors to the various widgets• Writing the classes as to define those behaviors (including

delegates)• Adding needed support files• Building and running the app• Iterating until you are satisfied with your app

This is all done within Xcode.

What’s Xcode?You can start developing functional, good-looking apps almost from the moment you download Xcode, Apple’s integrated development environment (IDE) for making iOS and Macintosh apps. Among other features, Xcode includes a source code editor, graphical user inter-face (GUI) editor (sometimes called Interface Builder), source code repository manager, compiler, and much more. iOS applications are typically developed by manipulating views graphically and by typing Objective-C code for the models and controllers.

To get Xcode, simply go to the App Store and download the applica-tion (it’s free). To do this, click on the App Store icon in your Mac’s dock, or visit https://itunes.apple.com/us/genre/ios/id36?mt=8

The app store will download and install Xcode in your Application folder. From Applications, double-click the Xcode icon to launch Xcode and you’ll see its splash screen (Figure 1). From there you can click on “Create a new Xcode project” to take you to a menu of several templates on which to base your application. Selecting a template opens an Xcode workspace pre-populated with frameworks and other files Xcode thinks you will need using that template.

Although you can develop, build and simulate your app on your computer in Xcode, you can’t run your app on a target device (even your own iPhone) until you become a registered iOS developer and join the iOS Developer Program. To do that, go to develop-er.app.com/ and navigate to the iOS Dev Center. While there, you will also find documentation, sample code and other useful resources such as information on how to submit your app to the iOS App Store.

Everything you do in Xcode is done in a window, called a workspace (Figure 2), consisting of multiple work areas, some of which are also divided into panes. All the files needed to build your app belong to a project, and the Navigator area (far left) lists all your projects (there can be several in a workspace) and all files for each project. Clicking on a file in the Navigator area shows its contents in the Editor area and invokes the appropriate editor. Clicking on a .h or .m file, for example, shows the file’s source code and invokes the Source editor, so you can edit the code. Clicking on .storyboard or .xib (sometimes called a “nib”) file shows the app’s storyboard and invokes the Inter-face Builder, so you can design a view using the Builder’s drag and drop features.

An especially handy feature is that the Editor area can have both a right and a left pane — with each pane aware of your edits in the other. So, for example, you can simultaneously edit an object’s .h

header file in the left pane and its corresponding .m in the right pane. Or you might click on a button object (displayed graphically) in the left pane and edit its method’s source code in the right pane. To toggle between a single pane (the “Standard Editor”) and double pane view (the “Assistant Editor”), use the Editor selector button on the right of the toolbar. You can option+command+click a symbol in the editor to open the definition in the opposite editor pane.

You can also resize the entire Editor area simply by dragging its borders. For even more editing space, you can also remove the Debug area or both the Debug and Utility areas using the View Selector button on the far right of the toolbar.

As its name suggests, the Debug area shows information, like variable state and console logs, helpful in debugging code.

The Utility area has two panes: the Inspector and Quick Help pane (top) and the Library pane (bottom). Although there are five inspectors — File, Help, Identity, Attributes, Size and Connec-tions — only the inspectors that are currently relevant appear in the Inspec-tor list at the top of the pane. (To see the name of an inspector, move the cursor over its icon in the Inspector selector bar.)

You will use inspectors to add and modify object attributes for views in the Interface Builder. For example, if you click on a UILabel in the Editor area of a storyboard, you can use the Attributes inspector to change the label’s color and use the Size inspector to change the label’s size.

The Help inspector shows help information about a selected class. Use the Identity inspector to view and manage an object’s metadata such as its class, runtime attributes, label and so forth. Use the

Connections inspector to view the outlets and actions of an interface object, to make new connections and to delete existing connections.

The Library pane has libraries of resources (like file templates, code snippets, interface objects and media files) that are prebuilt and ready to insert into your project. Use the Library selector to select which of these libraries (e.g., code snippets or interface objects) you wish to insert. To insert one, drag it directly into your storyboard while using the Interface Builder editor.

These are basics you need to know to get started using Xcode to build your first app. But to really understand how it’s done, it helps to walk through an actual app or two. Let’s start with a simple “Hello World” app that does not employ a backend connection, and then look at a somewhat more functional app that does.

“Hello World!” sample appThis app displays a button (“Press Me”) and a label (“Label”) so that when the user presses the button the text of the label changes to “Hello World!” as in Figure 3:

To get started, launch Xcode and select “Create a New Xcode Project.” From the iOS Application templates, select “Single View Application” and click “Next.” Fill in your product’s name and a company identifier, typically “com.yourCompanyName.” Deselect “Use Storyboards” and leave “Use Automatic Reference Counting” selected. Then click “Next” and select a destination for your projects files.

Follow these steps to make your app:

1. Select your project’s ViewController.xib file in the Navigator(Figure 4), to open the Interface Builder editor.

2. Drag a “Round Rect Button” from the Objects library (lowerright) onto the view in the Editor area; select the button’s textand type “Press Me.”

3. Drag a Label from the objects library onto the view, as well.4. Select and drag the Label sizing handles, centering the object

and making it wide enough to hold the “Hello World!” text; then,

5. With the “Hello World!” label still selected, click on centeralignment in the Attributes inspector.

6. Open the Assistant Editor (Figure 5), exposing the source codeheader file (ViewController.h) of the view controller you justbuilt graphically.

7. Select the button and control-drag from the button to justbelow the ViewController definition in the Assistant panel. Inthe form that opens, select “Action” for the connection type,type in a name (“showText”) and click “Connect.” This creates aninterface builder (IB) action as highlighted in Figure 6.

8. Next step is to create an outlet for the label. To do this, selectthe label object and control-drag from the label to just belowthe IB action you just created. Select “Outlet” as the connectiontype and enter a name “label” and click “Connect.” This createsan interface builder (IB) outlet as shown in Figure 7.

9. Finally, it’s time to add some logic to the view controller so itknows what to do when the button is pressed. To do this, select “ViewController.m” in the project navigator to show the code editor. Find the button’s IBAction you just created (near the bottom), place your cursor between the { } brackets and hit the return key a few times to create some extra space. Then in that space type the method for how you want the label you speci-fied to respond: _label.text=”Hello World!”; as highlighted in Figure 8.

Congratulations! Your app is done. To build and run your new app in the simulator, click the Xcode Run button in the left corner of the toolbar. When you click the button, the text will update.

Sample app with a backend This second app (named “Kinvey Test Drive”) lets the user type text on an iPhone and save the text to a backend service, like Kinvey. It also lets the user load text on the iPhone from their Kinvey backend. Reading about this app will help you learn:

• How to set up Kinvey’s library in an iOS project• Additional Interface Builder techniques you can use to story-board an application• How to add view controller logic to interact with the backend service, allowing you to save and retrieve data

We will first present the app as a running application and then take it apart so you can see how it was made. To make the app yourself, you can review the various sections below and replicate the steps in your copy of Xcode.

First, to see the app in action, you should download the app and run it on your system. To do that, sign up for Kinvey, then navigate to “Dev Center”, “Samples,” find the “Test Drive” app, and click on its icon. (If you can’t find it right away, make sure you select iOS as your platform on the right side of the menu bar.) Click the download button to download the app’s project files to your computer. Then launch Xcode — just double click on the .xcodeproj file in the project folder.

But before you can run the app, you need to set up the app’s Kinvey backend.

Set Up Kinvey as a Backend Data StoreTest Drive’s project files include all the code the sample app needs in order to talk to Kinvey. However, that would not be the case if you were to build an app from scratch — so you would have to go through an initial Kinvey setup procedure. This involves downloading the Kinvey library files from the downloads section of devcenter.kin-vey.com and dragging them to the Navigator’s Frameworks folder in Xcode. You also need to tell Xcode to link your project with additional iOS frameworks. To find these frameworks, click on the Project folder

at the very top of the Navigator pane — which displays the Project editor — and then select the “Build Settings” tab. For detailed instruc-tions, complete the “Getting Started” page under “Guides” on the Kinvey website. But again, you can skip this setup procedure for now in order to run the downloaded Kinvey Test Drive app.

But you must still do this step: To run any app that uses Kinvey (including Test Drive) you need to do the “Create an App” step on the Kinvey website. Click on “My Apps” in the Kinvey menu bar and then click on “Add an App,” which will open an “Add” page. Type in a name for your app and click on the Apple logo and then click “Create.” The page that opens shows your App’s credentials. Copy and paste the App Key and App Secret into the AppDelegate.m file of the download-ed Test Drive project:

You are now ready to run the app — click on the Xcode run button and wait for the simulator to open and the app to appear (Figure 9).

Clicking the “+” toolbar button opens an alert (Figure 10) with an empty field into which the user can type some text (e.g., “some new data”). Clicking “save” uploads the data to Kinvey and displays text on the screen (a table view) and also displays an alert that the save worked (Figure 11).

To test the load function, enter some data (e.g., “some data to load”) in the “name” field of the Kinvey collection. To see the load, the swipe down on the table on the phone until the refresh spinner starts, and then the new data will appear in the table (Figure 12).

Figure 13 shows the Kinvey collection after the save that Figure 10 depicts on the iPhone. Figure 14 shows the Kinvey collection after the user adds a new row to the testObjects collection using the web browser. Note that every time a save is done on the iPhone, Kinvey automatically adds a new row (displayed on a collection refresh). To add a new row manually in the browser, click “+ row,” and type some descriptive text in the “name” column. That data will now load on the iPhone when the user pulls down on the table.

Storyboard the Test Drive AppMost of the Test Drive user interface objects visible in the simulation are available in Xcode’s Object Library and can therefore be added to the view graphically. The UI objects consist of a:

• Table view• Toolbar• Tool Bar Button item – flexible space• Tool Bar Button item – Add• Table view cell• Label – Title• Refresh Control

To create this app yourself, you would follow these steps:

• Launch Xcode and select the “Single View Application” template• Select the “Use Storyboard” option• Replace the default UIviewcontroller object with a UITableView-Controller • Drag and drop the other objects, in the order listed, onto the UIviewcontroller

Also note:

• The Flexible Space Bar Button item fills up the space on the toolbar so the add button is at the right. This is a standard pattern in table-based iPhone apps.• The add button shows the system “+” sign. That is done by dragging a bar button item onto the toolbar, clicking on the Identifier drop down menu in the Attributes inspector; and then selecting the “Add” option.

As with the “Hello World!” app, once your app’s view is complete (Figure 15), you would still have to create the various methods and connections that bring them to life. This is done using the Source editor while working with the ViewController.m file.

Add View Controller LogicSince the app performs two basic operations (save data to Kinvey and load data from Kinvey) these two methods must be added to the ViewController header file. That’s done with a control-drag from the “+” bar button over to just under the “@ interface ViewController” line in ViewController.h. (Open the Assistant editor to see both the storyboard and the file source.)

During the drag, the popup appears, asking for the name and type of connection. Enter “action” for the connection type and “add” for the name. Then repeat the drag, this time from the refresh control and using “add” for the name (Figure 16).

Note: to follow this discussion it will help to have the referenced files open in your Xcode Source editor.

In ViewController.m, you will see the implementation code associated with each of the two Interface Builder methods, whose names Xcode added automatically to the .m file:

- (IBAction)add:(id)sender- (IBAction)load:(id)sender

You will also see a third section of code not associated with these methods, which starts with the line: “#pragma mark - Table View Stuff.” These methods support the table view and are part of UITableViewD-elegate and UITableViewDataSource. They handle controlling the

display of the table, and respond to user gestures. For example, swiping a table cell will show the delete button because tableView:-canEditRowAtIndexPath: returns YES and tableView:editingStyleForRowA-tIndexPath: returns UITableViewCellEditingStyleDelete. If you tap the delete button, the delegate method tableView:commitEditingStyle:for-RowAtIndexPath: is called. The code of this method deletes the data for the row and removes it from Kinvey’s data store. When the backend delete is completed, the app displays an alert describing the success or failure.

The way that all three sections (and all Kinvey-enabled apps) move data in and out of a Kinvey collection is by getting a reference to the app’s backend collection (named “testObjects”), which is filled with instances (each named “TestObject”) of the data the app wants to move. That’s why you’ll find the following code repeated three times in Test Drive’s View Controller (once for the add, once for the load, and once for the delete):

To support these statements it is required to have a data object class (TestObject). To see how these files are written in the sample project, click on TestObject.h file and TestObject.m in the Navigator pane. If you were to supply these files in your own app, you would click File > New File, and specify Objective-C class, which would be a subclass of NSObject. Then you would type in the code, with a property for each column in the Kinvey backend collection (including one for the object’s id).

As mentioned earlier, your app also needs to authenticate itself to Kinvey, which is handled by AppDelegate.h and AppDelgate.m. These files are created by Xcode when you create a new project, and start out with just a stub implementation. Look in the sample app source

files for code to copy and paste.

For both the save and load operations, however, moving the data in and out of a backend collection is only part of the work. Table 1 lists all the functions that implements the save and load in the ViewCon-troller.m file, along with pointers to its corresponding block of imple-mentation source code. (For each function, its corresponding code begins with the “Starts at” line and ends with the “Ends at” line.) Refer to Appendix 1 to find the actual source code.

Say Hello To Our WorldThe key takeaway from all this is that “making an app” is a worthwhile thing to do for anyone with a clever idea and a working knowledge of Objective-C. The proof is in the hundreds of apps succeeding in the market every day, many written by people working on their own and who never wrote an app before in their lives. As with anything else, practice does make perfect. But hopefully with all the resources available, and the knowledge gained from this ebook, you have already started down the path toward joining the growing legions of iOS app developers. If so, we welcome you!

Appendix 1 — Test Drive Sample App ViewController.m Source Code

37

//

// ViewController.m

// Kinvey Quickstart

//

// Created by Michael Katz on 11/12/12.

// Copyright (c) 2012-2013 Kinvey. All rights reserved.

//

#import "ViewController.h"

#import "TestObject.h"

#define CREATE_NEW_ENTITY_ALERT_VIEW 100

@interface ViewController ()

@property (nonatomic, strong) NSArray* objects;

@end

@implementation ViewController

- (IBAction)add:(id)sender

{

UIAlertView* alert = [[UIAlertView alloc] initWithTitle:@"Create a New Entity"

message:@"Enter a title for the

new entity"

delegate:self

cancelButtonTitle:@"Cancel"

otherButtonTitles:@"Save", nil];

alert.alertViewStyle = UIAlertViewStylePlainTextInput;

alert.tag = CREATE_NEW_ENTITY_ALERT_VIEW;

[alert show];

}

- (void)alertView:(UIAlertView *)alertView clickedButtonAtIndex:(NSInteger)but-

tonIndex

{

if (alertView.tag == CREATE_NEW_ENTITY_ALERT_VIEW) {

if (buttonIndex == alertView.firstOtherButtonIndex) {

// Define an instance of our test object

TestObject *testObject = [[TestObject alloc] init];

// This is the data we'll save

testObject.name = [[alertView textFieldAtIndex:0] text];

// Get a reference to a backend collection called "testObjects", which

is filled with

// instances of TestObject

KCSCollection *testObjects = [KCSCollection collectionFromString:@"tes-

tObjects" ofClass:[TestObject class]];

// Create a data store connected to the collection, in order to save

and load TestObjects

KCSAppdataStore *store = [KCSAppdataStore storeWithCollection:testOb-

jects options:nil];

// Save our instance to the store

[store saveObject:testObject withCompletionBlock:^(NSArray *objectsOr-

Nil, NSError *errorOrNil) {

// Right now just pop-up an alert about what we got back from

Kinvey during

// the save. Normally you would want to implement more code here

if (errorOrNil == nil && objectsOrNil != nil) {

//save is successful!

UIAlertView *alert = [[UIAlertView alloc] initWithTitle:@"Save

worked!"

message:[NS-

String stringWithFormat:@"Saved: '%@'",[objectsOrNil[0] name]]

delegate:nil

cancelButtonTitle:@"Ok"

otherButtonTitles:nil];

[alert show];

self.objects = [@[testObject] arrayByAddingObjectsFromArray:_-

objects];

[self.tableView insertRowsAtIndexPaths:@[[NSIndexPath indexPa-

thForRow:0 inSection:0]] withRowAnimation:UITableViewRowAnimationAutomatic];

} else {

//save failed

UIAlertView *alert = [[UIAlertView alloc] initWithTitle:@"Save

failed"

message:[erro-

rOrNil localizedDescription]

delegate:self

cancelButtonTitle:@"Ok"

otherButtonTitles:nil];

[alert show];

}

} withProgressBlock:nil];

}

}

}

- (IBAction)load:(id)sender

{

// Get a reference to a backend collection called "testObjects", which is

filled with

// instances of TestObject

KCSCollection *testObjects = [KCSCollection collectionFromString:@"testObjects"

ofClass:[TestObject class]];

// Create a data store connected to the collection, in order to save and load

TestObjects

KCSAppdataStore *store = [KCSAppdataStore storeWithCollection:testObjects

options:nil];

KCSQuery* query = [KCSQuery query];

[query addSortModifier:[[KCSQuerySortModifier alloc] initWithField:KCSMetadata-

FieldLastModifiedTime inDirection:kKCSDescending]];

// This will load the saved 12345 item from the backend

[store queryWithQuery:query withCompletionBlock:^(NSArray *objectsOrNil,

NSError *errorOrNil) {

[sender endRefreshing];

// Right now just pop-up an alert about what we got back from Kinvey during

// the load. Normally you would want to implement more code here

if (errorOrNil == nil && objectsOrNil != nil) {

//load is successful!

_objects = objectsOrNil;

[self.tableView reloadData];

} else {

//load failed

UIAlertView *alert = [[UIAlertView alloc] initWithTitle:@"Load failed"

message:[errorOrNil

localizedDescription]

delegate:self

cancelButtonTitle:@"Ok"

otherButtonTitles:nil];

[alert show];

}

} withProgressBlock:nil];

}

#pragma mark - View Controller

- (void)viewDidLoad

{

[super viewDidLoad];

_objects = @[];

[self.refreshControl addTarget:self

action:@selector(load:)

forControlEvents:UIControlEventValueChanged];

}

- (void)viewWillAppear:(BOOL)animated

{

[super viewWillAppear:animated];

[self load:nil];

}

#pragma mark - Table View Stuff

- (NSInteger)numberOfSectionsInTableView:(UITableView *)tableView

{

return 1;

}

- (NSInteger)tableView:(UITableView *)tableView numberOfRowsIn

Section:(NSInteger)section

{

return _objects.count;

}

- (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(N-

SIndexPath *)indexPath

{

UITableViewCell* cell = [tableView dequeueReusableCellWithIdentifier:@"aCell"];

cell.textLabel.text = [_objects[indexPath.row] name];

return cell;

}

- (BOOL)tableView:(UITableView *)tableView canEditRowAtIndexPath:(NSIndexPath

*)indexPath

{

return YES;

}

- (UITableViewCellEditingStyle)tableView:(UITableView *)tableView editingStyleFor-

RowAtIndexPath:(NSIndexPath *)indexPath

{

return UITableViewCellEditingStyleDelete;

}

- (void)tableView:(UITableView *)tableView commitEditingStyle:(UITableViewCellEdit-

ingStyle)editingStyle forRowAtIndexPath:(NSIndexPath *)indexPath

{

if (editingStyle == UITableViewCellEditingStyleDelete) {

TestObject* objToDelete = [_objects objectAtIndex:indexPath.row];

NSMutableArray* newObjects = [_objects mutableCopy];

[newObjects removeObjectAtIndex:indexPath.row];

self.objects = newObjects;

[tableView deleteRowsAtIndexPaths:@[indexPath] withRowAnimation:UI-

TableViewRowAnimationAutomatic];

// Get a reference to a backend collection called "testObjects", which is

filled with

// instances of TestObject

KCSCollection *testObjects = [KCSCollection collectionFromString:@"testOb-

jects" ofClass:[TestObject class]];

// Create a data store connected to the collection, in order to save and

load TestObjects

KCSAppdataStore *store = [KCSAppdataStore storeWithCollection:testObjects

options:nil];

// Remove our instance from the store

[store removeObject:objToDelete withCompletionBlock:^(NSArray *objectsOr-

Nil, NSError *errorOrNil) {

if (errorOrNil == nil && objectsOrNil != nil) {

//delete is successful!

UIAlertView *alert = [[UIAlertView alloc] initWithTitle:@"Delete

successful!"

message:nil

delegate:nil

cancelButtonTitle:@"Ok"

otherButtonTitles:nil];

[alert show];

} else {

//delete failed

UIAlertView *alert = [[UIAlertView alloc]

initWithTitle:@"Delete failed"

message:[errorOrNil

localizedDescription]

delegate:self

cancelButtonTitle:@"Ok"

otherButtonTitles:nil];

[alert show];

}

} withProgressBlock:nil];

}

}

@end

38

//

// ViewController.m

// Kinvey Quickstart

//

// Created by Michael Katz on 11/12/12.

// Copyright (c) 2012-2013 Kinvey. All rights reserved.

//

#import "ViewController.h"

#import "TestObject.h"

#define CREATE_NEW_ENTITY_ALERT_VIEW 100

@interface ViewController ()

@property (nonatomic, strong) NSArray* objects;

@end

@implementation ViewController

- (IBAction)add:(id)sender

{

UIAlertView* alert = [[UIAlertView alloc] initWithTitle:@"Create a New Entity"

message:@"Enter a title for the

new entity"

delegate:self

cancelButtonTitle:@"Cancel"

otherButtonTitles:@"Save", nil];

alert.alertViewStyle = UIAlertViewStylePlainTextInput;

alert.tag = CREATE_NEW_ENTITY_ALERT_VIEW;

[alert show];

}

- (void)alertView:(UIAlertView *)alertView clickedButtonAtIndex:(NSInteger)but-

tonIndex

{

if (alertView.tag == CREATE_NEW_ENTITY_ALERT_VIEW) {

if (buttonIndex == alertView.firstOtherButtonIndex) {

// Define an instance of our test object

TestObject *testObject = [[TestObject alloc] init];

// This is the data we'll save

testObject.name = [[alertView textFieldAtIndex:0] text];

// Get a reference to a backend collection called "testObjects", which

is filled with

// instances of TestObject

KCSCollection *testObjects = [KCSCollection collectionFromString:@"tes-

tObjects" ofClass:[TestObject class]];

// Create a data store connected to the collection, in order to save

and load TestObjects

KCSAppdataStore *store = [KCSAppdataStore storeWithCollection:testOb-

jects options:nil];

// Save our instance to the store

[store saveObject:testObject withCompletionBlock:^(NSArray *objectsOr-

Nil, NSError *errorOrNil) {

// Right now just pop-up an alert about what we got back from

Kinvey during

// the save. Normally you would want to implement more code here

if (errorOrNil == nil && objectsOrNil != nil) {

//save is successful!

UIAlertView *alert = [[UIAlertView alloc] initWithTitle:@"Save

worked!"

message:[NS-

String stringWithFormat:@"Saved: '%@'",[objectsOrNil[0] name]]

delegate:nil

cancelButtonTitle:@"Ok"

otherButtonTitles:nil];

[alert show];

self.objects = [@[testObject] arrayByAddingObjectsFromArray:_-

objects];

[self.tableView insertRowsAtIndexPaths:@[[NSIndexPath indexPa-

thForRow:0 inSection:0]] withRowAnimation:UITableViewRowAnimationAutomatic];

} else {

//save failed

UIAlertView *alert = [[UIAlertView alloc] initWithTitle:@"Save

failed"

message:[erro-

rOrNil localizedDescription]

delegate:self

cancelButtonTitle:@"Ok"

otherButtonTitles:nil];

[alert show];

}

} withProgressBlock:nil];

}

}

}

- (IBAction)load:(id)sender

{

// Get a reference to a backend collection called "testObjects", which is

filled with

// instances of TestObject

KCSCollection *testObjects = [KCSCollection collectionFromString:@"testObjects"

ofClass:[TestObject class]];

// Create a data store connected to the collection, in order to save and load

TestObjects

KCSAppdataStore *store = [KCSAppdataStore storeWithCollection:testObjects

options:nil];

KCSQuery* query = [KCSQuery query];

[query addSortModifier:[[KCSQuerySortModifier alloc] initWithField:KCSMetadata-

FieldLastModifiedTime inDirection:kKCSDescending]];

// This will load the saved 12345 item from the backend

[store queryWithQuery:query withCompletionBlock:^(NSArray *objectsOrNil,

NSError *errorOrNil) {

[sender endRefreshing];

// Right now just pop-up an alert about what we got back from Kinvey during

// the load. Normally you would want to implement more code here

if (errorOrNil == nil && objectsOrNil != nil) {

//load is successful!

_objects = objectsOrNil;

[self.tableView reloadData];

} else {

//load failed

UIAlertView *alert = [[UIAlertView alloc] initWithTitle:@"Load failed"

message:[errorOrNil

localizedDescription]

delegate:self

cancelButtonTitle:@"Ok"

otherButtonTitles:nil];

[alert show];

}

} withProgressBlock:nil];

}

#pragma mark - View Controller

- (void)viewDidLoad

{

[super viewDidLoad];

_objects = @[];

[self.refreshControl addTarget:self

action:@selector(load:)

forControlEvents:UIControlEventValueChanged];

}

- (void)viewWillAppear:(BOOL)animated

{

[super viewWillAppear:animated];

[self load:nil];

}

#pragma mark - Table View Stuff

- (NSInteger)numberOfSectionsInTableView:(UITableView *)tableView

{

return 1;

}

- (NSInteger)tableView:(UITableView *)tableView numberOfRowsIn

Section:(NSInteger)section

{

return _objects.count;

}

- (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(N-

SIndexPath *)indexPath

{

UITableViewCell* cell = [tableView dequeueReusableCellWithIdentifier:@"aCell"];

cell.textLabel.text = [_objects[indexPath.row] name];

return cell;

}

- (BOOL)tableView:(UITableView *)tableView canEditRowAtIndexPath:(NSIndexPath

*)indexPath

{

return YES;

}

- (UITableViewCellEditingStyle)tableView:(UITableView *)tableView editingStyleFor-

RowAtIndexPath:(NSIndexPath *)indexPath

{

return UITableViewCellEditingStyleDelete;

}

- (void)tableView:(UITableView *)tableView commitEditingStyle:(UITableViewCellEdit-

ingStyle)editingStyle forRowAtIndexPath:(NSIndexPath *)indexPath

{

if (editingStyle == UITableViewCellEditingStyleDelete) {

TestObject* objToDelete = [_objects objectAtIndex:indexPath.row];

NSMutableArray* newObjects = [_objects mutableCopy];

[newObjects removeObjectAtIndex:indexPath.row];

self.objects = newObjects;

[tableView deleteRowsAtIndexPaths:@[indexPath] withRowAnimation:UI-

TableViewRowAnimationAutomatic];

// Get a reference to a backend collection called "testObjects", which is

filled with

// instances of TestObject

KCSCollection *testObjects = [KCSCollection collectionFromString:@"testOb-

jects" ofClass:[TestObject class]];

// Create a data store connected to the collection, in order to save and

load TestObjects

KCSAppdataStore *store = [KCSAppdataStore storeWithCollection:testObjects

options:nil];

// Remove our instance from the store

[store removeObject:objToDelete withCompletionBlock:^(NSArray *objectsOr-

Nil, NSError *errorOrNil) {

if (errorOrNil == nil && objectsOrNil != nil) {

//delete is successful!

UIAlertView *alert = [[UIAlertView alloc] initWithTitle:@"Delete

successful!"

message:nil

delegate:nil

cancelButtonTitle:@"Ok"

otherButtonTitles:nil];

[alert show];

} else {

//delete failed

UIAlertView *alert = [[UIAlertView alloc]

initWithTitle:@"Delete failed"

message:[errorOrNil

localizedDescription]

delegate:self

cancelButtonTitle:@"Ok"

otherButtonTitles:nil];

[alert show];

}

} withProgressBlock:nil];

}

}

@end

39

//

// ViewController.m

// Kinvey Quickstart

//

// Created by Michael Katz on 11/12/12.

// Copyright (c) 2012-2013 Kinvey. All rights reserved.

//

#import "ViewController.h"

#import "TestObject.h"

#define CREATE_NEW_ENTITY_ALERT_VIEW 100

@interface ViewController ()

@property (nonatomic, strong) NSArray* objects;

@end

@implementation ViewController

- (IBAction)add:(id)sender

{

UIAlertView* alert = [[UIAlertView alloc] initWithTitle:@"Create a New Entity"

message:@"Enter a title for the

new entity"

delegate:self

cancelButtonTitle:@"Cancel"

otherButtonTitles:@"Save", nil];

alert.alertViewStyle = UIAlertViewStylePlainTextInput;

alert.tag = CREATE_NEW_ENTITY_ALERT_VIEW;

[alert show];

}

- (void)alertView:(UIAlertView *)alertView clickedButtonAtIndex:(NSInteger)but-

tonIndex

{

if (alertView.tag == CREATE_NEW_ENTITY_ALERT_VIEW) {

if (buttonIndex == alertView.firstOtherButtonIndex) {

// Define an instance of our test object

TestObject *testObject = [[TestObject alloc] init];

// This is the data we'll save

testObject.name = [[alertView textFieldAtIndex:0] text];

// Get a reference to a backend collection called "testObjects", which

is filled with

// instances of TestObject

KCSCollection *testObjects = [KCSCollection collectionFromString:@"tes-

tObjects" ofClass:[TestObject class]];

// Create a data store connected to the collection, in order to save

and load TestObjects

KCSAppdataStore *store = [KCSAppdataStore storeWithCollection:testOb-

jects options:nil];

// Save our instance to the store

[store saveObject:testObject withCompletionBlock:^(NSArray *objectsOr-

Nil, NSError *errorOrNil) {

// Right now just pop-up an alert about what we got back from

Kinvey during

// the save. Normally you would want to implement more code here

if (errorOrNil == nil && objectsOrNil != nil) {

//save is successful!

UIAlertView *alert = [[UIAlertView alloc] initWithTitle:@"Save

worked!"

message:[NS-

String stringWithFormat:@"Saved: '%@'",[objectsOrNil[0] name]]

delegate:nil

cancelButtonTitle:@"Ok"

otherButtonTitles:nil];

[alert show];

self.objects = [@[testObject] arrayByAddingObjectsFromArray:_-

objects];

[self.tableView insertRowsAtIndexPaths:@[[NSIndexPath indexPa-

thForRow:0 inSection:0]] withRowAnimation:UITableViewRowAnimationAutomatic];

} else {

//save failed

UIAlertView *alert = [[UIAlertView alloc] initWithTitle:@"Save

failed"

message:[erro-

rOrNil localizedDescription]

delegate:self

cancelButtonTitle:@"Ok"

otherButtonTitles:nil];

[alert show];

}

} withProgressBlock:nil];

}

}

}

- (IBAction)load:(id)sender

{

// Get a reference to a backend collection called "testObjects", which is

filled with

// instances of TestObject

KCSCollection *testObjects = [KCSCollection collectionFromString:@"testObjects"

ofClass:[TestObject class]];

// Create a data store connected to the collection, in order to save and load

TestObjects

KCSAppdataStore *store = [KCSAppdataStore storeWithCollection:testObjects

options:nil];

KCSQuery* query = [KCSQuery query];

[query addSortModifier:[[KCSQuerySortModifier alloc] initWithField:KCSMetadata-

FieldLastModifiedTime inDirection:kKCSDescending]];

// This will load the saved 12345 item from the backend

[store queryWithQuery:query withCompletionBlock:^(NSArray *objectsOrNil,

NSError *errorOrNil) {

[sender endRefreshing];

// Right now just pop-up an alert about what we got back from Kinvey during

// the load. Normally you would want to implement more code here

if (errorOrNil == nil && objectsOrNil != nil) {

//load is successful!

_objects = objectsOrNil;

[self.tableView reloadData];

} else {

//load failed

UIAlertView *alert = [[UIAlertView alloc] initWithTitle:@"Load failed"

message:[errorOrNil

localizedDescription]

delegate:self

cancelButtonTitle:@"Ok"

otherButtonTitles:nil];

[alert show];

}

} withProgressBlock:nil];

}

#pragma mark - View Controller

- (void)viewDidLoad

{

[super viewDidLoad];

_objects = @[];

[self.refreshControl addTarget:self

action:@selector(load:)

forControlEvents:UIControlEventValueChanged];

}

- (void)viewWillAppear:(BOOL)animated

{

[super viewWillAppear:animated];

[self load:nil];

}

#pragma mark - Table View Stuff

- (NSInteger)numberOfSectionsInTableView:(UITableView *)tableView

{

return 1;

}

- (NSInteger)tableView:(UITableView *)tableView numberOfRowsIn

Section:(NSInteger)section

{

return _objects.count;

}

- (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(N-

SIndexPath *)indexPath

{

UITableViewCell* cell = [tableView dequeueReusableCellWithIdentifier:@"aCell"];

cell.textLabel.text = [_objects[indexPath.row] name];

return cell;

}

- (BOOL)tableView:(UITableView *)tableView canEditRowAtIndexPath:(NSIndexPath

*)indexPath

{

return YES;

}

- (UITableViewCellEditingStyle)tableView:(UITableView *)tableView editingStyleFor-

RowAtIndexPath:(NSIndexPath *)indexPath

{

return UITableViewCellEditingStyleDelete;

}

- (void)tableView:(UITableView *)tableView commitEditingStyle:(UITableViewCellEdit-

ingStyle)editingStyle forRowAtIndexPath:(NSIndexPath *)indexPath

{

if (editingStyle == UITableViewCellEditingStyleDelete) {

TestObject* objToDelete = [_objects objectAtIndex:indexPath.row];

NSMutableArray* newObjects = [_objects mutableCopy];

[newObjects removeObjectAtIndex:indexPath.row];

self.objects = newObjects;

[tableView deleteRowsAtIndexPaths:@[indexPath] withRowAnimation:UI-

TableViewRowAnimationAutomatic];

// Get a reference to a backend collection called "testObjects", which is

filled with

// instances of TestObject

KCSCollection *testObjects = [KCSCollection collectionFromString:@"testOb-

jects" ofClass:[TestObject class]];

// Create a data store connected to the collection, in order to save and

load TestObjects

KCSAppdataStore *store = [KCSAppdataStore storeWithCollection:testObjects

options:nil];

// Remove our instance from the store

[store removeObject:objToDelete withCompletionBlock:^(NSArray *objectsOr-

Nil, NSError *errorOrNil) {

if (errorOrNil == nil && objectsOrNil != nil) {

//delete is successful!

UIAlertView *alert = [[UIAlertView alloc] initWithTitle:@"Delete

successful!"

message:nil

delegate:nil

cancelButtonTitle:@"Ok"

otherButtonTitles:nil];

[alert show];

} else {

//delete failed

UIAlertView *alert = [[UIAlertView alloc]

initWithTitle:@"Delete failed"

message:[errorOrNil

localizedDescription]

delegate:self

cancelButtonTitle:@"Ok"

otherButtonTitles:nil];

[alert show];

}

} withProgressBlock:nil];

}

}

@end

40

//

// ViewController.m

// Kinvey Quickstart

//

// Created by Michael Katz on 11/12/12.

// Copyright (c) 2012-2013 Kinvey. All rights reserved.

//

#import "ViewController.h"

#import "TestObject.h"

#define CREATE_NEW_ENTITY_ALERT_VIEW 100

@interface ViewController ()

@property (nonatomic, strong) NSArray* objects;

@end

@implementation ViewController

- (IBAction)add:(id)sender

{

UIAlertView* alert = [[UIAlertView alloc] initWithTitle:@"Create a New Entity"

message:@"Enter a title for the

new entity"

delegate:self

cancelButtonTitle:@"Cancel"

otherButtonTitles:@"Save", nil];

alert.alertViewStyle = UIAlertViewStylePlainTextInput;

alert.tag = CREATE_NEW_ENTITY_ALERT_VIEW;

[alert show];

}

- (void)alertView:(UIAlertView *)alertView clickedButtonAtIndex:(NSInteger)but-

tonIndex

{

if (alertView.tag == CREATE_NEW_ENTITY_ALERT_VIEW) {

if (buttonIndex == alertView.firstOtherButtonIndex) {

// Define an instance of our test object

TestObject *testObject = [[TestObject alloc] init];

// This is the data we'll save

testObject.name = [[alertView textFieldAtIndex:0] text];

// Get a reference to a backend collection called "testObjects", which

is filled with

// instances of TestObject

KCSCollection *testObjects = [KCSCollection collectionFromString:@"tes-

tObjects" ofClass:[TestObject class]];

// Create a data store connected to the collection, in order to save

and load TestObjects

KCSAppdataStore *store = [KCSAppdataStore storeWithCollection:testOb-

jects options:nil];

// Save our instance to the store

[store saveObject:testObject withCompletionBlock:^(NSArray *objectsOr-

Nil, NSError *errorOrNil) {

// Right now just pop-up an alert about what we got back from

Kinvey during

// the save. Normally you would want to implement more code here

if (errorOrNil == nil && objectsOrNil != nil) {

//save is successful!

UIAlertView *alert = [[UIAlertView alloc] initWithTitle:@"Save

worked!"

message:[NS-

String stringWithFormat:@"Saved: '%@'",[objectsOrNil[0] name]]

delegate:nil

cancelButtonTitle:@"Ok"

otherButtonTitles:nil];

[alert show];

self.objects = [@[testObject] arrayByAddingObjectsFromArray:_-

objects];

[self.tableView insertRowsAtIndexPaths:@[[NSIndexPath indexPa-

thForRow:0 inSection:0]] withRowAnimation:UITableViewRowAnimationAutomatic];

} else {

//save failed

UIAlertView *alert = [[UIAlertView alloc] initWithTitle:@"Save

failed"

message:[erro-

rOrNil localizedDescription]

delegate:self

cancelButtonTitle:@"Ok"

otherButtonTitles:nil];

[alert show];

}

} withProgressBlock:nil];

}

}

}

- (IBAction)load:(id)sender

{

// Get a reference to a backend collection called "testObjects", which is

filled with

// instances of TestObject

KCSCollection *testObjects = [KCSCollection collectionFromString:@"testObjects"

ofClass:[TestObject class]];

// Create a data store connected to the collection, in order to save and load

TestObjects

KCSAppdataStore *store = [KCSAppdataStore storeWithCollection:testObjects

options:nil];

KCSQuery* query = [KCSQuery query];

[query addSortModifier:[[KCSQuerySortModifier alloc] initWithField:KCSMetadata-

FieldLastModifiedTime inDirection:kKCSDescending]];

// This will load the saved 12345 item from the backend

[store queryWithQuery:query withCompletionBlock:^(NSArray *objectsOrNil,

NSError *errorOrNil) {

[sender endRefreshing];

// Right now just pop-up an alert about what we got back from Kinvey during

// the load. Normally you would want to implement more code here

if (errorOrNil == nil && objectsOrNil != nil) {

//load is successful!

_objects = objectsOrNil;

[self.tableView reloadData];

} else {

//load failed

UIAlertView *alert = [[UIAlertView alloc] initWithTitle:@"Load failed"

message:[errorOrNil

localizedDescription]

delegate:self

cancelButtonTitle:@"Ok"

otherButtonTitles:nil];

[alert show];

}

} withProgressBlock:nil];

}

#pragma mark - View Controller

- (void)viewDidLoad

{

[super viewDidLoad];

_objects = @[];

[self.refreshControl addTarget:self

action:@selector(load:)

forControlEvents:UIControlEventValueChanged];

}

- (void)viewWillAppear:(BOOL)animated

{

[super viewWillAppear:animated];

[self load:nil];

}

#pragma mark - Table View Stuff

- (NSInteger)numberOfSectionsInTableView:(UITableView *)tableView

{

return 1;

}

- (NSInteger)tableView:(UITableView *)tableView numberOfRowsIn

Section:(NSInteger)section

{

return _objects.count;

}

- (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(N-

SIndexPath *)indexPath

{

UITableViewCell* cell = [tableView dequeueReusableCellWithIdentifier:@"aCell"];

cell.textLabel.text = [_objects[indexPath.row] name];

return cell;

}

- (BOOL)tableView:(UITableView *)tableView canEditRowAtIndexPath:(NSIndexPath

*)indexPath

{

return YES;

}

- (UITableViewCellEditingStyle)tableView:(UITableView *)tableView editingStyleFor-

RowAtIndexPath:(NSIndexPath *)indexPath

{

return UITableViewCellEditingStyleDelete;

}

- (void)tableView:(UITableView *)tableView commitEditingStyle:(UITableViewCellEdit-

ingStyle)editingStyle forRowAtIndexPath:(NSIndexPath *)indexPath

{

if (editingStyle == UITableViewCellEditingStyleDelete) {

TestObject* objToDelete = [_objects objectAtIndex:indexPath.row];

NSMutableArray* newObjects = [_objects mutableCopy];

[newObjects removeObjectAtIndex:indexPath.row];

self.objects = newObjects;

[tableView deleteRowsAtIndexPaths:@[indexPath] withRowAnimation:UI-

TableViewRowAnimationAutomatic];

// Get a reference to a backend collection called "testObjects", which is

filled with

// instances of TestObject

KCSCollection *testObjects = [KCSCollection collectionFromString:@"testOb-

jects" ofClass:[TestObject class]];

// Create a data store connected to the collection, in order to save and

load TestObjects

KCSAppdataStore *store = [KCSAppdataStore storeWithCollection:testObjects

options:nil];

// Remove our instance from the store

[store removeObject:objToDelete withCompletionBlock:^(NSArray *objectsOr-

Nil, NSError *errorOrNil) {

if (errorOrNil == nil && objectsOrNil != nil) {

//delete is successful!

UIAlertView *alert = [[UIAlertView alloc] initWithTitle:@"Delete

successful!"

message:nil

delegate:nil

cancelButtonTitle:@"Ok"

otherButtonTitles:nil];

[alert show];

} else {

//delete failed

UIAlertView *alert = [[UIAlertView alloc]

initWithTitle:@"Delete failed"

message:[errorOrNil

localizedDescription]

delegate:self

cancelButtonTitle:@"Ok"

otherButtonTitles:nil];

[alert show];

}

} withProgressBlock:nil];

}

}

@end

41

//

// ViewController.m

// Kinvey Quickstart

//

// Created by Michael Katz on 11/12/12.

// Copyright (c) 2012-2013 Kinvey. All rights reserved.

//

#import "ViewController.h"

#import "TestObject.h"

#define CREATE_NEW_ENTITY_ALERT_VIEW 100

@interface ViewController ()

@property (nonatomic, strong) NSArray* objects;

@end

@implementation ViewController

- (IBAction)add:(id)sender

{

UIAlertView* alert = [[UIAlertView alloc] initWithTitle:@"Create a New Entity"

message:@"Enter a title for the

new entity"

delegate:self

cancelButtonTitle:@"Cancel"

otherButtonTitles:@"Save", nil];

alert.alertViewStyle = UIAlertViewStylePlainTextInput;

alert.tag = CREATE_NEW_ENTITY_ALERT_VIEW;

[alert show];

}

- (void)alertView:(UIAlertView *)alertView clickedButtonAtIndex:(NSInteger)but-

tonIndex

{

if (alertView.tag == CREATE_NEW_ENTITY_ALERT_VIEW) {

if (buttonIndex == alertView.firstOtherButtonIndex) {

// Define an instance of our test object

TestObject *testObject = [[TestObject alloc] init];

// This is the data we'll save

testObject.name = [[alertView textFieldAtIndex:0] text];

// Get a reference to a backend collection called "testObjects", which

is filled with

// instances of TestObject

KCSCollection *testObjects = [KCSCollection collectionFromString:@"tes-

tObjects" ofClass:[TestObject class]];

// Create a data store connected to the collection, in order to save

and load TestObjects

KCSAppdataStore *store = [KCSAppdataStore storeWithCollection:testOb-

jects options:nil];

// Save our instance to the store

[store saveObject:testObject withCompletionBlock:^(NSArray *objectsOr-

Nil, NSError *errorOrNil) {

// Right now just pop-up an alert about what we got back from

Kinvey during

// the save. Normally you would want to implement more code here

if (errorOrNil == nil && objectsOrNil != nil) {

//save is successful!

UIAlertView *alert = [[UIAlertView alloc] initWithTitle:@"Save

worked!"

message:[NS-

String stringWithFormat:@"Saved: '%@'",[objectsOrNil[0] name]]

delegate:nil

cancelButtonTitle:@"Ok"

otherButtonTitles:nil];

[alert show];

self.objects = [@[testObject] arrayByAddingObjectsFromArray:_-

objects];

[self.tableView insertRowsAtIndexPaths:@[[NSIndexPath indexPa-

thForRow:0 inSection:0]] withRowAnimation:UITableViewRowAnimationAutomatic];

} else {

//save failed

UIAlertView *alert = [[UIAlertView alloc] initWithTitle:@"Save

failed"

message:[erro-

rOrNil localizedDescription]

delegate:self

cancelButtonTitle:@"Ok"

otherButtonTitles:nil];

[alert show];

}

} withProgressBlock:nil];

}

}

}

- (IBAction)load:(id)sender

{

// Get a reference to a backend collection called "testObjects", which is

filled with

// instances of TestObject

KCSCollection *testObjects = [KCSCollection collectionFromString:@"testObjects"

ofClass:[TestObject class]];

// Create a data store connected to the collection, in order to save and load

TestObjects

KCSAppdataStore *store = [KCSAppdataStore storeWithCollection:testObjects

options:nil];

KCSQuery* query = [KCSQuery query];

[query addSortModifier:[[KCSQuerySortModifier alloc] initWithField:KCSMetadata-

FieldLastModifiedTime inDirection:kKCSDescending]];

// This will load the saved 12345 item from the backend

[store queryWithQuery:query withCompletionBlock:^(NSArray *objectsOrNil,

NSError *errorOrNil) {

[sender endRefreshing];

// Right now just pop-up an alert about what we got back from Kinvey during

// the load. Normally you would want to implement more code here

if (errorOrNil == nil && objectsOrNil != nil) {

//load is successful!

_objects = objectsOrNil;

[self.tableView reloadData];

} else {

//load failed

UIAlertView *alert = [[UIAlertView alloc] initWithTitle:@"Load failed"

message:[errorOrNil

localizedDescription]

delegate:self

cancelButtonTitle:@"Ok"

otherButtonTitles:nil];

[alert show];

}

} withProgressBlock:nil];

}

#pragma mark - View Controller

- (void)viewDidLoad

{

[super viewDidLoad];

_objects = @[];

[self.refreshControl addTarget:self

action:@selector(load:)

forControlEvents:UIControlEventValueChanged];

}

- (void)viewWillAppear:(BOOL)animated

{

[super viewWillAppear:animated];

[self load:nil];

}

#pragma mark - Table View Stuff

- (NSInteger)numberOfSectionsInTableView:(UITableView *)tableView

{

return 1;

}

- (NSInteger)tableView:(UITableView *)tableView numberOfRowsIn

Section:(NSInteger)section

{

return _objects.count;

}

- (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(N-

SIndexPath *)indexPath

{

UITableViewCell* cell = [tableView dequeueReusableCellWithIdentifier:@"aCell"];

cell.textLabel.text = [_objects[indexPath.row] name];

return cell;

}

- (BOOL)tableView:(UITableView *)tableView canEditRowAtIndexPath:(NSIndexPath

*)indexPath

{

return YES;

}

- (UITableViewCellEditingStyle)tableView:(UITableView *)tableView editingStyleFor-

RowAtIndexPath:(NSIndexPath *)indexPath

{

return UITableViewCellEditingStyleDelete;

}

- (void)tableView:(UITableView *)tableView commitEditingStyle:(UITableViewCellEdit-

ingStyle)editingStyle forRowAtIndexPath:(NSIndexPath *)indexPath

{

if (editingStyle == UITableViewCellEditingStyleDelete) {

TestObject* objToDelete = [_objects objectAtIndex:indexPath.row];

NSMutableArray* newObjects = [_objects mutableCopy];

[newObjects removeObjectAtIndex:indexPath.row];

self.objects = newObjects;

[tableView deleteRowsAtIndexPaths:@[indexPath] withRowAnimation:UI-

TableViewRowAnimationAutomatic];

// Get a reference to a backend collection called "testObjects", which is

filled with

// instances of TestObject

KCSCollection *testObjects = [KCSCollection collectionFromString:@"testOb-

jects" ofClass:[TestObject class]];

// Create a data store connected to the collection, in order to save and

load TestObjects

KCSAppdataStore *store = [KCSAppdataStore storeWithCollection:testObjects

options:nil];

// Remove our instance from the store

[store removeObject:objToDelete withCompletionBlock:^(NSArray *objectsOr-

Nil, NSError *errorOrNil) {

if (errorOrNil == nil && objectsOrNil != nil) {

//delete is successful!

UIAlertView *alert = [[UIAlertView alloc] initWithTitle:@"Delete

successful!"

message:nil

delegate:nil

cancelButtonTitle:@"Ok"

otherButtonTitles:nil];

[alert show];

} else {

//delete failed

UIAlertView *alert = [[UIAlertView alloc]

initWithTitle:@"Delete failed"

message:[errorOrNil

localizedDescription]

delegate:self

cancelButtonTitle:@"Ok"

otherButtonTitles:nil];

[alert show];

}

} withProgressBlock:nil];

}

}

@end

42

//

// ViewController.m

// Kinvey Quickstart

//

// Created by Michael Katz on 11/12/12.

// Copyright (c) 2012-2013 Kinvey. All rights reserved.

//

#import "ViewController.h"

#import "TestObject.h"

#define CREATE_NEW_ENTITY_ALERT_VIEW 100

@interface ViewController ()

@property (nonatomic, strong) NSArray* objects;

@end

@implementation ViewController

- (IBAction)add:(id)sender

{

UIAlertView* alert = [[UIAlertView alloc] initWithTitle:@"Create a New Entity"

message:@"Enter a title for the

new entity"

delegate:self

cancelButtonTitle:@"Cancel"

otherButtonTitles:@"Save", nil];

alert.alertViewStyle = UIAlertViewStylePlainTextInput;

alert.tag = CREATE_NEW_ENTITY_ALERT_VIEW;

[alert show];

}

- (void)alertView:(UIAlertView *)alertView clickedButtonAtIndex:(NSInteger)but-

tonIndex

{

if (alertView.tag == CREATE_NEW_ENTITY_ALERT_VIEW) {

if (buttonIndex == alertView.firstOtherButtonIndex) {

// Define an instance of our test object

TestObject *testObject = [[TestObject alloc] init];

// This is the data we'll save

testObject.name = [[alertView textFieldAtIndex:0] text];

// Get a reference to a backend collection called "testObjects", which

is filled with

// instances of TestObject

KCSCollection *testObjects = [KCSCollection collectionFromString:@"tes-

tObjects" ofClass:[TestObject class]];

// Create a data store connected to the collection, in order to save

and load TestObjects

KCSAppdataStore *store = [KCSAppdataStore storeWithCollection:testOb-

jects options:nil];

// Save our instance to the store

[store saveObject:testObject withCompletionBlock:^(NSArray *objectsOr-

Nil, NSError *errorOrNil) {

// Right now just pop-up an alert about what we got back from

Kinvey during

// the save. Normally you would want to implement more code here

if (errorOrNil == nil && objectsOrNil != nil) {

//save is successful!

UIAlertView *alert = [[UIAlertView alloc] initWithTitle:@"Save

worked!"

message:[NS-

String stringWithFormat:@"Saved: '%@'",[objectsOrNil[0] name]]

delegate:nil

cancelButtonTitle:@"Ok"

otherButtonTitles:nil];

[alert show];

self.objects = [@[testObject] arrayByAddingObjectsFromArray:_-

objects];

[self.tableView insertRowsAtIndexPaths:@[[NSIndexPath indexPa-

thForRow:0 inSection:0]] withRowAnimation:UITableViewRowAnimationAutomatic];

} else {

//save failed

UIAlertView *alert = [[UIAlertView alloc] initWithTitle:@"Save

failed"

message:[erro-

rOrNil localizedDescription]

delegate:self

cancelButtonTitle:@"Ok"

otherButtonTitles:nil];

[alert show];

}

} withProgressBlock:nil];

}

}

}

- (IBAction)load:(id)sender

{

// Get a reference to a backend collection called "testObjects", which is

filled with

// instances of TestObject

KCSCollection *testObjects = [KCSCollection collectionFromString:@"testObjects"

ofClass:[TestObject class]];

// Create a data store connected to the collection, in order to save and load

TestObjects

KCSAppdataStore *store = [KCSAppdataStore storeWithCollection:testObjects

options:nil];

KCSQuery* query = [KCSQuery query];

[query addSortModifier:[[KCSQuerySortModifier alloc] initWithField:KCSMetadata-

FieldLastModifiedTime inDirection:kKCSDescending]];

// This will load the saved 12345 item from the backend

[store queryWithQuery:query withCompletionBlock:^(NSArray *objectsOrNil,

NSError *errorOrNil) {

[sender endRefreshing];

// Right now just pop-up an alert about what we got back from Kinvey during

// the load. Normally you would want to implement more code here

if (errorOrNil == nil && objectsOrNil != nil) {

//load is successful!

_objects = objectsOrNil;

[self.tableView reloadData];

} else {

//load failed

UIAlertView *alert = [[UIAlertView alloc] initWithTitle:@"Load failed"

message:[errorOrNil

localizedDescription]

delegate:self

cancelButtonTitle:@"Ok"

otherButtonTitles:nil];

[alert show];

}

} withProgressBlock:nil];

}

#pragma mark - View Controller

- (void)viewDidLoad

{

[super viewDidLoad];

_objects = @[];

[self.refreshControl addTarget:self

action:@selector(load:)

forControlEvents:UIControlEventValueChanged];

}

- (void)viewWillAppear:(BOOL)animated

{

[super viewWillAppear:animated];

[self load:nil];

}

#pragma mark - Table View Stuff

- (NSInteger)numberOfSectionsInTableView:(UITableView *)tableView

{

return 1;

}

- (NSInteger)tableView:(UITableView *)tableView numberOfRowsIn

Section:(NSInteger)section

{

return _objects.count;

}

- (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(N-

SIndexPath *)indexPath

{

UITableViewCell* cell = [tableView dequeueReusableCellWithIdentifier:@"aCell"];

cell.textLabel.text = [_objects[indexPath.row] name];

return cell;

}

- (BOOL)tableView:(UITableView *)tableView canEditRowAtIndexPath:(NSIndexPath

*)indexPath

{

return YES;

}

- (UITableViewCellEditingStyle)tableView:(UITableView *)tableView editingStyleFor-

RowAtIndexPath:(NSIndexPath *)indexPath

{

return UITableViewCellEditingStyleDelete;

}

- (void)tableView:(UITableView *)tableView commitEditingStyle:(UITableViewCellEdit-

ingStyle)editingStyle forRowAtIndexPath:(NSIndexPath *)indexPath

{

if (editingStyle == UITableViewCellEditingStyleDelete) {

TestObject* objToDelete = [_objects objectAtIndex:indexPath.row];

NSMutableArray* newObjects = [_objects mutableCopy];

[newObjects removeObjectAtIndex:indexPath.row];

self.objects = newObjects;

[tableView deleteRowsAtIndexPaths:@[indexPath] withRowAnimation:UI-

TableViewRowAnimationAutomatic];

// Get a reference to a backend collection called "testObjects", which is

filled with

// instances of TestObject

KCSCollection *testObjects = [KCSCollection collectionFromString:@"testOb-

jects" ofClass:[TestObject class]];

// Create a data store connected to the collection, in order to save and

load TestObjects

KCSAppdataStore *store = [KCSAppdataStore storeWithCollection:testObjects

options:nil];

// Remove our instance from the store

[store removeObject:objToDelete withCompletionBlock:^(NSArray *objectsOr-

Nil, NSError *errorOrNil) {

if (errorOrNil == nil && objectsOrNil != nil) {

//delete is successful!

UIAlertView *alert = [[UIAlertView alloc] initWithTitle:@"Delete

successful!"

message:nil

delegate:nil

cancelButtonTitle:@"Ok"

otherButtonTitles:nil];

[alert show];

} else {

//delete failed

UIAlertView *alert = [[UIAlertView alloc]

initWithTitle:@"Delete failed"

message:[errorOrNil

localizedDescription]

delegate:self

cancelButtonTitle:@"Ok"

otherButtonTitles:nil];

[alert show];

}

} withProgressBlock:nil];

}

}

@end

Written by

Randall Cronk

Since 1990, Randall has helped over 250 high-tech companies convey the value of what they do through white papers, web content, brochures, case studies and articles. Based today in downtown Boston, he was previously a vice president with Regis McKenna where he ran the Digital Equipment account.

Michael Katz

Michael has always been a programmer. In college he detoured into modeling the brain, but eventually found his way back into software development, doing hard-core desktop Java programming. But since 2010, he has developed mobile apps and software. He is also the author of a forthcoming iOS networking book, being published by Manning Publica-tions later this year.

What is Kinvey? Kinvey makes a fully-featured Backend as a Service solution, offering 3rd party data integrations, multi-plat-form support, push notifications, and custom business logic on a

platform where it's free to get started and you only pay when your app is successful.

Build your backend todayBuild your backend today

Project Manager

Brian Whalley

Designed by

Jake McKibben and Lauren Pedigo

HOW TO MAKE AN APP: iOS EDITION