Introduction‎ > ‎

Learn more

Why new build system?

This page answers to the question that many of you might have asked:  "why do we need a new, mobile related build system?".  There are already solutions like old-good-Makefile, ant, gradle, gantmaven, Rake and many more, so why the heck you need another system? Read on if you want to know more.


Agile approach

In the modern world of software development one of the most successful approaches is an Agile approach.  One of the enablers for Agile approach are automation of software development, continuous integration and continuous delivery. While this is very well known and popular approach in software development for web applications, it still have not found its way into mobile application development. 

Mobile is different

Build systems are mature solutions already - that's right.  Many of the build systems described above are extremely useful and matured over long-ish period of time. They are perfect for addressing the needs of server-side development though. In the server side world, things like continuous build, continuous integration have been on the radar for many years already and people learned how to build their software in automated way. That, in our opinion, has cut tremendously the overhead connected with environment setup, continuous integration configuration of your projects for teamwork. For all the tools above, there are numerous plugins and processes available in these tools that people learned over time and adapted to their needs. But this is in the other - server side world. 

This is not the case (yet) in the mobile development world. The tools that are used for mobile development (Eclipse + Android ADT plugin for Android,  XCode for iOS, MS Visual Studio for Windows Phone are  targeted for individual developers and for UI-driven build process. Also other tools like, otherwise excellent, IntelliJ Idea or AppCode have not been helpful. All the tools provide very basic command line built-in build support, which is not very useful in the cases where you want to move the software out of this particular developer personal PC. There are few important cases which are not covered by the tools: Teamwork, Continuous Integration, and Enhancements where the original tools are not enough - as we experienced in the course of our mobile development adventure. More on this - below.

Apphance Flow's basic design principles

Flow is addressing the need, with few very important aspects in mind.
First of all we know and believe that tools for individual developers to develop are EXCELLENT. Full stop. We do not want to change how individual developer works - whether they use Eclipse, or IntelliJ, XCode or AppCode - we know it's best for the developer continue using them or even change them freely (We know that in certain aspects some tools are more excellent than others). Main Flow design principle is - do not mess with what developers do already. Embrace it and learn from what they do, let them continue doing it - and give them extra possibilities that can significantly cut the overhead for repeatable tasks, open up completely new possibilities (in transparent way) which otherwise would be very costly and difficult to achieve. Adding Flow to existing project is dead simple and does not interfere with normal development process. Look at Hello Android , Hello iOSHello Windows Phone to see how simple it is.

Secondly, we did not want to build a new build system from scratch. Not at all. We are great proponents of "Standing on the shoulders of giants", and rather than complaining on how other build systems are build, we carefully analysed the existing  build systems, and based on our server side experience, word of mouth from many people we spoke to and our needs we chose Gradle as the foundation (er... shoulders) we built Flow on. Gradle has excellent capabilities and support, it's extremely flexible, and easy to extend by any developers. Unlike Ant or Maven where declarative build style is used, you can actually program-in the logic of your builds using powerful and flexible Groovy scripting language (which is very easy to learn for example for Java developers). Without Gradle we could probably spend years getting Flow to the place it is now in. We open-sourced the Flow system so that it is easy to extend by anyone, hoping also that it will be welcome by Mobile Development community. We also welcome contributions from the community.  More on this can be found in Contribution Guidelines section.

We are also not trying to reinvent the simple build steps that comes together with the standard mobile development platform Rather than re-develop standard build tasks, we are using what operating systems teams provide us with - we run the simple build steps under the hood (we run standard android ant tasks, xcodebuild command line tools.

Agile teamwork beyond just developers

One of the things that you experience when your development team starts to grow is how much different project coordination is when the application starts crossing single developer machine. This has not been so often few years back, when mobile applications were relatively small and easy to develop, but nowadays we cannot imagine serious application development without team working on it. The first need here is - how to make sure that the application works, compiles and can be build for all the developers in the team. This seems easy, but each of the tools on each of the developer's machines might be differently configured, different local extensions can be installed... and there are no easy to use and setup tools which can help in synchronising it. That's where the build system that works in the same way for all developers and always produces consistent results is great help to make sure that what compiles on your PC, will also compile at your peer's PC. That's where Flow helps.

Also - the team extends beyond just developers - testers, project managers, graphical designers, UI architects, customer representatives .... Mobile applications are very different than web applications in the sense, that they are (usually) not available at certain url in your browser. In case of web applications, it's already pretty common that the "latest and greatest" version of the website is continuously available to anyone testing it, right after developer commits the code to repository. This is so much different in mobile application world. In order to see the application "life" one has to build it, distribute binaries,  the other part has to install it on their devices. As a developer - if you need to do it often (being agile)  - the first thing you want to do is to avoid repetitive tasks, and offload them to an automated build system. At the end, this is what computers are good at - offloading repetitive tasks from people. Having Flow also enables tools (see further in Continuous Integration chapter) that give the other parties - not only developers to get the "latest and greatest" software easily released and installed, without involvement of developers - which gives the developers more time for doing what they are great at - developing software.

Another important aspect of teamwork, especially in bigger organisations, is to maintain cross-team standards between the teams. Often in order to provide consistent way of developing  applications. While it can be quite easily done in server development side, in mobile world, where people mostly work on their own PC, this present additional challenge. If you want to introduce standard approach such as consistent static analysis configuration, consistent convention of naming your deployment targets,  similar way to deliver application to your customers - Flow is here to help as well, by not only automating common tasks, but allowing your organisation to set (very easily) common conventions that will be used by all your teams. Flow also enables keeping the same code standards across the organisation - more on this in the enhancements chapter below.  

Continuous integration for mobile

In the server world, Continuous Integration and Deployment is already fairly mature concept. It's pretty common that software is not only build automatically and tested  when it is committed to source code repository. It is not so in the mobile world. The command line tools are not really well prepared for the case when software is build on the server in unattended way. Various workaround are needed in order to make this happen (such as working around certificate and signature issues in iOS). Testing needs to be performed using simulators or emulators of real devices which provides extra challenge. 

There is initial work in this area - such as Android Jenkins Emulator Plugin or Xcode Jenkins Plugin for example, and plenty of scattered blogs and tips&trick posts (just search for continuous integration Android/XCode)  but there is no simple drop-in solution that can be used for smaller or bigger teams of developers.  

Flow addresses this need extensively by providing set of mobile-specific gradle plugins that provide build tasks that can be executed at any time on a project. This is a drop-in solution, that requires very little configuration and installation steps, most of which are fully automated. Even though we heavily use (it's awesome BTW!) Jenkins continuous integration server, we have not build our own Jenkins plugin and we have not used the existing Android/XCode plugins.  The main reason for it that we now how difficult and unstable at times mobile automated build can become, therefore we wanted to have the possibility of running the whole automated build manually by each developer. At any time after following very simple and basic prerequisites (basically downloading and installing gradle) any developer can run end-to-end build process and recreate all the automated steps that should be run on our continuous development server. Using plugins such as the Android Jenkins Emulator Plugin (very good one BTW) makes it very difficult to reproduce what the server is doing without actually running the server. Another reason is that we want to address also other continuous integration servers: such as Bamboo, Cruise Control,  TeamCity and others.

Mobile build enhancements

Mobile builds are very special, comparing to the server side builds. First of all, the tools that we got are pretty limited and tied to IDE in which you develop software. Unlike the server side development, Mobile apps have been developed in IDE's (XCode, Eclipse, MS Visual Studio) from the very beginning, and command line support is not really a first-class-citizen in this world. Therefore you cannot do much besides simply building the binary. Plugging-in the build process is possible, but usually it is very little documented (XCode) or very difficult and prone to changes between SDKs (Android's Ant build system) That does not sound like a lot, but there are a lot of enhancements that can be done in order to get much more from the builds and automate lots of operations that are needed in case of more advanced projects. Flow enables mobile application enhancements like:
  • Continuous-Integration ready basic project builds
  • prepare varianted builds - generated from the same code, variants of the application 
  • automated testing - unit testing and integration testing level supported
  • automated Apphance Service integration
  • automated Code Quality checks that helps with finding common bugs and keep consistent code
  • preparing automatically ready-to-use OTA deployment of your application
  • and more ...
 
Follow the trail further and go to Getting Started page to add Flow into your projects.

Comments