FAQ

Open Mobile Hub (OMH) is an initiative by the Linux Foundation aimed at transforming app development with open source. It simplifies app development and enables services choice in the mobile ecosystem.

• App Developers: Especially those who desire alternatives to default OS services (like Google Maps, Apple IAP) and are interested in developing for devices beyond GMS Android and iOS.
• Service Providers: This includes providers of modules such as maps, authentication, in-app purchases (IAP), ads, and cloud storage, who are seeking broader app adoption for their services.
• Device Manufacturers/Platforms: Particularly those outside the mainstream who aim to make it easier for app developers to be compatible with their platforms.

• Limitations for App Developers: Established operating systems tightly integrate services (like Google IAP and Apple IAP), limiting third-party alternatives. These challenges are amplified on alternative platforms like FireOS by Amazon and HorizonOS by Meta. This often forces developers to maintain multiple codebases, which can be a significant burden.
• Service Distribution for Service Providers: App developers often default to OS-provided services, making it challenging for other service providers to distribute their services as replacing default services requires rewriting code. There are also 100+ SDKs with fragmented interfaces.
• Difficulty for Device Manufacturers/Platforms: Manufacturers of non-mainstream devices struggle to attract mobile app developers due to steep learning curves associated with their technologies.

OMH 2.0, launched in 2024, supports:

• Auth: Google Account, Microsoft Account, Facebook, Dropbox.
• Maps: Google Maps, Azure Maps, Mapbox, OpenStreetMap, Apple Maps.
• Cloud Storage: Google Drive, OneDrive, Dropbox. These modules are supported on Android Native and React Native (iOS and Android).

The MVP (Minimum Viable Product) components for OMH Maps include Markers, Polygons, and Polylines, with more features planned for future releases.

OMH 3.0+ plans to:

• Contribute Android modules to cross-platform frameworks like Flutter and React Native.
• Introduce new modules based on community requests, including In-App Payment, Identity Credential & Wallet.
• Support additional platforms like Kotlin Multiplatform and Compose Multiplatform.
• Focus on contributing to community modules to unify support for native and cross-platform frameworks.

OMH provides plug-and-play APIs that offer significant efficiency gains compared to traditional SDKs:

• Faster Learning Curve: Onboarding time for developers is 60-80% faster (1-2 weeks vs. 3-6 weeks).
• Faster Cycle Time: Time to develop a feature across multiple providers is 2-3x faster (3-4 weeks vs. 8-12 weeks).
• Faster Lead Time: From feature request to production is 2-3x faster (4-5 weeks vs. 10-14 weeks).
• More Frequent Releases: Higher deployment frequency due to faster updates and one integration.
• Less Testing & Debugging Effort: 50-70% less effort (1-2 weeks vs. 4-6 weeks).
• Reduced Maintenance Overhead: 30-50% reduction as there’s only one API to update instead of multiple SDKs.

OMH features an extensible two-layer architecture, providing cross-platform and native support. It includes interfaces for various services (Maps, Auth, In-App Purchases) that can integrate with community modules and underlying service providers.

The source code for OMH is available on GitHub, https://github.com/openmobilehub. This includes repositories for Maps SDK (React Native Maps, Android Maps), Cloud Storage SDK (React Native Storage, Android Storage), and Authentication SDK (React Native Authentication, Android Authentication).

OMH 3.0 will focus on extending community modules for cross-platform In-App Purchases. The goal is to provide alternative cross-platform solutions for IAP on non-GMS devices, addressing the current limitation where IAP mainly supports Android GMS (Google Play Billing) and iOS (Apple’s StoreKit). Unlike previous OMH modules, the IAP support will be a seamlessly integrated capability within the broader OMH ecosystem rather than a separate SDK.