10 Ways to Make Your App Development Life Easier
Here are a few objects and techniques that many app developers swear by. This is an idiosyncratic list that includes some commonly-used objects, some rather obscure ones, and some development techniques and reminders.
The Master-Detail application template
The Master-Detail application template is now a universal app template. For iPad, it uses a Split-View controller, and iPhone uses a Navigation controller. Both use the same view controllers to present data. For many developers, it's a mainstay.
UITextField notifications and delegate
If you're using text fields, these are essential to most developers. Either in your storyboard or in your code, set the text field's delegate to an object that will respond to these notifications:
The text field itself is stored in the object parameter of the notification, so when you register to observe the notification, you can have a single method that responds to the notification for every text field.
The delegate is often the view controller that contains the view that contains the text field. It conforms to UITextFieldDelegate.
Use asset catalogs
Asset catalogs are brand new in iOS 7. There's a little conversion to do from previous ways of handling images and icons, but it's well worth it. Instead of relying on fragile naming conventions, you use the name of the asset catalog and at runtime, the right image is used.
Use Core Data
For some reason, developers are often leery of using data management tools. Whether they are more comfortable implementing their own data management or they're uncomfortable with relational database theory, they tend not to use these tools. Core Data is one of the best, and it's well worth exploring.
There is just no getting around the fact that users appreciate having their apps and data synchronized on all of their devices. The iCloud learning curve is steep if you set out to learn all of it. But if you just want to store small amounts of data on iCloud (perhaps the high score on a game), you can get started by using key-value coding and not worrying about the details.
Organize your project
Every app project is different, so there's no standard way of organizing every project. Remember that you can move files and groups around in the Project navigator. Restructuring the project doesn't require moving files on disk because Xcode will keep track of them for you.
Here's the group structure for a typical app on the App Store:
Master View Controller
Detail View Controllers
Popovers and Pickers
Look at the sample projects on the Apple Developer site for other structures.
Use Auto Layout
If you have an older app that doesn't use Auto Layout, convert it (and do use Auto Layout for new apps). Apple talks about how Auto Layout helps you manage apps in multiple languages, but for many developers, the main feature of Auto Layout is that it automatically means your app runs on new devices with new screen shapes and sizes. That alone is a major reason to use it.
Update your app
Getting your app into the App Store is just the beginning. Don't let it sit there. Plan for regular updates and carry them out. People notice apps that are (or are not) updated regularly. In addition, the App Store discovery process takes updates into account in some cases (the details of discovery and search are not published). Developers have noticed that sometimes in the aftermath of an update, new users download the app.
The App Store provides cross references to additional apps by a developer in addition to the one that is being browsed. This is a good way to attract new users, but it does mean that if your app portfolio hasn't been updated for a year or two, you may lose out on those potential new sales.
At the very least, plan for an update to incorporate the annual (as of now) updates to iOS. If you can't find the time to update an app that's out of date, consider suspending its sales. Cleaning out your old apps shows that you're still alive and developing.
Use #pragma mark to organize your code
Structure your .m files so that you can see where things are by using #pragma mark directives. Many developers have at least an initialization section, a section for your own methods, and separate sections for each protocol that is implemented. Those are a good start; as you continue working, add new ones. There is no hard-and-fast rule, but you want to strike a balance between totally disorganized code and code that is so organized that each section contains one or two methods and you have almost as many sections as methods.
Welcome to the fast-paced world of app development. Remember that it really wasn't all that long ago when developers were teaching people how to use basic gestures on mobile devices. We're still exploring new gestures. As the iOS interface has evolved, we've been freed from a number of real-world metaphors. We don't have to say, "This is like a pad of paper" or "This is like a trashcan." Interface elements now can stand on their own, so all we have to do is to say "This is something you can write on." (The technical term for the older style of metaphors is skeuomorphism.)
Watch how people use mobile devices. In particular, watch the mistakes they make and the things that confuse them. You can learn more from watching the errors than from watching someone successfully use a device. (And learn to watch yourself when you put your user hat on.)