victor's hacker blog

Entender a Interoperabilidade Kotlin-Swift pode evitar que você cause bugs em produção

Sun, 15 Mar 2026 00:00:00 +0000

Interoperabilidade = A capacidade de sistemas distintos conversarem e compartilhar dados.

Talvez isso seja óbvio para alguns devs mobile, mas para quem desenvolve projetos que utilizam Kotlin Multiplatform e ainda não deu a devida atenção e realmente parou para ler sobre a interoperabilidade entre Kotlin e Swift, esse post é minha chance de te convencer a dominar esse tema.

No desenvolvimento com Kotlin Multiplatform, dominar a interoperabilidade do Kotlin com Swift é uma peça chave pra não gerar problemas em produção.

Tudo que vai no commonMain vale pro Android e iOS, portanto nós temos como expectativa que o código seja essencialmente a mesma coisa entre as plataformas: tenha as mesmas funções, classes e se comporte igual.

Esse compartilhamento de código entre a commonMain e código Swift é totalmente transparente para nós devs, tudo que eu escrevo em um aparece “igual” no outro… e após várias iterações disso é fácil esquecer que o código do commonMain passa por uma “etapa intermediária”, onde pode sofrer mudanças para que o Swift consiga entender nativamente.

De uma forma simplista, o código que o Swift vê é o produto da soma commonMain + iosMain + um processo de multiplas compilações, e não somente commonMain + iosMain.

Esse “processo de multiplas compilações” ou essa “etapa intermediária” que eu disse foi apenas uma forma de resumir, se você tiver interesse em como isso funciona vou deixar um link que dá explicações e detalhes técnicos sobre isso:

kotlin/docs/native/compilation-model.md

Quantas vezes você já fez um código que no Kotlin ficou belíssimo, mas quando você abriu o XCode notou que esse mesmo código tava péssimo pra usar? Ou até mesmo tinha coisas a mais nele que você não desenvolveu? Ou coisas faltando… “Cadê os parametros default que configurei??”

Vou te falar um bug que eu causei em produção por não ter conhecimento 100% de como meu código Kotlin ficava para o Swift.

Para quem não manja de swift, quando você faz qualquer código que pode gerar uma exception você é obrigado a declarar isso com uma palavra chave no código: throws. Se sua função tem essa palavra chave, quem chamar ela também é obrigado a tratar senão o projeto não compila.

func canThrowErrors() throws -> String

func cannotThrowErrors() -> String

Tem cenários onde você sabe que não vai gerar uma exception, como por exemplo carregar uma imagem local… Nesse caso voce ainda precisa manualmente desabilitar a propagação do erro.

let photo = try! loadImage(atPath: "./Resources/John Appleseed.jpg")

link para o restante da documentação da apple sobre isso

Qualquer exception lançada onde não está explícito que pode gerar uma exception (ou seja, não está marcada por throws) faz com que o app feche imediatamente. Mesmo quando ela estiver dentro de um do-catch (vulgo try-catch)!!! Esse é o comportamento padrão.

Eu sabia que existia uma annotation chamada @Throws, mas meu pensamento era: “poxa, se eu chamo meu código que vem do Kotlin dentro de um try catch no Swift, ele ja vai ser capturado e tratado - não tem necessidade de colocar essa annotation no Kotlin”.

Era uma exception esperada, ela de fato poderia acontecer eventualmente e ta tudo bem, inclusive foi pensando nisso que eu coloquei o try-catch. No final das contas minha função gerava essa exception em um cenário específico, e justamente por lançar uma exception que o Swift entendeu como inesperada, o aplicativo encerrava pois pra ele foi um erro fatal.

Você pode argumentar que eu só pensava assim pois tenho mais experiência em linguagens que o try-catch pode capturar todos os erros, não pela falta de conhecimento da interoperabilidade em si. E olha, você provavelmente está certo.

Mas num olhar pragmático, KMP para devs mobile que já trabalhavam na área cai EXATAMENTE nesse mesmo cenário: temos uma bagagem/conhecimentos de outras linguagens que acabamos trazendo junto, e isso de um lado é ótimo, mas se não tivermos cuidado isso pode nos sabotar (vide evidência do bug que eu causei).

A realidade é que:

as plataformas/linguagens que se beneficiam com nosso código KMP tem demandas específicas, que ao subestimadas eventualmente vão trazer dores de cabeça para devs e consequentemente para os usuários finais.

Eu poderia simplesmente sair estudando Swift e todas suas particularidades, isso certamente iria fazer diferença para esse erro que comentei mais acima do post. Porém esse caminho apesar de funcionar acaba sendo bem ineficiente.

