Forge 2.1: open-source modules and collaborative development

Today, we’re really excited to announce version 2.1 of’s mobile development platform: Forge.

This version is hugely significant for us, as it marks a shift towards a more open, collaborative development approach on the platform. As part of this, is open-sourcing the native modules that we’ve developed.

Since we launched our native modules feature at the end of July, we’ve been blown away by our users’ enthusiasm for adding new native functionality to your apps. Already, there have been over 1300 updates to the almost 400 modules our users have been working on, including modules for Urban Airship, Apptentive and keyboard customisation:

Three 3rd party modules

With version 2.1, we’re doubling down on native modules by making it super-simple to publish, consume and collaborate on native modules. Changes include:

  • ability to publish modules into the module index
  • introduce concept of module namespaces, which allows independent developers to collaborate on one codebase
  • dependency declaration and resolution between modules, so you can rely on a library being present without inlining it
  • add changelists and documentation for your module


We’ve wanted to open source our modules for a long time, but before now there hasn’t been much point because it would have been so hard for our users to take our code and set themselves up to develop on it.

With the changes described above, those restrictions are now gone, and we’re excited to announce that we are open-sourcing all of our own native modules under the 2-clause BSD license.

If you want to tweak the form or function of a native module (e.g. customising the gradient of our topbar module, or extending our file module to capture audio as well as video), you can clone our code from GitHub and make the changes you want in your own module.

You can keep that module un-published — meaning only you and your team-mates can use it — or you could publish the updated module so everyone benefits. Of course, we’ll always appreciate pull requests back to our repo so that we can update the original module when it makes sense!

Note that we’re not open-sourcing everything. Our cloud build service, toolchain, and the core of our platform will remain under wraps: this means you won’t be able to do local-only builds that don’t use our cloud build service. But we firmly believe that the huge usability, speed and collaboration benefits you get from using a cloud-based compiler easily make up for that.

How to get involved

If you’re an existing user, our v2.1 update is rolling out now and you’ll be prompted to update shortly. If you’re not at the stage of creating native modules just yet, note that v2.1 includes a small change to JavaScript behaviour documented in the release notes.

Otherwise, head across to our site to create an account, download our lightweight tooling, and get started on your first app.

The native module development process is covered in our documentation, and keep your eye on GitHub — we’ll be uploading and updating our module code there!

Trying your app on iOS 7

It seems iOS 7 will be released sometime in the next couple of weeks, so today, we're pleased to share with you a preview of how your app will look and feel on the new OS.

To run your app on iOS 7, you'll need a device with the latest beta build on it, or an OS X machine with the Xcode 5 preview installed.

Until iOS 7 and Xcode 5 are out of beta, you'll need to manually select the right platform and module versions for full iOS 7 support. What you need to do is:

  1. update your app to use platform version v2.0.1 (you can do this in the App configuration section of the Toolkit)
  2. if you're using any of these modules, update them to use version 2.1 (you can do this in the public modules configuration section of the Toolkit):
  3. iOS 7 requires some different icon and launch images sizes: see the configuration section for those modules for what's required
  4. restart your Toolkit to see 7.0 in the dropdown of available iOS simulator versions, if necessary
  5. if using the 7.0 simulator, you need to move Xcode 5 preview into the default Xcode install location, e.g. something like:
    • sudo mv /Applications/ /Applications/
    • sudo ln -s /Applications/ /Applications/

There are a few other iOS-specific updates we'll make to our modules over the next few weeks (in particular, enabling you to customise the behaviour and appearance of the status bar). In the meantime, if you find any problems with the updated platform or modules, get in touch!

New docs and search – switching away from Read The Docs

Last week we significantly revamped our docs and docs search. Which do you prefer, old or new?

As part of that switch, we migrated from away from Read The Docs to hosting them ourselves. Read The Docs is great but our requirements changed and we needed to move, and we think in the switch we’ve got a few immediate wins:

  • Unscientifically, our search function is much better, using elasticsearch rather than in-page JavaScript search
  • The look-and-feel of the docs is much more consistent with the rest of our web site
  • We made a couple of little macros to handle things like API method signatures – yes, Sphinx has these, but they’re tailored towards Python, not JavaScript, and we think our version is much better for our needs.


