Last week our development team have been spending some ‘15% time’ bootlegging their own pet projects. We wanted this to be an opportunity to really road-test the platform for personal apps, and to add some more ambitious features to the platform that might have been on the ‘Someday, Maybe’ list, pushed to the side by our focussed fortnightly sprints.

Here’s a rundown of what lead engineers Connor, Tim and Antoine each chose for their own projects — and how they got on:

Antoine has been building an ambitious cloud simulator service for running and testing builds in the browser — without the need for the appropriate hardware. We’re looking at making this generally available if enough people are interested.

Would you pay $49 / month for access to this feature? Let us know. Here’s Antoine’s description:

If you’re developing for multiple platforms, you’re going to need a lot of hardware to test it out — this is something that cross-platform tools on their own don’t really solve. To reduce that upfront cost, I’m developing a way to run your applications in the cloud.

This would work alongside the existing options of running locally on your own devices or simulators: we’ll implement something like a ‘forge run cloud’ command to fire up the app in an emulator running through the browser, in the cloud.

At the moment I’m doing this by running OS X on a virtual machine, and I’ve written a chunk of software to launch the app, wrap, display and export it via VNC to the browser using noVNC – which means you can view an Android emulator from an iPad:

The difficulty is scaling enough server-side support, and overcoming the need for Mac hardware to back the iOS simulators. With a bit of tidying up though, I’m hoping we could implement this fairly soon.

Connor, back in London, has been working on other ways to make iOS development completely independent of Mac hardware:

At the moment you still can’t sign an iOS app on a Windows machine — which you need to do in order to run the app. So I’ve been working on a remote signing service for Windows and Linux machines which will sign the app and return it to the local machine to run:

When you run forge run ios on OS X, the app will build and then sign locally as normal. Now, on Windows and Linux, it will upload to our build service to sign the app and return it to the local machine. A key part of this is ensuring that your developer certificate is always safe: I’ve taken great care to ensure this is the case.

Another part of this is building the ability to run on iOS devices from non-Apple hardware, and log the output back to the terminal. There’s some tidying up to do to keep the build-and-run server calls as quick as possible, but this is a feature we should be able to implement with our next update.

Tim in our London office worked on building a simple Sokoban game from scratch, for Android, iOS and Windows Phone. Because Tim works on developing the Forge toolchain day-to-day, this was a good opportunity to really test them out as a user:

Building the app has been more about immersing myself in our user experience than building the end product — I wanted to really hit the rough spots and get a better idea of working end-to-end with the tools, particularly with some of the newer features.

I’ve deliberately worked on an app that would call on our more recent features. I’ve used native UI elements (like the native topbar), and in-app payments to unlock different worlds and levels within the game. So far, so good. There’s some UI issues to iron out, then I think some of the learnings from using the in-app payments system will fold into tweaks to the API and documentation.

If you have any suggestions of suitable projects to tackle on our next discretionary week — or thoughts on how we implement any of these — get in touch and let us know!