Se meu objetivo é melhorar o conhecimento e habilitade em desenvolver códigos multiplataforma, estudar uma linguagem inteira seria o equivalente a atirar para todos os lados, eu vou acertar o alvo, mas gastarei toda minha munição no processo.

Seria excelente se tivesse uma documentação ou algo que me alertasse sobre essa particularidade do Swift e ainda me da uma solução? É ai que entra a documentação de interoperabilidade com Swift/ObjC.

Olha aqui ela dizendo exatamente sobre o problema que eu tive e como resolver ele

Se você tem interesse em evoluir as habilidades em KMP, fica como minha sugestão: Estude a interoperabilidade entre as plataformas. Com esse conhecimento você vai saber o que deve evitar no seu código multiplataforma para não causar bugs em produção igual eu fiz.

Usando frida para fazer debug em apps mobile

Thu, 20 Nov 2025 00:00:00 +0000

Introdução

No desenvolvimento mobile somos quase que obrigados a usar alguma ferramenta de debug, só rodar o app e ver o comportamento dele muitas vezes não é o suficiente para entender que uma mudança deu bom ou não, ou até mesmo pra entender como que aquele bug sinistro está acontecendo.

Existem várias ferramentas bem estabelecidas no mundo mobile, acho que todos conhecem android studio e xcode. Quem desenvolveu apps usando react native talvez já ouviu falar de flipper ou reactotron.

Nesse post vamos ver uma ferramenta que talvez você nunca tenha ouvido falar, e que podemos usar para abordar o debug de problemas em aplicativos móveis de uma forma completamente diferente do tradicional.

Além de falar sobre ela, vou mostrar um exemplo simples de como usei ela para resolver um problema que tive recentemente.

Mas já adianto que acho improvável ela substituir outras ferramentas… A ideia aqui está longe disso, é muito mais sobre ter mais uma ferramenta no seu cinto de utilidades. Cada uma das ferramentas tem suas especialidades e seus casos de uso, e como engenheiro de software precisamos reconhecer quais ferramentas funcionam melhor para cada objetivo.

Contexto sobre ferramentas usadas em AppSec

No meu tempo livre as vezes eu me pego estudando sobre segurança da informação focado no mobile, pesquisando na internet mas também fazendo meus próprios testes e explorações, e isso contribuiu para ter novas ideias e perspectivas diferentes sobre aplicações android e ios.

A área de segurança da informação tem várias ‘sub áreas’ (AppSec acho que pode se dizer como uma sub área, certo?), mas acho que todos que trabalham com isso devem conhecer a existência de uma ONG que tem como objetivo melhorar a segurança das aplicações através de projetos open source, a famosa OWASP (Open Worldwide Application Security Project)

Um parenteses aqui, devo ressaltar que a ideia dessa ONG é muito legal e talvez até meio comica se puxarmos essa ideia para desenvolvimento de software: imagine por exemplo uma iniciativa dessa só que com o objetivo de acabar com todos os bugs dos softwares? ou outra pra acabar com as breaking changes ao atualizar?? apesar de meio bizarro isso seria simplesmente maravilhoso kkkkk, cade a ong pra acabar com vendor-lock? fica ai a reflexão pra você.

Dentro da iniciativa da OWASP tem um sub-projeto chamado OWASP Mobile Application Security - e por se tratar de mobile vamos olhar com mais atenção.

O OWASP de Mobile tem uma lista com várias ferramentas open source para facilitar o trabalho para quem quer explorar aplicações mobile.

O que eu tenho percebido é que dependendo do caso elas também podem ajudar os desenvolvedores. Vou abordar em especial a ferramenta Frida, mas essas outras que listei aqui também são interessantes e valem a pena conhecer:

Capacidades, vantagens e desvantagens

Okok eu entendi que essas ferramentas podem ser úteis, mas pra que exatamente?

Para definir Frida em uma frase eu vou usar a que tem no site deles: Dynamic instrumentation toolkit for developers, reverse-engineers, and security researchers., dai falando mais tecnicamente: frida por baixo dos panos usa um módulo escrito em C que permite você injetar códigos JS durante período de execução de tal forma que é possível interagir com APIs que esse módulo provem.

Vou explicar melhor como isso pode ser aplicável no dia a dia.

Você talvez já deve ter pego aquele bug cabuloso onde o uso de debug foi útil e talvez até necessário, aquele cenário de concorrência entre duas funções ou senão um erro que só ocorre quando o app está em um estado muito específico.

