Proud to see _both_ platforms of my year-long KMP ...

# feed

[darkmoon_uk]

Proud to see both platforms of my year-long KMP deep-dive go live!

Zeller is an Australian Payments FinTech to rival Square & Stripe in the local market. We building and maintain our own tech stack, and just launched Tap-to-Pay for *Android and iOS* 🚀

*A*lthough the front-end is React Native; the underlying payment engine and integration with each platform's card reader hardware is all Kotlin Multiplatform K ! (also, internal dev apps were built using Compose Multiplatform K)

The KMP engine was built by myself and one other dev; it was a very enjoyable experience!

An exposé article is on the to-do list 🙂

[zsmb]

Interesting integration of KMP, thanks for sharing!

On a side note, I found a typo on the site 🕵️‍♂️

[darkmoon_uk]

...thanks! I'll pass that onto the relevant persons for correction ASAP 😉

[Pablichjenkov]

So basically it turns the phone into a POS, no more need for a POS hardware.
BTW hell of integration, react-native + KMP

[darkmoon_uk]

@Pablichjenkov NGL the CI pipeline work alone on that was... significant. 😅

[Pablichjenkov]

I bet, great work 💯

[darkmoon_uk]

Thanks 🙂 The RN front-end team are essentially our internal customer for the engine; so to ensure we deliver them quality goods, we made our own Native & React Native Dev Apps to test-integrate - meaning each CI run builds 5 Apps:
• Native Android
• Native iOS
• RN Android
• RN iOS
• Desktop
...why Desktop?
Because with Compose Multiplatform - you're worth it!
The card reader is faked in that target; but it gives us a fast feedback loop during dev, for verifying other logic changes.

[Pablichjenkov]

I see, yeah the desktop target is super helpful I use it for development all the time. Basically the other platforms I just used for testing.

[darkmoon_uk]

@zsmb Typo fixed 🧑‍🔧 thank you color

[Joel Denke]

Wow, RN + KMP. That itself is impressive! Is it possible share something how you do this technically?

[darkmoon_uk]

• The interface between KMP and RN was actually nothing too exotic; we followed the Kotlin Interop guidelines on one side; and the React Native 'Native Module' implementation guide for each platform, on the other. The most significant runtime code at the interface, was implementing Coroutine Flow collection across React Native's concept of an 'Event Bus'. We did go through a couple of iterations on that; also trying an RN 'Callback' based approach which worked, but was more complex and less efficient. On the Typescript side of the Flow bridging; we inflated the JSON elements as equivalent TypeScript Objects and Protocols for the host App's consumption.
• The iOS card reader hardware was only exposed via a Swift ABI interface, so we had to write an Objective-C wrapper to go around it. The resulting framework could then be driven by K/N. Again it wasn't too complex, just 'more work'. We look forward to removing this if KMP gets direct Swift interop.
• Security was a major consideration in such a project: We needed Dev and Prod flavours across both platforms so that all debugging and logging code was not even present in the production version.
• We used Manual DI; it was a breeze, and further cemented my view that a DI framework is rather unnecessary with Kotlin.
• A major challenge was the sheer number of moving parts in the build process: Dealing with KMP, iOS builds and React Native all at the same time meant a lot of environment configuration on both Dev and CI machines; this was mitigated by defining a higher-order 'Gradle CI project' whose purpose was to:
◦ Coordinate execution of a few lower level Gradle projects.
◦ Set-up 'bottom level dependencies' which were actually environment setup tasks that verified the environment and if not satisfactory, took relevant remediation like 'Install JDK 17' or rbenv. This made the whole project more robust.
• Though this 'CI' project helped; having nested Gradle invocations isn't desirable in itself; I really wanted to achieve the full build graph using a Gradle Composite project with dependencies across `Task`s & `TaskRef`s. So far I've failed in this particular endeavour since Gradle's model proved frustratingly limiting in this area.
• Both devs were Senior, with native experience in both Android and iOS, which helped. We had little-to-no previous experience in React Native, but could consult a RN team whenever reassurance was needed.