Mobile Applications · Backend & Integrations
Thailand Store
Native loyalty rewards, authenticated commerce APIs, and release hardening for a hybrid e-commerce app.
- Company
- Fifty Studios Holding Company
- My role
- Mobile Software Engineer
- Status
- In production
- Key result
- ~3,000 app users
- Capacitor
- Swift
- Java
- WooCommerce
- WordPress REST API
- OneSignal
Overview
Thailand Store is an e-commerce app for iOS and Android with approximately 3,000 users. The shop itself runs on WooCommerce, and the app wraps it in a native shell that adds notifications, deep links, and a loyalty rewards program.
Customers earn loyalty points for actions in the app, such as enabling notifications, and the points are recorded against their store account.
Problem and context
The loyalty program existed on the server, but nothing in the app was reaching it. Awarding points from native code means proving to WordPress which customer is asking, from outside the web page where that customer is signed in.
Around that feature sat the usual hybrid app work: links that should open inside the app, permission prompts that customers dismiss, and platform updates that quietly change how the Android back button and release builds behave.
My contributions
Designed and developed
My own work
- A native loyalty rewards integration on Android and iOS.
- A notification permission reminder that checks the real system state and falls back to settings.
Integrated
Third-party services I connected
- Authenticated WordPress REST API calls from the native layer to the WooCommerce store.
Maintained and improved
Production systems I kept healthy
- Deep-link navigation into the app’s WebView on both platforms.
- Android and iOS WebView compatibility fixes.
- Release hardening: back navigation for newer Android versions, code shrinking, and SDK updates.
- Release preparation for the App Store and Google Play.
Built by others
Not my work
- The original application shell, built by another developer.
- The initial OneSignal and Crashlytics integrations.
- The WooCommerce store and its loyalty endpoints on the server.
Technical architecture
Where my work landed
Conceptual diagram
Commerce backend
- WooCommerce store (predates my work)
- Authenticated WordPress REST calls (my work)
Hybrid layer
- Capacitor app shell (predates my work)
- WebView compatibility (my work)
- Deep-link navigation (my work)
Native layer
- Loyalty rewards integration (my work)
- Notification permission reminder (my work)
- Initial OneSignal & Crashlytics setup (predates my work)
Release
- Android release hardening (my work)
- Store release preparation (my work)
- WooCommerce in a Capacitor shell
- The storefront is the WooCommerce site shown in a WebView. Native code on each platform handles notifications, links, and loyalty.
- Loyalty through the customer’s own session
- The native loyalty component works through the WebView where the customer is already signed in, so points are awarded as that customer with no second login.
- Links that stay in the app
- Android App Links and iOS Universal Links open store URLs inside the app. Links that arrive before the WebView exists are held and opened when it is ready.
Engineering challenges
Awarding points from native code
- Challenge
- The server’s loyalty endpoints worked, yet no calls were arriving from the app. Native code had no way to act as the signed-in customer.
- Approach
- After each page load, the native loyalty component runs a short script inside the WebView. It reuses the customer’s session to obtain a WordPress nonce, then calls the store’s award endpoints with it. Awards triggered before the WebView exists are queued and sent later.
- Technology
- Capacitor
- WordPress REST API
- Nonce authentication
- Swift
- Java
- Outcome
- Points are recorded against the right account without asking the customer to sign in again.
Asking for notification permission well
- Challenge
- Customers who dismiss the system prompt once are rarely asked again, and the notification SDK’s view of permission state can lag behind the operating system’s.
- Approach
- A reminder dialog in the app’s own right-to-left style appears at most once each time the app comes to the foreground. It reads the permission state from the operating system directly and opens app settings when the system prompt is no longer available.
- Technology
- OneSignal
- Android
- iOS
- App lifecycle
- Outcome
- Customers get a clear second chance to enable notifications without being nagged.
Links into a hybrid app
- Challenge
- Store links from messages and notifications were not reaching the right page. On a cold start the link arrives before there is a WebView to load it.
- Approach
- Verified App Links on Android and Universal Links on iOS route store URLs to the app. Incoming links are stored as pending when the WebView is not ready, and other URL schemes are handed to the apps that own them.
- Technology
- Android App Links
- iOS Universal Links
- WebView
- Outcome
- A link opens its page inside the app whether the app is running or closed.
Keeping up with the platform
- Challenge
- Newer Android versions stop calling the legacy back-button method, and Google Play checks expect optimized release builds. Either one can break an app that has not changed.
- Approach
- I migrated back navigation to the current dispatcher API, enabled code shrinking and obfuscation with keep rules for crash reporting and the WebView, and updated the SDK and build tooling.
- Technology
- Android
- R8
- Gradle
- Crashlytics
- Outcome
- The Android app meets current platform requirements and passes store checks.
Results and impact
- App users
- ~3,000
- Approximate.
- Native loyalty rewards integration on both platforms
- Deep-link and WebView issues on Android and iOS
- Android release builds hardened for current platform requirements
Visuals
No product screenshots published
App screenshots will be added once approved for publication. The cover and the architecture diagram on this page are conceptual illustrations.