From iOS to Android: A Candid Look at My Real-World Journey into Dual-Platform Development

Published on

Shudao Wang is an experienced iOS developer. After transitioning to full-time indie development a few years ago, he created a suite of minimalist apps—such as Zen Flip Clock and Minimal Diary—which have gained a loyal following thanks to their clean design and reliable experience.

Unlike many indie developers who stay fully within the Apple ecosystem, Shudao adopted a dual-platform strategy early on: once the iOS version is stable, he releases the Android version soon after. This naturally made me curious—how does he align functionality? How does he handle platform differences? How do the two ecosystems perform operationally? And what does his revenue mix look like across markets—especially between global markets and mainland China?

With these questions in mind, I invited him to share his experiences, lessons, and missteps in building for both platforms. I hope his story offers a fresh and unexpected perspective to developers who mainly work within the Apple ecosystem.

Just as this article goes to press, Zen Flip Clock has crossed the 4 million download mark on Google Play—a milestone its iOS counterpart reached long ago.

When I first began working on Zen Flip Clock and Minimal Diary, my world revolved entirely around iOS. I had just shifted from full-time employment to indie development, and every day I wished those 24 hours could stretch further. I poured all my energy into polishing the iOS experience.

Maybe it was the environment, maybe it was habit—but like many iOS developers, I carried a bias at the time:

  • “Android is fragmented, inconsistent, and harder to design for.
  • Users don’t pay as much either.
  • Why create extra trouble for myself?”

It sounded reasonable back then. But as my user base grew and feedback accumulated, one truth became clearer: If an app aims to reach more people, avoiding Android is not a long-term option.

So in 2020, I officially stepped into dual-platform development. Looking back, this decision changed not only my products, but also my thinking about both ecosystems.

The First Lesson of Cross-Platform Work: Find the Right Partner—Don’t Shoulder Everything Alone

At first, I seriously considered learning Android development myself. After all, for an indie developer, mastering two platforms sounds like doubling your “combat power.”

But reality taught me a quick lesson:

When you’re maintaining iOS, building new features, fixing bugs, and talking to users, learning a whole new ecosystem from scratch is a guaranteed recipe for burnout.

The Android ecosystem is large and complex. Keeping iOS development fast while writing an Android app that’s “production ready” is far harder than it sounds.

While I was hesitating, I reached out to a former colleague—who is now the Android developer for all my apps. We hit it off immediately, and our collaboration began. I was genuinely relieved: someone competent could take over Android, leaving me time to focus on UX and design.

Our collaboration model was surprisingly simple—almost counterintuitive.

iOS leads, Android follows

Every feature is validated on iOS first.

This stage lets me iterate freely and collect rapid user feedback. Only when I confirm a feature is “worth keeping long-term” do I hand it off for Android implementation.

This prevents time wasted building the wrong thing twice.

I provide recordings, screenshots, and assets—he recreates everything

We have almost no formal requirements documents, and no long review meetings.

Most of the time, I record the animation, send over design assets, and he recreates the feature—often faster than I expect.

We mostly talk via WeChat—no strict deadlines

We tried GitHub Projects and more formal workflows, but eventually realized the simplest method is the most efficient: chat, exchange messages, track commits.

I don’t set hard deadlines. He ships when he’s ready, and I test afterward. This relaxed rhythm has kept our collaboration smooth for years.

Cross-Platform Doesn’t Mean “Make Everything Identical”—It Means Respecting Each Platform’s Boundaries

At the beginning, I was very attached to the idea of “pixel-perfect parity.” Especially for a design-centric app like Zen Flip Clock, I hoped the two platforms could look identical.

But reality quickly showed otherwise: Some platform differences simply cannot be bridged—not through persistence, nor clever hacks.

On iOS: New UI frameworks and interactions every year

Each WWDC brings new components, new animations, and new design language shifts. I try to follow them as much as possible to keep the product modern.

On Android: Fragmentation and manufacturer customizations create structural obstacles

The widget system on Android illustrates this perfectly.

I wanted Zen Flip Clock’s widgets to look the same on both platforms. But in practice:

  • Different manufacturers support widgets differently
  • Rendering behaviors vary
  • Compatibility costs are extremely high

So the Android version has a more basic widget.

Minimal Diary shows the differences even more clearly.

It relies heavily on gestures—swipes, transitions, drag interactions. But iOS and Android gesture systems differ fundamentally. Forcing parity makes the UX awkward, as our tests confirmed.

That’s when I realized: Interaction parity is not the goal—experience parity is.

So our principles shifted:

  • Keep feature logic consistent
  • Respect each platform’s native interaction patterns
  • Don’t force pixel-level uniformity

Sometimes, the Android developer’s adaptations even feel more natural on that platform—those versions stay.

What’s Hardest Isn’t Coding—It’s Everything Around It

People often assume cross-platform development is mostly about writing twice the code. But the true difficulty lies outside the code.

17 languages of localization

Before AI, every text update felt like defusing a bomb.

Zen Flip Clock has a large volume of text, making localization extremely time-consuming. AI eased this pain later, but I still remember the early struggle.

Different minimum OS strategies

  • Zen Flip Clock on iOS: supports down to iOS 14
  • Zen Flip Clock on Android: supports down to Android 6.0 (even 5.0)
  • Minimal Diary on iOS: minimum version raised every year
  • Minimal Diary on Android: stays largely unchanged

This simply reflects user device diversity—and the huge compatibility cost behind Android.

Data Doesn’t Lie: The Value of Android Users Is Greater Than I Imagined

My attitude toward Android wasn’t changed by technology—it was changed by numbers.

A lot of iOS developers share the stereotype: “Android users don’t pay”.

But when I examined my data closely, the truth was far more nuanced.

