iPhone Design Award-Winning Projects

Table of contents

1. Copyright
2. About the Authors
3. About the Technical Reviewer
4. Acknowledgments
5. Introduction
   1. Readme
      1. Who is this book for?
      2. How technical is it?
      3. How were these interviewees chosen?
6. I. Innovating Beyond Apple's Design Standards, While Maintaining Apple's Logic for Consistency, Clarity, and Usability
   1. 1. Tweetie
      1. 1.1. A Billion Bad Twitter Apps
      2. 1.2. The Minimalist Flourish
      3. 1.3. Tearing Down Tweetie
      4. 1.4. Organic Marketing
      5. 1.5. Tweetie 2
      6. 1.6. Market Share
   2. 2. Facebook
      1. 2.1.
         1. 2.1.1. How did you become the sole iPhone developer at Facebook?
         2. 2.1.2. Yet Facebook Touch looks much different than the iPhone app.
         3. 2.1.3. Why isn't a static nav bar at the bottom of the screen useful for Facebook?
         4. 2.1.4. What was the thinking behind the grid interface?
         5. 2.1.5. You also use the top nav in an interesting way in this new version. Is the redesign a consequence of implementing the grid?
         6. 2.1.6. What are the compromises involved in using the grid?
         7. 2.1.7. What went into creating Facebook's view controllers?
         8. 2.1.8. Is it tempting to start playing with MapKit and add friend-mapping?
         9. 2.1.9. Is there a point where the Facebook app gets too big?
         10. 2.1.10. When the app gets memory warnings from the OS, how does it deal with them?
         11. 2.1.11. Otherwise, it all stays cached?
         12. 2.1.12. Why couldn't Facebook for iPhone have kept growing in its old layout?
         13. 2.1.13. But how different can you make your UI without alienating people?
         14. 2.1.14. As the app grows, how will you handle preferences?
         15. 2.1.15. What's going to be most enticing about future versions of the Facebook app?
         16. 2.1.16. How do you incentivize people to start caring about a feature?
         17. 2.1.17. Are the mobile versions of Facebook diverging from desktop Facebook?
         18. 2.1.18. Are there interesting ways you use Apple's frameworks?
         19. 2.1.19. Are there any interesting ways your Three20 frameworks have been used by the open source community?
         20. 2.1.20. Why did you choose to make Three20 open source?
7. II. Using App Connectivity with Core Location to Make Games Social
   1. 3. Topple 2
      1. 3.1. How to Do a Sequel: Conceptually
      2. 3.2. How to Do a Sequel: Technically
      3. 3.3. Designing Apps (and Companies) for the Mass Market
      4. 3.4. Managing a Universe
      5. 3.5. PVRTC-It
      6. 3.6. Fun, the Apple Way
      7. 3.7. Bureaucracy and Lightheartedness
      8. 3.8. Free vs. Paid
   2. 4. Q&A: Foursquare
      1. 4.1.
         1. 4.1.1. What was your plan for Foursquare for iPhone, and how did you divide the work?
         2. 4.1.2. Is there a governing aesthetic?
         3. 4.1.3. Do you each have varying ideas about what information the user should be presented with first?
         4. 4.1.4. Your app relies heavily on tabs to sort information. Is this a good long-term solution?
         5. 4.1.5. Did any apps serve as inspiration for Foursquare's interaction design?
         6. 4.1.6. You use a lot of Apple's frameworks. Why not source some of the work out to Apple's built-in apps?
         7. 4.1.7. Now that you've cranked out your initial versions, how do you go about revising the interface?
         8. 4.1.8. Is it better to have more tabs and a cleaner interface, or fewer tabs and a more crowded screen?
         9. 4.1.9. Foursquare seems to rely heavily on WebKit. Why?
         10. 4.1.10. Though Foursquare definitely has a unique visual design, Apple inspired some of the smaller details, didn't it?
         11. 4.1.11. Certain screens of your app contain "help" text. How do you decide where and when to include those instructions?
         12. 4.1.12. Do you use any wider system for collecting feedback?
         13. 4.1.13. Did you assume that Foursquare for iPhone users had seen the Web service first?
         14. 4.1.14. Do you take user's real-world behavior into account when you're adding features?
         15. 4.1.15. Do you try to think one step ahead of Apple? Or take their iPhone OS revisions as they come?
         16. 4.1.16. What were some of the fights you had over user experience?
