--- title: "Desenvolvedor mobile júnior: como conseguir a primeira vaga" url: "https://eu.dev.br/carreira/desenvolvedor-mobile-junior-brasil/" markdown_url: "https://eu.dev.br/carreira/desenvolvedor-mobile-junior-brasil.MD" description: "Guia prático para entrar em desenvolvimento mobile júnior: escolha de stack, projetos que provam entrega, leitura das vagas e preparação para entrevista." date: "2026-08-22" author: "" --- # Desenvolvedor mobile júnior: como conseguir a primeira vaga Guia prático para entrar em desenvolvimento mobile júnior: escolha de stack, projetos que provam entrega, leitura das vagas e preparação para entrevista. **Para conseguir uma vaga de desenvolvedor mobile júnior, escolha uma porta — Android, iOS ou multiplataforma — e publique um aplicativo pequeno que outra pessoa consiga instalar, testar e entender.** Você não precisa dominar Kotlin, Swift, Flutter e React Native ao mesmo tempo. Precisa provar fundamentos de programação, consumo de API, estado, persistência, tratamento de erro, Git e capacidade de explicar decisões. No Brasil, o título varia: **desenvolvedor mobile júnior**, **Android developer junior**, **iOS junior**, **engenheiro de software mobile**, **Flutter developer** e **React Native developer** podem apontar para rotinas parecidas. O catálogo recente do eu.dev.br mostra oportunidades de entrada com Kotlin, Kotlin Multiplatform, iOS, Android, Flutter e stacks híbridas, mas também muita vaga sênior. Por isso, busque pela tecnologia e leia a senioridade no corpo do anúncio — não conclua que “mobile não contrata júnior” depois de ver três resultados experientes. Comece pelas [vagas mobile abertas](/vagas/?q=mobile) e repita a busca por [Android](/vagas/?q=android), [iOS](/vagas/?q=ios), [Flutter](/vagas/?q=flutter) e [React Native](/vagas/?q=react+native). Se você ainda está escolhendo área, compare este caminho com [frontend júnior](/carreira/frontend-junior-brasil/) e [backend júnior](/carreira/backend-junior-brasil/). Mobile é desenvolvimento de produto com restrições próprias: tela pequena, rede instável, bateria, permissões, versões de sistema e publicação em loja. ## resposta rápida: o que fazer para entrar em mobile júnior Use esta sequência: 1. escolha **Android nativo**, **iOS nativo** ou **multiplataforma**; 2. aprenda a linguagem principal da porta escolhida; 3. faça um aplicativo simples sem depender de tutorial passo a passo; 4. consuma uma API e trate loading, vazio, erro e tentativa novamente; 5. salve algum dado localmente; 6. escreva testes para pelo menos uma regra importante; 7. publique código, README, capturas de tela e instruções de execução; 8. gere uma versão instalável ou distribua por um canal de teste; 9. adapte currículo e portfólio aos verbos do anúncio; 10. aplique também para estágio, software júnior e vagas que usam “engenharia mobile” no título. A meta não é construir “o próximo iFood”. É terminar um produto pequeno com qualidade suficiente para sustentar uma conversa técnica. ## Android, iOS, Flutter ou React Native: qual escolher? Não existe uma resposta universal. A escolha depende do equipamento que você tem, do mercado que quer acessar e da base que já conhece. | porta | base principal | vantagem para começar | atenção | |---|---|---|---| | Android nativo | Kotlin, Android Studio, Jetpack Compose | ecossistema grande e possibilidade de testar em muitos aparelhos Android | fragmentação de versões, ciclo de vida e detalhes da plataforma | | iOS nativo | Swift, Xcode, SwiftUI | caminho direto para apps Apple e boa integração com a plataforma | desenvolvimento exige macOS e o custo de entrada pode ser maior | | Flutter | Dart, Flutter | uma base para Android e iOS, interface consistente e prototipação rápida | você ainda precisa entender comportamento de cada plataforma | | React Native | JavaScript ou TypeScript, React Native | aproveita base de React e aproxima web e mobile | bridge, dependências nativas e diferenças de plataforma não desaparecem | | Kotlin Multiplatform | Kotlin e APIs das plataformas | compartilha lógica sem obrigar toda interface a ser igual | costuma fazer mais sentido depois de alguma base nativa | Se você já conhece React e TypeScript, React Native pode reduzir a distância até o primeiro app. Se já programa em Kotlin ou quer vagas Android, siga no nativo. Se quer criar uma demonstração para as duas plataformas e não tem base web forte, Flutter é uma porta razoável. Se você tem Mac e mira o ecossistema Apple, Swift e SwiftUI formam o caminho mais direto. Não escolha apenas pela pergunta “qual paga mais?”. A primeira barreira é conseguir aprender, publicar e explicar. Uma stack menos badalada com projeto concluído vale mais do que quatro stacks listadas sem aplicativo instalável. ## o que uma pessoa desenvolvedora mobile júnior faz A rotina de entrada costuma incluir: - implementar tela a partir de design e componentes existentes; - conectar a interface a uma API; - tratar estado de carregamento, sucesso, vazio e erro; - corrigir bug reproduzido em aparelho ou versão específica; - escrever teste unitário ou de interface sob orientação; - abrir pull request e responder ao code review; - acompanhar métricas de erro e logs; - ajustar acessibilidade, navegação e comportamento de teclado; - colaborar com produto, design, backend e QA; - apoiar uma versão enviada para canal interno, beta ou loja. Você não precisa chegar sabendo publicar sozinho um aplicativo bancário. A empresa, porém, espera que você entenda que mobile não é só “fazer tela bonita”. A interface vive em cima de rede, dados, permissões, ciclo de vida e integrações. Um botão pode disparar uma chamada lenta, falhar sem internet, ser tocado duas vezes ou receber resposta depois que a pessoa saiu da tela. Essa capacidade de pensar nos estados diferencia um projeto de portfólio de uma cópia visual. ## a base técnica que aparece nas vagas ### linguagem e fundamentos Aprenda a linguagem da sua stack o suficiente para explicar: - tipos e nulidade; - funções e estruturas de dados; - orientação a objetos ou composição; - imutabilidade; - tratamento de erro; - operações assíncronas; - organização em módulos ou camadas. No Android, isso geralmente significa Kotlin. No iOS, Swift. No Flutter, Dart. Em React Native, JavaScript ou TypeScript — com preferência prática por TypeScript quando o projeto cresce. ### interface e estado Você precisa saber transformar requisito em tela e manter a interface coerente quando os dados mudam. Isso inclui: - componentes reutilizáveis; - navegação; - formulário e validação; - lista, detalhe e paginação simples; - estado local e estado vindo da rede; - loading, vazio, erro e retry; - adaptação a tamanhos e orientação quando necessário. Não decore nomes de arquiteturas sem entender o problema. MVVM, unidirectional data flow e outras estruturas existem para separar responsabilidade e tornar mudança e teste menos dolorosos. Em entrevista, explicar por que você tirou a chamada de rede da tela é melhor do que recitar siglas. ### rede e dados Um projeto mobile júnior convincente costuma demonstrar: - requisição HTTP; - leitura e envio de JSON; - autenticação simulada ou real quando o escopo justificar; - timeout e falha de conexão; - persistência local; - cache ou funcionamento parcial sem rede; - cuidado básico com dado sensível. Não coloque token secreto no repositório nem armazene senha em texto puro. Se o projeto usa uma chave de demonstração, explique como configurar por variável ou arquivo ignorado pelo Git. ### Git, teste e depuração Saber abrir branch, fazer commits legíveis e criar pull request é parte da vaga. Também é importante conseguir: - reproduzir bug; - ler stack trace; - usar breakpoint e log; - isolar hipótese; - escrever teste de regra de negócio; - descrever no PR o que mudou e como testou. Os guias de [GitHub para júnior](/carreira/github-junior/) e [primeiro pull request](/carreira/primeiro-pull-request-dev-junior/) ajudam a organizar essa prova. ## três projetos de portfólio que funcionam para mobile ### 1. aplicativo de acompanhamento de candidaturas Crie um app para registrar empresa, vaga, etapa, data e próximo passo. Ele combina com um problema real de quem busca emprego e permite mostrar: - formulário com validação; - lista e filtros; - persistência local; - edição e exclusão; - estado vazio; - lembrete local opcional; - acessibilidade e modo escuro, se você conseguir manter o escopo. Não precisa ter login ou backend na primeira versão. Um app local bem terminado é melhor que autenticação quebrada e cinco telas incompletas. Você pode usar a lógica da [planilha de candidaturas](/carreira/planilha-candidaturas-junior/) como referência de campos, sem copiar o artigo inteiro para dentro do produto. ### 2. cliente de uma API pública Escolha uma API estável e crie busca, lista, detalhe e favoritos. Mostre: - loading; - paginação; - falha de rede; - tentativa novamente; - cache de favoritos; - teste de transformação de dados; - README com origem e limites da API. Evite o projeto que funciona apenas na sua internet e trava numa tela branca quando o servidor responde erro. O tratamento de falha é parte central da demonstração. ### 3. aplicativo com recurso do aparelho Use câmera, localização, armazenamento, notificação ou sensor em um escopo pequeno. Por exemplo: registrar locais de estudo, guardar foto e nota de uma atividade ou lembrar uma rotina. Esse projeto prova que você entende permissões e comportamento da plataforma. Mas não peça todos os acessos na abertura. Explique por que a permissão é necessária e trate a recusa sem quebrar o app. Para escolher e encerrar escopo, use [três projetos para portfólio](/carreira/portfolio-3-projetos/) e [como escrever README de projeto júnior](/carreira/readme-projeto-junior/). ## o que colocar no README e na demonstração Seu repositório deve responder sem reunião: 1. o que o aplicativo faz; 2. qual problema resolve; 3. qual stack usa; 4. como executar; 5. quais decisões técnicas você tomou; 6. como testou; 7. quais limitações permanecem; 8. onde baixar ou assistir à demonstração. Inclua capturas de tela reais e, se possível, um vídeo curto mostrando o fluxo. Para Android, você pode disponibilizar uma versão de demonstração por release do GitHub quando isso for seguro. Para iOS, a distribuição é mais restrita; um vídeo, instruções claras e TestFlight quando disponível ajudam. Em qualquer stack, não publique credencial, dado pessoal de usuário ou arquivo de assinatura. O vídeo não substitui o código. O código não substitui uma demonstração que funciona. Os dois juntos reduzem o trabalho de quem avalia. ## como escrever o currículo para vaga mobile júnior No topo, use o cargo-alvo e a stack principal: ```text desenvolvedor Android júnior | Kotlin · Jetpack Compose · APIs REST ``` ou: ```text desenvolvedora mobile júnior | Flutter · Dart · testes · integração com API ``` Depois, transforme projeto em evidência. **fraco:** > Conhecimento em Android, iOS, Flutter, React Native, Firebase, AWS e metodologias ágeis. **melhor:** > Desenvolvi app Android em Kotlin e Jetpack Compose para acompanhar candidaturas, com persistência local, filtros e testes das regras de mudança de etapa; publiquei código e APK de demonstração no GitHub. **melhor para React Native:** > Criei aplicativo em React Native e TypeScript que consome API paginada, mantém favoritos no aparelho e trata estados de carregamento, vazio e falha de rede. Se você vem de outra área, traduza experiência anterior. Atendimento pode provar investigação, escrita e contato com usuário. Design pode provar consistência de interface e colaboração. QA pode provar reprodução de bug. Backend pode provar API e autenticação. Não invente experiência mobile profissional: apresente a ponte real. Revise a base com [primeiro CV tech sem experiência](/carreira/primeiro-cv-sem-experiencia-tech/) e adapte título, resumo e primeiro projeto para cada anúncio. ## como procurar vaga sem depender do título exato Crie alertas com combinações diferentes: - `desenvolvedor mobile júnior`; - `mobile developer junior`; - `engenheiro de software mobile junior`; - `Android developer junior`; - `Kotlin junior Android`; - `iOS developer junior`; - `Swift junior`; - `Flutter developer junior`; - `React Native junior`; - `estágio desenvolvimento mobile`; - `software engineer entry level mobile`. Busque em [vagas de tecnologia](/vagas/), páginas oficiais de carreira, LinkedIn, Gupy, Greenhouse e Lever. Aplique também para estágio e programas de formação quando você tem vínculo educacional. O guia de [estágio em engenharia de software](/carreira/estagio-engenharia-de-software/) ajuda a preparar essa rota. Leia com atenção a senioridade. Algumas plataformas classificam mal a vaga, e alguns anúncios juntam “júnior” no filtro com responsabilidades de pleno ou sênior. Confira autonomia, anos de experiência, liderança, arquitetura e responsabilidade por publicação. Use [como identificar vaga fake júnior](/blog/fake-junior-como-identificar/) quando título e escopo entram em conflito. ## remoto, híbrido e o problema do aparelho Desenvolvimento mobile pode ser remoto, mas teste em hardware importa. Antes de aceitar ou avançar, pergunte: - a empresa fornece Mac para desenvolvimento iOS? - fornece aparelhos físicos ou usa fazenda de dispositivos? - existe ajuda de custo para internet e equipamento? - quais versões mínimas de Android ou iOS o time suporta? - o trabalho é remoto de qualquer estado ou ligado a um escritório? - como o time compartilha builds para teste? - quem acompanha a pessoa júnior no onboarding? Não compre um Mac caro apenas porque viu uma vaga de iOS. Primeiro entenda se essa porta faz sentido para você e se a empresa fornece equipamento. Para Android e multiplataforma, um computador limitado também pode sofrer com emulador; testar em aparelho físico e controlar o escopo pode ser mais viável no início. Se remoto é obrigatório, leia [como filtrar vaga remota júnior](/carreira/filtrar-vaga-remota-junior/) e [trabalho remoto sem experiência](/carreira/trabalho-remoto-sem-experiencia-tech/). “Mobile” não transforma uma vaga híbrida em home office. ## o que costuma cair no processo seletivo ### conversa sobre o projeto Prepare uma explicação de cinco minutos: - problema; - usuário; - stack; - arquitetura em linguagem simples; - erro mais difícil; - como você testou; - limite atual; - próximo passo. A pessoa entrevistadora pode pedir para abrir um arquivo e explicar o fluxo da tela até a API. Conheça seu próprio código. ### fundamentos de programação Podem aparecer estruturas de dados básicas, nulidade, concorrência ou assincronismo, HTTP, orientação a objetos, funções e testes. A cobrança deve ser compatível com entrada, mas “só sei fazer layout” costuma ser insuficiente. ### exercício prático Um teste razoável pode pedir uma lista consumindo API, uma tela com formulário ou correção de bug pequeno. Controle o escopo, escreva instruções e documente o que ficou fora. Se a tarefa exige aplicativo comercial completo em um fim de semana, questione o limite e proteja seu tempo com o método do [teste técnico júnior](/carreira/teste-tecnico-junior/). ### perguntas específicas de mobile Exemplos: - o que acontece quando a rede cai? - como você evita duas requisições ao tocar duas vezes? - onde salvaria um dado sensível? - como trataria rotação ou recriação de tela? - como investigaria um crash que acontece só em um aparelho? - qual parte da lógica você testaria primeiro? - como garantiria acessibilidade de um botão apenas com ícone? Você não precisa responder como arquiteto sênior. Mostre raciocínio: reproduzir, observar, formular hipótese, testar e comunicar limite. ## erros que atrasam a primeira vaga 1. **Estudar quatro stacks ao mesmo tempo.** Você termina sem profundidade e sem app pronto. 2. **Copiar clone de tutorial.** A entrevista revela rápido quando você não escolheu nada. 3. **Fazer só a tela feliz.** Sem loading, vazio e erro, o projeto não parece produto. 4. **Ignorar Git e README.** Quem avalia não consegue rodar nem entender. 5. **Prometer Android e iOS sem testar nas duas plataformas.** Multiplataforma não elimina diferença real. 6. **Guardar segredo no repositório.** Isso demonstra descuido, não velocidade. 7. **Aplicar só para “mobile júnior remoto”.** O título pode ser engenharia de software, Android, iOS ou estágio. 8. **Desistir porque o feed tem muito sênior.** Mobile tem menos vagas de entrada que algumas áreas, mas existem portas júnior e estágio; a busca precisa ser mais específica. 9. **Comprar equipamento antes de validar a rota.** Escolha stack e mercado antes de assumir custo alto. 10. **Não conseguir explicar o próprio estado e fluxo de dados.** Interface pronta não substitui entendimento. ## plano de 30 dias para sair da teoria ### semana 1 — escolha e base - escolha uma stack; - configure ambiente e rode um app vazio no aparelho ou simulador; - revise linguagem, componentes e navegação; - leia dez anúncios e anote requisitos repetidos. ### semana 2 — fluxo principal - construa lista, detalhe e formulário; - conecte API ou persistência local; - implemente loading, vazio e erro; - faça commits pequenos e legíveis. ### semana 3 — qualidade e publicação - escreva testes de uma regra importante; - revise acessibilidade básica; - trate falha de rede e entrada inválida; - escreva README; - gere vídeo e versão de demonstração. ### semana 4 — candidatura - atualize currículo e LinkedIn; - crie alertas por stack e por títulos em inglês; - aplique para vagas compatíveis; - treine a apresentação do projeto; - registre respostas na [planilha de candidaturas](/carreira/planilha-candidaturas-junior/); - faça [debrief](/carreira/debrief-teste-tecnico-junior/) de cada teste ou entrevista. Trinta dias não garantem contratação nem transformam iniciante em especialista. Servem para produzir uma evidência completa e começar a receber retorno real do mercado. ## perguntas frequentes ### preciso aprender Android e iOS para conseguir vaga mobile? Não. Para a primeira vaga, escolha uma plataforma ou framework e aprofunde. Entender que Android e iOS têm comportamentos diferentes ajuda, mas dominar as duas bases nativas não é pré-requisito universal. ### Flutter ou React Native é mais fácil para júnior? Depende da sua base. React Native tende a ser mais direto para quem já conhece React e TypeScript. Flutter oferece uma experiência integrada para quem aceita aprender Dart. O melhor para o portfólio é aquele em que você consegue terminar, testar e explicar um app — e que aparece nas vagas que você pretende disputar. ### preciso publicar na Play Store ou App Store? Não é obrigatório, mas alguma forma de demonstração ajuda. Código público, vídeo, capturas de tela e build instalável já provam bastante. Publicação em loja adiciona processo e custo; faça quando trouxer aprendizado real, não apenas um selo. ### faculdade é obrigatória? Nem toda vaga júnior exige graduação, mas estágio normalmente depende de vínculo com instituição de ensino. Faculdade também aparece como filtro em algumas empresas. Quando não houver exigência, portfólio, fundamentos e processo técnico podem sustentar a candidatura. ### dá para começar mobile com computador fraco? Dá, com limites. Emuladores podem consumir muita memória; aparelho Android físico pode ajudar. Desenvolvimento iOS exige macOS. Antes de investir, teste o ambiente e escolha um projeto pequeno. Em processo seletivo, pergunte se a empresa fornece equipamento. ### preciso saber backend? Você não precisa ser backend júnior também, mas deve entender HTTP, JSON, autenticação, status de resposta e contrato de API. Criar uma API simples pode ajudar, porém não deixe o backend engolir o objetivo do projeto mobile. ### como provar experiência sem emprego anterior? Mostre aplicativo concluído, decisões explicadas, histórico de commits, testes, tratamento de erro e uma demonstração instalável ou em vídeo. Projeto não vira “anos de experiência”, mas vira evidência concreta de preparo para uma posição de entrada. ## próximo passo Escolha agora uma porta: Android, iOS, Flutter ou React Native. Depois abra as [vagas mobile](/vagas/?q=mobile) e anote quais tecnologias e entregas aparecem nos anúncios compatíveis com júnior ou estágio. Seu próximo projeto deve provar esse núcleo — não tentar impressionar com todas as stacks. A primeira vaga de desenvolvedor mobile júnior não exige um aplicativo gigantesco. Exige uma história técnica coerente: você escolheu um problema, construiu o fluxo, tratou falhas, testou uma regra, documentou o projeto e consegue explicar o que faria melhor. Termine essa prova, publique e comece a aplicar antes de inventar a quinta tela que ninguém pediu.