1. Zen Flip Clock: A dramatic reversal in daily active users

In the early years, iOS DAU was roughly twice that of Android.

But as iOS traffic naturally declined and Android’s long-tail traffic kept growing, Android eventually overtook iOS—now by a factor of two.

This was my first real understanding of Android’s long-tail advantage.

2. Revenue surprises

At its peak, the Android side (Google Play + AdMob + China Android markets) generated revenue comparable to iOS.

I genuinely did not expect this.

3. Minimal Diary: Mainland China’s Android users were surprisingly willing to pay

Especially after a major influencer on Xiaohongshu (rednote) recommended the app, the difference became obvious:

  • Android revenue was 2–3× that of iOS
  • Downloads were 4–5× higher

Which led me to accept something I had underestimated: When a product solves the right problem, the Android market in mainland China has very strong purchasing power.

Three Ecosystems, Three Pricing Strategies

Over time, I realized: No single monetization model fits all platforms.

  • iOS: Free → Donations → One-time purchase → Subscription

    As more themes and animations were added, subscriptions became the most sustainable model.

  • Google Play: One-time purchase + subscription + ads

    In global Android markets, users are less inclined to pay upfront. Ads are a pragmatic way to cover costs.

  • Mainland China Android stores: One-time purchase only—and prices must stay low

    After comparing competitor pricing, it became clear:

    • High prices don’t work

    • There’s little room for increases

    • Competition is extremely intense

Five Years Later: Google Play Console Completely Changed My Perception

When I first opened Google Play Console in 2020, I wasn’t impressed. The layout felt unintuitive, and the navigation seemed a step behind App Store Connect.

But five years later, I have to admit: I misjudged it—Google Play Console has become something I genuinely appreciate.

Two aspects stand out the most:

Speed & Stability: Console feels modern; Connect feels outdated

Accessing App Store Connect from China is notoriously slow—page loads, navigation, charts, everything lags.

Google Play Console, in contrast, loads instantly. With my dashboard bookmarked, it’s literally one click to view all key metrics.

Another crucial difference: login behavior.

App Store Connect frequently logs you out, requiring passwords, codes, and 2FA. Sometimes it feels like being constantly “monitored.”

Google Play Console?

In five years, I’ve only had to log in a handful of times. It quietly stays ready, like a tool that trusts you.

To developers who check metrics often, this “frictionless” experience is priceless.

Policy Communication: Google talks with developers; Apple talks at them

Google hosts quarterly online policy briefings. They’re easy to join—just open the link.

The experience is surprisingly pleasant:

  • Presenters speak naturally and conversationally
  • They use real examples
  • Q&A is responsive
  • Sometimes they even give out small gifts—I’ve received some

Apple’s online sessions, meanwhile, feel much more rigid:

  • You must download an outdated app just to join
  • The video often lags
  • Presenters mostly read the slides verbatim
  • The tone feels standardized and distant

I’m not saying one is objectively better. But to indie developers, the difference in feeling is significant:

  • Google Play feels collaborative
  • App Store feels regulatory

This cultural difference runs deeper than technical distinctions.

Payments: RevenueCat’s Simplicity vs. the Harsh Reality of Mainland China Android Payments

In international markets, RevenueCat is a lifesaver. It handles:

  • Unified in-app purchases across platforms
  • Receipt validation
  • Subscription analytics
  • Online paywall generation
  • A/B testing
  • Cross-platform revenue reports

It solves nearly everything I need.

The situation is very different in mainland China’s Android ecosystem.

Google Play is not fully accessible there, so I ultimately chose WeChat Pay. But this choice comes with a long list of challenges:

  • Running my own backend (Express.js + Parse)
  • Handling payment callbacks
  • Managing account mismatches (login with account A, pay with account B)
  • Dealing with a large volume of user complaints
  • Constantly worrying about lost payment records

These are issues you only understand after stepping into the ecosystem yourself.

Note from Fatbobman

In China’s smartphone ecosystem, the Android market is dominated by several major domestic manufacturers. Each of them operates its own official app store, with different requirements, review rules, and technical specifications. As a result, publishing and maintaining Android apps in China often means navigating multiple parallel ecosystems rather than a single unified platform.

The Mainland China Android Market: High Barriers and Real-World Constraints

To publish on major Chinese Android app stores, you must:

  • Register a legal company
  • Open a corporate bank account
  • Obtain software copyright certificates
  • Complete ICP (Internet Content Provider) filing
  • Handle different review processes, documents, and rules across each store

This is far more work than App Store or Google Play.

There was a time when I said: “Android isn’t worth it.”

But if you want real reach and revenue in mainland China, these hurdles are compulsory. Once you get through them, the path becomes smoother.

How Our Long-Term Collaboration Stays Productive

Today our workflow is extremely stable:

  • Simple, lightweight requirement notes
  • Communication mostly through WeChat
  • No rigid deadlines
  • Testing happens when he pushes commits
  • Android is allowed to adapt to local patterns—not forced to match iOS

In this setup, we don’t need complex tools.

Trust is our highest-efficiency resource.

Dual-Platform Work Isn’t About Copying—It’s About Understanding and Adapting

These years taught me something important: iOS and Android aren’t just two platforms—they’re two different worlds.

  • iOS offers consistency and cohesive design
  • Android offers scale and long-tail growth
  • iOS users often pay more readily
  • Mainland China’s Android users can have stronger purchase behavior
  • iOS relies on system-level features
  • Android requires heavy compatibility work

Dual-platform development isn’t easy. But as feedback accumulates and understanding deepens, I’ve come to realize: When you truly understand the differences—rather than judge them—your product naturally becomes more complete.

Weekly Swift & SwiftUI highlights!