As 2014 draws to a close, my publisher has released their list of the best reviewed books they published in 2014. I’m honored to be able to say that App Accomplished was one of them.
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.
The first thing that many potential app creators want to do is to get a prospective developer to sign a nondisclosure agreement (NDA). I am not going to tell you not to do this (especially since that would potentially be legal advice). What I am going to tell you is that if you insist on this, a number of good developers will refuse to talk to you at all. Why?
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.
I’ve become very careful about pushing the submit button. I’ve learned the hard way how necessary that is. I urge you to learn from my past examples, rather than emulating them. In fact, my normal process now is to do my final testing and get everything into place and then I wait overnight before I actually submit, just in case I think of anything else.
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).
Once again, Apple has given us a new, beta operating system, with new options and new features that is scheduled to be released some time in the Fall. As with every time they’ve done that before, they’ve put app creators in a position to make a choice–do we target our development efforts at the iOS8 (the new version), iOS7 (the existing version), or do we try to support both?
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.
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.