8. III. Using Compression to Cram More Data into a Local App–Large Images, Geo Data, and Lots of It
   1. 5. AccuTerra
      1. 5.1. Building a Framework
      2. 5.2. Divide and Conquer
      3. 5.3. Building an In-App Store
      4. 5.4. PVRTC or Broke
      5. 5.5. Lazy Loading
      6. 5.6. Memory Diagnostics: Sample Project
      7. 5.7. Dealing with Low Memory Warnings
      8. 5.8. Building Forward
   2. 6. Q&A: Exit Strategy NYC
      1. 6.1.
         1. 6.1.1. You had an app idea that demanded a big time investment, even before programming began. How did you know it'd be worth it?
         2. 6.1.2. New York is a big city, but how did you know there'd be a market to sell to?
         3. 6.1.3. Why is this idea best suited for the iPhone?
         4. 6.1.4. How do you handle the database of stops and cars?
         5. 6.1.5. How did you ensure that all these images would load quickly?
         6. 6.1.6. How, if at all, can you make this a sustainable business?
         7. 6.1.7. How do you make your app useful to more people?
         8. 6.1.8. So the app will become something else entirely—a hyperlocal neighborhood transit map.
         9. 6.1.9. What about the 10MB download limit over 3G?
         10. 6.1.10. Version 1.0 didn't cover every subway station in New York. Is it worth pursuing the "long-tail" customer who wants every corner of a map documented?
         11. 6.1.11. How deep should you drill into the NYC market before moving on to other cities or projects?
         12. 6.1.12. How do you handle an update that's so major?
         13. 6.1.13. Do you have an economic theory behind your pricing?
         14. 6.1.14. How did you get attention for your app?
         15. 6.1.15. You've chosen to go beyond the iPhone. Why?
         16. 6.1.16. What's the most important thing you learned making version 1.0?
9. IV. Creating a Beautiful App Without Falling Victim to Memory Issues—OpenGL, Skinning, Object Reuse, and Coding Efficiently
   1. 7. Postage
      1. 7.1. There Were Sheep
      2. 7.2. Is This One of Them Internets?
      3. 7.3. Coding for Fun
      4. 7.4. The Circling Shark
      5. 7.5. Homegrown Design
      6. 7.6. Building On Postage
   2. 8. Q&A: Delicious Library
      1. 8.1.
         1. 8.1.1. What's behind the theming?
         2. 8.1.2. Your plan was to get it looking right first and foremost?
         3. 8.1.3. Why were you so dead-set against animation?
         4. 8.1.4. So skinning was the healthy medium?
         5. 8.1.5. How did you achieve that speed?
         6. 8.1.6. How does that database work?
         7. 8.1.7. That's a lot of data, isn't it?
         8. 8.1.8. You didn't, um, RTFM?
         9. 8.1.9. Did you consider making the app standalone?
         10. 8.1.10. Were you looking to imitate the desktop experience?
         11. 8.1.11. Delicious Library overlaps a little with iTunes. How did you deal with that paradigm?
         12. 8.1.12. Other challenges we haven't talked about?
         13. 8.1.13. Did you bring this up to engineers at Apple?
         14. 8.1.14. What would you tell someone starting app tomorrow?
         15. 8.1.15. What does it do to the logic of code to be so judicious about memory?
         16. 8.1.16. What's good about this mode of developing?
         17. 8.1.17. Did designing the iPhone app change the way you view desktop UI?
10. V. Fitting a Big Idea into a Small Space–Keeping the Feature List Focused, Simple, Refined, and Compelling
    1. 9. Wooden Labyrinth 3D
       1. 9.1. The Dropout
       2. 9.2. The Challenge
       3. 9.3. Building the Labyrinth
       4. 9.4. The "Magic" Piece
       5. 9.5. Into the Fray
    2. 10. Q&A: Prowl
       1. 10.1.
          1. 10.1.1. How did you get involved with the open source community?
          2. 10.1.2. What aspect of the project took the most time?
          3. 10.1.3. How did you first envision people using Prowl?
          4. 10.1.4. Why use Growl?
          5. 10.1.5. How does the plug-in work?
          6. 10.1.6. How do you hack it?
          7. 10.1.7. What's unique about the way Prowl uses Push notifications?
          8. 10.1.8. What's the 'chain of command' that a notification traverses to get to an iPhone?
          9. 10.1.9. Apple doesn't let you relay a message from an application directly to its servers?
          10. 10.1.10. What's particularly interesting about the way Prowl works?
          11. 10.1.11. What's tricky about interacting with the Push server?
          12. 10.1.12. How many messages have gone through Prowl to date?
          13. 10.1.13. When building a utility, do you think about usability differently than you would for another kind of app?
          14. 10.1.14. How can the open source community add to Prowl's functionality?
          15. 10.1.15. What do you know now about working with Growl that you wish you knew at beginning?
          16. 10.1.16. Prowl doesn't make use of most of the iPhone's inputs. Is it tempting to add more features?
          17. 10.1.17. What about genuinely useful stuff, like the Bluetooth proximity feature you mentioned?
          18. 10.1.18. How important is Prowl's Web interface?
          19. 10.1.19. How has the API changed the way you think about Prowl's usability?
          20. 10.1.20. Has Prowl created a new usage scenario for the iPhone, or replaced an extant scenario that was too clunky?
          21. 10.1.21. What are some of the most interesting usage scenarios you've come across?
          22. 10.1.22. How did you arrive at that $2.99 price-point?
          23. 10.1.23. So the price point keeps the app in the hands of the l33t, so to speak?
          24. 10.1.24. Is Prowl profitable?
          25. 10.1.25. Is there a lesson to other developers in Prowl?
