To celebrate this, they’re offering 40% off the eBook until January 22, 2015.
And if you’re still on the fence, you can read one very thorough review here and the rest here on Amazon.
]]>First of all, most of the potential app creators developers speak with don’t end up shipping any products at all. Second, developers speak with many potential app creators for each project they actually do. If we were to sign NDAs with every app creator with whom we spoke, we would be opening ourselves up to nearly constant legal litigation. I have found that there are actually very few original app ideas. Most of them are variations on one theme or another. If a developer signs an NDA with you and then later another potential app creator comes to him or her with a similar idea, that developer is now in a quandary. Choosing to work with the second app creator might open the developer up to being sued, even though he or she had nothing to do with the second app creator’s idea.
It’s certainly possible that your idea is truly unique, or that you represent an established brand (in which case you probably have your own legal department already). I’m simply asking you to consider whether you think that protecting your idea or getting the best developer is more important before you require a signed NDA at a first meeting.
]]>And to test on every manner of device I can get my hands on before I do.
You see, back in 2011 there was a bug in Xcode 4.0.1 with LLVM 2.0. The optimizer would generate app packages that crashed immediately on an ARMv6 processor (like the iPhone 3G) but worked fine on an ARMv7 processor (like the iPhone 3GS).
The key word there is optimizer. You see, the way Xcode worked at the time (and likely still does) was that apps built for “Debugging” had optimization turned off, and only apps built for “Release” ran the optimizer.
And so it was that I built an app for a client, and tested it on all the different pieces of hardware I had available to me – but only with Debugging turned on (after all, if any bugs turned up during that testing, I wanted to be able to figure out what was wrong). Then I created the Release build to go to the store and I did one last sanity check with my iPhone 4, but didn’t bother to test it with my old iPhone 3G.
Apple’s App Reviewers also apparently only checked it with an iPhone 4 (or some other ARMv7 device) because they approved it. And the app got into the store. And all Hell broke loose.
Because this wasn’t a new app – it was an updated version of an existing app that I had written for that client. I had taken an app that worked fine and, in the process of fixing a couple of bugs and adding a couple of new features, had rendered it utterly unusable by a substantial fraction of the app’s existing users. Anyone with an older device who downloaded the update had the app crash immediately when they tried to start it. They couldn’t run the app, couldn’t see their data, and couldn’t get to the feedback address in the app to let us know. So they turned to the App Store review process. In droves.
Within a few minutes of seeing one of the bad reviews, I had installed the shipping version of the app onto my iPhone 3G and found the problem. A quick web search told me I wasn’t alone, but that was small consolation. I turned off the optimization and resubmitted, but it was days before the new version got through the process, and some users never got over it (although thankfully my client eventually did).
It was Apple’s bug, and arguably Apple’s fault, but the users didn’t care. And ultimately, the decision to release without testing the final version on older hardware was mine, as was the ultimate blame.
]]>Although we don’t know exactly when iOS8 will be released to the public, it will most likely be in September or October. So if you’re planning on shipping much after that (for example, if you’re targeting the Christmas season in the U.S.), then based on past experience, you should expect that a majority of the devices your software will run on will be iOS8.
Last year, with iOS7, the look and feel of the iOS platformed changed dramatically, and apps that still used the old style looked out of place. That doesn’t seem to be the case this year, so I wouldn’t alter your plans just based on look and feel this year.
iOS8 has a number of new features that might be relevant to your app. If your app uses (or could use) one of these features, I would recommend targeting iOS8 exclusively.
If your app tracks, stores, analyzes or reports on health data (weight, calories, blood sugar, blood pressure, exercise, etc), then I think you should take advantage of the new HealthKit features. I expect apps in this space that don’t support HealthKit to become second-class citizens quickly this Fall.
If your app does Home automation, then you should target HomeKit as well.
If your app is early in development, needs a backend platform, and is only going to run on iOS and OS X (i.e. iPhones, iPads, iPod touches and Macs), then I’d recommend that you seriously investigate using Apple’s new free CloudKit. There’s risk there, because Apple doesn’t have the best track record on such things, but it’s a feature-set full of promise, and it’s worth at least taking some time to look at.
Apple has made some changes to the way that iBeacons and indoor navigation work. If your app does this, it might well be worth targeting iOS8.
If you have a Mac app and a corresponding iPhone/iPad app, you should take a look at Apple’s new technology in iOS8 and OS X 10.10 that allows users to switch devices without losing their place. I expect this to be a small number of apps, though.
Otherwise, if you’re planning on shipping well before the Christmas season and you don’t use one of Apple’s new features, I’d say you’re probably okay sticking with your original schedule. Just remember that when the new iPhones ship, Apple will be looking for apps to feature, and if yours doesn’t make the best use of iOS8, you’re likely to be low on their list.
]]>Explains some of the common misconceptions about mobile app development and gives some reasons why so many app projects fail.
Provides an overview of the high-level steps in the app development process
Explains how to turn your app idea into something a developer can understand how to develop
Provides a list of the different kinds of technologies, libraries, features and functionalities that are commonly used in mobile apps and explains what each is and why you might want to include it in your app
Provides a list of the different services and kinds of development environments and tools that are used to build apps and explains why and when you might need to use them.
Explains the different kinds of potential development resources that you might use, where each can be found and the pros and cons of each.
Explains how to figure out what skills you need to have to get your app built and how to figure out which ones you are missing and what you might do about that.
Explains how app projects can be organized and managed and gives some recommendations about strategies that have worked for me.
Discusses the process of determining whether a particular developer might be a good fit for your app project or not.
Explains how to estimate the quality of the app that you are getting and the code that is being written for it.
Explains how to use a bug or issue tracking tool to communicate with your present and future development teams.
Explains how to determine how far off track your project seems and how to decide whether it’s recoverable or not.
Explains how to find and work with testers of your app to get the quality you need.
Discusses submitting your app to the store, what to do if it gets rejected and how to start planning your follow-up release.
Consider the Stock Market. There’s no guarantee that you won’t lose your money in the stock market. Some people were heavily invested in Enron, or AIG, or with Bernie Madoff. But those are rare exceptions. The vast majority of well diversified investors make money over time. Contrast that with the Lottery. A few people, statistically, have made more money than they’ve lost on the lottery, but they are few and far between, and their existence doesn’t make the lottery an intelligent investment strategy.
Unfortunately, it can be hard for many people to tell the difference between the app-development-project equivalents of the lottery and the stock market.
This book isn’t (and can’t be) about “how to have a successful app project every time.” Instead, it’s about how to maximize your chance of success – about how to make sure you’re investing in the Stock Market instead of playing the Lottery. With the average app development project running into tens of thousands of dollars, we’d like to hope that reading this book will a small investment that can make a huge amount of difference in your odds of success.
]]>