Building a Solana Mobile App: The Pains of the App Store Duopoly

As recently announced, SOL Strategies has launched a dedicated mobile application for Solana staking. Although we are not the first to build a Solana mobile application, the number of Solana-native apps available on the Apple App Store and Google Play remains extremely limited. Given our investment into Solana’s success, we aim to contribute by sharing technical insights and challenges we encountered during the development and submission process.

Starting with a Minimum Viable Product (MVP)

In January 2025, we released a minimal version of what would later become the Orangefin app. Functionaly, the MVP was barebones: users could connect via their Phantom or Solflare wallet and manage their stake accounts.

The architecture at this stage was straightforward: a React Native application integrated with Solana Mobile’s mobile-wallet-adapter library. Most components functioned smoothly, although we did identify a Phantom transaction flow bug. While this took a bit to isolate, we were able to find a pretty simple workaround that worked well for our needs.

Planning for Cross-Platform Distribution

Following the MVP launch, we began planning for broader distribution on the Apple App Store and Google Play.

Despite Solana Mobile devices running Android, porting the app to Google Play was not trivial, due to:

1. Wallet Dependency: The MVP relied on users already having a funded Phantom or Solflare wallet, which comes preinstalled on Solana Mobile devices. App Store guidelines (especially Apple’s) mandate that testers must be able to evaluate all core functionality without external dependencies. Requiring testers to import wallets, fund them, and connect would have likely led to immediate rejection.
2. Deep Linking Limitations: Android deep linking works reasonably well (aligning with mobile-wallet-adapter design), but iOS universal links are not well-suited for an app like ours, leading us to abandon the native deep link approach after testing. Solana Mobile’s actually wrote a blog on this very issue.

Ultimately, we came to the conclusion that the only viable path was to build a self-contained wallet application, optionally allowing Android users to connect their existing Solana wallets.

Managing Private Keys

Transitioning to a standalone wallet introduced the challenge of securely managing private key material. This is a complex challenge where the cost of doing it incorrectly is extremely high.

We evaluated several architectures, including self-custody SDKs and key management solutions. After researching and testing several different solutions, we ended up selecting Privy. Our decision was based on:

1. Cryptographic Design: Privy’s Shamir Secret Sharing-based key sharding model, with multiple external audits.
2. Key Portability: Full private key export functionality for users.
3. Developer Experience: Their SDK was very easy to integrate.
4. Operational Control: Robust admin panel for custom configuration.
5. User Experience: Social login flows enabling “normie-friendly” onboarding.
6. Cross-Platform Support: Unified credential management across web and mobile.
7. Fiat Onramp Integration: Support for direct SOL purchases via Moonpay and Coinbase Pay.
8. Proven Adoption: Trusted by crypto ecosystem players like Jupiter and OpenSea.

Integrating Privy was simple, however we did have to switch away from bare React Native to Expo. The reason for this was while almost every feature worked perfectly inside of our bare React Native app, the OAuth flow did not due to some deep linking issues. Switching to Expo resolved this.

Building Web and Mobile with a Unified Codebase

Another architectural goal of ours was to share as much code as possible between our web and mobile apps.

With Expo and react-native-web, we were mostly able to accomplish this and deployed our web app at https://app.orangefin.ventures.

Initially, we started with a single monorepo for both platforms. This introduced a number of challenges however such as:

• Divergent SDK APIs: Privy’s web and mobile libraries differ in both structure and method names, requiring a lot of branching logic.
• Polyfill Inconsistencies: Certain polyfills necessary for mobile (but not web) complicated build processes.
• Platform-Specific Navigation: Navigational patterns differed substantially between web and mobile.
• Dependency Bloat: Accumulated platform-specific dependencies increased repo size significantly, which was worrisome from a security perspective.

Ultimately, we shifted to a model of shared UI component libraries across otherwise distinct web and mobile codebases.

Engaging a Third Party Auditor

Due to the fact that our application expanded in scope, we felt it was necessary to engage an auditor to pentest our mobile application. We ultimately settled on Halborn, one of the most well-respected names in this space.

The Halborn team was extremely helpful and helped us identity some issues that were able to patch before launch. Our full audit can be found https://www.halborn.com/audits/sol-strategies/mobile-app-ios–android-blackbox-3e52f5.

