New feature roundup: native confirm, loader and Android toasts UI, audio playback and new foreground camera module

You asked for more native UIs and we’ve delivered!

On top of that we’ve expanded on our native APIs by enhancing the media module for audio playback and adding a new foreground camera module for use with older Android versions where the file.getImage API doesn’t suffice.

We’ve had a much broader range of APIs in our core product than other hybrid platforms for a while – it’s not just about native features, but also UI components and cloud SDK integrations, as you can see from our features summary.

Here are the details:

Native confirm, loader and toast UIs

 

Available on both iOS and Android, we’ve added new native UI components in the notification module.

You can show and hide a native loader using forge.notification.showLoading and forge.notification.hideLoading:

forge.notification.showLoading("Please wait", "Video is loading...", function() {
    //Success callback
}, function() {
    //Error callback
});

You can prompt the user for confirmation using a customizable confirm UI with forge.notification.confirm:

forge.notification.confirm("Confirm your action", "Are you sure you to delete this item?", "Yes", "No",
    function (userClickedYes) {
      if (userClickedYes) {
        // ... implement logic for when user clicked "Y"
      } else {
        // ... implement logic for when user clicked "N"
      }
});

“Toasts” are small temporary popups which are great for giving your user unobtrusive feedback as they use your app. We’re pleased to now offer a toast API for Android and iOS: forge.notification.toast.

These features make it easier than ever to make your Trigger.io look and feel native since you can use actual native UI components rather than working on mimicking them in HTML5.

Audio playback

Our media module has had a native video playback API for a while.

And although it’s possible to achieve audio playback using HTML5 <audio> or <video> tags we’ve had many requests for more control over the audio player than HTML5 on its own can offer. So we’ve introduced native audio player controls with the forge.media.createAudioPlayer API.

forge.file.getLocal("music.mp3", function (file) {
  forge.media.createAudioPlayer(file, function (player) {
    player.play();
  });
});

As well as the basic “play” method, the audio player has the usual “stop” and “pause” controls plus APIs to get the “duration”, “seek” a particular position in the track and listen for playback position changes with “positionChanged.addListener”.

Foreground camera module

Older Android versions can struggle with the memory requirements of the forge.file.getImage API which provides native camera access. To handle that, we’ve added a new foreground camera module to be used on Android only.

Unlike the file module this module displays the camera as part of your app. Although this means that the user will not have the option to select an image from the gallery, or perform advanced options such as zooming or changing other camera settings, on low memory devices this is a more reliable method of capturing a photo – it tends to be snappier too!

What’s next?

Follow us on Twitter or Facebook to see our latest news and updates.

Sign up now to take advantage of these new features or get in touch with us at anytime at support@trigger.io.

Webinar: learn how to build native plugins for Android

Join James Brady, Trigger.io CTO on Tuesday, May 14 at 10am (Pacific time) for our second webinar covering native plugins. This webinar is open to all Trigger.io customers and free trial users.

Build native plugins for Android

Join us for a Webinar on May 14

Space is limited. Reserve your Webinar seat now at:
https://www1.gotomeeting.com/register/854875241

Details

Trigger.io co-founder and CTO, James Brady, demonstrates how to get started building a native plugin for Android.

There will be an opportunity to ask questions about your specific app, and the best one will earn the asker an exclusive Trigger.io t-shirt!

Title: Trigger.io Webinar: build native plugins for Android
Date: Tuesday, May 14, 2013
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

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.

Background

When we first launched our Trigger.io 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 support@trigger.io. We’d love to hear from you!

Trigger.io named to Facebook’s Technology Partners Program

Social features in your mobile app have never been easier with Trigger.io

We’re excited to announce that Trigger.io has been named to Facebook’s Technology Partners Program.

See the integration in action with this short screencast showing how fast you can get started with our demo app and tutorial:

Trigger.io makes it simple to create amazing mobile apps using the best of HTML5 and native. You write your code in the JavaScript using our APIs and can build native apps for iOS and Android in seconds. Sign-up now to try it for yourself.

We’ve integrated the Facebook SDKs for iOS and Android into Trigger.io so you can now access native Facebook SDK features through our JavaScript API. Check out the Facebook module documentation.

When it comes to social and sharing, Facebook is a ‘must have’ for your mobile app.,

Customers are already using it – check out PumpUp

