* A-A-P is portable over many systems. At least most Unix variants, MS-Windows and possibly the Macintosh. * A-A-P is open source, free software. Most of it is under the GNU GPL. Interfaces and libraries are more free. * A-A-P is not a monolitic program. It is made out of separate modules with clear interfaces. Most of the work is done by existing tools. * Since network connections are slow and unreliable - and when using a laptop - a local copy of a file is often required. A-A-P caches files, obtains a new version when available and cleans up files that have not been used recently. * The more alternatives there are, the more choices a developer has to make. Making all these choices slows down development. Therefore A-A-P provides a preferred set of modules. Many people will be satisfied with most of these modules, but will still be able to use a different module where they have a preference. * A-A-P is available in a command-line version and in a GUI version. The command-line version works on a console and over a telnet connection. The GUI version is easier to use, but requires a windowing system. * A-A-P maintains a set of preferences. These are global to all projects but local to the user or system. This specifies where specific tools, libraries, documentation files, etc. can be found. This greatly reduces the need to configure a package when building or installing it. * English is used in the original code. Provisions are made to add translations through the use of message files. * Reliability is considered more important than fancy features. A-A-P is a tool you can rely on.

* WORKFLOW EDITOR * Configure your integrations in an easy to use UI * Your tools become the build steps in your workflow, which will run in the order you set them up. You can configure a build for building or testing, or sending out test releases, you can cover all your bases easily. * BITRISE.YML * Create and test workflows in your terminal * You prefer to work in your terminal instead of using a web browser? No problem! If you don't need your build logs to be on the web for the whole team to see, just install the CLI, download the config.yml from Bitrise and keep a tab in your terminal for Bitrise. * Continuous Delivery * You get your apps without the need of messing with manual controls. It’s like switching on autopilot. Lean back and order a scotch. * Code Security * Every build runs in its own virtual machine, and all data is discarded at the end of the build. We also hired sharks with laser beams on their head, just in case. * Hosted Environment - You don’t need your computer for building, go use it to binge-watch Breaking Bad instead. * Open Source - Oh, the steps you can use in your workflow? They’re open source. Modify, and share them as you like, or create a new one (if you think we were lazy bums, who missed an important service to integrate). * Customizable Workflows - We integrate with the services you love to use, like Slack, HipChat, HockeyApp and Crashlytics. Or you can generate random funny quotes, we’re not going to judge. * Support by Devs, for Devs - We don’t just have a support staff, we have Engineers, and you can talk to them whenever you want. Providing they aren’t on a space walk or having tea with a Klingon (a.k.a. virtually always!) * GitHub Pull Request support - If you are using a GitHub repository we are going to send the build's status to GitHub, so you can see it directly in your repository. Furthermore if you create a Pull Request we won't just test the fork or the feature branch, Bitrise will test the actual merged code too. * Over-The-Air App Deployment - We support a lot of third party beta testing and deployment services, but we wanted to provide an integrated solution to help you distribute your apps to your testers, without the need of registering yet another account after signing up to Bitrise.