The process of getting a successful mobile application deployed can be complex and daunting. Architecting, designing and developing natural user interfaces for touch and gesture on mobile devices is not the same as web and desktop UI design and development. Mobile devices are used in different contexts, and bring different personas to the table. Having web and desktop architecture, development, and UI design experience does not make you a qualified mobile architect, developer, or UI designer.
Although it was much worse back in the Dot Com Boom days, I still see publication and commercial print designers trying to design web sites the way they design a magazine. A lot of them finally figured out web design is different, and we are now dealing with getting them to realize web and desktop UI design experience does not make you a qualified mobile UI designer.
The same was true back in the Dot Com Boom days for developers and architects. Mainframe developers and VB6 developers carried over skills they needed to leave behind. Not all of them, but developing client server applications was different than building web applications. For the past decade or so, a ton of people have jumped on to the web development money cow, now they are jumping ship to the next money cow, mobile apps.
To make money in the app stores, or as part of an enterprise effort, you need to know what you are doing. Regretfully, all we know, is what we have done. Luckily books like this come out and help us avoid a lot of the learning by trial and error. I have listed the chapters of the book below to give you a high level view of what is covered.
1. What Could Possibly Go Wrong?
2. The App Development Life Cycle
3. Prototyping and Wireframing Your App
4. Determining Your App's Components
5. Finding the Right Tools
6. Skill Gap Analysis
7. Finding a Developer
8. Interviewing and Selecting a Developer
9. Managing to Milestones
10. Understanding What You're Getting
11. Pulling the Plug Early
12. Communicating Using Bugs
14. Submission and Beyond
The author won me over with his definition of a failed project. He summarized them in the four bullets below.
1. The app failed to ship (that is, didn't become available to users).
2. The app failed to work (that is, didn't work as intended for a noticeable percentage of intended users).
3. The project cost significantly more money than planned (more than 10% or 20% over budgeted funding).
4. The project took significantly more time than planned (more than 10% or 20% over budgeted time).
I have witnessed some software projects succeed, some crash and burn, and the rest get close enough to success that the team can sell it as a success. Sometimes the later takes a heck of a sales job. I would say in my book 80% of those sold as successes failed. They either came in well over budget, well beyond their projected delivery date, or delivered such buggy software that the maintenance effort was as big as the development effort.
I have seen teams only meet #1 in the author's list above, delivering an app so buggy it should not have been used. Success to the team simply meant they considered the project over for themselves, and they passed the headache on to support. You will find the members of those project teams run as fast as they can to the next project, instead of doing a retrospective study. After several months of releases to the app stores, the maintenance team got the major bugs out of the app.
Each chapter of the book covers a ton of topics. For example chapter 4 covers Devices, Native apps, Web apps, Hybrid apps, Third-Party Frameworks, Analytics, Video and Audio, Peripherals, Accessibility, Custom or Complex Animations, Conditional Formatting, Localization, User Preferences, Data Storage, Servers, Syncing, Push Notifications, and Background Tasks.
Chapter 6 covers Programming, Testing and Quality Assurance, Server Support and Troubleshooting, User Experience Design, Graphic Design, Sound Design and Music, Copywriting, Marketing, and Games.
Covering so many topics does not allow for a deep discussion of each one. Instead the author introduces the topic and provides enough information that you understand the topic well enough to continue learning more about it. There is also a lot of cohesion in the chapter's topics, which helps to provide a context for the topics as a whole.
The one thing I had a little trouble with is that in certain places in the book the author gets into a mode of "That having been said", and then saying it is ok to do the opposite of what he recommends. That is fine, but it drags out those sections with info that is repeated over and over. At least that is the way it felt.
Prototyping and Wireframing Your App was where this came through pretty hard. In this section he also seemed to get a little simple for the reading audience by covering in detail how to cut and paste images into Keynote from OmniGraffle. I am not going to ding the book for this, because I feel it is just a writing style. I have learned over the years there are a lot of people who like this style of writing.
One of my favorite parts of the book are the sidebar case studies. Here is a partial list of them- API documentation, app development company outsourcing, Auto Layout UI code, cookie refreshing, design changes, Groovy and Grails languages, miscommunication with developer, missing source code, multiple bug reports, number comparison bug, optimization updates, outsourcing developers, plagiarism detection, spaghetti code, and vague requirements.
The case studies really help tie the topics being covered in the chapter to the real world. They are also lessons learned the hard way. By reading them, you gain the experience of having made the mistake yourself, without actually having to make the mistake. You just reap the lesson learned.
Over all I highly recommend this book to anyone getting into the mobile application world. The book is good for getting a sweeping view of the mobile world in its current state.