When we first launched our Forge development platform, our documentation needs were pretty straightforward.

At the time, we only supported browser extensions, had a fairly limited number of “modules” (standardised cross-platform APIs to native features), and we were working on 2-4 week release schedule.

Read the Docs was a great tool for us at that time. It handled versioning for us, it meant there was one less thing for us to have to think about deploying and serving, and we already wrote a bunch of internal documentation in ReST: we started throwing new documentation at it and were happy for a good year or so.

After a while, however, the cracks started to show. Our codebase became much more modular and our release cycle accelerated, meaning it became a headache to keep our documentation in sync with our platform… We had to keep the documentation in a separate open-source repository from our private platform so that Read the Docs could consume from it… Read the Docs versioning only seems (seemed?) to work with branches on a git repo, but all of our other repos were mercurial… Using Sphinx to generate HTML from the ReST does let you create decent-looking output very quickly, but gets quite cumbersome when you want to step outside the normal workflow (adding extensions and including pre-built HTML for example)…

Preparing for Trigger 2.0 – “It’s not you: it’s me”

When we started working on a native plugin system for our platform, we knew things had to change. “It’s not you: it’s me”, we said to Read the Docs, and started converting our own documentation to Markdown, using pandoc for a first pass, then lots of manual touch-ups.

The thing is, we want the plugins our customers are writing to be properly documented, so that they can be effectively shared and used between and among teams and users. But, we can’t expect everyone to grasp the vagaries of ReST syntax, and the implicit assumption that Read the Docs projects are monolithic and homogeneous wasn’t really holding for us any more.

However, the benefits of having full control over how our docs are stored, processed and delivered are yet to be fully realised. We’re looking forward to being able to easily give our users per-module, per-version documentation, to easily tweak the appearance of all the docs to track our website, and maybe even include runnable examples for API methods.

Of course, taking control over our documentation like this has taken some effort. The biggest pieces were probably the conversion from ReST to Markdown (although pandoc did accelerate that quite a bit), and the generation of the navbar on the left side of our docs pages. But, once we had those in place, the clean, semantic HTML output from Markdown instantly looked pretty good with our Bootstrap styling. Integration of elasticsearch via Haystack was straightforward, and deployment just becomes a case of putting some HTML files in the right place.

The level of maturity in those ancillary libraries and tools has reached a point where NIH-ing your own documentation system may make a lot of sense: it did for us!

What’s next?

As the list of native modules keeps growing we ‘ll split that out from the core docs. But other than that we expect the basic docs structure and the way we host it to be stable for a while to come.

We’re always trying to improve the content and make it easier to discover. So if you have suggestions or feedback, please do get in touch at We’d love to hear from you!

Work On What You Want Week #2

When you’re developing software it’s easy to fall into the habit of ploughing through the backlog to knock off the most-requested features and highest priority bugs, iteration after iteration, without setting aside time to explore and experiment our product and our service.

At, work on what you want week (wowyww) happens once a quarter: the idea is we give all our developers free rein to hack on anything they want, so long as it’s somewhat related to one of our products.

This time around, wowyww produced a tile-based game built on our Forge platform using canvas elements, an improved analytical backend to help us understand what parts of the platform our customers use most, and a custom sound generator built on our shiny new plugin system. Here, I’ll let the guys describe what they did and why.


What did I want to work on?

I wanted to push the limits of our Forge tools a little and see if it was possible to write a mobile game using Javascript and the Canvas element.

I’m a huge fan of simulation games such as SimCity so I came up with the idea of adapting a model from the book “The Limits To Growth” by
Meadows & Randers and creating a simple tile-based game around it.

Why did I want to work on that?

I’m a firm believer in the principle of “Eating your own dog food” and wanted to get a real feel for the behavior & performance of our tools when used in anger.

Getting to have a boatload of fun in the process was, of course, no small incentive!

What was the result at the end of the week?

No doubt I’m somewhat biased but my strongest impression of using Forge over the course of the week was how little time I spent thinking about Forge vs the amount of time I spent thinking about my code!

I used the Trigger Toolkit primarily to create the project, manage my app configuration and deploying to a physical device. For rebuilding my changes and testing them in an emulator I opted to use our Command-line Tools instead.

