📑 Table of Contents

Indie Dev Diary: Android vs HarmonyOS Challenges

📅 · 📁 Industry · 👁 3 views · ⏱️ 9 min read
💡 An indie developer navigates complex API crashes and widget fragmentation while preparing Sticki for multi-platform launch.

Indie Developer Weekly 173: The Endless Pitfalls of Android and HarmonyOS Dual Development

Sticki's Android launch faces critical delays due to unexpected API instability and widget fragmentation issues. Developers must now choose between slow but stable third-party libraries or risky native solutions.

This week's update from an independent developer highlights the harsh reality of cross-platform mobile development in 2026. Despite initial confidence, core features like subject segmentation and home screen widgets presented significant technical hurdles. The journey reveals that even mature platforms like Android still harbor hidden compatibility traps.

Key Facts

  • ML Kit Limitations: Google's ML Kit for subject segmentation remains in beta after two years without updates.
  • API 35 Crashes: Native Android抠图 (cutout) functions crash on API 35 virtual machines despite documentation claims.
  • ONNX Runtime Choice: The developer selected ONNX Runtime for stability, accepting slower processing speeds.
  • Widget Fragmentation: iOS, Android, and HarmonyOS handle home screen components with incompatible architectures.
  • RevenueCat Integration: Payment gateway setup was delayed by core functional bugs rather than billing logic.
  • Launch Delay: The Google Play Store release is postponed until critical stability issues are resolved.

The Subject Segmentation Dilemma

The first major obstacle involved implementing subject segmentation, commonly known as background removal or 'cutout' functionality. The developer initially relied on Google's native ML Kit, expecting a seamless integration process. However, this feature has remained in a beta state for over two years, raising concerns about its long-term support and reliability.

Testing revealed a critical failure when running on API 35 virtual machines. Although official documentation claimed full support for this version, the application crashed consistently during image processing tasks. This discrepancy between documentation and reality forced a reevaluation of the entire technical stack.

Evaluating Third-Party Alternatives

To resolve the crash issue, the developer investigated third-party packages available within the Flutter ecosystem. One prominent solution utilized ONNX Runtime for machine learning inference. Unlike the native ML Kit, this package received regular updates and maintained strong compatibility across various Android versions.

The primary drawback of the ONNX Runtime approach was performance speed. Image processing took significantly longer compared to the native Google solution. However, after extensive comparative testing, stability emerged as the non-negotiable priority. A crashing app offers zero value to users, regardless of how fast it processes images.

Consequently, the decision was made to adopt the ONNX Runtime-based solution. This choice ensures that the Sticki application remains functional for all users, even if it sacrifices some processing efficiency. It serves as a reminder that in mobile development, reliability often trumps raw performance metrics.

Widget Architecture Across Platforms

The second challenge involved developing home screen widgets, which are essential for user engagement and quick access to app features. While the concept appears universal, the implementation details vary drastically between operating systems. The developer noted that iOS widgets, Android widgets, and HarmonyOS service cards share similar goals but differ fundamentally in architecture.

Each platform requires distinct coding approaches and lifecycle management strategies. For instance, iOS provides a relatively unified framework for widget creation, whereas Android demands handling multiple screen sizes and density variations. HarmonyOS introduces yet another layer of complexity with its unique service card mechanisms.

Fragmentation Increases Development Costs

This fragmentation means developers cannot simply write code once and deploy it everywhere. Each platform requires specific adjustments and rigorous testing. The time investment for creating a single widget feature effectively triples when targeting iOS, Android, and HarmonyOS simultaneously.

For indie developers with limited resources, this overhead is substantial. It diverts attention from core product innovation to mere compatibility maintenance. The lack of standardization forces teams to maintain separate codebases or complex abstraction layers, increasing the likelihood of bugs.

Industry Context: The State of Mobile AI

The struggles faced by this indie developer reflect broader trends in the mobile technology landscape. Major tech companies often prioritize flagship devices and latest OS versions, leaving older APIs and niche use cases under-supported. Google's stagnation on ML Kit's beta status exemplifies this shift in focus.

Meanwhile, the rise of HarmonyOS adds another dimension to global mobile development. As Huawei expands its ecosystem internationally, developers must prepare for a tri-polar market dominated by iOS, Android, and HarmonyOS. This diversification challenges the traditional dual-platform development model.

The Role of Cross-Platform Frameworks

Frameworks like Flutter aim to bridge these gaps, but they cannot entirely abstract away hardware-specific limitations. Machine learning tasks, in particular, remain deeply tied to underlying system capabilities. When native APIs fail, developers must rely on heavier runtime environments like ONNX, impacting app size and performance.

What This Means for Developers

The experience underscores the importance of robust fallback mechanisms in mobile applications. Relying solely on native APIs can lead to sudden breakages when operating systems update. Integrating flexible libraries like ONNX Runtime provides a safety net against such volatility.

Furthermore, early testing on target APIs is crucial. Waiting until the final stages of development to verify API compatibility can result in costly delays. Proactive identification of deprecated or unstable features allows teams to pivot strategies before launch deadlines become critical.

Looking Ahead

As Sticki moves toward its eventual launch, the focus shifts to optimizing the ONNX Runtime implementation. Future updates may include performance tuning to reduce the latency introduced by the third-party library. Additionally, the developer plans to address the widget complexities for each platform individually.

The timeline for the Google Play Store release remains tentative. Stability takes precedence over speed, ensuring that early adopters receive a polished experience. Meanwhile, preparations for the HarmonyOS version continue, aiming to leverage the growing ecosystem in Asian markets.

Gogo's Take

  • 🔥 Why This Matters: This case study highlights the hidden costs of cross-platform development. For startups and indie devs, choosing between native speed and third-party stability is a critical architectural decision that defines product viability. Ignoring platform fragmentation leads to user churn.
  • ⚠️ Limitations & Risks: Relying on beta native APIs like ML Kit is a high-risk strategy. The crash on API 35 demonstrates that documentation cannot be trusted blindly. Furthermore, slower processing via ONNX Runtime may impact user retention if image editing feels laggy compared to competitors.
  • 💡 Actionable Advice: Do not wait for QA to test API compatibility. Integrate automated tests for specific OS versions early in the sprint. Consider using ONNX Runtime or similar portable ML solutions for critical features to ensure stability across fragmented Android ecosystems. Always budget extra time for widget development on each platform.