A founder wraps a working Solana web app in a Trusted Web Activity and submits it.
On the test phone, the wallet button does nothing. No error. No log line.
The Solana Mobile docs say that wrapper "breaks MWA wallet connections." The fix is a different shell.
Save this checklist. Three paths, their scope cost, and a store charging 0% platform fees.
The 3 Paths and What Each Costs in Scope
Pick the path before the framework. The wrong order doubles a short build.
Path 1: Mobile-first app (React Native or Kotlin)
You build an Android app with Mobile Wallet Adapter (MWA) baked in. The user taps connect, a wallet sheet opens, and the signed transaction comes back. It is the only path with a native store listing and no wrapper.
Scope cost: a separate codebase, Android signing keys, store assets, and publisher KYC. You also need an iOS plan.
Path 2: Web app or PWA with MWA, wrapped for the store
You keep one Next.js codebase, register MWA with @solana-mobile/wallet-standard-mobile, and wrap it with Solana Mobile's WebView shell CLI. The publishing-a-web-app recipe asks for wallet-standard-mobile v0.5.1 or later, so the library detects the shell.
Scope cost: small. One codebase, one listing. The web apps page supports Chrome for Android and Chrome PWAs, and it states that "MWA is not available on any iOS browser."
Path 3: Web app, no store
You ship to the browser and skip the store. Android users still get MWA through Chrome, and iOS users get the wallet flow you already have.
Scope cost: lowest. You give up store discovery and the Seeker audience for the fastest release loop. Our web development services page covers how we scope this version.
The iOS caveat on all three paths
The wallet signing on iOS recipe is blunt. "Mobile Wallet Adapter is not available on iOS, and deep links are not a viable replacement for it." iOS suspends backgrounded apps, which kills the local connection.
The same page warns that heavy deep-link use may hurt App Store review. Its alternatives are wallet-as-a-service or passkeys. Our recommendation: ship Android with MWA first, and keep iOS on the web until the user base justifies a second custody model.
Mobile Wallet Adapter: Integrate Once, Every Wallet Works
MWA is the piece every path shares. The protocol page calls it "an open protocol that defines how mobile apps communicate with wallet apps on the same device."
Your app sends an Android intent. The wallet opens a local WebSocket, shows its own approval UI, and returns the signature.
The current React Native path is @wallet-ui/react-native-kit on @solana/kit, or @wallet-ui/react-native-web3js if you still use web3.js v1. Both were at 4.4.1 on npm when we checked.
Both depend on @solana-mobile/mobile-wallet-adapter-protocol 3.0.1, released 2026-10-09 per the MWA releases page. The sample below targets @wallet-ui/react-native-kit 4.4.1. It is the provider plus a connect button, which is all a first wallet flow needs.
// App.tsx - targets @wallet-ui/react-native-kit 4.4.1
import { Button } from 'react-native'
import {
createSolanaDevnet,
MobileWalletProvider,
useMobileWallet,
} from '@wallet-ui/react-native-kit'
const cluster = createSolanaDevnet({ url: 'https://api.devnet.solana.com' })
const identity = {
name: 'My Solana App',
uri: 'https://mysolanaapp.com',
icon: 'favicon.png', // resolved relative to uri, shown in the wallet prompt
}
function ConnectButton() {
const { account, connect, disconnect } = useMobileWallet()
if (account) return <Button title="Disconnect" onPress={disconnect} />
return <Button title="Connect Wallet" onPress={connect} />
}
export default function App() {
return (
<MobileWalletProvider cluster={cluster} identity={identity}>
<ConnectButton />
</MobileWalletProvider>
)
}Two details cost teams a day each. MWA uses Kotlin native modules, so Expo Go does not work. The React Native installation page requires a custom development build, and the crypto polyfill must load before any Solana library.
On native Android, the Kotlin installation page pins the Kotlin client library at 2.0.3. You call walletAdapter.transact(sender) to authorize and sign inside one block.
Seed Vault: You Don't Integrate It, You Talk to It Through MWA
Founders often budget a "Seed Vault integration." For an app, that line item does not exist.
The Seed Vault page describes a system service on Seeker that keeps keys in the processor's secure execution environment. Every signature is gated by a fingerprint or PIN, and your app never touches the keys.
The user's Seed Vault Wallet is an MWA-compatible wallet, so the connect flow above works with it unchanged. The SDK itself is for wallet builders. The Seed Vault SDK repo says it is "primarily intended for consumption by developers of Android wallet apps."
One release note matters if you build large transactions. The Seeker MR10 build "increased transaction size limit to 4,096 bytes to fully support Solana Transaction V1" (MR10 notes). If your flow batches many instructions, test on a device running that build.
Seeker Status and Why It Changes the Decision
On 2026-10-27, solanamobile.com/seeker listed the device as "Available Now | Free Shipping" with an order button. The page gives no price or unit count, and we won't invent one. The listed hardware includes 8 GB of RAM, 128 GB of storage, and a fingerprint sensor on the power button that gates Seed Vault.
Two things make Seeker a distribution decision rather than a novelty:
- The dApp Store is fee-free. The FAQ states that "Solana Mobile Inc. does not currently collect any fees on in-app purchases, app purchases, or subscriptions."
- Seeker owners hold a Seeker Genesis Token, an NFT "minted once per device as proof of verified Seeker ownership" (Seeker page). You can gate perks on it.
A newer SDK is worth knowing too. Seeker Connect connects your app "directly to a Solana Mobile certified device's own wallet," built on the MWA libraries. It swaps the wallet picker for a direct branded connection, with React Native, Kotlin, and web packages listed as available.
You do not need the phone to build. The docs say, "You don't need a Seeker to build for Seeker," and any Android device or emulator with an MWA wallet installed is enough for testing.
The dApp Store Submission Path, as a Checklist
Submission runs through a web Publisher Portal. The submit-new-app guide is the source for every step below, and it is where the scope hides.
- Sign up at publish.solanamobile.com and create a publisher profile (individual or organization).
- Complete KYC or KYB. You can skip it at profile creation, but you cannot add an app until it is approved.
- Connect a Solana wallet with a small amount of SOL. It becomes your publisher wallet "for all future submissions of this app," so use a fresh one and back it up.
- Enter the package name. It "must exactly match the application ID in your APK" and "can't be changed later." Save, approve the transaction, and your App NFT is minted.
- Prepare assets: a 512x512 icon with no transparency, a 1200x600 banner, and 4 to 8 screenshots, plus public HTTPS pages for your site, terms, and privacy policy.
- Build a release APK signed with your release key, supporting arm64-v8a and at most 2 GB. Debug builds are rejected.
- Create a release, upload the APK, write the "What's New" note, and approve each wallet transaction. Skipping one stops the submission.
Review results arrive "typically within 3-4 business days." For later versions, the publishing CLI can push an update from CI with one command. It needs an API key, which you generate in the Publisher Portal under Settings and store as a CI secret.
# Targets @solana-mobile/dapp-store-cli as documented on 2026-10-27
npm install -g @solana-mobile/dapp-store-cli
export DAPP_STORE_API_KEY=<your-api-key> # from publish.solanamobile.com, Settings > API keys
dapp-store --apk-file ./app-release.apk \
--keypair ./publisher-keypair.json \
--whats-new "Bug fixes and performance improvements"The KYC step and the one-way package name are the two items that stall submissions. Put them in week one, not launch week.
FAQ
Do I need a Seeker phone to build a Solana mobile app?
No. The Solana Mobile docs state that any Android device or emulator with an MWA-compatible wallet is enough for development and testing. Solana Mobile also says it is "not running a developer device program for the Seeker," so plan on your own test hardware.
Can a PWA be listed on the Solana dApp Store?
Yes. You wrap the web app with Solana Mobile's WebView shell CLI to produce a signed APK, then submit it through the standard Publisher Portal flow. If the app connects to wallets, update @solana-mobile/wallet-standard-mobile to v0.5.1 or later, so MWA works inside the shell.
Does Mobile Wallet Adapter work on iPhone?
No. The protocol page states that "iOS does not support MWA due to platform restrictions on inter-app communication." iOS needs a different custody model, such as a wallet-as-a-service provider or passkeys. That is a separate design decision from your Android build.
What does the store charge?
Nothing at the moment. The official FAQ says Solana Mobile Inc. does not currently collect fees on in-app purchases, app purchases, or subscriptions. You still pay Solana network fees for the App NFT and release transactions from your publisher wallet.
How long does store review take?
The submission guide says results typically arrive within 3 to 4 business days by email. If you have heard nothing after 5 business days, the guide points you to an App Review Inquiry in the Solana Mobile Discord.
Decide the Path Before You Fund the Build
Our Zeta Mad Wars Competition case study is a useful contrast. We built the Mad Wars Leaderboard for Zeta Markets as an xNFT, an app format that runs inside a wallet rather than shipping as a standalone store app. It shipped in Next.js, TypeScript, and web3.js over three months, with all requested features delivered.
That is a fourth distribution path, and one we would not pick first today. Wallet-hosted apps reach the users of one wallet. MWA plus the store reaches every compliant wallet on Android, including the Seed Vault Wallet, from one integration.
Three questions settle it. Whether you need Seeker users on day one, whether an iOS audience must sign, and whether one web codebase can carry both. Try the checklist above against your current app before you answer them.
Our Solana development service settles that choice up front, and an Architecture Sprint ($5K to $8K) is where it happens before any build starts. If you want the scope written down with the versions that apply to your stack, talk to us about your Solana mobile build.