During development I also used Trigger Catalyst which provides a remote WebKit-style debugger. It’s an incredibly powerful tool but I found it could be a bit slow when your network connection is heavily loaded.

(Game graphics courtesy of the most excellent Danc’s Miraculously Flexible Game Prototyping Graphics for Small Worlds)

This was my first time writing a game for a mobile device instead of the desktop so I wasn’t sure what to expect.

While I knew writing Javascript would be orders of magnitude easier than a language such as Java or Objective-C I had concerns about the amount of effort required to coax realistic performance from HTML5/Canvas.

It therefore came as a welcome surprise to find that I could populate a 2048×2048 pixel canvas with over a thousand bitmap tiles to create a smoothly scrollable game world without applying even the simplest of optimizations to my code.

Overall I found mobile gaming performance to be bounded more by the memory constraints of the device rather than Javascript execution speed or rendering performance. A nice constraint to have indeed!


What did I want to work on?

I wanted to try out our new native plugins from the perspective of a user. I wanted to make something fun that couldn’t be done without native code, so I decided to make a plugin to generate silly noises based on user input.

Why did I want to work on that?

Seeing things from the perspective of the user is a good way for us to find out if we’re doing things that make sense: this is especially important in a large project (like native plugins) where we have had to make a number of decisions and assumptions about how users will want to work.

Acting as a user allowed me to see what worked well and what could be improved, and doing this while we are still developing native plugins means this feedback can be quickly applied in our development iterations.

It also provided a chance to check our documentation made sense and to create a more detailed example of what a complete plugin looks like, rather than just the very basic example code we include with the inspector projects used to develop native plugins.

What was the result at the end of the week?

First I created a plugin working on both Android and iOS that can start, stop and change the properties of a continuously generated noise. The start and stop events are hooked up to touchstart and touchend events, and changing the noise to touchmove in Javascript.

The result is an app that when touched makes noise that the user can control:

Native Plugins for Forge: a simple sound generator.

This sort of feature could be really useful when creating a game or other fun apps, and it demonstrates the power of native plugins and how you can go about coding them.

All of the source is available on GitHub:


What did I want to work on?

Analytics on the config.json files submitted by our users when creating apps with our cloud build service. Users use the config.json file to specify what version of the Forge platform they want to use in their app, as well as which modules they need and various other metadata.

Why did I want to work on that?

The Forge platform (both the native code and JavaScript code) are being developed at a rapid pace by the team at, so we wanted a better way to keep track of what parts of our platform people are using.

This will hopefully lead to better insights as to what features our users really value in the platform, and generally help us keep track of the uptake of new versions of the platform, which lets us deprecate older versions at a pace which doesn’t inconvenience anyone.

What was the result at the end of the week?

The analytics are live and we’re now able to get a better idea about what people are requesting from the Forge build service, in terms of both platform versions and modules.

Most people seem to stay up to date with the Forge platform by sticking with the latest major version (currently v1.4), which always refers to the latest deployed code in the 1.4.x series.

On the left we can see the most used modules: request, logging and reload are among the most popular.

Now that we have a system in place for collecting these basic analytics from the build service, we should be able to measure more statistics on builds without too much work!

Webinar: learn how to build and package for iOS devices

Join James Brady, CTO and the team next Wednesday for our second webinar back by popular demand!

This webinar is available to customers on our paid plans: sign up for a paid plan starting from a LIMITED-TIME OFFER of $19 for Go Iterate. This offer will be discontinued next week and the $19 rate will only be available with a year up-front payment after that.

How to setup provisioning profiles and certificates for building and packaging for iOS

Join us for a Webinar on October 10

Space is limited. Reserve your Webinar seat now at:

Details co-founder and CTO, James Brady, demonstrates how to setup your Apple developer center and environment for building for iOS and packaging for App Store submission.

Title: Webinar: how to setup provisioning profiles and certificates for building and packaging for iOS
Date: Wednesday, October 10, 2012
Time: 10:00 AM – 10:45 AM PDT

After registering you will receive a confirmation email containing information about joining the Webinar.

System Requirements

PC-based attendees
Required: Windows® 7, Vista, XP or 2003 Server

Macintosh®-based attendees
Required: Mac OS® X 10.5 or newer
Mobile attendees
Required: iPhone®/iPad®/Android™ smartphone or tablet

