Native UGC galleries inside your iOS or Android app: the SDK, not a standalone Idukki app

Two ways to be "in the app," and they are not the same claim

Before this SDK existed, "does the widget work in native apps" had a real but limited answer, shipped as part of the widget speed program: a tap bridge that fixes the two things that silently break a web widget inside a WebView (product taps going nowhere because WebViews drop window.open, and storage degrading ungracefully when a WebView ships with it disabled). That bridge is real, shipped, and stays the right answer for any app that already renders its own site, or a widget page, inside a WebView. It is not what "native rendering" is asking for, and we try not to describe it as one.

Why a toolset, not an app

A UGC gallery is a feature, not a destination. Nobody opens an app to browse Idukki; they open a merchant's app to shop, and the gallery earns its place by sitting inside that experience, next to that merchant's own cart, their own account system, their own push notifications and their own App Store listing. Building "the Idukki app" would mean asking a merchant's customer to install a second app for one feature, competing for a home-screen slot the merchant already owns. That is a worse outcome for the merchant, and it does not match how the web widget already works: it embeds on a merchant's own domain, under a merchant's own brand, not on a page hosted by us.

So the native mobile work follows the same shape as the web SDK, not a new shape: a client library and a UI component (or, for Android today, just the client) that a merchant's engineers drop into an app they already own and control. The cart stays theirs (an onAddToCart delegate, never our checkout). The analytics stay theirs (an onEvent callback mirrored into whatever mobile analytics SDK they already run). The App Store listing stays theirs. We ship the gallery; they ship the app.

What's shipped: React Native

The React Native package renders the gallery as a real <FlatList>-backed grid, no WebView and no iframe anywhere in the tree. Tapping a product opens a native modal with tagging, not a browser sheet. It consumes the same public gallery endpoint the web widget already uses, so a merchant is not managing a second content pipeline: tag a product once, it shows correctly everywhere.

import { IdukkiGallery } from '@idukki/widget-sdk-native';

<IdukkiGallery
  layoutGuid="your-gallery-guid"
  businessGuid="your-business-guid"
  onAddToCart={async ({ productId, variantId, quantity }) => {
    // Call your own app's cart API here. Return { ok: true } on
    // success — same contract the web widget's cart hook uses.
    await myAppCart.add(productId, variantId, quantity);
    return { ok: true };
  }}
  onEvent={(event) => {
    // Mirror into Firebase / Amplitude / whatever you already run.
    analytics.logEvent(event.event, event);
  }}
/>

That is the whole integration for a grid layout: a component, a cart callback, an optional analytics callback. Behind it, the client resolves a persistent per-device identity (there is no browser cookie jar on native), fetches and paginates the gallery feed, and maps the six theme tokens the dashboard's Brand Kit already produces onto the component's styling, so a merchant's colours and radius carry over without them touching a design file.

Two things this does not do yet, said plainly rather than discovered the hard way mid-integration: only the grid layout ships (no reel, carousel or story layout for v1), and the gallery component itself has been reviewed and unit-tested but not yet mounted inside a real production RN app. It is ready for a design partner, not for a general-availability npm install.

What's shipped: Android

The Android client is a plain Kotlin/JVM port of the same logic: identical URL construction, identical pagination fallback, identical theme-token reconciliation, so the three clients (web, React Native, Android) cannot quietly drift on what the backend actually sends. It is deliberately smaller in scope than the React Native package: a data client only, no Compose UI, because writing a Compose gallery with no way to actually render or test it would be worse than not writing it.

val client = IdukkiNativeClient(
    IdukkiNativeClientConfig(
        layoutGuid = "your-gallery-guid",
        businessGuid = "your-business-guid",
        fetcher = HttpGalleryFetcher(),
    )
)

val page = client.fetchGallery()
// page.posts, page.theme, page.hasMore — render with your own
// Compose LazyVerticalGrid; the client does not paint UI.

A Compose gallery component matching the React Native one's feature set is the next piece of this, not a separate roadmap item. If your app is Android and the data client alone is enough to get started (you already have grid UI patterns you would rather reuse than adopt ours), it is usable today.

iOS: written, not yet a claim we make

The honest state of the iOS side: Swift source exists, mirrors the Android and React Native clients field-for-field against documented Foundation and URLSession APIs, and has never been compiled. That is not a small caveat softened for a blog post; it is the actual current state, and we would rather say it plainly here than have a sales conversation discover it. Getting this in front of an actual Xcode build is the very next step, not a someday item, the moment a design partner's stack calls for it.

How this gets tested, and how you could test it yourself

Every claim above about "tested" means an automated suite that runs against a mocked network, by design: neither client's core logic should depend on Idukki's production infrastructure being reachable just to prove the URL-building and pagination logic is correct. Both the React Native and Android clients also carry a second, opt-in test that hits the real public gallery endpoint for a true end-to-end check, kept separate and disabled by default so a normal test run never needs network access.

• React Native: `npm test` runs the full mocked suite; `IDUKKI_LIVE_TEST=1 npm run test:live` runs the real one.
• Android: `gradle test` runs the full mocked suite; `IDUKKI_LIVE_TEST=1 gradle test --tests "*LiveIntegrationTest"` runs the real one.
• iOS: `swift build` and `swift test` are the two commands that would turn the "never compiled" caveat above into an actual result, the first time anyone with Xcode access runs them.

None of the three packages are published to a public registry yet (no npm, no Maven Central, no Swift Package Index listing) — they ship today as source to design partners, the same early-access shape as the other pieces of the platform we are honest about not having finished. If your app's stack is React Native, Android or fully native iOS and a WebView tile is starting to look wrong inside it, that is the conversation worth having with us directly rather than waiting for a public release.