In order to work with our build system, modules must be developed with a few requirements.

Building from source

Builds run automatically on our build server. This imposes a few restrictions:

• It is a case-sensitive environment, so imported filenames need to match the case of actual filenames, e.g. import * from 'some-lib' won't work with a file called Some-Lib.js.
• The automated system starts with a clean directory, installs dependencies and builds using npm. This means that everything needs to build from source.
• Builds need to go into a dist/ folder, and include a dist/index.html file as their entry point.
• By default, builds use npm run publish to build from source. You can use whatever build tools you prefer by adding a publish script to your package.json (See npm docs). Unless there is a pressing reason to use another command, publish is preferred.

Including an o3hmanifest.json

An o3hmanifest.json file must be distributed along side your index.html file in your builds.

See Manifest Configuration for more info about how to configure this file correctly!

Other Gotchas

Tripping hazards to check before delivering your builds:

• Production builds must not use postMessage (like some dev servers do)
• Make sure you have a VideoAsset or VideoAssetCollection output for the your creatorFeedVideo and audienceFeedVideo. See o3hmanifest Configuration for more info.
• Loading content outside of your module folder is not allowed except for approved external APIs. If your module calls an external service, contact Oooh to make sure to it's on the whitelisted domain list. Otherwise, ensure you include all your dependencies with the module delivery, and use the UserPersistentDataService instead of setting cookies or using local storage.

Performance Budgets

• Download size: Modules should be no more than a 3MB initial distributable.
• Load time: Modules should fully load in no longer than 3 seconds on an LTE connection. It is expected that all assets are loaded in the background, and each screen loads sequentially with no delay (see Oooh's loading optimisation guide).
• Frame rate: 30 FPS hard cap, but 25 FPS is an acceptable minimum on an iPhone 8.
• Memory: There is no enforced cap, but modules should never run our min spec - an iPhone 8 - out of memory.
• Displays: Modules should always have all display assets loaded before switching views, emulating the feeling of a native application by avoiding partially loaded screens.
• Target device resolutions: modules should be fully responsive, displaying correctly on all iPhones & iPads running iOS 13 and up.
• Audio assets: Oooh will accept MP3, WAV, and OGG. We recommend you simply use MP3 throughout. No "fallback" alternative formats should be included in the module delivery.
• Image assets: images/sprites/textures should be run through format-appropriate image optimization (examples: jpegtran, pngquant, pngcrush, or higher-level tools like imagemin or imgoptim).
• Built code: building from your project's source code should result in a single, minified file. The exception is that the o3h.js library is required to be loaded externally, so be sure not to package it.

Final Check

Two main points - make sure your files are considered case sensitive, because this is different in a Linux environment, where we deploy your module. If you're using Webpack, consider using this plugin. This will force Webpack to build with case sensitivity. Finally, run this script to make sure obvious errors can be resolved such as manifest errors. The script will validate the manifest on our end and make sure your module will at least build in your local environment. It will also validate the structure of the build delivery.

📘

Not sure about any of the above? Please reach out!