Many of our customers such as PumpUp are already taking advantage of the integration.

PumpUp is a new mobile app that provides you with personalized workout sessions based on your fitness and goals. Check it out in the App Store.

They’ve used our integration with Facebook to handle user login, and let users publish their workouts to their stream to get motivated. Here’s what the co-founder of PumpUp said about Trigger.io and the integration with the Facebook SDK:

Trigger made it dead simple for us to integrate with the native Facebook SDK and implement push notifications as well. Their Reload feature also lets us push test builds to my debug users as well as do A/B testing with live users. I can’t believe how much Trigger has accelerated our development — we’d be nowhere near where we are today without it! I’d recommend Trigger as the superior alternative ”

How to get started with our demo app

We’ve created a simple demo app to get you started – you can see it in action in the screencast above and the code is here.

Simply follow the instructions in the README to start building. It explains the simple steps to setup Trigger.io and the Facebook configuration to get started.

Dive into the code to see how you can use the Trigger.io Forge API to interact with the native topbar UI element and get fine geolocation using GPS:

forge.topbar.show();
forge.topbar.setTitle('Scrumptious');
forge.geolocation.getCurrentPosition( {
  enableHighAccuracy: true
}, function(location) {

});

 

And see how simple it is to enable Login with Facebook and Open Graph calls:

forge.facebook.authorize(['publish_actions'], function(token_information) {
  logResponse(token_information);
  window.location.hash = '#menu';
});

 

forge.facebook.api("/me/trigger-scrumptious:eat",
  "POST",
  params,
  function (response) {
    logResponse(response);
    if (!response || response.error) {
      errorHandler(response.error);
    } else {
      handleOGSuccess(response);
    }
  }
});

 

What’s next

If you’re building mobile apps incorporating social features, we’d love to hear from you – get in touch with us at support@trigger.io and sign-up to get started now.

With the Technology Partners Program, Facebook is committed to providing the best tools for you to be successful building social apps and we’re delighted to partner with them for mobile.

Expect more integrations and tutorials down the line showing how you can use Trigger.io’s tools in conjunction with Facebook and other cloud services

One year on: the numbers, the product, the future

We launched our Forge platform in January last year. We’re immensely proud of it. Nevertheless, many things have changed since then as we’ve iterated fast with new releases week after week.

Our goal is the same: to provide web developers with the best framework for developing mobile apps across multiple platforms.

There’s a huge shift to mobile underway right now and we’re really only at the start. Ranking #1 for a search for “phonegap done right” and #4 for “mobile development platform” with our article on how to understand mobile platforms we want to enable web developers to make the transition with helpful content as well as our platform.

If you haven’t already check out Trigger.io Forge to see how it can accelerate your app plans by letting you re-use your HTML / CSS / JS skills and code for your mobile apps for iPhone, iPad, Android or mobile web.

The numbers

It’s been a while since I updated you on our build stats – you can see how they looked last summer. Compare that to now:

We’re pretty happy with that strong growth – 10x since March last year. More developers are more engaged than ever in our platform – you can see examples of what they’ve created on our site.

Our customers range from companies building apps for themselves, through contract web developers and studios to product companies that are building many templated apps for industry verticals.

The product

With a stable core team of developers, we’ve been getting more and more productive at responding to your feedback and improving our product. At launch we were confident that our build / test cycle was far faster and simpler than the main hybrid app alternatives – PhoneGap and Appcelerator.

With the improvements we’ve made over the year, we’re now not only confident that our platform is the fastest and simplest to develop with, but it also allows you to achieve the best results. Basically it is the best mobile app platform out there. Don’t take our word for it, try it for yourself.

Reload

A huge part of that is Reload – the ability to push updates to your app contents and logic without needing to resubmit to the App Store.

We kicked off this feature during our away trip in Barcelona, and since launching it’s become one of the main reasons devs choose Trigger.io.

This is a unique feature amongst mobile platforms. It’s not possible to download and execute remote code with natively developed apps. Other hybrid mobile platforms let you reference remote HTML / CSS / JS but that doesn’t help if the user is offline and you’d have to write your own caching and synching logic.

Reload productizes all of that and gives you both offline performance and fast updates when network is available.

Native UI components

Using pure HTML5 for your front-end and Forge APIs to access native features is great for many cases, especially with emerging UI libraries like Lungo making this simpler than ever when used with Trigger.io.

