> AffiliateOS Help Center. Index of every article for AI tools: https://www.affiliateos.ai/help/llms.txt

# Add the wall to an iOS, Android or React Native app

Hosted Offerwall · For publishers · Updated 30 October 2026
Web version: https://www.affiliateos.ai/help/offerwall/add-to-mobile-app

Open your wall's link in a browser tab from your app (SFSafariViewController on iOS, a Custom Tab on Android) and it works with no other code. Host the wall in your own WebView only when it has to sit inside your screens or your app needs its events, and then hand store links to the phone yourself.

## Pick how to show it

| | Browser tab | WebView in your app |
|---|---|---|
| Code you write | Open one URL | Link routing and a message bridge |
| App Store and Google Play links | Work as they do in Safari or Chrome | You hand them to the phone |
| Wall events | None reach your app | All except `offer_redirect`, which is for iframes |
| How the user closes it | The browser's own Done or back button | The wall's close control, which your app has to hear |

We recommend the browser tab unless you need the events. You learn about every conversion from your postback either way.

## Build the launch URL

Use the same wall link as on the web, with the phone's details:

```text
https://offerwall.affiliateos.xyz/w/owapp_your_wall?uid=u_48213&country=US&source=ios&platform=ios&device_id=IDFA_IF_ALLOWED
```

Example: user u_48213 on an iPhone in the US.

- `source` is `ios` or `android`, once. A second `source` in the URL makes the launch fail.
- `platform` is `ios` or `android`, so an iPhone user is never shown an app that only exists on Android. Never send `platform=web` from a phone: the wall then lists web offers only.
- `device_id` is the IDFA or GAID when the user allowed it. Anything that isn't in an advertising ID's shape, including an all-zero IDFA, is dropped and the wall opens as usual. On iOS, a real IDFA with `platform=ios` also shortens the [iPhone tracking guide](https://www.affiliateos.ai/help/offerwall/iphone-tracking-guide) to its second screen.
- If your wall requires signed links, your app asks your server for a fresh URL each time. The wall secret never goes in the app.

## Show it in a browser tab

### iOS: present the URL in SFSafariViewController

Present an `SFSafariViewController` with the launch URL, as a sheet over your screen. Offers and App Store links open as they would in Safari.

### Android: open the URL in a Custom Tab

Launch a `CustomTabsIntent` with the launch URL, and fall back to the default browser if the phone has no Custom Tabs support. Google Play links open the Play Store.

### Check it worked

Open the wall from your app with a test user ID. The wall hides its own close control in a browser tab, because nothing in your app can hear it; the user closes the tab with the browser's button. Your app gets no events from the tab.

## Host it in a WebView

In your own WebView the wall is the page itself, so it moves itself to each offer it opens. Your app has three jobs.

### Send store links to the phone

When the WebView is about to load an App Store or Google Play store page, or a link with a scheme that isn't `http` or `https` (such as `itms-apps:`, `market:` or `intent:`), cancel the load and hand the URL to the phone (`UIApplication.open` on iOS, an `Intent` on Android, `Linking.openURL` in React Native). A WebView can't open those itself, and the offer dead-ends on a blank screen.

### Open offers over the wall, not in it

When the wall's WebView is about to load an `http` or `https` page on any host other than the wall's, cancel it and load that page in a second WebView on top of the wall. Close the second one when it hands a store link to the phone. The user then comes back to the wall, where the offer shows as started. Some offer links stop on a page of their own that expires once the user leaves it, and without this that page is what the user returns to.

Load the wall's own URL, not a link of yours that redirects to it, so the host you compare against is the wall's.

### Forward the wall's messages and close on `close_requested`

In a WebView the wall posts its events to its own window. Inject a short script that listens for `message` events whose `type` starts with `affiliateos.offerwall.` and passes them to your app through your WebView's bridge. When `close_requested` arrives, dismiss the WebView.

The wall shows its close control only where it can tell something is listening: inside an iframe, or in a React Native WebView. With your own native bridge, add `&close=show` to the URL. If your screen has its own close button, add `&close=hide`.

### Check it worked

Open the wall with a test user ID and add `&testMode=1`: tapping **Get** then records the start without leaving the wall, and your app should receive `offer_started`. Then, without test mode, tap a game offer: the App Store or Play Store should open, and closing it should bring the user back to the wall. [Test your wall before launch](https://www.affiliateos.ai/help/offerwall/test-before-launch) covers the rest.

## React Native

Use `react-native-webview` and do the three jobs above in `onShouldStartLoadWithRequest` and `onMessage`. We have a ready-made React Native container that does all three, with tested link rules. It isn't published as a package: ask for it at [hello@affiliateos.ai](mailto:hello@affiliateos.ai).