Já deve estar cansado de saber que debug em ferramentas como android studio e xcode da pra colocar breakpoints para inspecionar e alterar variáveis, mas algo muito bacana e que não vejo muitas pessoas comentando é sobre o watchpoints (android) onde você consegue registrar um ‘hook’ para pausar a execução do app quando uma variável específica for alterada, ou no iOS o thread return (lldb no iOS) que permite você alterar o valor de retorno de uma função nativa.

A Frida tem as mesmas capacidades de debug que falei acima (leitura, escrita e observar uma variável), mas aborda isso de uma maneira completamente diferente, e eu acredito que é ai que podemos tirar proveito dela.

Um exemplo simples de debug que fiz usando Frida

Nessa semana encontrei um bug muito esquisito que acontecia apenas em dispositivos iOS em um cenário desconhecido, a única evidência ou log que eu tive sobre isso é o código do erro e uma mensagem muito superficial: -25291 (errSecNotAvailable) - que se você ler a doc basicamente diz No trust results are available., no log de erro a seguinte mensagem aparece: No keychain is available..

Bom, depois de muito investigar e achar diversos links de pessoas que passaram pelo mesmo problema e não acharam a causa raiz, ficou muito difícil para reproduzir o erro e corrigir o que causa ele de fato, mas para não sair de mãos vazias eu decidi seguir pela abordagem de assumir que ele vai ocorrer e tratar o erro de forma elegante.

Dai veio um pensamento: Ok mas quando eu fizer essa possível tratativa do erro, como que vou comprovar que minha solução de fato trata o erro se eu nem consegui reproduzir ele? É basicamente uma solução às cegas, um tiro no escuro. Até podemos lançar um throw no meio do código pra fingir que o erro aconteceu, mas com certeza não é a mesma coisa que a API do módulo de Security te retornar esse erro de fato.

Eu poderia usar o modo debug do xcode e tentar colocar um breakpoint e usar o thread return para trocar o valor, mas iria gastar um bom tempo para entender quais comandos usar no lldb para modificar o retorno do método que eu quero… dai veio a ideia de usar o Frida - lendo as docs eu vi que você pode usar APIs em JS para poder modificar os retornos, o que pareceu bem promissor e relativamente simples de fazer, e como no passado eu já tinha configurado e instalado Frida no meu macbook, decidi tentar.

No final eu cheguei nesse código para forçar esse erro a acontecer, escrevi esse script que basicamente faz o hook na função nativa que consulta a keychain e força o retorno do erro que quero.

// keychain_hook_specific_error.js
const secItemCopyMatching = Module.findExportByName("Security", "SecItemCopyMatching");
if (secItemCopyMatching) {
    Interceptor.attach(secItemCopyMatching, {
        onEnter: (args) => {
            console.log("SecItemCopyMatching called");
        },
        onLeave: (retval) => {
            console.log("SecItemCopyMatching returning -25291");
            retval.replace(-25291);
        }
    });
} else {
    console.log("SecItemCopyMatching not found");
}

Lembrando que para usar o frida no iOS você precisa ter o dispositivo jailbroken ou escolher outro método de operação.

Com esse script, toda vez que a função SecItemCopyMatching for chamada, o retorno dela será alterado para o código de erro -25291 para simular o erro que quero testar. Dai depois disso bastou executar o seguinte comando:

ID_DO_SEU_DEVICE="" # serve tanto para simulador quanto device fisico.
# -F pra pegar o app que estiver rodando no momento, portanto abra o app antes de rodar esse comando
frida -D $ID_DO_SEU_DEVICE -F -l ./keychain_hook_specific_error.js

Agora que que esse script está rodando, toda vez que qualquer parte do meu app chamar essa função do módulo de Security, aquele erro vai ser retornado conforme eu configurei, dessa forma eu consigo comprovar que meu código está funcionando pois o módulo literalmente retornou esse erro, só precisei dar um empurrãozinho.

Esse foi um exemplo simples, mas já da pra ter uma ideia do poder do frida para fazer debug em runtime, e o melhor de tudo é que você não precisa modificar o código fonte do app para isso, muito menos saber onde que esse código está, você pode fazer o hook em qualquer função nativa ou gerenciada que quiser.

Além disso vale ressaltar que eu usei apenas 2 módulos do projeto (Interceptor e Module) mas existem outras que podem ser usados.