But on mobile there’s sometimes no good substitute for real native UI. Can you have the best of both worlds? We think so and we have made native UI components available starting with the native topbar and tabbar:

Still no need to code Java or Objective-C to use those with Trigger.io Forge, it’s all controlled from JavaScript!

We continued with native alert and confirm dialogs, including Android toasts, in our notification module and native date / time pickers. More are on their way.

Standalone build API

For our customers who build large numbers of apps, sometimes based off common templates, having a slick update process and native UI isn’t enough: automation is a must.

You wanted to be able automate your builds, testing, parameterize your apps, and even let your end-users create their own apps on your site.

To deliver the best mobile platform for these requirements we launched a standalone build API so you can automatically trigger builds directly without going through our Toolkit.

We didn’t stop there – pre and post build hooks together with our parameters module enable further automation.

Native plugins

While our customer value the ability to build native apps without needing to write native code, some of the time there’s no option but to drop down into native code to get that last 10% of differentiation, quality and functionality.

To that end we’ve made the platform plug-able and launched our native plugins beta last year.

Plugin development is now enabled by default on all of our plans and we expect to take the ‘beta’ label off soon.

What’s next?

In summary: Trigger 2.0!

Breadth of APIs is our #1 priority right now so you can access a wide variety of device features to differentiate your app. To that end we went to Berlin on an away trip in February and hammered out a major set of changes to enable that. You’ll see the results of that work in the product soon.

Don’t worry though – we’re concerned about backwards compatibility and Trigger 2.0 is not a re-write or pivot, it will build on the existing product. Some of our customers have called Trigger.io “PhoneGap done right”. We hope you’ll be able to think of Trigger 2.0 as “Trigger.io as we know it, but now even more awesome”.

As always stay in touch with us at support@trigger.io, we’re eager to hear from you.

Build content-rich mobile apps with Trigger.io and the Rackspace Open Cloud

We’re excited to announce a partnership with Rackspace to make building content-rich mobile apps simple in the Open Cloud.

 

Read more about Rackspace’s mobile developer ecosystem launch today. We’re delighted to be part of it.

Building mobile apps, which include large photo and video content, but still perform and download fast is usually challenging. But by integrating Trigger.io Reload and Rackspace Cloud Files, it’s possible to achieve fast performance by storing media locally within the app, while also allowing fast updates from the cloud.

Learn the technical details of the integration in our docs, and see it in action with our demo app in this screencast:

Challenges of large content in mobile apps

The initial user experience is so important to attract and retain users for your mobile app. But to keep their attention you also need to provide fresh new content all the time.

This means you have to overcome the following challenges to build a great content-rich mobile app. Your app must:

  • Be small to allow for fast download onto the device
  • Have content local to the app for fast performance and a great offline experience
  • Be able to access new content to keep the user engaged

Achieving all three requirements at the same time is challenging. You must package some content locally while also having a mechanism to pull down new, remotely hosted content in the background.

Using Trigger.io Reload with Rackspace Cloud Files

You can overcome the challenges of using large content in mobile apps by using Trigger.io Reload with Rackspace Cloud Files.

Rackspace Cloud Files provides a scalable, high-performance CDN that’s perfect for your web apps, and now, with the integration with Trigger.io Reload, ideal for your mobile apps as well. Trigger.io Reload makes it simple to update the content of your mobile app in the background.

You can see how to use the two together in our docs. Sign-up for Trigger.io and the Rackspace Open Cloud now to follow along yourself.

What’s next?

Expect more integrations and tutorials down the line showing how you can use Trigger.io’s tools in conjunction with Rackspace’s cloud service to create amazing mobile apps using the best of HTML5 and native.

Rackspace is committed to supporting mobile app development by providing open hybrid cloud services in all categories so we’re delighted to announce this initial integration and partnership.

If you’re building content–rich mobile apps, we’d love to hear from you, get in touch with us at support@trigger.io and sign-up to get started now.

Getting mobile app builds to your customers

It’s good practice to send builds to your customers or test users early and often. But what are the best ways to do that?

Here we outline the main options and our recommendations, especially focusing on iPhone and iPad apps where the process can be a lot trickier than Android.

Our customers value the simplicity with which they can build native mobile apps using their web skills with Trigger.io. So we’re happy to say that there is a very simple option and we’re delighted to work with Kickfolio for online app previews.

