Cross-Platform Maintenance for Open-Source Apps: Ecosystem Friction Between iOS and Android, and Engineering Solutions

A Real Dilemma Facing Open-Source Developers

In the open-source community, a perennial and still-unresolved topic has surfaced once again: How do you maintain the same open-source app across both iOS and Android? A Reddit developer recently posted a candid rant about the friction that Apple's "walled garden" imposes on independent developers and open-source maintainers.

The core argument is straightforward: distribution on Android is dead simple — just upload the compiled binary to GitHub or F-Droid and you're done. Even publishing to Google Play, while "annoying, is manageable." iOS, on the other hand, is a completely different story: builds signed with a free Apple developer account expire after just 7 days, and if that weren't bad enough, proper distribution requires a recurring annual fee of $99. For open-source projects built purely out of passion with no profit motive, this policy feels fundamentally misaligned.

The post resonated widely because it touches on a fundamental tension between the open-source ethos and commercial platform rules: open source means free distribution with zero barriers, while the App Store's closed mechanisms are inherently at odds with that principle.

Three Layers of Friction Apple's Ecosystem Creates for Open-Source Developers

Signature Expiration: The 7-Day Shackle

For developers unwilling to pay, Apple allows the use of a free developer account to self-sign and sideload apps. But these signatures are valid for only 7 days. This means users must re-sign and reinstall the app every week, or it simply stops launching.

To understand this limitation, you need to grasp the underlying logic of iOS code signing. iOS requires all code running on a device to be verified through Apple's chain of trust — a mechanism rooted in Apple's extreme emphasis on security, designed to prevent malware and unauthorized code execution. Free developer accounts use a personal Development Certificate, which Apple limits to a 7-day validity period with a maximum of 3 simultaneously signed apps. This is essentially positioned as a debugging tool, not a distribution mechanism. Paid accounts grant signing validity of up to one year, along with the ability to distribute through TestFlight or the App Store. This tiered design reflects Apple's strict control over distribution privileges.

For ordinary users, re-signing every week is a nearly unacceptable user experience. For developers, it renders the "bypass the App Store and distribute directly" path practically useless. By contrast, once an APK is installed on Android, it works indefinitely. F-Droid even provides a complete open-source app store ecosystem.

F-Droid is a fully community-driven free and open-source software (FOSS) app store for Android, established in 2010. Unlike Google Play, every app on F-Droid must be open source, and F-Droid's servers recompile each app from source (Reproducible Build), ensuring the distributed binary matches the published source code exactly — fundamentally eliminating the possibility of developers injecting malicious code during the build stage. F-Droid requires no developer registration or fees; developers simply submit their app's metadata and source repository URL to apply for listing. This model has made it a core distribution infrastructure for the open-source community on mobile and a quintessential example of Android's open ecosystem.

The $99 Annual Fee Barrier

To move beyond the 7-day limitation, achieve stable distribution, or list an app on the App Store, developers must join the paid Apple Developer Program at $99 per year with continuous renewal required. For a hobby project with zero revenue, this is a genuine ongoing financial burden.

The original poster called this policy "nuts." From Apple's perspective, the paywall serves as a mechanism to filter developer quality and maintain ecosystem security. But from the open-source perspective, it silently bars a vast number of excellent free projects from iOS. This is one of the key reasons why many well-known open-source Android apps have never had an iOS version. For comparison, Google Play's developer registration fee is a one-time $25 with no renewal required — a one-time cost that's far easier for open-source projects to absorb.

The Closed Nature of Distribution Channels

Android has stores like F-Droid dedicated purely to open-source software, and users can freely install apps from third-party sources. iOS, by contrast, has long had the App Store as its only official distribution channel. While the EU's Digital Markets Act (DMA) has begun requiring Apple to allow third-party app stores, this change is currently limited to specific regions, and iOS distribution remains highly closed on a global scale.

The EU Digital Markets Act was passed in 2022 and came into force in March 2024, aiming to curb monopolistic behavior by large tech companies (defined as "Gatekeepers"). Apple was designated as a Gatekeeper and required to allow third-party app stores and alternative payment methods on iOS. In response, Apple introduced an "Alternative Marketplace" mechanism in iOS 17.4, but attached stringent conditions: third-party store operators must provide a €1 million letter of credit, and app developers must pay €0.50 per installation as a "Core Technology Fee" after exceeding 1 million downloads. These conditions have been criticized as "Malicious Compliance" — formally meeting the regulatory requirements while using prohibitive financial thresholds to prevent genuine competition. As of now, these changes apply only to users in the EU's 27 member states; iOS users everywhere else can still only get apps through the App Store.

Engineering Strategies for Cross-Platform Code Reuse

The original poster raised another key question with significant engineering value: When codebases across two platforms must stay in sync, how should you architect things to make the migration from Android to iOS as painless as possible?

The approach outlined was quite professional and worth studying for any cross-platform developer:

Isolate Core Logic into Platform-Agnostic Modules

Extract core business logic into pure Kotlin modules with no dependencies on any Android platform APIs. These modules can then theoretically be reused on iOS through Kotlin Multiplatform (KMP).

Kotlin Multiplatform is a cross-platform development framework from JetBrains. Its core philosophy isn't "Write Once, Run Anywhere" but rather "Share What You Want." KMP allows developers to write platform-agnostic code — business logic, data models, network requests, etc. — as shared modules (Common Modules), then use the expect/actual mechanism to provide platform-specific native implementations. On iOS, Kotlin code compiles to native binaries via Kotlin/Native and can interoperate directly with Swift and Objective-C. As of late 2024, KMP has reached stable release status. Google has listed it as one of the officially recommended cross-platform solutions for Android, and companies like Netflix, McDonald's, and VMware have adopted it in production.

