Blog
Product Updates
SDK Integration Timeline for a 10-Week Loyalty Launch
Cas Schalkx
SDK integration does not have to be the critical path of a 10-week loyalty launch, as long as your app team starts in week 1 and your app already has a working login. The NeoDay SDK ships ready-made loyalty screens whose content is driven from the NeoDay backoffice, so the app work is bounded; what usually decides the date is identity (the token endpoint the SDK needs), getting purchase events from your POS, and your own app release cycle.
Below: what your developers actually build, a sample 10-week timeline per team, and when the SDK really does move to the critical path.
What your app team actually builds
NeoDay publishes native SDKs for iOS and Android, a Flutter plugin, and a Web SDK, documented on docs.neoday.com. The native SDKs return prebuilt screens (campaigns, coupons, reward shop, loyalty card, feedback and surveys) that your app pushes, presents or embeds in its own navigation. Behaviour and content are set in the backoffice; the app renders what is configured.
The integration itself follows the same pattern on every platform:
Install the SDK and get access to the package repository from NeoDay.
Configure it once at app start with your gateway URL and client ID.
Authenticate the signed-in user through an endpoint on your side that returns a signed token.
Request screens from the SDK and place them in your navigation.
Handle deep links between SDK screens, loading states, re-authentication and analytics events.
On iOS and Android the SDK handles token refresh itself, so your team does not write that networking layer.
Platform | What the docs list as requirements (October 2026) |
|---|---|
iOS | iOS 12.0 or higher, Swift 5 language mode, Swift Package Manager, gateway URL and client ID, an authentication flow that can provide the token |
Android | minSdk 21, Kotlin 2.1.0, Java 17, Gradle and Android Gradle Plugin versions as listed, a FileProvider entry in your manifest, credentials for NeoDay's private Maven repository provided at onboarding |
Flutter | Flutter 3.38.0 or later, iOS 13.0 and Android API 24 minimum, SSH access to the plugin repository provided by NeoDay |
Web | a script include on your site, plus an endpoint that returns a signed JWT for the user; campaign pages render in a container or a custom element |
Check these against your app's minimum versions in week 1; a mismatch is cheap to find early and expensive in week 6.
Sample 10-week rollout timeline
NeoDay's public plan has three phases: design in weeks 1 to 3, build in weeks 4 to 7, launch in weeks 8 to 10. It is realistic when your POS and app partners are involved from day one. The table below shows how the work typically divides across those phases when loyalty goes into your existing app through the SDK. It is a sample, not a contract: your scope and systems set the details.
Weeks | What NeoDay does | What the brand's app team does | What marketing does |
|---|---|---|---|
1 to 3: Design | Runs the workshops, defines goals, mechanics and KPIs with you, maps your systems | Confirms the platform (native iOS and Android, Flutter or web), checks SDK requirements against the app, decides where loyalty screens live in the navigation, plans the signed-token endpoint, gets gateway details and repository access, books a release slot for weeks 8 to 10 | Appoints the project owner, agrees goals and mechanics, approves the programme design |
4 to 7: Build | Configures the platform, campaigns and front end | Installs and configures the SDK, builds the token endpoint, wires screens, deep links and analytics; works with the POS vendor and app agency through NeoDay's connectors and API | Prepares the first campaigns, rewards and content in the backoffice |
8 to 10: Launch | Tests end to end with your team, trains your marketers, goes live after your sign-off; customer success stays on board after launch | Tests the release build, ships it through your normal app store process in time for go-live | Gets trained, signs off, launches the programme to members |
Two things in this table carry most of the risk. The first is the token endpoint in weeks 4 to 7, because it touches your identity system. The second is the release slot in weeks 8 to 10, because store review and your own release train sit outside NeoDay's control.
Where the critical path usually sits
Identity and the token endpoint
Every SDK needs to know who the member is. On iOS, Android and Flutter, your app supplies an endpoint the SDK calls to get a signed token; on the web, your endpoint returns a signed JWT. If your app already has customer accounts and a backend that can issue that token, this is a contained task. If loyalty is the first reason your app needs a login, building accounts becomes the real project and the SDK waits for it.
Purchase events from the POS
Loyalty in a physical store depends on purchases reaching NeoDay. In the documented POS flow, the POS identifies the customer (by NeoDay user ID or customer card number, for example scanned from the app), sends a purchase event to the Data Bridge, and marks used coupons as consumed. The event schema has to be defined in NeoDay first. This work belongs to your POS vendor or IT team, and it is why the public plan says POS partners should be involved from day one. NeoDay lists ready-made connectors for 40+ platforms on the integrations page, including POS systems such as Oracle Simphony and Tokheim, plus an open API for the rest.
Your app release cycle
The SDK goes into your app, so it ships with your app. If you release every two weeks, that is easy to plan. If you release quarterly, or have a code freeze around peak trading, the release slot can set the date more than any development work does.
When the SDK itself becomes the critical path
The SDK work moves to the critical path when:
your app has no customer login yet, or identity sits in a system that is hard to change;
your app's minimum OS or framework versions are below what the SDK requires;
your app is built in a framework the docs do not cover, which is worth raising in week 1;
the app is built by an agency that cannot plan the work into weeks 4 to 7;
the navigation needs redesigning to give loyalty a place, rather than adding screens to an existing structure.
Each of these can be checked in the design phase and given a date.
Alternatives that change the critical path
A standalone branded app. For brands without an app, or brands that prefer a dedicated loyalty experience, NeoDay builds a fully branded loyalty app, handles App Store and Google Play submission, and maintains it. The standalone loyalty app goes live within 10 weeks and needs no development team on your side. Your app team drops off the critical path; POS events and identity remain.
Web. Web-based loyalty runs in any browser with no download and no store approval, also live in 10 weeks. That removes the release slot entirely. If you want loyalty pages inside your existing website, the Web SDK embeds campaign pages and needs only a script include and your token endpoint.
See deployment and integration for how each option connects to CRM, POS and e-commerce systems.
What changes after launch
Once the SDK is live, new campaigns do not need a new app release, because content and behaviour are configured in the backoffice. That is what makes the layered approach workable inside your own app: always-on points and tiers, monthly milestones, weekly challenges and daily games, each with a start and end date, without a developer ticket per campaign. In the Tesco Central Europe campaign (run with MAGNEDS, powered by NeoDay), later campaigns ran without a new IT project. For the business side of app activation, see increase app engagement, and for sector detail see the pages on quick serve restaurants, petrol stations, food retail and fashion. More general questions are answered on the loyalty FAQ, and the SDK page summarises the product.
FAQ
Is SDK integration the critical path for a 10-week loyalty launch?
It does not have to be. The SDK ships ready-made loyalty screens configured from the NeoDay backoffice, so the app work is bounded if your team starts in week 1. The date is more often set by identity (the token endpoint the SDK needs), POS purchase events, and your own app release cycle.
What does our app need before we can integrate the NeoDay SDK?
A working authentication flow that can provide a signed token for the logged-in user, the gateway URL and client ID from NeoDay, access to the SDK repository, and minimum versions that match the SDK: iOS 12, Android minSdk 21, or for Flutter iOS 13 and Android API 24, as listed in the docs in October 2026.
How many developer days does SDK integration take?
That depends on your app rather than on a standard number. The main variables are whether a login and token-issuing backend already exist, how your navigation is structured, how many SDK screens you want to show, and how your release cycle works. Your team can size it in the design phase once those are known.
Can we launch loyalty without an app release?
Yes, through the web. NeoDay's web-based loyalty runs in any browser with no download or store approval, and the Web SDK can embed campaign pages in your existing site. NeoDay's standalone branded app is another route: NeoDay handles the store submission, so your own app release is not needed.
Do new campaigns need a new app release after launch?
No. The SDK renders what is configured in the backoffice, so marketing can launch and change campaigns without an app update. You still ship an app update when you move to a newer SDK version or change where loyalty sits in your app.
Who needs to be involved from day one?
A project owner on the brand side, your app team or app agency, and your POS vendor or IT team. NeoDay's 10-week plan is realistic when POS and app partners are involved from the start, because the token endpoint, POS events and release slot are the items most likely to set the date.
Which SDK platforms does NeoDay support?
The developer docs cover a native iOS SDK, a native Android SDK, a Flutter plugin that wraps both, and a Web SDK. If your app uses another framework, raise it in the first week so the approach can be agreed before the build phase.
Photo: Markus Winkler on Pexels
More questions about loyalty platforms and integration? Find the answers in our loyalty FAQ.