Let’s go through the main options we see developers on our platform using. Do email us as you try these with Trigger.io to build and distribute your app. We’d love to hear your feedback.

The main options for iOS

In order of simplicity we’d recommend you consider the following options to get app builds to your customers:

  • Kickfolio for a browser-based iPhone Simulator with your app installed
  • TestFlight  to let test users and your customers install on their own device
  • Wireless distribution of your app outside of iTunes to your select audience

Each option has its benefits and drawbacks depending on exactly what you need.

Trigger.io does support wireless distribution – that’s probably the most flexible option but also the most complex (and possibly expensive) to set up. You’ll need to buy the iOS Developer Enterprise Program if you want to distribute to more than 100 users. If you don’t need that many then TestFlight is easier to setup than doing it manually.

But once you’re setup, that method does allow you to make your app available to a private audience with a really simple install mechanism for them where they can click through an email link to a download web-page and install your app from there. Email us if you’re considering it.

Let’s go through Kickfolio and TestFlight in more detail:

Using Kickfolio

Kickfolio is by far the simplest option. If all you need is for your client to be able to quickly try out an app build in a simulator to see your progress or provide feedback, this is going to be the best method.

It’s ideal for sending builds early and often in your development cycle when you’re still ironing out the user flows – best to get them in front of customers early for feedback rather than finding out that something fundamental is wrong when you thought the project is nearly done!

This is the process for using Kickfolio to show a Trigger.io app build to a customer:

  1. Use the Trigger.io Toolkit or command-line tools to build your app and run it on your own iPhone Simulator.

    On Windows or Linux simply create the build with our ‘forge build ios’ without running it.

    Sign-up for Trigger.io and follow the get started docs if you haven’t already.

  2. Sign-up for Kickfolio and upload your build.

    Your build is created at ‘development/ios/simulator-ios.app’ inside your app directory.

    Zip it up using a command like ‘zip my-app.zip –r simulator-ios.app’ and then click ‘Upload New Version’ from your Kickfolio dashboard.

  3. …. Actually there’s no more steps, it’s that simple. You’ll now have a preview link that you can email to your customers where there’ll see a browser-based interactive demo like this:

  4. It’s cool technology – your customer can have their own iPhone Simulator in the browser where they can try out your app and with no need for them to have flash installed.

Give it a try now by signing up for Kickfolio.

Using TestFlight

When you’re at the point that you need clients or test users to rigorously test the app out on their own device then TestFlight is the way to go. It helps you manage the process of ‘ad-hoc’ distribution and managing your users’ feedback.

It’ll require a more setup from you, and several steps from the person trying to install the app which can result in frustration if not done right. But it’s a necessary step when you’re at the user-acceptance testing stage and to try out features that are tricky to see in action in a simulator, such as fine geolocation or real barcode scanning.

Here’s an outline of the process you should follow:

  1. Create your TestFlight project and invite your customers or test users

    Click ‘Invite People’ from your project dashboard

    They’ll get an email inviting them to your TestFlight project and have them setup their device to prepare it to be able to install your build. They will need to open up the invite email on their device and click to install the TestFlight app.

    This process will end up with them appearing as a team member in your TestFlight project and you being able to see their device UUID there.

  2. Setup your Apple App Id, Certificate and Provisioning Profile

    You do this in the Apple Provisioning Portal. The Apple Developer Center has good documentation on this process.

    The important thing is to add all your test users’ devices in that tab. You can add up to 100 devices with a normal developer account. Any more you’ll  need an enterprise account.

    When you come to create the provisioning profile you’ll want to select the ‘Ad Hoc’ distribution provisioning profile type, and make sure to associate it with all the devices you just configured.

  3. Package your iOS app with the Trigger.io Toolkit or command-line tools

    You’ll need to download the certificate and provisioning profile you just  created and use the package command in the Trigger.io tooling:

    forge package ios
        --ios.profile.provisioning_profile ad_hoc.mobileprovision
    

    You can do that at the command-line or the Trigger.io Toolkit UI with detailed instructions here.

  4. Upload the build to TestFlight

    From your TestFlight dashboard you can now upload the app package which is a .ipa file in the release/ios subdirectory inside your Trigger.io app directory

    You’ll then be prompted to inform your test users that a build is available to install by way of an email from TestFlight.

  5. Add more users

    That’s it!

    But if you want to add more users to your TestFlight project, there’s a small gotcha: once they’ve accepted their invitation to your project, you’ll need to go back to the Apple Provisioning Portal to add their device.

    You’ll also need to regenerate your provisioning profile with the new device  associated with it, download it, and be sure to use it in the Trigger.io tooling when you create your next build.

    Unfortunately the new user won’t be able to install the builds you’ve   uploaded in the past since their device id wasn’t associated with the provisioning profile that you used to create those builds.

