Apps built using the Build product are native mobile apps, using Swift on iOS and Kotlin on Android, which leverage the Build mobile framework.
They are hybrid apps, in the sense that they are developed using the official native development SDKs provided by Apple and Google, and leverage web technologies to display some of all of their contents.
The Build mobile framework is a library used by the mobile app to manage the user interface, leverage the web assets and trigger native, built-in, features.
Web pages are rendered using the WebKit engine provided by the OS, over which several layers are added to interact with the pages and optimize their performance. This means that any feature working in the mobile browser of a mobile device will work, out of the box, in the generated app.
There are 3 main components to an app developed with Build.
The SDK part of the app is the Build framework itself, which also includes the FollowAnalytics Analytics and Engagement components.
The SDK is building the UI of the app, renders the web pages and controls its built-in native features.
It is highly customizable: every default behaviour can be overridden or extended in the app code.
The app base code is generated from our servers and comes with the boilerplate necessary to set up the SDKs, handle push notifications, universal links, and more.
The central piece of the app is its configuration file, a JSON file placed in the app Xcode or Android Studio project.
This file, described later in the document, is versioned and also is hosted online to allow remote updates to the app, even after it has been published.
The custom code component is usually quite limited in the app. Most of what makes the app unique is defined in the configuration file. But in some cases, the app will require to override the behaviour of the framework, for instance to slice a barcode scanned by the framework before having it inserted in a web page. This is performed in the native code.
Almost everything the framework does can be customized to fully customize the app: page loading, script injection, tab bar buttons, top navigation bar buttons and title, native features, and more.
Similarly, any custom feature, section, or 3rd party library can be added to the app, alongside or intertwined with the hybrid experience provided by the Build framework.
Native sections, modals, panels, can be displayed and connected to the Build app to show up based on web "signals", native button taps, or as entirely stand alone sections.
The configuration file defines the structure of the app: login detection and behaviour, sections, top navigation bar and its buttons, how / where links should open, and more.
For each section, the Configuration file can define web elements to hide, CSS to inject and JS to execute on the pages it will display.
The file is versioned, and if configured to do so, the app will check online, on startup, for a newer version. This allows to remotely add / remove entire sections or native features, and also to fix potential issues on web pages by editing injected scripts or adding new ones.
Distribution of the app
Apps built with Build are standard native apps and can be distributed both on public and private app stores.
The app can be packaged into an IPA on iOS or an APK or AAB on Android, and then published.
On the public stores, the app is submitted to Apple or Google for review. The Build app can be either a whole new app or an update to an existing one.
There is no requirement for the website aside from working properly on mobile browsers.
No API call is made from the app to the company server other than the ones a web browser would do when browsing the site.
The framework runs on iOS 11.1+ and android API 21+.
Updating an existing app on Android requires to have the keystone file used to publish the current live app.