Developers | Shoppingate

Get started

Choosing your path

There are two ways to put an app inside Shoppingate, and they are different enough that advice written for one will mislead you if you are building the other. Pick before you write anything.

Both produce a mini-app that the host installs and launches the same way, appears in the same places, and goes through the same review. The difference is where your screens live and what your code can call directly.

Native mini-app

Screens built as mini-app pages

1
You write
.fxml markup, .ftss styles and page JavaScript
2
Your code calls
the whole ft.* runtime directly — no bridge in between
3
The host renders
your pages natively, with native scrolling and navigation

Everything is available immediately, and nothing needs relaying. The cost is that existing web code does not come along — each screen is built against this runtime.

Web view

Your existing web app, wrapped

1
You write
a small shell mini-app holding a single <web-view>
2
Your page loads
the JSSDK, which gives it an ft of its own
3
The host renders
your page, full screen, inside the mini-app

Your web app ships without a rewrite. The cost is a smaller API surface in the page, a relay in the shell for the rest, and page-level work to stop it feeling like a website.

Which one fits

If…

Then

You already have a web app

A web view ships it as-is. Rebuilding every screen as a native page is the expensive option, and it is optional.

You are starting from nothing

Build native pages. You get the full runtime, native scrolling and navigation, and no bridge to reason about.

The screens are mostly content

A web view is fine. Catalogues, articles, help centres, policy pages.

The screens are mostly interaction

Prefer native pages. Lists, pickers and transitions feel better when the runtime owns them.

You need to take payment

Either. A wrapped page can charge — ft.callNativeAPI('orderPayment', …) works from page JavaScript and returns its result.

You need the camera, album, Bluetooth, contacts or calendar

Both work, but a web view reaches most of these only through a relay you write in the shell. See what a page can reach.

One web app, several platforms

A web view keeps a single codebase. Native pages are Shoppingate-only.

It is not all or nothing

A mini-app can hold native pages and a <web-view>. Wrapping an existing checkout while building the home screen natively is a normal and often the right shape. The pages that need to feel fastest get built natively; the rest get wrapped.

The shell in a web-view wrap is itself a native mini-app, so you will read some of both sections regardless. Where a native page is what is being described, the web-view pages say so.

The one thing that is genuinely unavailable in a web view: anything that needs a real tap on a native control. A tap inside a web-view is not a tap on a mini-app button, so controls built on open-type — opening the permission settings screen, for instance — have to live on a native page in your shell. There is a one-page pattern for it in permissions.

Where to start

Building native pages: Create a project in SG Studio. Wrapping a web app: Web view — overview & SDK. Either way, Environments explains beta versus live first.