How to use native iOS and Android services in your hybrid app
Here's how you build a single web app and either deploy it for a browser, or wrap it in a hybrid app using the mParticle solution.
The landscape of software technologies you can use to build a product is hugely varied, argued over, and increasingly complex. I find it helpful to bucket similar technologies by purpose:
- Physical platforms, like a laptop or an iPhone
- Software platforms and apps, such as Windows, Android or an Android app
- Frameworks and SDKs used to build the software platforms
- The languages themselves that are used to build the frameworks
The modularity of the technologies in each of these layers yields a combinatorial explosion – businesses have a dizzying array of technologies they can combine to create a product.
If you’re creating a mobile software product, there’s an ongoing debate about which combination to use. One option is to write your app in the given native platform language, such as iOS’s Objective-C. Another option would be to avoid the Apple App Store and Google Play Store completely, forcing users to the browser, and just use the same web app for all platforms. Last, you could combine the two approaches in order to create a ‘hybrid’ app by using web technologies such as Javascript, hosted in either a WebView (Android) or a UIWebView (iOS), all within a native app. There are fanboys and haters on either side, and it’s all very boring.
Truth be told, at mParticle, we don’t care which combination you use; our goal is to let you organize and control your data so you can best optimize your product or service. Choose whatever combination works best for your product and team. To cover all the bases, we’ve started by creating ‘native’ iOS and Android SDKs and, the focus of this post, a Javascript SDK that is platform agnostic.
With the mParticle Javascript SDK, you build a single web app and either deploy it for a browser or wrap it in a hybrid app. This is done without having to change any of your code that captures user engagement and analytics. In a typical scenario, you might build a web app with a few Javascript SDKs using custom code for each SDK. In order to hybridize that same app, you then have to choose which native SDKs that you want to use – each of which has different (if any) guidelines for how to bridge from Javascript to their respective native SDKs. Then to share the codebase across platforms, you have to write conditional code (and likely your own abstraction layer to organize it) in order to detect if the app is running in a browser or in a webview. If that sounds inefficient and complex, that’s because it is.
The mParticle Javascript SDK avoids this complexity by detecting whether it’s running in a web browser or a webview, and can bind with our native SDKs, bridging the gap between web and native for you. While in a browser, our Javascript SDK works just like other Javascript SDKs by communicating directly with mParticle and other service providers. However, while in a native app’s webview, your data is passed from the Javascript layer and into our native SDKs, leveraging all of the offline, performance, and native-only features from which the native SDKs benefit.
Maybe the most important advantage is that you’re now able to send your hybrid app data to all of the same services that the mParticle native SDKs support. Take a look at documentation of the 40+ services that we support and tell me which of those services support implementing their native SDKs in Javascript. If you’re using mParticle, the answer is that all of them do – you can go right ahead and ignore their docs – our Javascript SDK serves as a trump card for your hybrid-web app strategy.
So, write your mobile app with any combination of Swift or React or Java or Angular, for whatever platform, it’s all gravy.