Enterprise Mobile Iteration: come see the team at Dreamforce ’12

The team has been busy getting our platform ready for enterprise and with our integration with the Salesforce Touch Platform, we’re there!

Come visit our booth at Dreamforce ’12 to learn how to build and iterate enterprise mobile apps fast:

We’re based in the Touch Stadium / developer center in Moscone West. You can come and meet the founders there and watch our CTO James demo at 3:45 on Wednesday.

Announcing the white paper: the real deal on native + HTML5

It’s a busy week on the blog: today we’re pleased to be announcing the online publication of the white paper.

We’ve written this as a tight, 23-page overview of the mobile development landscape, HTML5 opportunity and how our product fits into it.

With the app market still exploding, and so many routes to entry – different platforms, different languages, different cross-platform frameworks – accessing that $15bn market isn’t as straightforward as it should be. Our platform is all about making it as simple as possible to build native apps and to access that market: and our white paper is an extension of that mission.

You can download and read the paper here.

And whilst I recently wrote a more technically-focused post on how developers can make sense of mobile development platforms, we want the white paper to explain the context of what is happening in the industry to a general audience, and help developers lobby the company-internal case for our platform. We hope it’s particularly helpful within companies facing the need to build for mobile but finding the landscape confusing.

We’ve filled it with facts, but it’s opinionated too: we make the case for as the single best solution out there.

Here’s a quick overview of the main chapters within:

The industry landscape

To start, we address the growth of mobile apps and touch on the need for businesses to build a platform-agnostic presence on mobile and on the web (closing their viral loops).

Considerations for developers

How to go about building for that need isn’t straightforward, and section two addresses some of the considerations developers face in choosing a route through the mobile programming landscape. Which platform, language and app market is worth investing in? How do cross-platform frameworks fit in?

The HTML5 opportunity

Section three unpacks and explains the strengths of HTML5 and cross-platform apps, from how they work to how to best take advantage of community tools and libraries to build the best hybrid apps possible – the best of both worlds.

HTML5 fact and fiction

HTML5 hybrid apps aren’t going to suit graphically-intense applications and games: some kinds of app are going to be better served by native builds (a false dichotomy which refuses to die). At the same time, with HTML5 standards and browser tech improving so rapidly, a lot of lazy prejudice is already outdated: here we survey some of the potential hurdles of working with HTML5, and offer some solutions for dealing with speed and native look and feel, using third-party libraries and other tips and tricks.

The paper also includes a couple of case studies of good cross-platform practise, and a high-level untechnical run-through of how to build your first Forge app, from concept to app store. We hope it encourages you to dive in and give it a go.

Here’s the link again. This will be a living document that we’ll regularly update to reflect the evolution of our platform, and the evolution of the industry. Comments? Feedback? Typos? Let us know.

Making sense of Mobile Development Platforms

Mobile development platforms are so hot right now that even video ad networks want to launch one. “App cloud” is to 2012 what “pet food” was to 1998.


Firstly, mobile app development is exploding – Gartner said app store revenue would reach $15Bn in 2011 – because consumer attention on mobile devices is shifting to apps, away from the web.

But mobile app development is hard because you need to know all sorts of different languages: Objective-C for iPhone / iPad, Java for Android. And any serious app needs a remote data-store so you get into the business of provisioning servers and write Ruby, PHP or Python.

So mobile apps are a big deal, but technically complex. That’s why development platforms are springing up to help developers build them. But how can we make sense of them all? Here’s one attempt:

Mobile Development Platforms, made unnecessarily complex

Kudos to Kinvey and RWW for making this attempt and this graphic does in fact contain all the top mobile platform companies. But unfortunately, this doesn’t really help a developer trying to decide what they need, much like London Underground maps makes little sense to foreigners.

The Simple VersionTM

So let’s really boil this down to make it simple. Basically, to create a mobile app, you need some code that runs on the server-side (the cloud) and some on the device.

Ok, let’s talk about the cloud bubble.

The back-end is all about aaS

The simplest server-side (aka back-end) is where you don’t actually have to write any code – instead you call some remote API that provides the service using code someone else has written. This is a BaaS – a backend-as-a-service – and examples are Parse, StackMob or MongoHQ for data-store, Pusher for notifications.

