Head First iPhone and iPad Development (2013)
Chapter 6. The Review Process, Design, and Devices: How to live with Apple
iOS development comes with some strings. Everybody has heard the war stories. The Apple review process is famous for being painful and having tons of rules you’ll have to follow. Yes, there are some hoops to jump through, but once you know what you’re doing, it’s not nearly so bad. And besides, once you’ve gotten your app approved, the massively popular App Store is waiting for you... full of eager device owners with a few bucks to burn. So what’s not to love?
Yes, writing apps can be simple when you know what you’re doing. But there’s a little more work involved to actually sell your app in the App Store.
The App Store could just as well be named the Apple store. It is Apple’s world you’re playing in, and they take their ownership of the store (and your device’s hardware and software) pretty seriously.
If you spend much time developing iOS apps, you’ll start to hear the war stories. Some beautiful app got rejected three or four times by Apple’s review process, while the Facebook and Apple Trailers app released four new versions. Or what seems like the smallest detail—a URL in a description or a bad naming choice—got an app shot down.
Yes, you have to get your app approved by Apple for sale. And yes, there are lots of reasons your app might get rejected. But...most rejections are for minor things that can be fairly easily fixed. And if you know what you’re doing, you can avoid long hang-ups and costly app rewrites pretty easily.
It’s Apple’s world...you’re just living in it
There’s a big difference between developing for iOS and developing for Android (as well as most other platforms): Apple’s App Store is a curated, gated community. That means Apple retains exclusive rights to approve or deny apps on their store based on certain criteria. It ensures consistency and some degree of quality. Apple censors applications, so violent or vulgar apps just won’t get approved.
NOTE
Love it or hate it, Apple holds the keys. Whether you think that results in a better, more secure device or a Big Brother situation, you’ve got to live by Apple’s rules in the iOS world.
So, you might as well accept that this process is part of your life if you want to play in the iOS space. Parts of your schedule are going to be beyond your control and sometimes hard to predict, like when a new version of iOS comes out, and what it’ll mean for your app. iOS 7 made some major changes to the designs of applications and suddenly “new UI” got run up to the top of everyone’s to-do list. Review times vary from a week to a month, and a rejection usually means you start the review “clock” over on re-submission.
You also are going to have to learn from a few documents that take you beyond writing code specific to your app. You need to get familiar with...
UP CLOSE APPLE REJECTIONS...
Wondering about what a typical rejection looks like? Here are some representative examples. Read each rejection carefully... in most cases, you’ll quickly see that you can avoid these rejections with a little forethought.
NOTE
These aren’t actual rejections... Apple doesn’t allow that. But they’re typical... the types of rejections that are really common.
|
To: Dean “the Machine” Developer |
|
From: Apple Review Folks |
|
Subject: App rejection |
|
We’ve reviewed your app and determined that you are in violation of the guidelines. |
|
“Apps that link to external mechanisms for purchases or subscriptions to be used in the app, such as a “buy” button that goes to a website to purchase a digital book, will be rejected.” Apple is extremely particular about your app linking to external websites. If those sites sell anything digital-books, music, movies, whatever-then your app is going to get rejected. And don’t think Apple is too busy to check each link out. They’re notorious for making sure you don’t sell digital content except through the App Store’s In App Purchase mechanism. |
|
To: Moe Ney Coming |
|
From: Apple Review Folks In this day and age, most apps have to function on both the iPhone and iPad. If that’s your case, you need several resolutions of your icons to get approved. You’ve got to support the various device resolutions, as well as what’s shown on iTunes and the App Store. Fortunately, the iOS Human Interface Guidelines (more on those later) are very clear about what you need. You just have to read those guidelines and make sure you include the right resolutions. Easy! |
|
Subject: App rejection |
|
“We’ve reviewed your app and determined that your application icons need additional resolutions.” |
UP CLOSE APPLE REJECTIONS...
|
To: Slo Mo Apper |
|
From: Apple Review Folks |
|
Subject: App rejection |
|
“We’ve reviewed your app and determined that your app doesn’t pass the performance testing. Your application fails on iOS 4.0.” |
NOTE
Those older phones don’t really matter anymore, right? Wrong! Apple allows you to indicate which versions of iOS you support, but whatever you say you’ll support, Apple makes sure you DO support.
NOTE
What does this mean for you? Testing on every device you want to have your app work on... no exceptions!
|
To: Upfront Development |
|
From: Apple Review Folks Even with giant 64GB phones and iPads, Apple is serious about your app being a good (and unselfish) device citizen. While there aren’t any written rules here, you should try to only use the space you really need. User-generated content is generally acceptable, too, but if your app downloads lots of stuff when it launches—especially without user intervention—watch out. This rejection might be coming your way... |
|
Subject: App rejection |
|
“We’ve reviewed your app and determined that your app downloads too much initial content. Applications are limited in the resources that they can consume on initial download.” |
EXERCISE
OK, so that’s only a few rejections, but you should already be getting an idea of the basic reasons that Apple might reject an app. Use what you’ve just learned, put on your Apple hat, and see if you can figure out why the app shown below is sure to get rejected.
In fact, if you’re feeling really mean, come up not with just one, but three reasons this app is sure to get red-carded from Apple.
THERE ARE NO DUMB QUESTIONS
|
Q: |
Q: Foul! Unfair! What a ripoff! |
|
A: |
A: Yeah, it can seem that way sometimes. But this whole process is what you have to go through for the very cool right to see your app on an iOS device. It’s simply the only way to get there. Of course, the prize is really significant: the App Store far out-earns its competitors, and that makes it the best place to sell your app! |
|
Q: |
Q: How can I be sure my app won’t get rejected beforeI submit? |
|
A: |
A: Well, you can’t know, at least not 100%. The best you can do is to carefully review the App Store review guidelines before you really get into coding. (Yes, before coding!) If there’s any functionality in your app that you think may be questionable, spending some time combing through the App Store and try to find other apps that are tackling similar issues. If those apps got approved, they probably have a handle on any land mines you might need to avoid. At the end of the day, though, you really won’t know for sure until you submit your app. Practically, that means you should plan for at least one rejection and re-submission! That way, if something hangs you up, your marketing and business schedules aren’t totally trashed! |
|
Q: |
Q: They rejected my app! How do I resubmit? |
|
A: |
A: It depends on why your app got rejected. If it’s a metadata problem, sometimes you can jump right back in at the head of the line. That’s your best case. Unfortunately, most rejections require code-level changes, beyond just your app’s metadata. That means you need to resubmit the entire app...and that means you have to start the whole process over again. |
|
Q: |
Q: Can you appeal a rejection? |
|
A: |
A: Sure! When your app gets rejected, appealing is always an option. But the appeal process isn’t quick, so be sure that if you want to appeal, you’re really sure that you have a good case. Otherwise, you’ll burn time on an appeal and another re-submission, too. |
|
Q: |
Q: How in the world can you plan for all this? What a mess... |
|
A: |
A: Yup, from a scheduling perspective, this isn’t easy. But it’s not something you can choose to opt out of. Seriously, experienced app developers often plan at least a month for the submission (and re-submisson) process. |
|
Q: |
Q: But some of this is nuts! I really can’t even link to external sites? What about my own website? |
|
A: |
A: Well, not all external links are forbidden... but many are. What gets tricky with external links is that if there is any navigation path from the external site to any kind of payment mechanism, Apple’s probably going to reject you. Even if it’s not intentional, Apple sees this as an app trying to get around Apple’s payment processes (In App Purchase or IAP), and they’re very serious about shutting that kind of thing down. Even worse, external links can negatively affect your app’s rating. Your kid-friendly game that’s going to be a hit in middle school could get slapped with an adult rating because of content three pages away from a page you link to. Yeah, it’s happened...in general, you should be very, very careful using external links. |
EXERCISE SOLUTION
Rejection... such an ugly word. Hopefully, you figured out a couple of reasons that the app below would get rejected. Make sure you understand what’s wrong from Apple’s perspective. The better you are at seeing things from their point of view, the less you’ll see of their rejection emails.
Device checking... it’s not optional
The first iPod came out back in 2001, and the first iPhone in 2007. That’s something like 32,000 years in tech terms. And even though Apple is good about pushing out OS updates, these older devices simply can’t be updated past a certain point. That means you’ve got to explicitly decide which OS versions you’ll support... and therefore which devices you’ll support.
Even more importantly, what does that mean for devices that are too old to update to the version of iOS you support? These older devices may or may not have cameras, the ability to capture video, internal speakers, and GPS... just for starters!
The technical term for handling these situations responsibly and gracefully is device checking. That’s the process you’ll have to use to ensure that devices that can run your app all behave, even if they don’t support the hardware and software that your app can take advantage of.
NOTE
“Handle gracefully” is a nice way of saying, “doesn’t brick your iPad.”
So how does device checking actually work?
Device checking case study: the camera
How does device checking actually work? Let’s say your application needs a camera supported on devices. As soon as your app needs something in a device’s hardware, you’ve got some pretty specific additional requirements to consider.
Any application written for the iPhone also must be able to run on an iPod Touch and on an iPad. That means that when you use a feature like the camera that’s only on some of the supported devices, you’ve got to check for that feature... and handle the case where it’s not present.
NOTE
Yes, you can specify “iPad only,” but for the most part, you’ve got to support every device (iPad, iPod, iTouch, iSomethingNewIn2015) that runs the iOS your app targets.
So take the camera: the UIImagePickerController has a method to check for the camera.
iOS handles the heavy lifting
iOS is smart enough to know which features a specific device has. So if you ask the UIImagePickerController which source types are available, you can decide which options to show the user.
Hmmm... supported device, missing feature
OK, so checking for a source like the camera is a must. But just because you check for a source doesn’t mean the device actually has that source. Remember those third-generation iPods?
In a case like this, you have to figure out what should happen without that feature. You may need to disable an entire section of your application. Of course, that’s a pretty nuclear option, so it’s better to try to figure out if there’s some subset of things that those devices can still take advantage of.
With images there’s almost always another good option: the photo library. If there’s no camera, a user still can get images from their existing photos. So think about whether most of your app still works, and you can just disable certain buttons (and if possible, hide the controls that don’t make sense for that device).
If your application can’t work at all without a camera (or net access or accelerometer, etc.), you can specify device capabilities for your application so users without those capabilities can’t even install your application on their device.
Well... they kinda do that, too. Welcome to the Human Interface Guidelines.
By now you’ve probably noticed that all the apps on iOS devices (except for games), have pretty consistent designs and interaction patterns. It makes for a “feel” for iOS apps, and that means things are generally easier for the user. It’s called having a minimum accessibility standard: you can count on it being relatively easy to use almost any app because you’ve used other apps, and they function and look similar.
All those interactions are described and detailed in the Human Interface Guidelines. It’s another document up on the Developer Portal that gives you details on interaction patterns.
NOTE
iOS 7 meant a major overhaul to app look and feel. The new HIG helps you look like an iOS 7 app and feel like an iOS 7 app.
Chafing a bit at Apple’s design restrictions? It’s OK... lots of people do until they think things through a bit more.
The HIG helps, rather than hurting you
The HIG is full of rules that help you. It’s a long document, but one that’s worth going through so that you only have to refer to it from time to time for a refresher. Everything from app design tips to rules about icon use is covered. You’ll learn how to design apps that “feel” like standard Mac apps, like Apple Mail...
You’ve already gotten used to the HIG...
You may be starting to feel like the HIG is just documenting the kinds of things you’re already used to... and you’d be right! You may not have realized it, but every time you used an app like Mail, you were really teaching your eyes (and fingers) to work with a HIG-designed app.
Take iTunes as another example...
THERE ARE NO DUMB QUESTIONS
|
Q: |
Q: OK, I get it... but surely there are some apps that don’t need the HIG, right? |
|
A: |
A: Actually, that’s not true. There are some apps that need a lot less of the HIG... like games that are immersive and completely graphical. But even then, the HIG helps you design interactions that feel natural and “iOS-like.” That’s really important... |
No. The HIG involves the design of your app, but it isn’t only about your visual design.
Information architecture is an important consideration in designing your app for real people to interact with it. And iOS7 did significantly change the look and feel of iOS but it also moved functionality around. iOS now has a control center that comes up from the bottom of the device at any time and holds cross-device functionality for any app to use, and there are other goodies as well.
NOTE
Things like Bluetooth, AirPlay, messaging via various networks—things that lots of apps want to use.
Design = look + feel
NOTE
...and some other stuff, too.
The more precise fonts and increased resolution of screens as the iOS ecosystem has matured mean that the new iOS has started to leverage the extra space for extra detail.
Good design is about more than how the app looks.
iOS 7 Top 5
1. Flat design is in.
The design trends all over the web and on iOS are toward flat design. Gone are the drop shadows and blue underlined links of the old Internet. Now the devices and web are shadowless with no depth.
2. Skeumorphism is out. In a big way.
Up through iOS 6, Apple was encouranging developers to mimic real-world interfaces to leverage people’s knowledge of how to use a menu or a calendar into using an iOS device. With iOS 7, apps are much more similar across devices because they are embracing their digital nature.
3. More unified interactions across devices.
iPad and iPhone are different, and we’re going to get into how to effectively use what each piece of hardware has to offer in the coming pages. But with iOS 7, Apple has made a full-court press to unified interaction patterns between iPhone and iPad.
4. Strategic use of color.
Apps on iOS have a tint color that indicates interactivity (rather than all of those drop shadows and buttons), so gone are old school underlined links. Instead, the text you can interact with is tinted.
NOTE
People who are color blind may have trouble with certain colors, so do some research.
5. iOS provides a sense of depth.
Parallax is used by iOS 7 with the springboard of the device that gives the illusion of depth behind the app icons. In addition, the use of translucency within apps means that you can see views slipping under navigtion elements in the app and show a sense of layers.
More to think about: your iPad is not your iPhone
So far, you’ve not really had to think much about whether your app will run on an iPhone or an iPad. The code’s been the same for both. But there are differences: besides screen size, iPad always supports multiple orientations, whereas many iPhone apps are portrait only. Interaction time is a key difference between the two devices as well. iPhone apps are designed for quick, easy access to information. iPad users are expecting to interact with the device and the app for longer periods of time and expect a more involved experience.
All these differences mean you’ve got to start thinking about devices...differently.
NOTE
You can’t just make images and fonts bigger for iPad, either. Not only will it look lousy, Apple might reject your app.
UP CLOSE DEVICE DIFFERENCES...
Take a look at how Calendar looks on each device. Take some time studying the decisions Apple made... you’ll need to make similar choices in your own apps!
UP CLOSE DEVICE DIFFERENCES...
Safari between the iPhone and iPad is very similar. You’ll see that some options are on the top or the bottom of the different interactions but otherwise the same. There’s one different interaction pattern though...
Making sure that you understand when your interface just won’t work on a smaller screen is important. Nobody thinks you can read tabs on an smartphonesized screen, so they came up with a better idea.
Forget about iPad/ iPhone... How is iOS different from Android?
FIRESIDE CHATS
Tonight's talk: What’s it like developing apps for other devices?
|
Apple Developer: |
Android Developer: |
|
Hi there. Now that we’ve gotten the gist of what it’s like to live in my world with Apple, it’ll be nice to get a fresh perspective. |
|
|
It sounds like there are an awful lot of rules for iOS developers to follow. The HIG, the approval process, and isn’t there a programming guide, too? |
|
|
Yeah, there’s definitely a programming guide. It gives you lots of information about the latest and greatest with Objective-C, interaction and software patterns you should follow, that sort of thing. What language do you all use for apps? |
|
|
Android apps are all written in Java. And we have lots of reference tools, too—free for us to use, but we don’t have to use all that stuff if we don’t want! |
|
|
What do you mean, you don’t have to? Don’t your apps need to be approved to go up on the App Store? |
|
|
Which app store? We have lots, not just one like on iOS. There’s Google Play, the Amazon Appstore, and probably more by now, too. We don’t have to get approval, either. Our apps just go right up on the store. Sweet, huh? |
|
|
So... you can just make your apps however you want? I’ve heard users complain about a lot of weird Android apps that behave oddly... |
|
|
Well, sure, but that’s just because some developer made bad choices. My choices are always awesome, especially when it’s nothing anyone’s ever done before. Besides, you wouldn’t believe the new code tricks I’m figuring out to make devices do things the hardware designers never thought about... |
|
|
Wait, you’re actually changing basic device behavior? Who’s making sure that code works on all those Android phones and tablets out there? |
|
|
Well, nobody... but it works on my phone and my two tablets! |
|
|
Yeah, but there are like... a zillion Android devices! |
|
|
Isn’t it great? So many options! You only have, what, three sizes? We have a ton more than that! And we can use each device however we want. Designing my app is wide open! |
|
|
Uhhh... yeah. So you can write apps that only work on your phone, and your tablet? Maybe the Apple approval process isn’t looking so dumb when my app doesn’t brick my user’s devices... |
|
|
Well, yeah, it happens, but so what? I just release an update. And no waiting around for some stupid team to approve anything! |
|
|
Sure. That’s awesome. So you can push out your new broken app really fast, right? That must be a real benefit. |
|
|
Android is all about flexibility. Don’t get your Lightning connector all in a wad, ok? |
|
|
How could I? They’re all the same, so I can actually make sure that what works for me works for everyone else, Android boy. |
|
|
Lemming! |
|
|
Anarchist! |
|
|
Whatever. You’re just... oh, gotta run, just got another crash report. Gotta push version 324... |
|
|
See ya... all I’m doing today is checking my sales on the App Store... |
BULLET POINTS
§ The Human Interface Guidelines (HIG) are important to follow if you want to have a good app.
§ You give up some flexibility in design to ensure that users get a consistent experience with their apps.
§ Plan for approvals to take time, but also plan for less buggy apps to get released as a result.
§ Apple exerts more control over their apps. Love it or hate it, that’s the iOS way, for good or (and!) bad.
THERE ARE NO DUMB QUESTIONS
|
Q: |
Q: How has the HIG changed over time? |
|
A: |
A: Apple has become more flexible with the HIG as time has gone on. As more and more applications go up on the App Store, new innovations add interaction patterns to apps, and Apple has let those innovations through and made them acceptable. For example, there are lots of apps that are using a control that slides in from the side of the app and partially covers the main screen (Facebook is using this heavily). That control isn’t anywhere in the HIG, but it’s becoming fairly standard for iOS apps. |
|
Q: |
Q: Will following the HIG just make my app look generic? |
|
A: |
A: Yes and no. The goal is to make your app interactions like other apps, which is easier for users. But creativity is great, and new UIs are a cool way to differentiate from a competing app. You can be original in your design without totally ditching the HIG and standard interaction patterns. |
|
Q: |
Q: What if I’m writing a game? What are the rules then? |
|
A: |
A: As soon as you start straying from standard controls, you start straying from the HIG. Once you spend some time doing iOS development you’ll get a feel for when you’re going to need to care about the HIG (like putting settings in the settings bundle), and when you can really go all-out custom. |
|
Q: |
Q: What about natural user interfaces? Is that still a thing? |
|
A: |
A: It used to be a big thing. Apple initially made a pretty big push, especially with iPad, to have you mimic a real-world interface in your apps whenever possible. The calendar app is a great example of that—the torn pages and familiar wall calendar design look like “real” objects. As the iOS platform has matured, though, apps seem to be moving away from that look. |
|
Q: |
Q: So Android developers really don’t have to get approval on their apps? |
|
A: |
A: Nope. Android is an open source platform, and that community is based on the idea that there isn’t a “gatekeeper” adding an approval layer to apps. Don’t think that means that it’s a free-for-all, though. Most of the Android apps that do well are those that follow the voluntary app guidelines. Android has similar programming and interaction guides to those that we’re using on the Apple side... they’re just not mandatory. |
|
Q: |
Q: Is device fragmentation a problem for iOS too? |
|
A: |
A: It is definitely something to keep in mind when you’re designing a UI. There are now three sizes to deal with: the original iPhone/iPod touch screen, the new iPhone 5 screen, and the iPad screen. There are also multiple resolutions for each of these devices. You’re going to have to use more and more relative positioning with your views, which will ultimately make designing for these different devices easier. |
You can be original in your design without ignoring the HIG and standard iOS interaction patterns.
POOL PUZZLE
Your job is to take items from the pool and place them into the list for iPhone, iPad, or iPod Touch. You may use the same item more than once. Your goal is to make a complete list of functionality for the iPhone, iPad, and iPod Touch. If the device has it, add the functionality; if not, leave it in the pool!
|
iPod Touch |
iPhone |
iPad |
Note: Each feature from the pool can be used more than once!
POOL PUZZLE SOLUTION
Your job was to take items from the pool and place them into the list for iPhone, iPad, or iPod Touch. You could use each item more than once. Your goal was to make a complete list of functionality for the iPhone, iPad, and iPod Touch.
WATCH IT!
This list will change.
Apple is always coming out with new devices and updating capabilities. You need to check for yourself!
|
iPod Touch iPod Runs most apps Video viewing Limited location You can get some info about location from Wi-Fi on iPod. Accelerometer Wi-Fi May have Camera |
iPhone You may have noticed some random stuff on this list—who would’ve thought about the speaker? iPod Runs most apps Video viewing GPS This one can be an issue. Accelerometer Wi-Fi Cell phone Camera External speaker Video recording Only on the 3GS and newer... Magnetometer |
iPad iPod Runs iPhone and iPad apps Video viewing May have limited location Accelerometer Wi-Fi May have GPS May have Camera External speaker Video recording |
APPLE WORLD CROSS
You've spent some serious time in the Apple universe in this chapter. Make sure you know all the lingo!
|
Across |
Down |
|
1. Device _________ in code prevents failures when hardware is missing. 7. The name of the process Apple uses to review apps 8. You can ______ if your app is rejected. 10. ______ is used to implement purchases from within iOS apps. |
2. _______ linking can be problematic. 3. The _________ Interface Guidelines have design and interaction guidance. 4. iOS ______ support is developer-configured and Apple tested. 5. Hardware that can be missing 6. ____ isn’t available on an iPod touch. 9. That other smartphone operating system 11. The ____ Library is used to hold pictures. |
APPLE WORLD CROSS SOLUTION
You've spent some serious time in the Apple universe in this chapter. Make sure you know all the lingo!
|
Across |
Down |
|
1. Device _________ in code prevents failures when hardware is missing. [CHECKING] 7. The name of the process Apple uses to review apps [APPROVAL] 8. You can ______ if your app is rejected. [APPEAL] 10. ______ is used to implement purchases from within iOS apps. [IAP] |
2. _______ linking can be problematic. [EXTERNAL] 3. The _________ Interface Guidelines have design and interaction guidance. [HUMAN] 4. iOS ______ support is developer-configured and Apple tested. [VERSION] 5. Hardware that can be missing [CAMERA] 6. ____ isn’t available on an iPod touch. [GPS] 9. That other smartphone operating system [ANDROID] 11. The ____ Library is used to hold pictures. [PHOTO] |
Your Apple toolbox
Now you’ve added some tools from the Apple ecosystem to your toolbox.
BULLET POINTS
§ The Human Interface Guidelines (HIG) are important to follow if you want to have a good app.
§ You give up some flexibility in design to ensure that users get a consistent experience with their apps.
§ Plan for approvals to take time, but also plan for less buggy apps to get released as a result.
§ Apple exerts more control over their apps. Love it or hate it, that’s the iOS way, for good or (and!) bad.