Aplicações para telemóvel, construídas de forma a que a lógica possa ser verificada sem telemóvel.

Não. Nenhuma das nossas aplicações está na App Store ou no Google Play, e é correto perguntar isso primeiro. O que podemos mostrar: cinco destinos de aplicação definidos no mesmo projeto, dos quais quatro para iPhone e um para macOS, que compilam e se instalam no simulador, mais a suite de lógica de 160 verificações, executada a pedido à sua frente. O bloqueio na publicação é `DEVELOPMENT_TEAM` vazio na configuração do projeto, ou seja, a ausência de um identificador de equipa do Apple Developer Program. No Mac existe uma identidade de assinatura válida, do tipo desenvolvimento — chega para instalação em dispositivo próprio, não para a loja.

De nada, se pedir uma prova de publicação — não a temos e não a inventamos. O que pode verificar é o resto da cadeia: código que compila, testes que passam, ficheiros de confidencialidade presentes, permissões declaradas, ícones e versões configurados. O passo que falta é uma inscrição paga num programa Apple, feita na empresa que detém a aplicação. Num projeto de cliente, essa conta é do cliente e é aberta no início, exatamente para que não seja ela o passo que surpreende alguém no fim.

Depende dos sensores. Se a aplicação lê movimento, saúde, Bluetooth ou câmara em tempo real, nativo — essas interfaces são da plataforma e qualquer camada intermédia acrescenta latência e novas formas de falhar. Se a aplicação é, essencialmente, formulários, cálculos e ecrãs de resultado, um único código cobre iOS, Android e browser a partir de um repositório. Temos ambas as variantes no portefólio e escolhemo-las com argumento escrito, não por defeito.

Através de código comum, sim: o mesmo projeto Expo gera build para Android, com o ícone adaptativo e a variante monocromática exigida pelo sistema já configurados. Android nativo, em Kotlin, não temos no portefólio — se um projeto o exigir, dizemo-lo antes, não depois da assinatura.

Pelo facto de o núcleo não depender do ecrã. Os ficheiros de análise compilam-se separadamente, com o compilador Swift, e correm como programa no Mac. A suíte atual tem 160 verificações em 16 etapas e executa-se em poucos segundos. O que não pode ser verificado assim — como se sente uma vibração, como fica um ecrã num telemóvel específico, como se comportam os auscultadores quando saem de uma orelha — testa-se no dispositivo, e diz-se o que é o quê.

Só se os aprovar, tipo por tipo, no ecrã da Apple, e apenas os declarados. No código, a política é explícita para cada tipo de dado: alguns ficam apenas no telefone, outros são lidos do HealthKit, outros podem ser escritos de volta como treino ou como sessão de relaxamento. Não se faz diagnóstico, e os dados não chegam até nós.

Ficam no telefone. Na aplicação iOS de referência no nosso portefólio não existe qualquer chamada de rede — a pesquisa por `URLSession` nas fontes desse alvo devolve zero resultados. O histórico é gravado num ficheiro local e pode ser apagado na aplicação. Quando um projeto precisa de servidor, nós construímo-lo, mas não o colocamos por reflexo.

Começa com uma verificação de compatibilidade, não com uma proposta: que versão de plataforma visa, que dependências tem e quais delas ainda são mantidas, se o build se reproduz numa máquina limpa, quem detém a conta de programador e as chaves. Há projetos em que a resposta honesta é que reescrever o núcleo custa menos do que mantê-lo.

No macOS, sim, e a partir do mesmo núcleo: no nosso repositório principal, o alvo de macOS reutiliza quinze ficheiros de lógica da aplicação de iPhone, como fontes partilhadas. Windows não está no portefólio.