They are the top level in the server-side stack and provide the maximum ease for developers. They often provide an iOS or Android SDK so you don’t even need to deal with the mechanics of calling their server-side APIs directly with an http request.

But if they don’t provide the exact features you need so you want more flexibility, then you have to go lower in the stack and write some code to handle your server-side logic.

At this point you decide whether you want to customize a Rails or Django setup, or if you just want to write Ruby and Python and be done with it.

In the former case, you’ll want to provision a server on Amazon’s EC2 (Infrastructure-as-a-Service) and start installing software. In the latter case, you don’t need to. You can just use a Platform-as-a-Service, like Heroku or Google App Engine, that provides a Rails or Django runtime out of the box.

The client-side is native, or HTML5, or something in between

The code you write on the client-side is going to be deployed to a device that is going to be running an Operating System such as iOS or Android.

To create your app you have 4 different approaches to choose from:

1) Pure native

(top-left box)

This is where you write Objective-C on iOS and Java on Android. The upside is that you can use the full-power of the device and have the maximum flexibility in how your app works. The downside is that you need to create and maintain multiple codebases if you want to support multiple platforms. And, if you’re a web developer, you need to learn new, strange languages that need you to get yourself setup to compile.

2) HTML5

(top-right box)

Instead of writing a mobile-specific app, you could just create a website using HTML, CSS and JavaScript and just make sure it looks good in mobile browsers.

There advantages of this approach are that you can use standard web dev technologies and only need create / maintain a single codebase. Also you can use a whole bunch of JavaScript and CSS libraries such as jQuery Mobile, Sencha Touch, HTML5 Boilerplate etc. Awesome!

But there are serious downsides:

  • You can’t get distribution in the App Store and Android Marketplace
  • You can’t use powerful device features such as the camera and notification center
  • Your user-interface will probably look website-like and not app-like
  • Users will have to remember to navigate to your website in their mobile browser (a pain to type in the url) rather than just having a nice app icon on their homepage

Those disadvantages are show-stoppers because consumer attention on mobile is moving to apps away from websites.

3) Hybrid

(top-middle box)

Hybrid apps use a combination of native and HTML5 to reduce the trade-offs between them. Typically a hybrid app consists of HTML5 code running inside a provided a native Webview component (like a mini web browser) with all the advantages of (2). But there are two native elements also:

Firstly, there is some kind of ‘native wrapper’ which lets you distribute your HTML5 code as if it were a native app, so you can get distribution in the App Store and Android Marketplace.

Secondly, there is a ‘native bridge’ which allows you to access native features such the camera and notification center, but still writing your code in JavaScript rather than native languages.

Some hybrid development frameworks even let you write your own native code if you really want to, sitting side-by-side with your HTML5 code so you can mix and match as you like. Examples of development platforms for hybrid apps are PhoneGap, Appcelerator and Sencha Touch 2.

Great right? However, there are still downsides:

Complex development process:

To get the best of both HTML5 and native, some frameworks need to sacrifice the simplicity of the development process.

For example, with Appcelerator, you need to use their own IDE. And to use PhoneGap’s open-source native wrappers, you need to set yourself up for local compiles in Eclipse or XCode.

If you use a cloud build service, such as PhoneGap Build, you save yourself from needing a particular IDE or setting up for local compiles. But instead you need to zip up your code and upload it into a web form and wait several minutes while your native apps are queued and built, then download them from the web ready to test.

Not a great build / test cycle if you’re used to updating your HTML and JavaScript, hitting refresh and immediately seeing the results.

Bad UI:

Users can tell the difference between an HTML5 app and a native app, and the latter are inevitably better.

Frameworks like Appcelerator accept this reality and give you a true native UI even if the development process sucks. With Sencha and PhoneGap you’re left to make your HTML5 look like native, which can come close with a lot of effort, but can never quite be as good

That’s why you should go with

4) Awesome Hybrid by

(big box in the middle)

These problems with existing client-side hybrid frameworks are why we founded We provide both a super simple development process and genuine native UI components. We’re the only mobile platform that provides this, and judging by our growth and the quotes we’ve published on our homepage, developers like it.

