Desenvolvimento de Aplicativo Mobile com React Native e Typescript

Busca profissional freelancer com experiência em **React Native e TypeScript** para desenvolver o frontend visual e navegável de seu aplicativo financeiro para **Android e iOS**.
Já possui um anteprojeto com as principais telas, jornadas e identidade visual, que deverá ser utilizado como referência para o desenvolvimento.
Nesta primeira etapa, **não haverá integração com APIs, backend ou sistemas bancários**. Saldos, clientes, chaves, limites, extratos e transações serão fictícios. O objetivo é entregar um aplicativo instalável, visualmente consistente e navegável de ponta a ponta, preparado para futura integração.
Entregar o frontend completo do aplicativo como um produto visual demonstrável, permitindo que a equipe valide as telas, navegação e experiência do usuário antes da integração com as APIs bancárias.
Ao final, o aplicativo deverá ser instalado em Android e iOS e permitir a simulação das principais jornadas utilizando exclusivamente dados fictícios e recursos locais.
O profissional será responsável por:
* Criar o projeto React Native com TypeScript para Android e iOS.
* Implementar as telas conforme o anteprojeto
* Criar componentes reutilizáveis e padrão visual consistente.
* Implementar navegação completa entre as telas.
* Criar dados fictícios, mocks e cenários simulados.
* Implementar estados de carregamento, vazio, sucesso, falha, pendência e indisponibilidade.
* Implementar validações e máscaras locais.
* Entregar builds periódicos para demonstração e homologação.
* Trabalhar no repositório indicado pela Two-s
* Documentar instalação, execução, estrutura e geração dos builds.
### Tecnologias desejadas
* React Native + TypeScript.
* Expo Development Build, quando tecnicamente adequado.
* React Navigation ou equivalente.
* React Hook Form e Zod, ou alternativas justificadas.
* React Native Testing Library.

## Regra desta etapa

Não serão realizadas chamadas HTTP ou WebSocket, nem integrações com Core Banking, dict, spi, banco central, lydians ou qualquer sistema externo.

Também não serão utilizados dados reais de clientes, credenciais, certificados, banco de dados remoto ou transações financeiras reais. Todas as operações deverão ser simuladas localmente.

## Jornadas e telas

### 1. Acesso e início

* Login com senha fictícia.
* Recuperação e redefinição de senha simuladas.
* Biometria visual.
* Tela inicial com identificação, saldo e movimentações fictícias.
* Ocultar/exibir saldo.
* Menu inferior: Início, Extrato, Pix e Suporte.

### 2. Pix e transferências

* Área Pix.
* Transferência por cpf, cnpj, telefone, e-mail e chave aleatória.
* Transferência por banco, agência, conta e cpf/cnpj.
* Favoritos e contatos recentes.
* Valor, descrição, data e confirmação.
* Pix Copia e Cola.
* Fluxo visual de QR Code.
* Resultado de sucesso, falha, pendência e cancelamento.
* Comprovante fictício e compartilhamento simulado.
### 4. Extrato e devolução
* Extrato com diferentes movimentações.
* Detalhamento da transação.
* Comprovante.
* Devolução total ou parcial simulada.
### 5. Chaves e limites Pix
* Consulta, cadastro e exclusão de chaves.
* cpf, cnpj, telefone, e-mail e chave aleatória.
* Portabilidade e reivindicação de posse.
* Limites por beneficiário e período.
* Solicitação de aumento ou redução.
* Limite noturno.
* Beneficiários diferenciados.
* Gerenciamento de favoritos.
### 8. Contestação e MED
* Acesso pelo suporte.
* Orientação inicial sobre MED.
* Seleção de transação fictícia.
* Escolha do motivo e descrição.
* Simulação de envio de documento.
* Protocolo fictício.
* Consulta do andamento da contestação.
A navegação deverá ser completa: todas as jornadas precisam permitir avançar, voltar, cancelar e concluir, sem telas sem saída, links quebrados ou ações sem retorno visual.
## Dados simulados e arquitetura
Todos os dados deverão ser fictícios e centralizados. Não será aceito espalhar nomes, saldos, chaves e transações diretamente pelos componentes.
Os cenários deverão contemplar, no mínimo:
* Conta e saldo fictícios.
* Pix enviado, recebido, devolvido, pendente, bloqueado e cancelado.
* Extratos e diferentes tipos de lançamentos.
* Chaves Pix.
* Limites por perfil e período.
* MED em diferentes situações.
O código deverá ser estruturado pensando na integração futura. Fixtures, mocks, modelos TypeScript e serviços simulados deverão permanecer separados da interface, permitindo substituir posteriormente os dados fictícios por APIs reais sem reconstrução das telas.
* Código-fonte completo no repositório da Two-s
* Aplicativo navegável Android e iOS.
* Builds periódicos para homologação.
* Componentes reutilizáveis.
* Fixtures, mocks e modelos centralizados.
* Testes acordados para componentes e navegação principal.
* README com instalação, execução, estrutura e geração de builds.
* Handover e apresentação técnica final.