Desenvolvimento de aplicativo de audiolivros: ler e ouvir como um só produto

O desenvolvimento de aplicativo de audiolivros muda de natureza no momento em que o mesmo livro também precisa ser lido na tela. Deixa de ser um app com um botão de áudio. Passa a ser dois produtos, texto e áudio, que precisam concordar em uma coisa: onde a pessoa está no livro. O UnderBooks, uma plataforma de leitura e audição desenvolvida pela Logics7, é construído em torno desse único ponto compartilhado.

Esta nota apresenta a lógica de produto por trás dele: do que cada modo precisa, como funciona a alternância e quais decisões precisam ser resolvidas antes de alguém escrever código. Ela não faz afirmações sobre audiência ou tamanho de catálogo.

O UnderBooks é uma plataforma de livros em dois modos, leitura na tela e audição, com a possibilidade de alternar entre eles sem perder o ponto. É feito para smartphone, tablet e desktop. Mantém o progresso sincronizado entre dispositivos, permite acesso offline aos títulos baixados e recomenda o que ler ou ouvir a seguir com base no que a pessoa já escolheu.

Nos termos que a maioria dos briefings de desenvolvimento de aplicativo de audiolivros usa, é um app de e-books e audiolivros, não um app de audiolivros com um leitor acoplado. Essa distinção molda todas as decisões abaixo.

Ler e ouvir parecem uma única funcionalidade e são dois produtos diferentes. O texto precisa de tipografia, busca, anotação e renderização rápida. O áudio precisa de streaming, buffering, reprodução em segundo plano e uma posição que sobreviva a uma ligação. O que segue é a lógica de cada modo em qualquer produto desse tipo. Não é uma lista de funcionalidades do UnderBooks.

Leitura: EPUB, tipografia, offline

O desenvolvimento de um app leitor de e-books começa pelo formato. O padrão aberto para e-books é o EPUB, hoje em sua terceira versão principal, o EPUB 3. Um leitor de EPUB precisa refluir o texto para cada tela, do celular à janela do desktop. Aqui a tipografia não é decoração: comprimento da linha, tamanho da fonte, margens e contraste decidem se a pessoa lê por uma hora ou fecha o app. Busca e anotações, incluindo destaques, notas e marcadores, precisam continuar presas ao trecho certo quando o texto reflui. Acesso offline significa que o livro, suas fontes e as anotações do leitor estão no dispositivo antes que a conexão caia.

Audição: streaming, capítulos, velocidade, reprodução em segundo plano

O streaming de audiolivros é um problema de entrega antes de ser um problema de player. Gravações longas costumam ser servidas em segmentos por meio de uma CDN, para que a reprodução comece rápido e faça buffer adiante em uma conexão fraca. Os ouvintes tratam navegação por capítulos, velocidade de reprodução, marcadores e timer de sono como o básico de qualquer app de audiolivros. A reprodução em segundo plano é onde a engenharia mobile aparece: o sistema operacional pode pausar ou parar o áudio a qualquer momento, e iOS e Android têm regras diferentes. A posição precisa sobreviver a uma ligação, a uma tela bloqueada e a uma perda de sinal.

A lógica que une os dois é um único ponto no livro compartilhado pelos dois modos. Acertar isso é a diferença entre um app com botão de áudio e um produto em que as pessoas realmente trocam de modo. No UnderBooks, a pessoa pode passar do texto para o áudio, ou de um dispositivo para outro, e continuar do mesmo ponto.

A parte difícil é invisível. Uma posição no texto é um local no livro; uma posição no áudio é um tempo em uma gravação. Sincronizar leitura e audição significa mapear um no outro para cada título, e isso só se sustenta quando o texto e a gravação são da mesma edição. No desenvolvimento de aplicativo de audiolivros, esse mapeamento faz parte do trabalho de catálogo, não é uma configuração do player.

A leitura em modo duplo já não é uma ideia de nicho. A Amazon oferece o Whispersync for Voice há anos: o leitor alterna entre o e-book do Kindle e a narração no Audible sem perder o ponto onde parou. Quem planeja construir um app como o Audible deve esperar que os leitores peçam a mesma continuidade.

Em uma plataforma de conteúdo, a lógica de produto começa fora do código, e o desenvolvimento de aplicativo de audiolivros não é exceção. As perguntas abaixo são decisões de produto, não de engenharia, e precisam ser resolvidas antes do primeiro sprint. É isso que “nenhum desenvolvimento sem lógica de produto” significa na prática.

Catálogo e direitos

Direitos e catálogo vêm primeiro: o que pode ser oferecido, onde, em que termos e como isso é acompanhado. O licenciamento de conteúdo para texto e para áudio costuma ser negociado separadamente, com titulares de direitos e editoras diferentes, então um título pode existir em um modo e não no outro. Os metadados do catálogo precisam registrar qual edição, território e formato cada licença cobre. Se a narração por IA ou a conversão de texto em fala estiver em consideração, saber se uma licença a permite é uma pergunta para o titular dos direitos e para um advogado. O DRM para e-books e audiolivros decorre desses termos: é uma exigência de licenciamento expressa em código.

A entrega de áudio pertence à mesma conversa. Gravações longas, transmitidas e baixadas, fazem do armazenamento e do tráfego de CDN um custo recorrente que o modelo de preços precisa carregar.

Economia do formato e retenção

Em seguida vem a economia do formato: assinatura, venda por título ou uma mistura, e a retenção que cada um exige. Uma assinatura só gera receita enquanto as pessoas continuam lendo ou ouvindo, então a retenção em um app de leitura é o próprio modelo de negócio, não uma métrica ao lado dele. Créditos e vendas por título dependem da próxima compra, e as compras no app pelas lojas de aplicativos acrescentam suas próprias taxas e regras. A continuidade entre modos e as recomendações baseadas no que a pessoa já escolheu são mecânicas de retenção, não extras.

A acessibilidade fecha a lista. Para algumas pessoas, ouvir não é uma conveniência, mas a única porta de entrada. Um produto que trata o áudio como complemento falha primeiro com elas.

A mesma estrutura serve a qualquer produto de conteúdo ou mídia, não só ao desenvolvimento de aplicativo de audiolivros: plataformas de aprendizagem com texto e áudio, bibliotecas corporativas de conhecimento, apps de mídia por assinatura, conteúdo infantil com controle parental. A Logics7 os constrói com a engenharia de nível mobile que traz dos jogos e dos sistemas em tempo real (reprodução em segundo plano, tolerância ao offline, sincronização) e os opera depois do lançamento.

Para um novo produto, a rota é uma Product Partnership: verificamos o mercado, o usuário pagante e a lógica de monetização antes de falar em desenvolvimento. Para um produto de leitura ou áudio no ar, com usuários, cujo crescimento estagnou, um Existing Product Review é como a Logics7 decide se entra com uma participação. As duas rotas terminam em uma decisão no Leadership Gate, descrita em como funciona o nosso processo.

Se você está trabalhando em um produto de conteúdo ou mídia, comece pela rota certa.