Tiveram pelo menos mais outras 2 vezes onde eu usei Frida e ferramentas que usam Frida por baixo dos panos (como o objection) para resolver problemas como esse, eu gostei que consegui chegar em uma solução bacana mais rápido do que eu esperava, e ainda por cima com evidências sólidas que minha solução funcionava - o que é muito bom, eu poderia citar elas aqui mas o post vai ficar longo demais, com o exemplo que eu dei já deu para entender por cima como uma ferramenta dessa pode ajudar no fluxo de debug.

Conclusão

Nesse post passamos um pouco sobre ferramentas de que são usadas na área de segurança da informação, dei alguns exemplos e aprofundamos um pouco mais na ferramenta Frida dando um exemplo bem simples.

A principal mensagem que quero que leve desse post é não ficar preso as ferramentas tradicionais por estar acostumado a usá-la.

Explore alternativas, até aquelas que são de outras áreas se realmente tiver interesse. Saber identificar as ““melhores”” ferramentas para cada caso pode te pagar dividendos, uma analogia interessante e meio exagerada para se pensar é: você consegue furar uma parede usando uma parafusadera? Não manjo muito de obras mas acredito que dependendo da potência dela e o material da parede até deve conseguir sim, mas sem dúvidas uma ferramenta própria para isso seria bem mais fácil.

Renderização Declarativa - React Reconciler

Thu, 16 Jan 2025 00:00:00 +0000

Introdução

Eu fiz esse post aqui como forma de eu aprofundar no tema de renderização declarativa, minha ideia é abordar alguams bibliotecas que funcionam dessa forma e entender com mais profundidade as diferenças de abordagens entre cada ferramenta.

Eu quero cobrir tanto o React Reconciler quanto o Jetpack Compose Runtime, e talvez outras ferramentas que eu for encontrando no caminho. Por hora vamos começar com o React Reconciler.

Disclaimer: Nesse artigo vou procurar colocar referencias das informações que eu estou compartilhando, mas é importante ressaltar que essas informações podem mudar com o tempo ou até mesmo eu posso cometer algum erro, portanto minha recomendação é ler este artigo com o ‘livro de regras embaixo do braço’ e sempre verificar a documentação oficial das ferramentas.

React

É uma biblioteca bem conhecida na web, e eu particularmente já usei bastante em projetos usando react-native. Poderíamos falar especificamente do react native, mas como a ideia é falar sobre a renderização declarativa, vou abordar apenas o react.

Eu imagino que você já deve ter ouvido falar algo sobre ou talvez até desenvolvido alguma aplicação que utilize react, se não teve contato com a ferramenta não tem problema, vamos aprofundando aos poucos. Para iniciar um projeto react é bem simples, basta criar um elemento “root” e chamar uma função passando um componente para ser renderizado:

import { createRoot } from 'react-dom/client'; //react-dom@19
import App from './App'; 

const domNode = document.getElementById('root');
const root = createRoot(domNode);

root.render(<App />);

Vamos explorar um pouco como o react-dom funciona por baixo dos panos, e como que só esse trecho de código ja permite que voce renderize e atualize a interface do usuário de forma declarativa.

Procurando no código fonte do react-dom, podemos encontrar a função createRoot aqui. esse é um código exemplo de como ele funciona:

type RootType {
    render: (element: ReactElement) => void;
    // ...
}

export function createRoot(
  container: Element | Document | DocumentFragment,
  options?: CreateRootOptions,
): RootType {

    /*
        usa-se o options para fazer uma serie de configurações que nesse momento não são importantes
    */
        
    // react-reconciler/src/ReactFiberReconciler
     const root = createContainer( 
        container,
        /* ...demais configurações... */
    );
    // ...
    return new ReactDOMRoot(root);
}

Perceba que o createRoot faz algumas configurações que no momento não são relevantes, importante é que ele chama a função createContainer, que vem de uma biblioteca chamada react-reconciler. Ou seja, a lib react-dom sozinha não cuida da renderização dos elementos, ela delega essa responsabilidade para a biblioteca react-reconciler, o que faz sentido pois ter essa logica abstraida em uma lib separada de react-dom permite que o reconciliador possa ser importado e utilizado de forma independente.

Reconciler & Renderer

O react reconciler é responsavel em fazer a gestão das mudanças de estado e props dos componentes, basicamente ele é o motor que faz toda a lógica de comparação entre uma versão D e D+1 da árvore de componentes, e decide quais componentes precisam ser atualizados, removidos ou adicionados.

Além dessa gestão de mudanças sendo feita, existe outro componente que cuida de como essas mudanças são aplicadas na interface do usuário, e é ai que entra o renderer, ele é a camada que faz a ponte entre o reconciler e a plataforma onde a aplicação está rodando, seja ela web, mobile ou desktop.

