Building JVH Puzzle for Android: From Swift to Kotlin

After launching JVH Puzzle on iOS, I quickly started getting the same question: "Is there an Android version too?"

My priority was to make the iOS app solid first. Once it was stable, I checked demand again with the community. The response was clear: Android users wanted it too, and many were specifically active in Jan van Haasteren puzzle groups.

That was the moment I committed to the next challenge: a new platform, a new language, and a new development mindset. This is the journey from Swift to Kotlin.

Choosing Native Over Shared Codebase

When bringing JVH Puzzle to Android, I had a core architectural choice to make:

I chose native development, and that decision shaped everything that followed.

Why Native?

Native means separate codebases (Swift + Kotlin), so yes, more work. But it gives major advantages:

• Platform features: Full access to iOS and Android specific APIs without compromise.
• Performance: Directly compiled apps with no cross-platform overhead layer.
• UX quality: Each app feels natural on its own platform and follows native conventions.
• Future-ready: New Apple/Google platform features can be adopted immediately.
• Growth: Building native forces deeper platform understanding and better technical decisions long-term.

Native development means more code to maintain, but the result is better products that genuinely feel at home on each platform.

The Shared Backend Advantage

While the UI code is separate, I still benefit from shared infrastructure. Firebase serves as the shared backend for both platforms, handling:

• Real-time database synchronization
• Authentication (Google Sign-In, email/password)
• Cloud storage for images and data

Building the Android App

The development process started in December 2025, and the app went through a closed beta phase before launching on the Google Play Store in February 2026. Here's how the app evolved:

Learning Android Studio

One of the toughest parts was learning Android Studio. Coming from Xcode, the workflow initially felt overwhelming: project structure, build system, debugging flow, and navigation all worked differently.

I had to relearn how to work with an IDE from the ground up, which was frustrating at times but ultimately worth it.

"Xcode still feels more polished and streamlined to me. Android Studio is powerful, but it comes with a steeper learning curve and a busier workflow."

I spent a lot of time simply figuring out where things were and how to do tasks that felt automatic in Xcode. But I kept going.

The closed beta became my fastest learning loop. Between versions 1.0 and 1.8, feedback-driven updates helped me understand Android-specific expectations much better. Over time, Android Studio became more familiar, even if I still prefer Xcode's workflow.

From Testing to Launch

I didn't have an Android device at the time, and I prefer testing on real hardware rather than emulators. So I bought an Android phone and just started building.

Publishing to Google Play Store

Once the app was stable and well-tested, I expected the launch to be straightforward. In reality, the Google Play process was much more layered than expected.

Launch Timeline

1. Closed beta requirement: even after thorough internal testing, the app first had to go through a mandatory closed beta.
2. Initial waiting window: before beta could even start, there was an additional 1-7 day waiting period.
3. 14-day tester rule: 12 people needed to keep the app installed for 14 consecutive days. If someone dropped out near the end, the countdown had to restart for that spot.
4. Post-beta review: after beta, I had to report what I learned, what I changed, and submit again with another review wait.
5. Production release: once production track access was unlocked, I uploaded again and waited one more review cycle before it finally went live.

The hardest part was not just building the app, but coordinating timeline dependencies and keeping beta momentum. The process works, but it demands patience and very careful planning.

"All that waiting time I find so irritating. The entire process involved multiple waiting periods and multiple rounds of questions before the app could finally go live."

What made this phase difficult was that progress was not only about code quality anymore, it was also about timing, compliance, and coordination. Even small delays in one step could push everything else forward.

Still, the launch itself was a great milestone. Seeing JVH Puzzle finally live on Google Play made the entire process worth it, and it gave me a clear foundation for the next Android updates.

Google vs Apple: A Different Approach

Publishing to both platforms made one thing very clear: both are strict, but they are strict in different ways.

Key takeaway: Apple is quicker operationally; Google is more procedural. Both protect users, but the launch rhythm is very different.

Lessons Learned

Building JVH Puzzle for Android taught me several valuable lessons:

Conclusion

Building JVH Puzzle for Android was a journey of learning and growth. Choosing native development over cross-platform frameworks, learning Android Studio (which I found much more challenging than Xcode), and navigating the Android ecosystem was challenging but rewarding. The entire development process took about 2.5 months, with extensive testing on a real Android device.

The Google Play Store submission process was more frustrating than I expected, with multiple waiting periods, closed beta requirements, and multiple rounds of questions. But despite all the hurdles, the app is now live on the Google Play Store, and we've reached Top 5 in Top Apps Netherlands, a milestone I'm proud of.

The Android version brings the complete puzzle tracking experience to Android users, with all the features they need to manage their Jan van Haasteren puzzle collection. And with Firebase handling the backend, users can seamlessly sync their collections across iOS and Android devices.

Thanks for all the feedback and patience from the Android community. As always, please keep sharing bugs or ideas, they help make the app better for everyone.