AlooChat — Messaging, Calling, Payments & AI in One App

Lead mobile engineer, full application ownership · Live on the App Store and Google Play

The project

A consumer messaging app that is really four hard products under one icon. Chat is the easy part. Calling has to ring on a locked, force-quit phone or the product is broken. Payments touch real money and can't double-charge. An AI assistant has to be useful inside a conversation without being expensive or creepy. All of it in one codebase, passing two independent store reviews, on unreliable mobile networks.

I owned the whole thing — architecture, implementation, the rebrand across both stores, and the release train. There was no platform team to escalate to, which shaped most of the decisions.

The architecture rule

One Expo codebase, four subsystems that deliberately don't share a lifecycle. The rule holding it together: anything the operating system can present without JavaScript running — an incoming call, a push notification — is owned by the native layer, and JavaScript subscribes to it rather than driving it.

That single decision is why calls survive kill state. Anything that needs JS alive to work is a dropped call the moment the user force-quits.

Decisions worth explaining

VoIP push on iOS, high-priority FCM plus a foreground service on Android. One abstraction over two genuinely different platform contracts, rather than a lowest-common-denominator that fails on both.

Payments as an idempotent state machine, never request/response. Payment callbacks arrive late, twice, or not at all. Without explicit state and an idempotency key, someone eventually gets charged twice — and it's real money, not a retry counter.

The AI assistant runs server-side with scoped conversation context, not on the client. Model credentials stay off the device, cost and rate limiting are enforceable in one place, and the prompt contract can change without shipping a new build to two stores.

A hard cap of one active call, enforced natively. Telephony concurrency bugs surface as ghost calls the user can't dismiss. A cap enforced where the OS can see it is worth more than the feature it removes.

The hardest bug

Incoming calls worked in foreground and background but vanished when the app had been force-quit — the worst case, and the one users actually notice.

I built a diagnostic harness that injects synthetic VoIP pushes and traces the payload through the native handler, the token registry, and CallKit reporting, which isolated exactly where the chain broke: tokens were being registered during a launch phase where the JS bridge wasn't yet listening. Tokens now queue and replay once the bridge is live, and the harness stayed in the repo as a regression test for a class of bug that's otherwise invisible until a user complains.

Why this matters for your project

Most mobile developers have shipped a CRUD app with a login screen. Fewer have shipped native-grade calling, and fewer still have handled real money on a device. If your product touches telephony, payments, or an AI feature inside a live app, those are the areas where estimates fall apart — and where I've already found the bottom.

Built with: React Native, Expo, TypeScript, WebRTC, CallKit, ConnectionService, VoIP push/APNs, FCM, Payzah, LLM APIs, EAS Build