11. VI. Making Better Apps and Enfranchising Your Users–The Right Way to Iterate, Planning an App Store Strategy, and Some Serious iPhone Development Philosophy
    1. 11. User Experience: Ge Wang
       1. 11.1.
          1. 11.1.1. What is your background like?
          2. 11.1.2. Why did you bring your research from computers to the iPhone?
          3. 11.1.3. Why is the iPhone unique that way?
          4. 11.1.4. How do Smule apps create music?
          5. 11.1.5. What did you learn doing laptop orchestras that informed your iPhone app design?
          6. 11.1.6. Before you began building apps, were there any that you particularly admired?
          7. 11.1.7. Are Ocarina and Leaf Trombone games?
          8. 11.1.8. How have your apps built on each other?
          9. 11.1.9. How do you know how difficult to make an instrument?
          10. 11.1.10. What do you have in mind when you set out to build a new Smule app?
    2. 12. Iterative Design
       1. 12.1. The Canadian Way
       2. 12.2. Simply Complex
       3. 12.3. Group Single-mindedness
       4. 12.4. Reverse Engineering Cocoa
       5. 12.5. The Sidebar Solution
       6. 12.6. Enter the iPhone
       7. 12.7. Project Yellow Canary
    3. 13. Upgrading
       1. 13.1.
          1. 13.1.1. One question many of the developers in this book have pondered: do I charge for my upgrade? Do I charge for my app at all?
          2. 13.1.2. What about ad-supported apps like your free version of Instapaper?
          3. 13.1.3. Are free upgrades a good idea? Or should you make users pay again? Let's use Exit Strategy NYC, featured in Chapter 6, as an example.
          4. 13.1.4. Loren Brichter, who developed Tweetie 2 and is featured in Chapter 1, decided not to do a free upgrade. Yet Tweetie 2 still shot to the top of Apple's "top grossing list" when it went on sale. How is Tweetie 2 different from Exit Strategy NYC?
          5. 13.1.5. What happens when the scope of your app changes with a second version, as with Exit Strategy NYC? Should Jonathan have changed the name and risked losing the benefit of SEO in the App Store, in the hopes of having a name that describes the app better?
          6. 13.1.6. Does the name of an app need to convey exactly what the app does?
          7. 13.1.7. Do you think buyers have price "benchmarks" that developers should attend to?
          8. 13.1.8. So reviews are skewed negatively in the App Store?
          9. 13.1.9. What is the case to be made for apps over $5.00?
          10. 13.1.10. You dropped the price of Instapaper Pro. What did you learn from that?
          11. 13.1.11. Why not go lower?
          12. 13.1.12. Zach West, who is profiled in this book in Chapter 10, said he deliberately priced Prowl a little on the high end to cut out novice users who would flood him with support requests. Do you always want as many sales as possible if you're doing your own customer service?
          13. 13.1.13. Like a lot of iPhone apps, Instapaper has a desktop version. Should you build an iPhone companion app as a standalone?
          14. 13.1.14. Why haven't we seen more apps like Prowl that use push notifications in a useful way?
          15. 13.1.15. When iPhone first came out, there were a few missing links with MapKit; do you think push will evolve the same way?
          16. 13.1.16. So you can't assume your users have self-control?
          17. 13.1.17. Why didn't you make Instapaper for iPhone a mobile web site instead of an app?