Por conta dessa arquitetura desacoplada, que permite que sejam criados vários renderers, APIs que se conectam com o react-reconciler e fazem a implementação na sua plataforma especifica, uma imagem bacana sobre isso:

Algoritmo

Agora sabemos que ele é quem faz todo o trabalho pesado de comparar e decidir o que precisa ser atualizado, varrendo toda a arvore de componentes e fazendo essas comparações.

Em uma perpectiva de performance, quanto menos nós sendo atualizados desnecessáriamente, melhor. Essa comparação e identificação é a chave para uma renderização eficiente.

Links para entender mais sobre o algoritmo de reconciliação:

Essas informações salvas dentro desse nó são importantes para que o Reconciler saiba qual nó ele precisa atualizar, e qual ele pode simplesmente ignorar pois não houve mudanças.

Stack Reconciler e Fiber Reconciler

Na versão 15 e anteriores, o react utilizava um algoritmo de reconciliação chamado de “Stack Reconciler”, a desvantagem dele era a performance: ele percorria toda a arvore de componentes de forma sincrona, componente a componente fazendo aplicando as mudanças, isso é passivo a problemas de performance como drop de frames em animações.

Por mais que isso fosse prejudicial, era possivel contornar esse problema de performance fazendo esse trabalho no tempo livre no final dos frames, fazendo uso do requestIdleCallback. Essa saída ajuda mas não é bala de prata porque nós ainda teriamos que percorrer a arvore toda de qualquer forma.

Para resolver de forma definitiva esse problema de performance, foi necessário permitir que o algoritmo pudesse pausar e continuar a execução de um update, além disso esse novo algoritmo introduziu formas de aplicar atualizações com base na prioridade (link para ler mais sobre).

Esse esquema de pausar e continuar os trabalhos, permite que o react quebre todo o trabalho de atualização em pequenos pacotes, essa técnica é chamada de “time-slicing”:

Explain the concept of time-slicing in Concurrent Mode

A versão 16 do react foi lançada em 2017, então ja faz um tempinho que teve essa mudança para o novo algoritmo, portanto talvez você ja deve ter percebido ou ouvido falar que alguns dos updates de estados no react não ocorrem de forma sincrona, em resumo é justamente isso que o novo algoritmo permite.

Lançamento do React v16.0

Árvore de Componentes React

O ‘Fiber Reconciler’ deu nome de cada ‘trabalho’ a ser feito nos componentes como um nodo Fiber, ele é a representação de um trabalho pendente ou um trabalho ja feito.

Esse trabalho a ser feito podem set vários tipos de tarefas, como por exemplo: Executar um ‘Efeito’ como useEffect (link), ou atualizar o estado de um componente (link) e assim por diante.

Mas somente saber o que precisa ser feito não da para construir uma arvore de componentes, precisamos de relações entre cada nodo, portanto dentro de um Fiber temos informações extras que nos ajudam a montar uma arvore, como por exemplo o estado atual do componente, as props, e referencias para os filhos, irmãos e pai, e lista de atualizações pendentes.

Tendo uma estrutura de árvore fica bem mais fácil navegar entre os nodos, saber qual deles tem alguma pendência, as dependencias dos nodos entre si, etc. E para poder fazer tudo isso acontecer foi quebrado em fases.

Na primeira fase do algoritmo (normalmente chamada de “Render phase”), o reconciler precisa entender primeiro qual nó precisa ser adicionado, atualizado, deletado, e também se teve algum efeito colateral a ser computado.

Esses componentes “alterados” são justamente o que vão ser usados na segunda fase!

Para ficar tangível esse comportamento, sugiro ver esse vídeo.

Na segunda fase (normalmente chamada de “Commit phase”), o reconciler teve tempo de calcular todas as mudanças necessárias, portanto agora ele precisa fazer (nessa ordem):

Depois que todas as mudanças foram aplicadas, o reconciler limpa a fila de tarefas e espera o próximo update :) E assim finalizamos o ciclo de vida de um update no react.

victor's hacker blog

Entender a Interoperabilidade Kotlin-Swift pode evitar que você cause bugs em produção

Usando frida para fazer debug em apps mobile

Introdução

Contexto sobre ferramentas usadas em AppSec

Capacidades, vantagens e desvantagens

Um exemplo simples de debug que fiz usando Frida

Conclusão

Renderização Declarativa - React Reconciler

Introdução

React

Reconciler & Renderer

Algoritmo

Stack Reconciler e Fiber Reconciler

Árvore de Componentes React

Referências