Phew! Now TestFlight manages the process of informing your test users about the build and prompting them to install it and provide feedback

What about Android?

The good news it that for Android, it’s a lot simpler for customers to install your app builds – you can simply package up the app into a .apk file and send it to them to install over email.

There are also options for showing them browser-based previews like Kickfolio provides for iPhone / Android apps. But most people opt to simply send the build to install since the Android emulator can be a lot slower than real devices and the process is simple enough.

To package and Android app into a .apk with Trigger.io follow our tutorial on preparing your app for release.

That’s it!

If you haven’t already, sign up to Trigger.io to get started with your native mobile app. After all you need to build your app first before you can distribute it to customers to try out!

Have you found other methods that work for you? We’d love to hear about those and get your feedback on these methods. Get in touch at support@trigger.io.

New feature roundup: Calendar module, integrate remote web content into your app and more

Having the breadth and quality of native mobile APIs to make your app successful is our #1 product priority right now.

The Trigger.io team was in Berlin in February for one of our work trips away and we were entirely focused on changes to allow us to accelerate making more native UIs, APIs, and cloud SDK integrations available.

But preparing for our next major release hasn’t stopped us continually adding to and improving our native modules.

Here’s an update of the new features we’ve added in the past few months:

 

Calendar module

We’ve created a new calendar module to allow you to prompt users to create calendar events within your app

 

With a single API call you can show a native UI with the calendar event details:

forge.calendar.addEvent({
    title: "Anniversary of adding my first event",
    start: new Date(),
    end: new Date(),
    allday: true,
    recurring: "yearly"
}, function () {
    alert("Event added!");
});

The user must confirm the event to be added to their calendar. More modules and improvements like this coming soon!

Contact support@trigger.io anytime to tell us what you need. We’re eager for your feedback.

Integrate your remote web content

You can now re-use web code that you’ve already deployed inside a Trigger.io app using our trusted urls configuration.

The HTML / CSS / JavaScript of your Trigger.io app is packaged locally to offer the best performance and offline capability, and we provide our Reload feature to let you update it without needing to go through App Store approval.

But sometimes you do need to reference remote web content within your app and we now support that allowing you to specify trusted urls in your config along with the other basic parameters of your app:

{
    "name": "My App",
    "author": "Forger",
    "description": "My First Forge App.",
    "version": "1.0",
    "platform_version": "v1.3",
    "homepage": "http://example.com"",
    "modules": {},
    "partners": {},
    "config_version": "2",
    "trusted_urls": [ "http://example.com/use_forge/*" ]
}

You can load content from the trusted_urls directly into the main view of your app by specifying the window.location. JavaScript in that page can make use of Forge APIs.

This is  a powerful feature and with that comes responsibility: you need to make sure the Forge APIs that you call in your remote code are compatible with the modules that are enabled in your Trigger.io app that references the trusted url!

And there’s more…

We’ve made a host of other improvements which you can track in our release notes. Amongst these are:

Sign up now to take advantage of these new features or get in touch with us at anytime at support@trigger.io

Webinar: learn how to build native plugins for iOS

Update

A recording of this webinar is now available – https://vimeo.com/62099282


Join James Brady, Trigger.io CTO this Thursday at 10am (Pacific time) for our first webinar covering native plugins. This webinar is open to all Trigger.io customers and free trial users.

Build native plugins for iOS

Join us for a Webinar on March 14

Space is limited. Reserve your Webinar seat now at:
https://www1.gotomeeting.com/register/574846176

Details

Trigger.io co-founder and CTO, James Brady, demonstrates how to get started building a native plugin for iOS.

There will be an opportunity to ask questions about your specific app, and the best one will earn the asker an exclusive Trigger.io t-shirt!

Title: Trigger.io Webinar: build native plugins for iOS
Date: Thursday, March 14, 2013
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

