Lancei o app iOS do DIALØGUE meses atrás como um port do produto web. Depois reconstruí quase tudo como um app nativo.
Ele já está no ar na App Store — se você ficou curioso, vai lá fuçar. O resto deste post é sobre o que mudou, e por quê.
A diferença parece só uma questão de palavra até você segurar as duas versões na mão. A primeira era o app web encolhido pra caber no celular: as mesmas abas, o mesmo assistente de criação, o mesmo dashboard. Compilava, rodava, passou na revisão da Apple. E parecia um site vestido com fantasia de app.
Um app web encolhido pra caber no celular continua sendo um app web. Ser nativo não é uma camada de tinta por cima do seu layout web — é um contrato diferente com o aparelho. Esse contrato foi justamente o que eu tinha pulado, e reconstruir pra honrá-lo mudou as abas, o áudio, a tela de escuta, o comportamento offline e a forma como o app abre. Aqui está o que isso significou de verdade, tela por tela.
O port era um dashboard
A primeira versão partia do princípio de que o trabalho do app era expor o gerador. O DIALØGUE faz podcasts com IA, então o raciocínio foi: jogue toda superfície da web na tela e está pronto.
O que você ganha com isso é um dashboard. Cinco abas, um assistente de vários passos, painéis pra tudo. Ninguém abre um app de podcast pra operar um dashboard. As pessoas abrem pra transformar uma ideia em áudio, pra ouvir algo que criaram, ou pra começar um programa que já rodaram antes. A interface portada protegia o layout do app web. Ela não protegia esses três trabalhos.
Então a reconstrução começou pela primeira coisa que você vê.
Três abas, porque o celular castiga abas
O app antigo abria com cinco abas: Library, Studio, Create, Credits, Profile. É isso que portar o app web te dá — toda superfície da web vira uma aba.
O app reconstruído tem três: Listen, Create, You.
Duas abas não sobreviveram. Credits deixou de ser um destino — ninguém abre um app pra ficar olhando pra um saldo. Foi pra dentro de "You", e o único momento que realmente importa, ficar sem crédito bem na hora de gerar, agora abre uma tela de compra exatamente ali. Studio deixou de ser um lugar. Virou Series — uma configuração salva (apresentadores, tom, formato, idioma, padrão de fonte) que mora dentro do Create e aparece no Listen como uma coleção, em vez de uma aba se passando por sala de controle. Library e Profile viraram os mais simples "Listen" e "You".
No desktop, uma aba a mais é de graça. No celular, cada aba é um imposto sobre a atenção. A reconstrução quitou parte dessa dívida.
Áudio do jeito que o iOS espera
É aqui que "ser nativo é um contrato" deixa de ser abstrato.
O app portado não era analfabeto em áudio. Ele já aparecia na tela bloqueada com play, pause e pular, pausava numa ligação e parava quando você tirava o fone. Isso é o básico, e estava lá.
O que ele não conseguia fazer era se comportar como um app de áudio de verdade depois que a tela travava. Você não conseguia arrastar o cursor de reprodução pela tela bloqueada. Não tinha capa ali — só texto. Não tinha botão de AirPlay, nem timer de soneca, e pular era fixo em quinze segundos, gostando você ou não.
A reconstrução fechou essa lacuna com a plataforma, não contornando ela. A tela bloqueada agora mostra a capa dinâmica do episódio e uma barra que você pode arrastar pra qualquer ponto. Tem AirPlay, um timer de soneca que vai abaixando o volume aos poucos em vez de cortar seco, e um intervalo de pular que você define de dez a sessenta segundos — que daí também controla os botões da tela bloqueada, porque os controles do sistema têm que bater com os do app. A sessão de áudio se declara como áudio falado, então o sistema operacional trata aquilo como fala, não como música.
Nada disso é glamouroso. E esse é justamente o ponto. No celular, um áudio que ignora a tela bloqueada e o AirPlay não é "minimalista". Ele está quebrado exatamente nos momentos em que as pessoas de fato escutam — andando, dirigindo, com o celular no bolso.
Uma transcrição que só um podcast de IA consegue construir
Aqui está a parte que é genuinamente nossa, não só boa higiene de iOS.
Enquanto um episódio toca, o app mostra uma transcrição sincronizada: a linha atual fica destacada, a tela rola sozinha pra mantê-la centralizada, e você pode tocar em qualquer linha pra saltar direto pra aquele momento. Um app de podcast genérico não consegue fazer isso de verdade, porque ele não sabe o que foi dito e quando. O DIALØGUE sabe — ele gerou o roteiro, então já conhece a estrutura do episódio.
O detalhe honesto de engenharia é que uma linha só fica tocável quando o áudio tem o tempo exato de cada trecho. Quando o tempo é aproximado, a linha ainda aparece, só que não dá pra saltar, e o app não finge o contrário. Esse mesmo tempo de cada trecho desenha as marcas de capítulo direto na barra de reprodução, então você consegue passar os olhos por um episódio como áudio, mas com um mapa do que o sistema fez. A transcrição ainda mostra qual apresentador disse cada linha, porque o roteiro foi escrito como um diálogo entre dois apresentadores.
Essa é a diferença entre pregar uma transcrição num player e tratar o roteiro gerado como a fonte da verdade pra toda a experiência de escuta.
Duas coisas fazem isso funcionar, e nenhuma das duas aparece na tela. O backend carimba cada trecho com seu tempo de início e fim e marca se o tempo é exato ou só estimado — então o app pode deixar você tocar numa linha de tempo exato e, discretamente, recusar fingir numa de tempo estimado. E a sua posição de reprodução fica salva no servidor, não só no aparelho, então "continuar de onde parou" vale até quando você começa um episódio na web e termina no celular.
Offline que sobrevive a um trajeto de verdade
O app já baixava episódios desde o começo. Isso não é novidade, e quero ser preciso aqui. O que a reconstrução acrescentou foi resiliência — a diferença entre ter um recurso de download e ter um offline em que você confia.
Um download interrompido agora retoma de onde parou em vez de começar do zero, porque o app salva os dados de retomada do sistema por episódio e reinicia a partir deles. Tem uma opção só-WiFi que realmente proíbe o uso de dados móveis, então um download na fila espera o WiFi em vez de queimar seu plano de dados sem você perceber. Os downloads rodam no máximo três por vez numa fila FIFO, em vez de atropelarem a rede. Tem uma tela de armazenamento pra ver e apagar o que está no aparelho. E as requisições passageiras que falham numa conexão instável tentam de novo com backoff — três tentativas, meio segundo crescendo até um teto, sem nunca repetir um cancelamento feito pelo usuário.
Tentar de novo é fácil; tentar de novo sem brigar com quem apertou cancelar é a parte que faz o offline parecer sólido numa conexão ruim de metrô, em vez de ficar rodando à toa.
Instantâneo, porque um spinner parece coisa quebrada
No celular, latência é uma sensação, não um número. Um spinner numa abertura a frio parece dizer "esse app está quebrado", mesmo quando não tem nada de errado.
O app portado rebaixava todas as capas a cada abertura a frio, então a biblioteca abria como uma parede de spinners. A reconstrução acrescentou um cache compartilhado de memória e disco pra capa dos episódios — a camada de disco sobrevive aos reinícios, a camada de memória mantém a rolagem suave, e a tela bloqueada reaproveita o mesmo cache pra capa dela. Reabrir um episódio antes esperava uma ida e volta na rede; agora os trechos e a transcrição ficam em cache por episódio e aparecem na hora, depois se atualizam de mansinho em segundo plano. Também tirei das linhas da lista aquele tique de reprodução de meio em meio segundo, pra que o cronômetro pare de forçar a biblioteca inteira a se redesenhar.
Não é um recurso que você consegue capturar num print. É justamente o abismo entre um app e um site.
Ele te avisa quando o episódio fica pronto
Gerar um podcast leva minutos, não segundos — tem pesquisa, um roteiro de tópicos, um roteiro de fala e, então, o áudio. O app portado te fazia ficar olhando pra uma barra de progresso o tempo todo. O app nativo não faz isso.
Com a sua permissão, ele manda uma notificação push no instante em que o seu episódio fica pronto, então você pode bloquear o celular, fazer outra coisa e voltar quando ele vibrar. O token do aparelho fica guardado no servidor, só o serviço de notificação consegue lê-lo, e você pode desligar tudo isso nas configurações. É um pedacinho de encanamento — uma tabela, um worker, o serviço de push da Apple — mas muda a forma como o produto se sente, de "fique esperando nesta tela" pra "eu te aviso quando estiver pronto".
O fluxo pode começar de fora do app
Um app nativo não vive só dentro da própria janela. A reconstrução acrescentou suporte a Siri e Atalhos através de App Intents, então "criar um podcast", "continuar ouvindo" e "abrir meus podcasts" funcionam como frases faladas, no app Atalhos e no Spotlight — sem precisar de nenhuma permissão especial. A decisão do que "continuar" deve fazer (seguir o episódio atual, ou abrir a biblioteca se não tiver nada carregado) é uma funçãozinha pura que pude testar de forma isolada, que é o tipo de coisa que evita que o comportamento da Siri fique se desviando.
Tem também uma boas-vindas comedida de três telas na primeira vez — criar, vozes, ouvir em qualquer lugar — mostrada uma única vez, e deep links pra que um link tocado abra a tela certa em vez de te largar na aba inicial. Coisas pequenas. São a diferença entre um app que fica sobre o celular e um que pertence a ele.
Uma palavra sobre onde eu parei: ainda não tem widgets na tela de início, nem Live Activities, nem CarPlay — cada um precisa da própria extensão ou de uma permissão concedida pela Apple, e eu escolhi lançar primeiro o núcleo da escuta. "Ser nativo" aqui é uma direção, não uma lista de tarefas concluída.
A lição que estou tirando disso
Se você está portando algo pra uma plataforma nova, o movimento tentador é fazer rodar lá e dar por encerrado. Vai rodar. Mas também vai parecer emprestado.
Ser nativo é um contrato com o aparelho: respeitar a tela bloqueada, as mudanças de saída de áudio, a realidade do offline, as superfícies do sistema que as pessoas já usam. Um port honra o seu layout antigo. Um app nativo honra as convenções da plataforma, mesmo quando isso significa apagar abas e reescrever telas que você já tinha lançado.
Não tenho números dramáticos de instalação ou retenção pra exibir por aí — a versão atual está no ar na App Store, e esse é o estado honesto da coisa. O teste de verdade nunca foi se os prints pareciam nativos. É se alguém cria um episódio, ouve numa caminhada com o celular bloqueado, e volta pra fazer outro.
Se você desenvolve pra mobile, fico curioso pra saber onde você traça a linha: quando "roda no celular" é suficiente, e quando o contrato da plataforma te obriga a reconstruir?
Perguntas Frequentes
O que mudou na reconstrução do app iOS do DIALØGUE?
O app saiu de um port do produto web pra uma reconstrução nativa. A arquitetura de informação caiu de cinco abas pra três (Listen, Create, You). A experiência de escuta ganhou uma transcrição sincronizada com toque-pra-saltar, marcadores de capítulo, controle de reprodução e capa na tela bloqueada, AirPlay, timer de soneca e intervalos de pular configuráveis. Os downloads offline ficaram resilientes, o app faz cache das capas e dos trechos pra uma sensação instantânea, Siri e Atalhos deixam as ações principais começarem de fora do app, e uma notificação push avisa quando um episódio fica pronto.
Por que cinco abas viraram três?
Porque o celular castiga cada aba a mais. Credits não era um lugar onde ninguém queria ir, então foi pra dentro de "You" mais uma tela de compra que aparece quando você de fato fica sem crédito. Studio virou Series — uma configuração salva dentro do Create em vez de uma aba própria. Library e Profile viraram os mais simples "Listen" e "You".
Quais recursos nativos do iOS a reconstrução acrescentou?
Controle de reprodução e capa dinâmica na tela bloqueada, AirPlay, timer de soneca com redução gradual de volume, intervalos de pular configuráveis (10–60s) que também controlam os botões da tela bloqueada, marcas de capítulo na barra de reprodução, transcrição sincronizada com toque-pra-saltar, downloads offline resilientes (retomada, só-WiFi, gestão de armazenamento, fila com limite), caches compartilhados de capa e de trechos pra renderização instantânea, intents de Siri e Atalhos, notificações push de "episódio pronto", posição de reprodução salva no servidor que continua entre web e celular, deep links e onboarding na primeira vez.
A transcrição sincronizada funciona pra qualquer episódio?
Uma linha da transcrição só é tocável pra saltar quando o áudio tem o tempo exato de cada trecho. Quando o tempo é aproximado, a linha ainda aparece, mas não dá pra saltar, e o app não finge o contrário. A transcrição é possível porque o DIALØGUE gerou o roteiro, então sabe a estrutura e quem disse o quê.
Qual a diferença entre Studio e Series?
Studio dava a entender uma sala de controle cheia de botões. Series é só uma configuração salva — apresentadores, tom, formato, idioma e padrão de fonte — que deixa você começar o próximo episódio sem reconfigurar tudo. É um preset dentro do Create, não uma aba isolada.
Como isso é diferente das audio overviews do NotebookLM?
O NotebookLM é genuinamente útil, e gratuito, pra transformar suas fontes numa audio overview rápida. O DIALØGUE está tentando ser um produto de escuta nativo completo por cima da geração: revisão de tópicos e roteiro antes de qualquer áudio, escolha de voz, transcrição sincronizada com toque-pra-saltar, capítulos, controles de tela bloqueada e AirPlay, downloads offline, Siri, e Series pra programas reutilizáveis. A diferença honesta é menos "quem gera o áudio melhor" e mais "o que acontece com o episódio depois que ele existe".
A reconstrução adicionou a escuta offline?
Os downloads offline já existiam. A reconstrução os deixou resilientes: downloads interrompidos retomam em vez de recomeçar, tem uma opção só-WiFi e uma tela de armazenamento, os downloads rodam no máximo três por vez, e falhas passageiras de rede tentam de novo com backoff sem brigar com quem cancela.
E é isso por enquanto, pessoal.
Abraço, Chandler