The reason we can do that is we run a cloud build service so you don’t have to setup your machine for local compiles but we can still add genuine native features. And we’ve been smart about building it so incremental builds take < 2 seconds, making for a very nice development flow.

Check out our screencast, or judge it for yourself by signing up for free now.


We hope this has helped you make sense of mobile platforms being able to categorize them as making the server-side or client-side part easier, and then breaking them down further within those categories.

Questions? Thoughts? We’d love to hear from you at and hope this inspired you to try our hybrid app development.

How to build hybrid mobile apps combining native UI components with HTML5

Last week we showed a screencast of Forge in action, this week we’ll explain how you can use a native top bar and native tab bar along with your HTML / CSS and JavaScript in a hybrid app created with

We’ll add more native UI components in the future, but here’s how you can get started creating a beautiful, responsive mobile apps for iOS and Android using just web technologies.















These are screenshots of a simple recipe app that we created using the Forge native UI components, and we’ll explain how we built it. Along the way we’ll show you how to:

  • Configure Forge to add native top bar and tab bar elements to your app
  • Style the native elements
  • Add listeners to and control the native elements from JavaScript

Please feel free to base your own projects on this – it’s a great springboard for a new project! The code is hosted on github here:

Create your app and add a top bar

You’ll need to use the Forge framework to be able to get native UI components using only web technologies. Get started by signing-up. There’s complete documentation on how to get setup and once you’ve done that just run:

You’ll be prompted for the app name and once the command completes, you’ll be setup with the code for a ‘Hello World’ app in the src subdirectory. Let’s start by adding a native top bar and testing that in the Android emulator.

Replace your existing src/config.json with this:

Enabling the topbar is as simple as setting: “topbar”: true in the modules configuration. Let’s also clean-up index.html until we’re ready to customize it:

Hello world!

You can then run and test the app so far using the following forge commands:

Any problems at this point? Check out our FAQ, ask the community on StackOverflow or contact

Configuring a tab bar

Great! It turns out that adding the tab bar at the bottom is just as easy – you simply enable the module by adding “tabbar”: true to the src/config.json:

But before that will look good and behave well we need to add some buttons and listeners so we can execute JavaScript to handle the page transitions when you click on each tab. To do that, let’s add a JavaScript file called src/js/main.js:

Here we’ve using the forge.topbbar.setTitle API call to alter the title at the top, and then used forge.tabbar.addButton to configure the tab bar buttons including adding a listener to execute JavaScript when they are pressed. We reference this file from src/index.html:

Hello world!

You can find the images referenced in src/js/main.js in the example code in Github. You’ll also need to copy those across to your src/img directory. Now if we build and test (this time on iOS), we see this:

Creating list views and controlling navigation

Ok, now we have the native UI elements in place, we need to create our list view and connect up the tabs so they trigger transitions. We’ll use the lightweight zepto.js library to help us handle the DOM manipulation. We’ve blogged before on how to create fast HTML5 mobile apps using zepto.js and backbone.js. We’ll create the recipe list using HTML / CSS / JavaScript in the main part of the view since it’s simple to create good-looking lists this way. First, let’s embed the recipe data and the zepto.js library. You can do that by downloading data.js and zepto.js from the example in Githuband putting them in your src/js directory. Then we update the updateRecipe function in src/js/main.js – this is called when a tab bar button is pressed:

Now to complete the app, all we need to do is add some simple styling to the list and reference the JavaScript files in src/index.html:

That’s it

You should now be able to build and test the app to look like the screenshots at the top of this post. As an optional extra, you can also explore different styling for the topbar and tabbar by trying out the following API calls:

So now you can create rich hybrid apps, using real native UI components using! Let us know your feedback and how you get on.

Any problems at any point? Check out our FAQask the community on StackOverflow or contact

How Forge works and why we’re proud of it

We think a lot about how to make the process of creating mobile apps using our Forge framework easier. The result of that is it takes just 3 commands to create a build and run it in a simulator, and it takes seconds to get started:

> forge create

> forge build

> forge run ios

There’s a lot of heavy lifting that goes on behind the scenes to make it that simple, and one unique aspect of our Forge framework is how our build service compiles our customers’ apps – by splitting the build between local tools and a remote server. The approach keeps users’ local development environments as simple and platform-agnostic as possible, and allows our servers to run multiple platform compiles in parallel to deliver the builds faster.