Trend towards the Mass Customization of Apps from Banking to Government to Entertainment

When we launched Trigger.io we were expecting two types of customer – those that were building apps for themselves or their organizations, and contract developers or studios building on behalf of 3rd parties. We’ve got plenty of examples of both types and recently launched our Projects feature to cater to teams of developers working on multiple apps for different end customers.

But in the past couple of months we’ve noticed another category of customers, and that group is growing fast.

I call the trend the “mass customization” of apps, to borrow the manufacturing term. This group creates app templates designed for a particular industry and then customize those templates for each end customer. The customization could be as simple as different branding but more often includes adding differentiating features also.

We think this trend is really valuable for the companies who buy the apps in this way. The use case is super interesting for us to support and we’ve starting building specific features to enable it on our platform – I’ll go into that further, but let’s start with some examples.

Government and Banking

Comcate offer a SaaS CRM solution for local and federal government to engage their “citizens” – because public agencies care about their customers’ satisfaction too!

They started by offering a web product which they customize for each customer. But now, as mobile has become omnipresent, so to has the demand for a mobile product.

The value-add of their mobile app is simple – empower citizens to engage their government via requests from their mobile phones. Pot hole in the road? Graffiti in your neighborhood? Street light out on your block? Snap a photo on your smartphone, send the request tagged with your location, receive updates, and watch your government at work for you.

Jwaala have taken a similar “mass customization” approach but for online banking applications.

They’ve enabled many credit unions to offer awesome mobile banking much faster than those organizations building an app from scratch in house. Because they serve multiple customers in the same industry and have productized the common features into a template, they give their customers a head start.

Why this trend is great

In the early days of the web, every new site needed to be hand crafted from scratch. Over time, as well as technical standards emerging, standard ways of doing things by industry and by use case emerged which made life easier for everyone.

For example, publishing written content in the form of a blog became well understood both from the consumers’ and producers’ points of view –  you didn’t have to build a blog from scratch each time, you just customized WordPress. You may think that online storefronts look very different, but the basic components are the same, pioneered by Amazon and “mass customized” by Viaweb (now Yahoo! Store).

We’re still in the very early days of mobile – I think people are still underestimating how big the shift is. Forget the 1M apps developed so far, we’re going to see another 5M built in the next three years. This sort of hyper-growth is enabled by decreasing mobile development costs: the trend towards “mass customization” makes me confident we’re on the right track and mobile development is starting to mature.

To spell it out: mass customization is great for companies because they can get a mobile experience in front of their customers faster, cheaper and with higher quality than creating everything from scratch. They also know they’re not going to be missing basic features for their industry since they’re taking advantage of the learnings of others.

Trigger.io features supporting mass customization of apps

If you’re going to mass-customize apps then HTML5 is a great starting point – we’ve found that our customers usually have existing web solutions (and web skills) which they want to extend to mobile web and then add native mobile features.

The challenges you need to solve to offer mass customization are:

  • How can I build and test a large number of apps fast?
  • How can I enable my customers to customize their app by adding unique content and branding, and in a self-serve manner
  • How do I avoid spiraling maintenance costs when my customers keep wanting to push updates?

Trigger.io can already help you in a number of ways.

Underpinning all the benefits of Trigger.io is our core ability to wrap your existing HTML5 code in a native container, and give you a JavaScript API into native features – here’s how that works.

That ability to reuse web code and skills is a big win for all our customers, but for those interested in mass customization specifically, we also have:

  1. A fast standalone build API which allows you to integrate your back-end with ours to automatically trigger (pun intended) builds. This is different from manually kicking off builds from our locally-installed Toolkit: using this, you could automate to the point where your end users could create an app and kick off a native app build right from your site. You’re effectively white-labeling our service.
  2. Reload allows you to push new content to your apps. So you can enable your customers to automatically make updates without needing to manually resubmitting a new app build to the App Store.

What’s next

We have ideas on making mass customization apps even better with Trigger.io, but ultimately we’re going to be guided by what you need.

Please get in touch with us at support@trigger.io if you’re working on mass customization of apps. We’ll work fast in our 2 week sprints to add what you need - you can see from our past release log how quickly we iterate.

We have customers doing mass customization of apps on Trigger.io right now. If you sign-up for a trial, you may be surprised by how much just works for you right now.