Dependency Inversion: Isolate Platform-Specific Capabilities Behind Interfaces

Hide platform-specific capabilities like storage and encryption behind interfaces. Core logic depends only on abstract interfaces, while concrete implementations are provided separately by each platform. This dependency inversion design is the cornerstone of cross-platform architecture and minimizes platform coupling.

The Dependency Inversion Principle (DIP) is the fifth of the SOLID object-oriented design principles, proposed by Robert C. Martin ("Uncle Bob"). Its core idea is: high-level modules should not depend on low-level modules — both should depend on abstractions; abstractions should not depend on details — details should depend on abstractions. In the cross-platform development context, this means core business logic (high-level modules) should not directly call platform-specific APIs like Android's SharedPreferences or iOS's Keychain (low-level modules). Instead, you define an abstract storage interface (e.g., IKeyValueStore) with platform-specific implementations. This architectural pattern, combined with KMP's expect/actual mechanism or dependency injection frameworks (like Koin), allows the vast majority of business logic code to be fully shared across platforms — switching platforms requires only replacing the concrete interface implementations.

Standardizing UI and Concurrency

• Commit to building the UI with pure Jetpack Compose, leaving room for a potential future migration to Compose Multiplatform;
• Standardize concurrency and state management to avoid a hodgepodge of async approaches throughout the codebase, enabling unified handling of threading and state when going cross-platform.

Compose Multiplatform is a cross-platform UI solution developed by JetBrains based on Google's Jetpack Compose declarative UI framework. It allows developers to use the same Compose code to build user interfaces across Android, iOS, desktop (Windows/macOS/Linux), and Web. On Android, Compose is already Google's recommended primary UI framework with a highly mature ecosystem. However, on iOS, Compose Multiplatform's iOS target only entered Beta in 2024, and there are still known performance differences and native control integration issues — for example, deep integration with iOS native navigation, Accessibility, and system-level gestures remains incomplete. This is the technical uncertainty behind the poster's "MAYBE painless" qualification.

Regarding concurrency standardization, in the Kotlin ecosystem this typically means fully adopting Kotlin Coroutines and Flow as the unified async programming model. Kotlin Coroutines have full multiplatform support in KMP, but the iOS concurrency model differs from Android's — early versions of Kotlin/Native had strict memory model restrictions (e.g., objects couldn't be freely shared between threads). While the new memory manager has significantly improved this, developers still need to be mindful of platform-specific behaviors like iOS Main Dispatcher scheduling.

If all these principles are followed, the migration to iOS could theoretically become "MAYBE painless" — but the poster also candidly admitted they hadn't actually taken this step yet, so it all remains theoretical.

The Gap Between Engineering Decoupling and Ecosystem Reality

This is precisely the crux of the issue: Architectural decoupling can indeed enable business logic reuse, but the real pain point has never been the logic layer — it's the platform boundary.

Kotlin Multiplatform can share logic, but on the UI front, Compose Multiplatform's maturity on iOS is still evolving. Even if the code runs, you still can't escape Apple's signing, certificates, and the $99 annual fee. In other words, engineering effort can reduce code maintenance costs, but it cannot eliminate the distribution costs imposed by ecosystem policies.

It's worth noting that KMP isn't the only cross-platform path. Flutter (from Google, using Dart) and React Native (from Meta, using JavaScript/TypeScript) are also mainstream choices, but none of them can bypass iOS distribution restrictions. In fact, regardless of which cross-platform technology framework you adopt, distribution on iOS must go through Apple's signing system — this is an OS-level requirement that no application framework can circumvent.

For open-source maintainers, common coping strategies in the community include:

• Community crowdfunding or foundation-backed developer account fees to enable legitimate App Store listing. For example, some well-known open-source projects raise funds through platforms like Open Collective or GitHub Sponsors specifically to cover infrastructure costs like Apple developer accounts;
• Charging a small fee on the App Store (e.g., a nominal purchase price) to cover costs while keeping the source code freely available — users can still compile and install it themselves. This "free source, paid binary" model is increasingly accepted in the open-source community because it doesn't violate any mainstream open-source license (MIT, GPL, etc.) — open source has never meant free distribution of binaries;
• Prioritizing Android users, only launching an iOS version when sufficient resources are available. This is the most common strategy in practice, and many excellent open-source mobile apps (like NewPipe, AntennaPod, etc.) remain Android-only to this day.

Conclusion: The Reality Tax on Open-Source Ideals

This post reflects a widespread sense of helplessness that independent developers and the open-source community face when confronting platform giants. Android's relatively open ecosystem stands in stark contrast to iOS's highly closed strategy, and the latter's annual fees and signing restrictions are essentially a "reality tax" levied on open source's ideal of zero-barrier distribution.

This tension is nothing new. Back in the desktop era, Linux distribution package managers (like Debian's APT or Arch's Pacman) achieved truly decentralized, zero-cost free distribution. F-Droid on mobile attempts to carry on this tradition on Android, while iOS's closed ecosystem represents a fundamentally different philosophy — Apple believes strict review and distribution control are necessary costs for ensuring user security and experience consistency, but these costs fall disproportionately on open-source developers without commercial revenue.

For developers planning to go cross-platform, the wise approach is: Decouple core logic from platform-specific capabilities as early as possible at the engineering level, while maintaining clear-eyed expectations about iOS distribution costs. Technology can make migration smoother, but the barriers imposed by commercial rules are often the real watershed determining whether an open-source project can reach iOS users.