When designing a mobile app, the first thing you need to decide is if this app will be a native app, a web app, or a hybrid app. Each uses different technologies to build, and it is important to consider the pros and cons of each before deciding on what your project will use.
Native apps work by leveraging the built-in system frameworks present on the device. The apps are written in languages that are compiled for quick execution, such as Objective C for iOS development or Java for Android development. Since these apps run native code (that is, code compiled directly for the platform, often down to assembly language or some other bytecode), they are very fast. As they use the built-in frameworks, they get a lot of features (including look and feel) nearly for free. The problem with native frameworks, however, is that they aren't cross-platform. For example, the code you write for iOS will not work on Android. If your app needs a wide variety of platform support, this can mean considerable development time as the app needs to be rewritten for each platform it supports. If you're the only developer, this means you need to learn each native framework and language in order to write your apps—often a lengthy endeavor.
Web apps, on the other hand, solve some of these difficulties by being inherently cross-platform (as long as web standards are adhered to). Furthermore, any HTML, CSS, and JavaScript knowledge you might have can be leveraged, so there may be less to learn at the outset. However, web apps have serious problems as well: they have very limited access to the capabilities of the device, and they are slower than native apps (given that they run inside a browser using an interpreted language, JavaScript). Furthermore, web apps don't inherit the native look and feel of the app. Although distribution and updates are easy (all you need is a web server), no app store will list your app, and so discovery by your users is difficult.
Hybrid apps try to be the best of both worlds. Since hybrid apps use some native code, the app has access to the native features of the device. It also means that app stores will allow the app in their stores, allowing easy discovery. Because hybrid apps use web technology, your code is largely cross-platform (assuming you follow the Web standards), and easy to port to other platforms. Of course, there are still downsides: the web portion of a hybrid app will likely still run slower than a native app. However, there is an upside: if you need that extra performance, hybrid apps allow you to write native code when needed.
Apache Cordova is a framework that allows you to write hybrid apps. These apps can be published to the app store of your choice, and they permit cross-platform development. Should you need access to the native features of the device, there are core native plugins that can be added, which permit access to the camera, accelerometer, microphone, and so on. There is a large community that has written several additional plugins that provide a wide-ranging set of features. If that isn't enough, you can always write your own plugin to accomplish what you need.
Apache Cordova didn't start as an Apache project. Initially, the project was named PhoneGap and was owned by Nitobi Software. In the early stages, it was distributed as project templates that could be used in Xcode or Eclipse to create hybrid apps. While it was easy to develop single-platform apps, it was more difficult to set up multi-platform apps (one had to create copies of the web portion and keep them in sync across projects). Even so, many production apps were developed and hosted on app stores.
In 2011, Adobe purchased Nitobi Software. As part of the acquisition, the PhoneGap code was contributed to Apache as open source, and was renamed to Apache Callback and then to Apache Cordova (when the prior name was considered too generic). Adobe kept the PhoneGap name, and maintained a fork of Apache Cordova's code. The version was upped to 2.x. Most of the time, the two were largely identical (with only minor variations). Because the project templates of the prior era were often problematic, project creation transitioned to a command-line interface. Multi-platform development was somewhat easier, though not ideal.
Apache Cordova 3.x was released in July 2013. It provided a new command-line interface that dramatically simplified multi-platform development while also making plugin installation easier and less problematic than before. It also split out all the core features (beyond the native packaging) and distributed them as core plugins. This allows users to pick and choose what plugins they need rather than taking them out later (which was often difficult). This means that apps written with 3.x only ask for the permissions they actually use, whereas under 2.x, an app would often ask for permissions it never needed.
At the very beginning, the only way to use PhoneGap was to compile your project on your own development machine. This meant that you needed a machine capable of supporting the specific development environment for the platforms you supported. Setting up and maintaining this environment can be time consuming and difficult, and so PhoneGap Build was released as a cloud-based development method.
PhoneGap Build allows developers to write their apps on their machines, and then upload those apps to the cloud for compilation and packaging. This means that there is no need to set up and maintain a fully developed environment, a text editor is sufficient. There are some platforms that require additional steps before the results can be tested or deployed (Apple requires various certificates and provisioning), but for the first time, it made it possible for less-technical web designers to begin making hybrid apps that could be sold on the App Store.
Whether you use Apache Cordova or Adobe PhoneGap is up to you; we'll use Apache Cordova 3.x. It provides a set of APIs that permit your project to access the native features of the mobile device, such as the accelerometer and the camera, and much more. Using these APIs, it is possible to create an app that runs on mobile devices that has native functionality, along with HTML, CSS, and JavaScript. Where necessary, Cordova also provides the necessary expansion to create additional plugins to support features that the core API doesn't support, which means the possibilities are truly endless.
Adobe PhoneGap 3.x is a distribution of Apache Cordova 3.x. Generally, these can be thought of as the same thing, but PhoneGap integrates closely with Adobe's PhoneGap Build offering, which allows developers to compile their apps without having a complete platform SDK on their computer. It's quite possible that Adobe will bring other enhancements to this distribution that aren't part of Cordova.
Adobe PhoneGap 3.x is a distribution of Apache Cordova 3.x. Generally, these can be thought of as the same thing, but PhoneGap integrates closely with Adobe's PhoneGap Build offering, which allows developers to compile their apps without having a complete platform SDK on their computer. It's quite possible that Adobe will bring other enhancements to this distribution that aren't part of Cordova.
Which one you use is up to you; we'll go over the installation instructions for both, how to use each (generally, the commands are the same), and where they differ. For the rest of the book, we'll be using the Apache Cordova distribution, but you are welcome to use the Adobe PhoneGap distribution as well.