iOS App Development For Dummies Cheat Sheet
As a developer, you can create apps for many different platforms. Here we offer some reasons why you should be developing apps for iOS. We also raise some points to consider when you're developing interfaces for iOS applications, and cover some of the more commonly used iOS architectural features.
Why Develop iOS Applications?
Why should you develop iOS apps? Because you can. Because they're fun. And because the time has come. iOS apps are busting out all over, and many developers have been very successful with them. Developing iOS apps can be the most fun you've had in your career in years, with very little investment of time and money (compared with developing for platforms like Windows). Here's why:
iOS apps are usually bite-sized, which means that they're small enough to get your head around. A single developer — or one with a partner and maybe some graphics support — can do them. You don't need a 20-person project team with endless procedures and processes and meetings to create something valuable.
The apps tend to be crisp and clean, focusing on what the user wants to do at a particular time and/or place. They're simple but not simplistic. This makes application design (and subsequent implementation) much easier and faster.
The apps use the most innovative platform available for mobile computing. iPhone and iPad have been game-changers. They're completely changing the Internet as a publishing medium, the software industry with regard to applications, and the mobile device industry with regard to the overall digital media experience.
The free iOS Software Development Kit (SDK) makes development as easy as possible. You can register as an iOS developer and download the SDK now, but (fair warning) jumping the gun leads to extra hassle. It's worth getting a handle on the ins and outs of iOS app development beforehand.
iOS has these three other advantages that are important to you as a developer:
You can distribute your app through the App Store. Apple will list your app in the App Store in the category you specify, and the store takes care of credit-card processing (if you charge for your app), hosting, downloading, notifying users of updates, and all those things that most developers hate doing. Developers name their own prices for their creations or distribute them for free; Apple gets 30 percent of the sales price of commercial apps, with the developer getting the rest. Keep in mind that Apple must approve your app before it appears in the App Store.
Apple has a robust yet inexpensive developer program. To place your app in the store and manage it, you have to pay $99 per year to join the Individual or Company version of the iOS Developer Program (which includes iPhone and iPad development support). (Apple also offers an Enterprise version for $299 per year to develop proprietary, in-house iOS applications that you can distribute to employees or members of your organization, and a free University version for educational institutions to include iOS development as part of a curriculum.) But that's it. You don't find any of the infamous hidden charges that you often encounter, especially when dealing with credit-card companies. Go to the iOS Apple Developer site and click the Enroll Now button to get started.
It's a business and productivity tool. Both the iPhone and iPad have become acceptable business and individual productivity tools, in part because they have tight security as well as support for Microsoft Exchange and Office, but even more for their designs as handheld mobile computers. Salespeople can close the deal faster. Automobile finance companies can begin the credit-application process while customers are standing near a vehicle. Doctors and nurses at hospitals are beginning to use iPads to view X-rays and CT scans and read medical records while standing next to the patient. This happy state of affairs expands the possible audience for your application.
Understanding How iOS Interfaces Work
Tap a button and something happens. It's amazing to the user, but it's hard work for you. Here are the points you have to consider about making your iOS interface work:
What does the user want to do?: As you start to design your app, at various points, you'll see that the user will have to take an action. Start making a list of what those actions are beginning with what the user wants to do. (For instance, cancel an operation, find the nearest dog-friendly park, and so forth.)
How does the user do it?: Does the action start with tapping a button? Moving a slider? Shaking the device? Typing something?
Can the user have second thoughts?: There's a robust and sophisticated undo manager available for your use. Do you need it?
What does the user need to know?: Do you have to keep the user informed as the action is progressing? Do you need a progress bar? Periodic messages?
Does the user need to know when it's done?: All software today is becoming less talkative. In many cases, you don't have to tell that user that something has been done either because the user can see that it's done or because the user trusts your app to provide a notification if something has failed.
Does the action involve other objects?: Calculating 2 + 2 doesn't require anything else, but calculating Contents of field A + Contents of field B requires that you can get to the fields and find their values before you perform the operation.
How will the user know how to do it?: Ideally, the tool (button, slider, and so on) is right there when the user might need to use it. In other cases, it pops up in an alert or popover. Sometimes, the user may need to go to a help screen to even know that the action is possible.
Does the user need to know that it has been done?: Some actions can only be done once; others may be unnecessary. If a list has been alphabetized, realphabetizing may or may not be allowed (if the data has changed, it generally is allowed).
Working with iOS App Architectures
iOS apps use and reuse a number of architectural features. Understanding them can make the development process simpler because you'll see that you're using standing patterns. Here are some of them:
Model-View-Controller (MVC): This is a design pattern in which the interface (view) is separated from the content (model); a controller mediates between the two. The model knows nothing about the view, and the view knows nothing about the model. The model is where most of what people consider typical coding happens.
Recognize Design Patterns: MVC is one of many design patterns in iOS. Recognize these common approaches to various design issues so that you can find and reuse them.
Use View Controllers: On iOS, you have a screen that displays various views. Each view is controlled by a view controller. That's where your code is written. (Sound familiar?)
Use Xcode graphical editors: Draw your view use Interface Builder. Create your data model for Core Data with Core Data Model Editor. Both provide a clear graphical visualization of what you're doing.
Use specialized view controllers: Split view controllers on iPad and specialized view controllers such as Page view on iPad and iOS do a lot of the work for you. Don't start coding until you're certain there isn't a view in the Cocoa Touch framework that's already got the code in it.
Understand navigation view controllers: These provide the common "drill-down" functionality that is often necessary on small screens.
Figure out how to get from here to there: Drilling down is a good strategy for organized data, but sometimes you need to get from one view and its view controller to another one. Make certain there's an interface element that will do that.