A dApp Store
Publicação e distribuição na Solana Mobile dApp Store.
Receita
- Build release APK/AAB com keystore assinado.
- Prepare ícones, screenshots e URL de política de privacidade.
- Submeta via portal de publisher Solana dApp Store (veja docs.solanamobile.com/dapp-store).
Quando usar isso:
- Distribuir apps alvo Seeker/Saga fora de estratégia somente Google Play.
- Descoberta crypto-native para usuários Solana.
- Co-marketing com hardware Solana Mobile.
Exemplo de Trabalho
# Production Android build (Expo)
eas build --platform android --profile production
# Artifacts needed for submission:
# - signed APK or AAB
# - app icon 512px
# - feature graphic and screenshots
# - short + long description
# - support URL and privacy policyO que isso demonstra:
- Use pipelines EAS ou Gradle release - não builds debug.
- Metadata deve mencionar requisito de carteira MWA.
- Declare uso de rede (mainnet/devnet) honestamente na descrição.
Mergulho Profundo
Como Funciona
- Conta publisher registra identidade do desenvolvedor.
- Processo de revisão verifica conformidade com política.
- Atualizações enviam novas versões APK com changelog.
- Coordene com anúncios de features Seeker quando aplicável.
Armadilhas
- Keystore debug no release - rejeição ou falha de segurança. Correção: chaves de assinatura de produção em secrets EAS.
- Política de privacidade ausente - submissão bloqueada. Correção: hospede página HTTPS de política.
- Coleta de dados RPC não declarada - violação de política. Correção: divulgue endereços de carteira e analytics.
- MWA quebrado em device de revisão - rejeição. Correção: teste em hardware de referência.
- Version code não incrementado - atualização rejeitada. Correção: versionCode Android monotônico.
Alternativas
| Alternativa | Use Quando | Não Use Quando |
|---|---|---|
| Google Play | Audiência Android em massa | Descoberta nativa SMS |
| APK sideload direto | Beta fechado | Confiança do consumidor |
FAQs
App Router?
Providers em client layout.tsx; páginas misturam componentes server + client.
Secrets?
Env server somente para keypairs; NEXT_PUBLIC_ para URLs RPC.
kit 7.0.0?
Todos os exemplos usam @solana/kit, não web3.js v1.
Carteira?
Assinatura somente em componentes client.
Cache?
Revalide leituras on-chain com cuidado - chain é fonte da verdade.
Actions?
Endpoints HTTPS retornando JSON Solana Actions.
Mobile?
App React Native separado com MWA.
Testes?
Surfpool para integração; mock RPC em testes unitários.
Mainnet?
Arquivos env separados e IDs de programa.
Erros?
Decodifique logs de simulação para mensagens voltadas ao usuário.
Relacionados
- Construindo um dApp Mobile - pipeline de build
- Noções Básicas de Solana Mobile - visão do stack
- Seed Vault e Segurança - chaves Seeker
Versões da stack: Esta página foi escrita para Agave 4.1.1, Solana CLI 3.0.10, Anchor 0.32.1, anchor-lang 0.32.1, Rust 1.91.1, @solana/kit 7.0.0, Surfpool 0.12.0 e LiteSVM 0.6.x.