App Store Submission: Lessons Learned

While building the app was relatively smooth, submitting it to the Apple App Store and Google Play was anything but.

iOS

Achieving approval for version 1.0.0 required 15 separate builds and nearly a full month of iteration, given Apple’s 24-48-hour review cycles.

Primary causes of rejection:

• Regulatory Disclosure Requests: Apple requested detailed information about our “cryptocurrency exchange services,” triggered by our Moonpay and Coinbase Pay fiat onramps. We provided legal documentation verifying that purchases were handled exclusively by licensed third parties.
• Authentication Testing Failures: Despite successful testing internally by nearly every employee at the company, Apple’s testers flagged issues “Sign in with Passkey.” We made numerous attemps to resolve these issues such as better error handling and more explicit reviewer instructions, however none of these seemed to work, and we were never able to replicate the issues that Apple flagged.
• Account Deletion Requirement: Apple once rejected the app for not providing an in-app method to “delete accounts,” in accordance with their policies for apps offering account creation. While cryptocurrency wallets cannot be deleted in a traditional sense, we implemented functionality allowing users to delete their associated records from Privy’s database. This preserves user custody over private keys and funds while satisfying Apple’s compliance requirements. Meeting this mandate required developing a lightweight server-side API, which had not been part of the original project scope.

Our primary regret regarding the iOS launch was the inability to secure approval for passkey support at launch, unlike our Android version. We intend to reintroduce passkey functionality in a future release.

Android

While Google was less picky about the functionality of the app itself, they were EXTREMELY picky about the store metadata.

While our app was in “Closed Testing” we received a warning for “impersonation”. The email below is the exact email we received along with the screenshot they referenced.

We were quite confused upon receiving this email because we saw nothing we were impersonating. Because of this, we decided to appeal. Our appeal was ultimately rejected because they accused us of impersonating Solana.

The following is an excerpt of the email we received after our appeal request.

“During review, we found that elements of your app’s store listing violate the Impersonation policy. We don’t allow apps that mislead users by impersonating someone else (for example, another developer, company, or entity) or another app.

Make sure not to imply that your app is related to or authorized by someone that it isn’t. And be careful not to use app icons, descriptions, titles, or in-app elements that could mislead users about your app’s relationship to someone else or another app.

Your app is currently impersonating the brand/app “Solana” without authorization. You can refer to the attached screenshot for additional information.

If you are authorized to use the copyrighted content, please reply with verifiable documentation (PDF) with a letterhead that shows your app is authorized, or a proper legal license with a signed document from both parties.”

At this point, our app was permanently suspended from the Play Store. We had to create a whole new store listing with a whole new bundle id, signing keys, and more.

To resolve this issue, we ultimately changed the Play Store name from “Orangefin: Solana Staking” to “Orangefin: SOL Staking.”

We got rejected a few more times after getting past the “impersonation violation”, mostly due to more store metadata issues. For example, at one point we had a sentence in our app store description that said, “The first dedicated app for staking SOL.” This goes against Google Play store guidelines.

Overall, Google was extremely picky over store metadata but nowhere near as picky about functionality as Apple. Google was much slower to review each submission taking about 48–72 hours each time, which pushed back our launch date pretty significantly.

Solana Mobile

We’d be remiss not to mention our experience with the Solana Mobile store. Luckily, we can keep this section pretty short. After submitting our app to the Solana Mobile store, the Solana Mobile team created a Telegram chat with us and their team where we were able to get in direct contact with the team and testers. Getting our new update published took <24 hours from when we pushed to the store from start to finish. Additionally, the Head of Marketing also joined the chat, agreeing to help promote our app on X as well. The process of submitting to the Solana Mobile store was extremely pleasant, and the team was extremely helpful.

Summary

The most time consuming part for launching our mobile application was actually getting the app approved on both iOS and Android. Despite this, we are very encouraged by the experience we had with Solana Mobile and hope it continues to gain adoption.

While building for iOS and Android was certainly painful and tedious, we do want to emphasize that with enough motivation and patience, it is possible to distribute your app across both platforms.

Our hope is that by sharing our experience, it helps the next Solana-native team have a smoother experience during the submission process.