WebView requirements
What a WebView has to support before an OmniLab experience will work inside your app.
Confirm these before your mobile team starts building. Each one has a failure mode that looks like a broken experience rather than a missing setting, which is what makes them expensive to find late.
The WebView itself
- JavaScript enabled. Nothing loads without it. This is off by default on some Android configurations.
- A current WebView component. Use the platform's standard component or a maintained wrapper. Old embedded browsers fail on animations and modern layout, and the failure is usually a blank screen rather than an error.
- Cookies and local storage allowed, including for the OmniLab domain. The experience uses them to remember a participant between screens; blocking them makes someone appear to be signed out mid-journey.
- A full-screen or edge-to-edge container. A WebView in a short fixed-height box crops games.
Permissions
Permissions are granted by your app, not by OmniLab. The WebView also has to forward the browser-level prompt to the native one — enabling the permission in the app manifest alone is not enough.
| The experience uses | Your app must grant |
|---|---|
| A scan or photo game, receipt upload | Camera |
| A venue or store-based experience | Location |
| Voice or video input | Microphone |
| A downloadable reward or ticket | File storage, and a way to open a downloaded file |
Test each on a real device. Simulators grant permissions differently and will pass when a real phone fails.
Why sign-in works here
A WebView loads the experience as the page, not inside one, so OmniLab is first-party in that view. Cookies behave normally, sessions persist, and passing a signed-in member through with fci works without further setup.
One thing to avoid: do not build an HTML page of your own inside the WebView and put the experience in a frame within it. That recreates the third-party situation a plain WebView avoids, and sign-in stops working. Point the WebView at the experience address directly.
Keyboard and forms
If the experience includes a form or a sign-in step, check that the keyboard does not cover the field being typed into, and that the view scrolls to keep it visible. This is the single most common WebView defect and it costs you the sign-up.
Session and navigation
- Decide what your back control does mid-experience. Leaving the experience halfway should be deliberate, not accidental.
- Confirm the experience survives the app going to the background and returning.
- Confirm a lost connection produces something the participant can recover from.
Screen sizes
Test the smallest phone you support and the largest tablet. Test both orientations if your app allows rotation.