Why Trigger.io doesn’t use PhoneGap – 5x faster native bridge
Firstly, our own native bridging technology is significantly faster – up to 5x on Android according to our testing below.
We wanted to design the best experience for web developers to create native mobile apps by having:
- a super fast build-test cycle
- no need to write any native code,
- no need to setup your environment for local compiles,
- no need to setup XCode and Eclipse
These design constraints mean that our approach includes a ton of small differences from PhoneGap, not just in our native bridge but in the code around it to provide the best possible API and best possible build process for developers coming from web technologies.
We’re not averse to using existing solutions, and working to promote them and improve on them, where it’s right for our customers (our Catalyst debugging tool is a hosted build of Weinre). PhoneGap is a great product with lots of flexibility to write your own platform-specific native code in conjunction with HTML5 (which is not something Trigger.io offers). Strobe and appMobi both decided to use PhoneGap rather than developing their own native bridge.
Speed is a big concern for developers considering HTML5 and hybrid frameworks as opposed to native. So how does Trigger.io’s native bridge perform in practice?
On iOS, compared with PhoneGap we saw that our bridge performed at a similar level to PhoneGap with a small increase in speed:
On Android it’s dramatically faster:
How Trigger’s native bridge technology works
Since launch, we’ve been asked about how our bridge technology works. Our architectural approach has much in common with PhoneGap’s – but with some differences that reflect our different priorities and ways of thinking.
Here’s how it works.
Wrapping and bridging to native
We deal with iOS and Android in different ways:
PhoneGap use a similar method, which explains why our performance is comparable in the benchmarking we did.
How does this look in practice? You don’t need to worry about what the bridge does – you simply call native functionality in through our Forge API (the full details of which are in our documentation).
Here’s what happens when you run a command to access the native camera:
We aim to keep our framework as lean as possible and making the development environment and build process simple. We want the start to finish of cross-platform app development to be as straightforward as standard web development.
As a result we opted to build our own, faster bridge to native, for more responsive apps and fast development.