How Reskyt works
Reskyt is a platform that turns an online store into native iOS and Android applications, and keeps them running over time. It does not replace your ecommerce: it builds on top of it.
This page explains the full model. If you are coming out of a meeting and want to understand how Reskyt fits into your stack, start here.
The three pieces
Section titled “The three pieces”Your ecommerce remains the source of truth. Catalog, prices, cart, checkout and user accounts live on your platform and are not duplicated.
The Reskyt platform is the technology layer: the backoffice where the app is configured, the push notification service, the integration modules, and the build and publishing of the binaries. It is deployed on AWS, with the main region in eu-west-1 (Ireland).
The apps are native containers (Swift on iOS, Kotlin on Android) that show your store inside a WebView and add the capabilities that only exist natively.
What is native and what is not
Section titled “What is native and what is not”| Native | Uses your ecommerce |
|---|---|
| Push notifications | Catalog and product pages |
| Biometrics (Face ID, Touch ID, fingerprint) | Cart and checkout |
| Deep links and Universal/App Links | User accounts and login |
| System permissions | Content and translations |
| Presence and listing in the stores | Prices, stock and promotions |
| System modals, such as the update modal | Business rules |
That split explains the most important consequence of the model: what you change in your store shows up in the app immediately, without going through Apple or Google review. Anything that touches the native layer (enabling a module, integrating an SDK) requires rebuilding and republishing.
Reskyt’s role
Section titled “Reskyt’s role”Reskyt provides the layer your ecommerce does not cover on its own: the native container and its maintenance, the build and publishing cycle, per-app configuration from a backoffice, the notification infrastructure, and the catalog of modules for connecting third-party services.
What it does not do is replace your store, your CMS, your payment gateway or your identity system. See Reskyt and your ecommerce for the exact split.
Push notifications
Section titled “Push notifications”Sending is done from the backoffice or from your own systems with the push API. The segmentation unit is the device, identified by whichever mechanism corresponds to the version of the API being used.
When planning campaigns, keep in mind that a device with a token is not the same as an active user. It is explained in users, devices and tokens.
Integrations, APIs and SDKs
Section titled “Integrations, APIs and SDKs”Third-party services are connected through modules. A module can be a native SDK, which is compiled into the binary, or an integration that does not touch the binary. That difference determines whether republishing is needed. See integrations and SDKs.
The push API is the Reskyt public API currently available.
Publishing and day-to-day operation
Section titled “Publishing and day-to-day operation”The apps are distributed on the App Store and Google Play. Those store accounts are owned by the customer, and so are the listing, the reviews and the metrics. See publishing to the stores.
After launch, operation is split: Reskyt maintains the container and the platform, and your team maintains the store and the content. Support goes through a ticket.
What Reskyt does not do
Section titled “What Reskyt does not do”It does not replace your ecommerce. Catalog, prices, cart and checkout are still yours, and so are their performance and availability.
It does not manage your users’ identity. In the usual Reskyt model, the identity system and the login are still the ecommerce’s. The native layer can add capabilities such as biometrics or social login when they are integrated as part of the project.
It does not process payments. Payment modules make the provider’s flow work inside the app, but the gateway is still yours.
It does not offer a broad catalog of public APIs today. The push API is the public API currently available; the rest of the integrations are handled through the web or through modules.
It does not avoid the store cycle. Anything that touches the native layer (enabling an SDK-type module, integrating a new provider) requires rebuilding, publishing and waiting for users to update.
Platform components breaks down each block. Architecture goes into the technical detail. Getting started walks through the project from start to finish.