End result: the normal development cycle is orders of magnitude faster than it is with other solutions, with builds taking seconds at the command-line rather than minutes to compile or requiring you to zip up and upload code through a web interface.

Here’s a run-down of how Forge builds work behind the curtain.

The app creation process

Once you’ve signed up to Trigger, the first thing you’ll do is download our Python build tools, which you’ll set up locally at the command line. (The build tools are completely open source, and you can find them on Github here.)

With these, you set up your basic app architecture. Running forge create, you’ll check in with our primary server to verify your account, and create a unique ID for your app. The local tools then set up a directory structure on your local filesystem, which will be the basic scaffolding for your app: within that structure you can place all your HTML, CSS and JavaScript files, and configure your options and features in the
config.json file.

The clever part comes when you run your first build:

On executing the build, Forge will (1) take the contents of your config file and fire it off to our server – we run Django and nginx, all hosted on EC2. Receiving the build request, our server matches your ID and config.json contents up against your account credentials to determine which platforms need to be built, and then compiles a template app for each of the given platforms – creating a specific template that will reflect the features you’ve enabled and disabled in the config.

Template wrapped apps will vary platform to platform: most browser add-ons don’t need to be compiled (it’s just a matter of organising JavaScript into place), but for Android we’ll compile the Java and for the iOS we’ll compile the Objective-C. Of course, we can’t do all those builds with the same back-end build servers (and you wouldn’t want to): you need to run iOS builds on a Mac, and so on.

On our end, the build is then (2) farmed out to separate build servers: both to run the compile with the appropriate back-end hardware, and so that builds can run in parallel and so return  much faster. Speeding up template creation is an ongoing goal for us: we have recently had good performance gains by creating a caching minification service to avoid JVM startup lag, and we’re trialling the use of RAM disks to cut down our I/O times.

(3) The template apps are returned to your machine, along with build instructions that dictate to the local build tools how to complete the final stages of the build locally. At this stage, the “Your code” green hatched section is effectively empty.

Structure of a Forge template app

(4) The contents of the src directory – your HTML, CSS andJavaScript – will be injected into the “Your code” green hatched section of the app, and various packaging and signing processes run to complete the build.

Advantages of local / remote hybrid build approach

By compiling on the server, we save the user from setting themselves up locally for compiling for different platforms. We take on all that complexity, which means we don’t dictate what you need to write and work on your apps – whether that’s in TextMate, WebStorm, Eclipse, XCode, Aptana, whatever. Our framework remains platform-agnostic, and just a text editor and command line will do.

Once the first build has been run there is no need to run the whole build again after making changes to the HTML, CSS and JavaScript. When you haven’t enabled or disabled any major features or functionality in the config file, you can re-inject with the local build tools. This cuts down the time to get your code running on a device from minutes to seconds.

By returning instructions for the final stage of the build to your local tools (rather than encoding them permanently in the tools), we ensure that there are as few as possible version clashes between your build tools and the Forge platform level you’re building against. We’ve already pushed out dozens of fixes and improvements to the Forge platform which take advantage of this loose coupling to avoid imposing constant build tool updates upon our customers.

Testing and CI

All this shifts much of the complexity to our back-end, with lots of moving parts to be kept in check. Whenever we release a new API, it’s a challenge to ensure changes don’t break functionality across platforms and devices. Unit testing is extremely important to us. Every time we make a change, we trigger off all our automatic tests with our unit test suite to look for problems. We do this continuous integration testing using a custom test aggregation
service (which we keep meaning to integrate with our Hudson setup…):

Internal Forge continuous integration dashboard

We also run interactivity tests based on the excellent QUnit JavaScript testing framework: these tests target the Forge features which are awkward to test automatically – buttons in the browser window, statusbar notifications, etc…

Lastly, we run Node.js-based end-to-end system tests before pushing new code out to the platform – to check that apps that have already been published through our platform will continue to function just the same after pushing the update.

Final word

All this to say that we’re proud of our back-end build system, and hope you see the value in the way we approach it. It offers our customers faster builds, less hassle, and let’s them push out streamlined, unbloated apps from unbloated environments. Interested? Give us a try.