DEV Community: Guilherme Yamakawa de Oliveira

[PT-BR] O Omarchy passou de 400 plugins. Um deles é meu

Guilherme Yamakawa de Oliveira — Tue, 18 Aug 2026 14:42:10 +0000

Um AirPods funcionando de verdade no Linux: bateria de cada fone e do estojo, os modos de escuta, detecção de ouvido. Nada disso existia fora do mundo da Apple, porque nem o Bluetooth do sistema sabe ler esses números. O GM sentou e fez. O primeiro commit é de anteontem no fim da tarde, e ontem já estava publicado no diretório: 24 commits, menos de um dia, de graça.

Isso teria sido piada dois anos atrás. Hoje é só mais um plugin no diretório, entre outros quatrocentos e quinze.

Explicando pra quem não acompanha: o Omarchy é a distro Linux opinativa do DHH, criador do Rails, e eu uso ela desde o primeiro dia. Sexta passada saiu a versão nova, com um sistema de plugins: pedaços de interface que qualquer pessoa escreve e qualquer pessoa instala na barra do sistema com um comando.

O diretório da comunidade levou dezessete dias pra chegar a cem plugins. Depois de sexta, entraram mais de trezentos em cinco dias: 35 naquele dia, 82 no sábado, 99 no domingo, 80 hoje. São 416 plugins da comunidade publicados até agora.

Um deles é meu.

O mclovin aberto na barra, com as regras que já existem

O que o plugin faz

O problema que ele resolve é bobo e persegue todo mundo que trabalha no computador: você clica num link do Slack e ele abre no navegador errado, ou no perfil errado. O link do trabalho abre no Chrome pessoal, o link pessoal abre no perfil da empresa.

O McLovin põe um seletor no meio da tela quando você clica num link, com uma linha por perfil de navegador. Você escolhe onde abrir. Marca always e aquela escolha vira regra, então o próximo link daquele site já vai direto pro lugar certo. O resto está no README.

O seletor, uma linha por perfil. Marcando always, a linha vira a regra que vai ser escrita

O formulário de regras

Tudo roda dentro do omarchy-shell, em QML: sem daemon, sem binário, sem processo extra.

E aqui tem uma volta que eu gosto. A primeira versão do McLovin, anos atrás, era um plugin de barra feito só pra mim. Depois eu quis que fosse maior que isso, tirei de dentro do shell e reescrevi em Rust como programa independente, com CLI, TUI e GUI, pensando em rodar em qualquer sistema. Agora ele é plugin de novo, sem carregar uma linha daquele Rust.

O círculo fechou num ponto diferente do que começou: da primeira vez o plugin era só meu, e agora qualquer um instala com um comando. O programa em Rust continua de pé, é o que eu uso nas máquinas sem Omarchy, e o plugin importa as regras dele se você já tiver.

Eu já fazia plugin. Só que pra mim

Isso não começou agora. O plugin da VPN, que troca o país com a bandeirinha do lado, nasceu no Omarchy antigo. Quando comecei a testar o Quattro eu refiz ele pro shell novo, escrevi outro pra alternar o modo de polimento do ditado, e mais um painel de tela cheia no monitor secundário.

O plugin da VPN aberto: filtro em cima, países com bandeira embaixo

O do voxtype, onde eu monto a pipeline que limpa o texto ditado

Os três moram em ~/.config/omarchy/plugins/ e nunca saíram de lá. Não por segredo, e sim porque não existia porta. Eles resolviam um incômodo meu e paravam ali, e eu achava que ia ser sempre assim.

Aí o HANCORE montou o diretório, o Quattro saiu na sexta, e a distância entre "resolvi o meu incômodo" e "resolvi o incômodo de quem usa o mesmo ambiente que eu" virou um comando:

omarchy plugin add https://github.com/guilhermeyo/omarchy-mclovin.git --enable

A diferença não é técnica. O código do plugin de VPN não ficou melhor por existir um diretório. O que mudou foi o destino dele.

Um amigo, quatro plugins, uma noite

Um amigo meu instalou o Omarchy ontem. Terminou o setup umas oito e meia da noite. Sete da manhã ele já tinha quatro plugins que achava que faltavam na máquina dele, um deles cem por cento pronto e já submetido pra aprovação no diretório.

Isso é o que me impressiona, mais do que o meu próprio plugin. O ciclo entre "isso aqui tá me incomodando, podia ser melhor" e "pronto, resolvi, e agora tá lá pra quem quiser" cabe numa noite.

O que o Mac cobra pela mesma coisa

Tenho um MacBook e preciso dele pro Xcode e pra publicar pra iOS. Voltei a usar ele com mais frequência esses meses, e a diferença de atrito é grande: tudo pede autorização, tudo pede uma permissão em algum painel. Depois de um tempo de Omarchy, onde você simplesmente faz, isso incomoda.

Como não quero viver dentro dele, montei uma barra pro macOS parecida com a do Omarchy, em Swift e AppKit. São umas 7.500 linhas, com relógio, calendário, bateria, workspaces e abas de janela escritos por mim. Ela continua só minha, e não é por falta de open source no Mac: o Finicky, que eu usava pra rotear link lá, é open source e só existe pra macOS.

A diferença é o tamanho do que você precisa entregar. No Mac, compartilhar quer dizer virar app: empacotar, assinar, notarizar, escrever instalação, sustentar um site. No Omarchy é um repositório com um manifesto, que cai dentro de uma barra que todo mundo já roda. Uma pede um projeto inteiro em volta, a outra pede um git push.

E o Windows, que eu nem tento

Não uso Windows há mais de quinze anos, tirando abrir pra jogar um CS no Faceit. Quando pensei em publicar o McLovin lá, era certificado de desenvolvedor, assinatura, e a mesma burocracia de publicar em loja. Pra um programa que roteia link. Desanimei antes de começar, e com o pessoal saindo do Windows 11 essa diferença de atrito vira porta de entrada.

Tem o outro lado, que pesa igual. Quando a Microsoft anunciou o Recall, ficou no ar que o sistema ia observar tudo que você faz na sua própria máquina. No Mac eu já sentia uma versão mais discreta disso: muita coisa rodando por trás que eu não sei o que é nem pra onde manda. O usuário comum não vê e provavelmente nunca vai ver. Eu sei que tá lá, e me incomoda.

No Omarchy tudo que vem instalado é open source. A diferença é que dá pra auditar o que sai da sua máquina, e a resposta pra "o que é esse processo aqui" existe em algum lugar que você pode ler. Já escrevi sobre isso quando contei do daemon que o Chrome instala calado no macOS.

São os dois lados da mesma porta: quando o sistema é legível, você consegue mexer nele e consegue ver o que ele faz. Quando é opaco, você só pode aceitar.

Qualquer um pode fazer melhor que o meu

E vai fazer. Com IA hoje, alguém chega, olha o meu plugin, acha ruim e escreve um melhor até o fim de semana.

Isso não me incomoda, é literalmente o objetivo. O que importa não é o meu plugin ganhar. É o incômodo ser resolvido, de preferência por quem usa aquilo todo dia.

Quem tá segurando o diretório

O omarchyplugins.com é um projeto independente do HANCORE. É ele que está pondo tempo dele pra organizar isso, ler código e aprovar o que entra.

O selo de verificado não se dá sozinho: alguém leu o código antes

Ter alguém revisando plugin de estranho é o que separa um diretório de uma pasta de links. Meu plugin passou por ali antes de aparecer pra você, e isso é trabalho de alguém.

Finalizando

O plugin está no diretório, o código está aberto sob MIT, e a instalação é um comando.

Mas não é sobre o meu plugin. Faz quinze anos que eu não uso Windows e mais de um que uso Omarchy, e nunca vi o ciclo entre se incomodar e consertar ser tão curto. Um fone da Apple funcionando de verdade fora da Apple, escrito em menos de um dia. Um amigo com quatro plugins entre o jantar e o café. Trezentos plugins em cinco dias, escritos por gente que só queria que a própria máquina fosse um pouco melhor.

As coisas estão ficando diferentes, e a parte boa é que dá pra entrar hoje mesmo. Se tem um incômodo pequeno te perseguindo há meses, ele agora cabe numa noite, e o resultado não precisa ficar guardado na sua máquina.

Fontes:

Publicado originalmente em guilherme44.com.

Omarchy passed 400 plugins. One of them is mine

Guilherme Yamakawa de Oliveira — Tue, 18 Aug 2026 14:42:06 +0000

AirPods working properly on Linux: battery for each bud and the case, the listening modes, ear detection. None of it existed outside Apple's world, because the system's own Bluetooth stack cannot even read those numbers. GM sat down and did it. The first commit landed the evening before last, and by yesterday it was published in the directory: 24 commits, under a day, for free.

Two years ago that would have been a joke. Today it is just another plugin in the directory, among four hundred and fifteen others.

For anyone not following along: Omarchy is DHH's opinionated Linux distribution, and I have been using it since day one. Last Friday the new version shipped with a plugin system: pieces of interface that anyone can write and anyone can install into the system bar with one command.

The community directory took seventeen days to reach a hundred plugins. After Friday, more than three hundred arrived in five days: 35 that day, 82 on Saturday, 99 on Sunday, 80 today. That is 416 community plugins published so far.

One of them is mine.

mclovin open in the bar, with the rules that already exist

What the plugin does

The problem it solves is a silly one that follows around anyone who works on a computer: you click a link in Slack and it opens in the wrong browser, or the wrong profile. The work link lands in your personal Chrome, the personal link lands in the company profile.

McLovin puts a picker in the middle of the screen when you click a link, one row per browser profile. You choose where it opens. Tick always and that choice becomes a rule, so the next link from that site goes straight to the right place. The rest is in the README.

The picker, one row per profile. Tick always and the line grows into the rule it will write

The rule form

All of it runs inside omarchy-shell, in QML: no daemon, no binary, no extra process.

There is a loop here that I like. McLovin's first version, years ago, was a bar plugin I built only for myself. Then I wanted it to be bigger than that, pulled it out of the shell and rewrote it in Rust as a standalone program with a CLI, a TUI and a GUI, meant to run anywhere. Now it is a plugin again, without carrying a single line of that Rust.

The circle closed at a different point from where it started: the first time the plugin was only mine, and now anyone installs it with one command. The Rust program is still around, it is what I use on machines without Omarchy, and the plugin can import its rules if you already have them.

I was already writing plugins. Just for myself

This did not start now. The VPN plugin, the one that switches country with the little flag next to it, was born on the old Omarchy. When I started testing Quattro I rebuilt it for the new shell, wrote another one to change the polish mode of my dictation, and a third that is a full-screen dashboard on the second monitor.

The VPN plugin open: a filter on top, countries with flags below

The voxtype one, where I build the pipeline that cleans up dictated text

All three live in ~/.config/omarchy/plugins/ and never left. Not out of secrecy. There was simply no door. They fixed something that annoyed me and stopped there, and I assumed it would always be like that.

Then HANCORE put the directory together, Quattro shipped on Friday, and the distance between "I fixed my own annoyance" and "I fixed the annoyance of everyone on the same setup" became one command:

omarchy plugin add https://github.com/guilhermeyo/omarchy-mclovin.git --enable

The difference is not technical. My VPN plugin did not get better because a directory exists. What changed is where the code can go.

A friend, four plugins, one night

A friend of mine installed Omarchy yesterday. He finished the setup around half past eight in the evening. By seven the next morning he had four plugins he thought his machine was missing, one of them completely done and already submitted to the directory for approval.

That impresses me more than my own plugin does. The loop between "this bothers me, it could be better" and "done, and it is out there for anyone who wants it" fits inside one night.

What the Mac charges for the same thing

I have a MacBook and I need it for Xcode and for publishing to iOS. I have been back on it more often these past months, and the difference in friction is large: everything asks for an authorization, everything wants a permission toggled in some panel. After a while on Omarchy, where you simply do the thing, that gets annoying.

Since I do not want to live inside it, I built a macOS bar that behaves like the Omarchy one, in Swift and AppKit. Around 7,500 lines, with a clock, calendar, battery, workspaces and window tabs I wrote myself. It is still only mine, and not for lack of open source on the Mac: Finicky, which I used to route links there, is open source and macOS only.

The difference is the size of what you have to ship. On the Mac, sharing means becoming an app: packaging, signing, notarising, writing install instructions, keeping a site alive. On Omarchy it is a repository with a manifest, dropping into a bar everyone already runs. One asks for a whole project around it, the other asks for a git push.

And Windows, which I do not even try

I have not used Windows in over fifteen years, other than opening it to play CS on Faceit. When I looked into publishing McLovin there, it was a developer certificate, signing, and the same paperwork as shipping to a store. For a program that routes links. I lost interest before starting, and with people leaving Windows 11, that difference in friction becomes a front door.

There is the other side, and it weighs the same. When Microsoft announced Recall, the impression it left was that the system would be watching everything you do on your own machine. On the Mac I already felt a quieter version of that: a lot running in the background that I do not know the purpose of, or the destination of. The average user does not see it and probably never will. I know it is there, and it bothers me.

On Omarchy everything that ships is open source. The difference is that you can audit what leaves your machine, and the answer to "what is this process" exists somewhere you are allowed to read. I wrote about this before, when I found the daemon Chrome quietly installs on macOS.

They are two sides of the same door: when a system is legible you can change it and you can see what it does. When it is opaque, all you can do is accept it.

Anyone can build a better one than mine

And somebody will. With AI today, someone can look at my plugin, decide it is bad, and write a better one by the weekend.

That does not bother me. It is the actual point. What matters is not my plugin winning. It is the annoyance getting fixed, preferably by whoever lives with it every day.

Who is holding the directory up

omarchyplugins.com is an independent project by HANCORE. He is the one spending his own time organising it, reading the code, and approving what goes in.

The verified badge does not appear on its own: somebody read the code first

Having someone review a stranger's plugin is what separates a directory from a folder of links. Mine went through that before it showed up for you, and that is somebody's work.

Wrapping up

The plugin is in the directory, the code is open under MIT, and installing it is one command.

But this was never really about my plugin. I have not used Windows in fifteen years and I have been on Omarchy for over one, and I have never seen the loop between being annoyed and having fixed it get this short. Apple headphones finally working outside Apple, written in under a day. A friend with four plugins between dinner and coffee. Three hundred plugins in five days, written by people who only wanted their own machine to be slightly better.

Things are changing, and the good part is that you can join today. If some small annoyance has been following you around for months, it now fits in one evening, and the result does not have to stay on your machine.

Sources:

Originally posted at guilherme44.com.

[PT-BR] Meu iPhone virou dumbphone, e eu fiz o launcher em React Native

Guilherme Yamakawa de Oliveira — Fri, 14 Aug 2026 02:59:43 +0000

No post do McLovin eu escrevi que iOS e Android ficavam pra depois. Chegou a vez deles, só que por outra porta. O que eu fui fazer no celular não foi roteamento de link, foi tirar tela da minha frente.

O número que me fez parar é brasileiro: segundo a Bain, o brasileiro passa 9 horas e 13 minutos por dia conectado, contra 6 horas e 38 da média mundial. Na mesma pesquisa, tempo de tela é o hábito que ele mais gostaria de mudar, na frente de alimentação e de sedentarismo. Não é que a gente não perceba. A gente percebe, e continua ali.

A minha tela inicial hoje: previsão em cima, os apps como lista de nomes

O que é um dumbphone

Pra quem nunca esbarrou no termo: dumbphone é aquele telefone que só faz ligação e manda SMS. Não roda rede social, não roda jogo, não tem navegador. Foi o que todo mundo tinha antes de 2007, e virou movimento justamente porque deixou de ser o padrão. Nos Estados Unidos os feature phones voltaram a vender, 2,8 milhões em 2023, empurrados pelo detox digital da Geração Z.

E funciona. Um estudo da PNAS Nexus bloqueou a internet móvel de 467 pessoas por duas semanas e atenção, saúde mental e bem-estar melhoraram nos três casos. Mas apenas 25,5% aguentaram o mínimo de 10 dias. O efeito é real e é difícil pra caramba de sustentar. Não estou aqui pra dizer que resolvi isso.

De onde veio a ideia

O que me apresentou o assunto foi o Dumb Phone (dp), do Michael Tigas. Ele troca a tela inicial por uma lista de botões de texto e ainda esconde o resto pelo Tempo de Uso. É bem feito e faz mais coisa que o meu.

Só que eu sou desenvolvedor e gosto de aprender e evoluir, e mobile é a tela que todo mundo tem na mão o dia inteiro. Dava pra estudar isso lendo changelog e assistindo talk, mas aí não tem skin in the game. Resolvi entrar do jeito que ensina: um app meu, que eu uso todo dia, e nas duas lojas.

O que eu fiz

A tela inicial vira uma lista de nomes em texto. Sem ícone, sem badge, sem grade. Você toca no nome e o app abre.

A ideia não é virar monge, é tirar a disputa. A tela de fábrica é uma grade de quadradinhos coloridos brigando pela sua atenção, e os apps que eu abro todo dia são cinco. O resto é barulho que eu rolo pra passar. Trocar ícone por texto tira a cor da equação, e sem cor você para de reconhecer o app de longe e passa a ter que ler. Ler é mais devagar. Devagar é o ponto.

O app é o editor, onde você monta a lista, escolhe a fonte e o alinhamento. O widget é o produto, e é ele que fica na tela.

Onde você monta a lista, com o preview do widget em cima

Por que não só Swift

Esse app já existia em Swift. A primeira versão dele é SwiftUI inteira, mora num repositório meu do lado, e funciona bem. Refazer em React Native foi decisão, não acidente.

O motivo é Android. Eu quero o mesmo app nos dois lugares e não quero escrever ele duas vezes. Essa versão aqui é a primeira, é iOS, e já está montada em cima da parte que vai junto quando eu atravessar. Se eu tivesse seguido em Swift, o Android um dia começaria do zero.

E tem o motivo pessoal: fazia tempo, mas não é a primeira vez. Lá no começo do React Native, quando o framework ainda era novidade, eu fiz uma calculadora de investimentos pra uma instituição financeira, e o que eu entregava no fim era o APK. Então a parte Android dessa aposta não é teoria pra mim, é uma coisa que eu já vivi uma vez.

Fora isso, React nunca saiu do meu caminho: meu dia a dia é Ruby, Rails e React, e React já apareceu neste blog em 2020. O React Native é que andou muito de lá pra cá, e eu queria ver no que ele virou, não no que eu lembrava dele. Pra essa pergunta ter resposta honesta, tem que ser app de verdade, com prazo de verdade.

Onde o JavaScript para

Resposta curta: o React Native cobre a metade de cima, e a plataforma cobra a de baixo.

No Android você troca o launcher inteiro e pronto, o sistema é seu. No iPhone não existe isso. Ninguém substitui a tela inicial do iOS, e é por isso que todo app desse nicho, o meu e o do Michael, chega pelo mesmo caminho: um widget. O widget é a única superfície que a Apple deixa você desenhar ali.

E widget no iOS é SwiftUI, sempre. O WidgetKit não tem runtime de JavaScript, não é preferência minha e não existe biblioteca que mude isso. Ou seja, justo a parte que fica na sua tela, a que importa, é Swift. Hoje são 2.840 linhas de Swift pra 7.371 de TypeScript, quase um terço do app.

Tem mais uma pegadinha, e essa o usuário sente. Um toque no widget não abre outro app direto, o iOS não permite. O toque cai primeiro no app hospedeiro, que aí te encaminha pro destino. Dá pra ver acontecendo, e não tem como esconder.

A frase entre os toques

Em vez de pedir desculpa por esse piscar, eu resolvi preencher ele. Cada pulo mostra uma frase, pelo tempo que você escolher, de zero a quatro segundos, e aí você chega onde ia.

Isso deixou de ser conserto técnico e virou a parte que eu mais gosto. Se a ideia do app é te fazer desacelerar na hora de pegar o telefone, uma pausa obrigatória no meio do caminho não é bug, é exatamente o produto. A limitação da plataforma virou o único momento de silêncio do aparelho.

São 20 frases por idioma, cada uma com autor, e cada idioma puxado da tradição dele em vez de traduzido do inglês. As suas você escreve, e elas nunca são mexidas quando você troca de idioma.

As frases que aparecem no caminho, com quem escreveu

A pegadinha que apaga tudo

Essa é a parte que eu não sabia antes de começar, e é a que quase me custou caro.

O app e o widget são dois processos que nunca conversam direto. O único canal entre eles é um App Group, um UserDefaults compartilhado, guardando uma string JSON. Parece trivial. Não é.

Se você entregar um objeto pro lado nativo em vez de uma string, a ponte converte o true do JavaScript pra 1. O Swift tenta ler aquilo como Bool, levanta erro, o erro escapa, um try? engole ele, e a configuração inteira volta pro padrão de fábrica. Todos os apps que a pessoa adicionou somem. Sem erro na tela, sem log, sem crash.

É por isso que o módulo nativo daqui recebe String e nunca objeto. E é por isso que os 257 testes do projeto quase não olham pra tela: eles cercam os quatro pontos onde estar errado é silencioso. A regra que eu adotei foi testar a falha, não o caminho feliz, porque entrada malformada é o que chega ali de verdade.

Status

O código está aberto em github.com/guilhermeyo/tsp, sob MIT. Roda no meu iPhone todo dia, e a lista da primeira foto é a minha de verdade.

O próximo passo é a App Store. Depois dela, o Android, que é o motivo de tudo isso estar em React Native.

Finalizando

Eu não fiquei mais produtivo de um dia pro outro, e aquele estudo já avisa que segurar isso é a parte difícil. O que mudou foi menor e mais concreto: eu pego o telefone pra fazer uma coisa e saio dele tendo feito aquela coisa.

Tem muita gente hoje contando que tem IA trabalhando 24 horas por dia, sete dias por semana, tocando cem produtos ao mesmo tempo. Entregue mesmo eu vejo pouco. Prefiro o contrário: um app só, terminado, que eu uso todo dia e que qualquer pessoa pode pegar e usar.

E terminar é o que ensina. Eu aprendi React Native lendo sobre React Native, e aprendi mais ainda levando um app até o fim e batendo em cada limite que a plataforma impõe. A base é a mesma que eu venho construindo há anos de carreira, só que aplicada numa tecnologia diferente, e é aí que ela consolida: você descobre o que era conceito de verdade e o que era só costume da ferramenta antiga.

No post do McLovin eu disse que iOS e Android ficavam pra depois. O depois chegou, e a régua que eu me dou é a mesma de lá: o mesmo app nos dois sistemas, escrito uma vez só. Por enquanto está metade entregue.

Fontes

Publicado originalmente em guilherme44.com.

My iPhone became a dumbphone, and I built the launcher in React Native

Guilherme Yamakawa de Oliveira — Fri, 14 Aug 2026 02:59:21 +0000

In the McLovin post I wrote that iOS and Android were for later. Their turn came, just through a different door. What I went and did on the phone was not link routing, it was getting screen out of my face.

The number that made me stop is a Brazilian one: according to Bain, someone in Brazil spends 9 hours and 13 minutes a day connected, against a global average of 6 hours and 38. In the same survey, screen time is the habit Brazilians would most like to change, ahead of diet and being sedentary. It is not that we do not notice. We notice, and we stay.

My home screen today: forecast on top, the apps as a list of names

What a dumbphone is

For anyone who has never run into the term: a dumbphone is the phone that only makes calls and sends SMS. No social apps, no games, no browser. It is what everybody carried before 2007, and it became a movement precisely because it stopped being the default. In the United States feature phones started selling again, 2.8 million units in 2023, pushed by Gen Z digital detox.

And it works. A study in PNAS Nexus blocked mobile internet for 467 people for two weeks, and attention, mental health and wellbeing all improved. But only 25.5% lasted the minimum 10 days. The effect is real and it is genuinely hard to sustain. I am not here to tell you I solved this.

Where the idea came from

What introduced me to the subject was Dumb Phone (dp), by Michael Tigas. It swaps the home screen for a list of text buttons and hides the rest through Screen Time. It is well made and it does more than mine.

Except I am a developer and I like learning and growing, and mobile is the screen everyone has in their hand all day. I could have studied that by reading changelogs and watching talks, but there is no skin in the game in that. So I went in the way that actually teaches: an app of my own, one I use every day, and on both stores.

What I built

The home screen becomes a list of names in plain text. No icons, no badges, no grid. You tap a name and the app opens.

The idea is not to become a monk, it is to remove the competition. The stock home screen is a grid of coloured squares fighting for your attention, and the apps I open every day are five. The rest is noise I scroll past. Swapping icons for text takes colour out of the equation, and without colour you stop recognising an app from across the screen and have to read instead. Reading is slower. Slower is the point.

The app is the editor, where you build the list and pick the type and the alignment. The widget is the product, and it is the part that stays on screen.

Where you build the list, with the widget preview on top

Why not just Swift

This app already existed in Swift. The first version is SwiftUI all the way through, it lives in a repo of mine next door, and it works well. Rebuilding it in React Native was a decision, not an accident.

The reason is Android. I want the same app in both places and I do not want to write it twice. This version is the first one, it is iOS, and it is already built on top of the part that travels when I cross over. Had I stayed in Swift, Android would start from zero some day.

And there is the personal reason: it had been a while, but this is not my first time. Back in the early days of React Native, when the framework was still new, I built an investment calculator for a financial institution, and what I shipped at the end of it was the APK. So the Android half of this bet is not theory to me, it is something I have already lived through once.

Beyond that, React never left my path: my day to day is Ruby, Rails and React, and React showed up on this blog back in 2020. React Native is the one that moved a long way since, and I wanted to see what it had become rather than what I remembered. For that question to get an honest answer, it has to be a real app with a real deadline.

Where JavaScript stops

Short answer: React Native covers the top half, and the platform charges you for the bottom one.

On Android you replace the whole launcher and that is that, the system is yours. On the iPhone there is no such thing. Nobody replaces the iOS home screen, and that is why every app in this niche, mine and Michael's alike, arrives through the same door: a widget. The widget is the only surface Apple lets you draw on there.

And a widget on iOS is SwiftUI, always. WidgetKit has no JavaScript runtime, that is not my preference and no library changes it. So the very part that sits on your screen, the one that matters, is Swift. Right now that is 2,840 lines of Swift against 7,371 of TypeScript, close to a third of the app.

There is one more catch, and this one the user feels. Tapping a widget row does not open another app directly, iOS will not allow it. The tap lands in the host app first, which then forwards you to the destination. You can watch it happen, and there is no hiding it.

The phrase between the taps

Instead of apologising for that flash, I decided to fill it. Every hop shows a phrase, held for as long as you choose, zero to four seconds, and then you arrive where you were going.

This stopped being a technical patch and became the part I like most. If the point of the app is to slow you down when you reach for the phone, a forced pause halfway there is not a bug, it is exactly the product. A limitation of the platform became the one quiet moment on the device.

Twenty phrases ship per language, each attributed, each drawn from that language's own tradition rather than translated from English. Yours are yours to write, and they are never touched when you switch languages.

The phrases shown on the way, with who wrote them

The trap that wipes everything

This is the part I did not know before starting, and the one that nearly cost me dearly.

The app and the widget are two processes that never talk to each other directly. The only channel between them is an App Group, a shared UserDefaults, holding one JSON string. Sounds trivial. It is not.

If you hand the native side an object instead of a string, the bridge turns the JavaScript true into 1. Swift then tries to read that as a Bool, throws, the throw escapes, a try? swallows it, and the entire config resets to the factory default. Every app the person added is gone. No error on screen, no log, no crash.

That is why the native module here takes a String and never an object. And it is why the project's 257 tests barely look at the screen: they fence off the four places where being wrong is silent. The rule I follow is to test the failure, not the happy path, because malformed input is what actually reaches that code.

Status

The code is open at github.com/guilhermeyo/tsp, under MIT. It runs on my iPhone every day, and the list in the first screenshot is my real one.

Next stop is the App Store. After that, Android, which is the reason all of this is in React Native.

Wrapping up

I did not become more productive overnight, and that study already warns that holding on to this is the hard part. What changed is smaller and more concrete: I pick up the phone to do one thing and I put it down having done that thing.

There are a lot of people right now telling you they have AI working 24 hours a day, seven days a week, running a hundred products at once. Shipped ones I see very few of. I would rather have the opposite: one app, finished, that I use every day and that anyone can pick up and use.

And finishing is what teaches. I learned React Native by reading about React Native, and I learned a lot more by taking an app all the way and hitting every limit the platform imposes. The foundation is the same one I have been building for years of my career, only applied through a different technology, and that is where it settles: you find out what was actually a concept and what was just a habit of the old tool.

In the McLovin post I said iOS and Android were for later. Later arrived, and the bar I set for myself is the same one from back there: the same app on both systems, written once. For now it is half delivered.

Sources

Originally posted at guilherme44.com.

[PT-BR] McLovin: o roteador de links multiplataforma

Guilherme Yamakawa de Oliveira — Fri, 15 May 2026 18:37:44 +0000

Semana passada escrevi que roteamento de links é a feature que SO e browser fingem não existir, e fechei dizendo que essa era de IA podia trazer um roteador multiplataforma decente, e que eu seria o divulgador número um. O multiplataforma ainda não saiu, mas a parte do Linux saiu. Lanço hoje o McLovin.

Igual no Superbad, o McLovin se dá bem com o Sistema Operacional (Oficial Slater) e os browsers (Oficial Michaels). Amigo dos dois, ele direciona cada link pro lugar certo.

Menu principal da GUI

Por que o McLovin existe?

No Mac eu usava o Finicky. Migrei pro Linux com o Omarchy faz quase um ano e fui procurar equivalente. O Junction só pergunta a cada link, o mimi não tem regras de roteamento. Sobrava o caminho do "monta o teu", e eu montei. Funcionou muito bem, fiz uma TUI que combinava com o Omarchy. Aí pensei: isso aqui deveria existir em todo SO por padrão, igual a regra que cada SO tem pra escolher qual app abre PDF. Então decidi fazer o McLovin do jeito certo: um roteador multiplataforma, configurável por qualquer pessoa, com picker de browser quando precisar e regras pra mandar cada link pro lugar certo.

No iOS e no Android, esse problema também existe, mas fica pra depois.

O que é

O McLovin se registra como o handler default do sistema pra http e https. Quando você clica em qualquer link, no Slack, no terminal, ou em qualquer outro app, o SO entrega a URL pro McLovin. Ele lê o rules.toml, decide pra onde mandar, despacha o app ou browser certo, e some.

Se nenhuma regra bater, abre um picker no estilo Walker pra você escolher entre os browsers detectados. Dois frontends compartilham o mesmo core em Rust: uma CLI pra automação e keybinds, e uma GUI (mclovin settings) pra mouse e teclado.

Picker quando nenhuma regra bate

As regras

As regras vivem no ~/.config/mclovin/rules.toml. São três tipos: substring, regex com reescrita, e Lua pra regras dinâmicas. Um exemplo curto:

fallback_browser = "brave"

[[handler]]
match = "github.com/empresa"
command = "chrome --profile-directory='Profile 1' {url}"
description = "GitHub do trabalho no Chrome do trabalho"

[[handler]]
match_regex = '^https?://open\.spotify\.com/(\w+)/([^?#/]+)'
rewrite = "spotify --uri=spotify:{1}:{2}"
description = "Spotify aberto direto no app desktop"

[[handler]]
match_lua = "ctx.url.host:find('work') and ctx.now.hour < 18"
command = "chrome --profile-directory='Profile 1' {url}"
description = "Links de trabalho dentro do horário comercial"

O fallback_browser cobre o que não bate em nenhuma regra. O Lua roda num ambiente isolado (sem os.execute, sem loadfile) e recebe o contexto da URL, a hora atual, e o app que originou o clique. Receitas prontas pra colar saem com mclovin examples.

Lista de regras na GUI

Status

A versão alpha pra Linux já está funcionando. macOS e Windows vêm em breve. Pra qualquer problema, abra uma issue no GitHub do mclovin-release.

Onde ver

O manual de instalação, configuração e exemplos de regras está no site oficial:

mclovin.org

Finalizando

No post passado escrevi "eu, além de usar, seria o divulgador número um" de um roteador multiplataforma decente. Estou divulgando o meu. Falta o multiplataforma, mas no Linux já está entregue.

Publicado originalmente em guilherme44.com.

McLovin: the cross-platform link router

Guilherme Yamakawa de Oliveira — Fri, 15 May 2026 18:37:40 +0000

Last week I wrote that link routing is the feature OSes and browsers pretend isn't there, and closed by saying this AI era could bring a cross-platform router, and that I'd be the number one promoter. The cross-platform piece didn't ship yet, but the Linux piece did. Today I'm launching McLovin.

Just like in Superbad, McLovin gets along with the Operating System (Officer Slater) and the browsers (Officer Michaels). Friends with both, he steers each link to the right place.

Main menu of the GUI

Why does McLovin exist?

On Mac I used Finicky. I switched to Linux with Omarchy almost a year ago and went looking for an equivalent. Junction only asks every time, mimi doesn't carry routing rules. The remaining path was "build your own", and I did. It worked well, with a TUI that paired nicely with Omarchy. Then I thought: this should be a built-in feature on every OS, the same way each OS has a rule for which app opens PDFs. So I decided to do McLovin the right way: a cross-platform router, configurable by anyone, with a browser picker when nothing matches and rules to send every link to the right place.

iOS and Android have the same problem, but that's for later.

What it is

McLovin registers as the system's default handler for http and https. When you click any link, in Slack, in your terminal, or in any other app, the OS hands the URL to McLovin. It reads rules.toml, decides where to send it, dispatches the right app or browser, and gets out of the way.

If no rule matches, a Walker-style picker shows the detected browsers and lets you pick one. Two frontends share one Rust core: a CLI for automation and keybinds, and a GUI (mclovin settings) for mouse and keyboard.

Picker shown when no rule matches

The rules

Rules live in ~/.config/mclovin/rules.toml. Three kinds: substring, regex with rewrite, and Lua for dynamic rules. A short example:

fallback_browser = "brave"

[[handler]]
match = "github.com/work-org"
command = "chrome --profile-directory='Profile 1' {url}"
description = "Work GitHub in the work Chrome profile"

[[handler]]
match_regex = '^https?://open\.spotify\.com/(\w+)/([^?#/]+)'
rewrite = "spotify --uri=spotify:{1}:{2}"
description = "Spotify links opened in the desktop app"

[[handler]]
match_lua = "ctx.url.host:find('work') and ctx.now.hour < 18"
command = "chrome --profile-directory='Profile 1' {url}"
description = "Work links during business hours"

fallback_browser covers anything that doesn't match. Lua runs in a sandboxed environment (no os.execute, no loadfile) and receives the URL context, the current time, and the app that triggered the click. Ready-made recipes come from mclovin examples.

Rules list in the GUI

Status

The Linux alpha is working today. macOS and Windows are coming soon. Run into a problem? Open an issue on the mclovin-release GitHub.

Where to look

The full install guide, configuration manual, and rule examples live on the official site:

mclovin.org

Wrapping up

In the previous post I wrote "I'd be the number one promoter" of a decent cross-platform router. I'm promoting mine. The cross-platform part isn't there yet, but Linux is.

Originally posted at guilherme44.com.

[PT-BR] Pela terceira vez, o Google enfia coisa no seu PC sem perguntar

Guilherme Yamakawa de Oliveira — Fri, 08 May 2026 18:31:44 +0000

Se você usa o Chrome, tem 4GB de modelo de IA na sua máquina que você nunca pediu. E não é a primeira vez que o Google faz isso, é a terceira. O pesquisador Alexander Hanff publicou o relatório em 4 de maio de 2026. O arquivo se chama weights.bin, fica em OptGuideOnDeviceModel dentro do diretório do Chrome, e é o Gemini Nano. Sem aviso, sem checkbox. Se você descobrir e apagar, o Chrome baixa de novo no próximo restart.

A primeira reação aqui foi de déjà vu, não de surpresa. Em dezembro de 2020 o Loren Brichter (@lorenb no X, o cara do "pull to refresh" e do Tweetie, cliente que o Twitter comprou em 2010 pra virar o app oficial do iPhone) publicou o chromeisbad.com, um site de uma página explicando como o Keystone, o updater do Google Chrome no Mac, ficava rodando em background deixando o sistema lento mesmo com o Chrome fechado. A reclamação dele veio onze anos depois da Wired publicar "Google Software Update Tool is evil" sobre o mesmo Keystone, quando ele apareceu enfiado no Google Earth coletando dados de hardware e baixando coisas em background sem avisar. O remédio que o Brichter indicou foi escrever instruções pra desinstalar Chrome e Keystone na mão, e recomendar Safari, Brave, Vivaldi, Opera no lugar.

O que o Hanff descobriu

A descoberta dele é mais detalhada que a do Brichter em 2020. O Hanff cruzou logs de filesystem do macOS (.fseventsd), o Local State do Chrome, feature flags e logs do GoogleUpdater pra montar uma cadeia de evidências de quatro pontas. No perfil de teste dele, o weights.bin apareceu em 24 de abril de 2026 às 16:38:54 e levou 14 minutos e 28 segundos pra terminar de baixar. Silenciosamente. Cada perfil de Chrome roda esse processo de novo.

A versão afetada é a Chrome 147 e seguintes. O modelo serve pra features como "Help me write" (composição de texto), detecção local de scam e APIs que sites podem chamar (Summarizer API, Translator API, Prompt API).

A parte que dá raiva

Aquele botão chamativo de "AI Mode" que apareceu no omnibox do Chrome, que parece ser a feature visível de IA do browser, não usa o modelo local. As consultas digitadas ali vão pra cloud do Google. Ou seja: o usuário paga 4GB de download e 4GB de espaço em disco por um modelo que não roda quando ele clica no botão de IA do browser. O custo fica com o usuário, o uso fica com o Google.

Em escala

Hanff fez as contas: 0,24 kWh por dispositivo pra baixar e instalar, 0,06 kg de CO2e por dispositivo. Em 1 bilhão de instalações, são 240 GWh e 60 mil toneladas de CO2e, equivalente à emissão anual de cerca de 13 mil carros europeus. E com a União Europeia em cima do GDPR, da ePrivacy Directive (o Artigo 5(3) proíbe armazenar dados no dispositivo do usuário sem consentimento prévio) e da CSRD (a diretiva europeia de reporte de sustentabilidade), a chance de virar caso jurídico é alta.

Como tirar isso da sua máquina

O Google adicionou em fevereiro de 2026 a opção pra desabilitar:

Chrome Settings > System > "Turn On-device AI on or off", se a opção já apareceu pra você.
Caminho alternativo: digite chrome://flags na barra de endereço, busque por "optimization guide on device" e marque como "Disabled". Reinicie o Chrome.

Lembrando que apagar o weights.bin na unha não basta. Sem desabilitar a flag, o Chrome baixa de novo.

O que faço no meu dia a dia

Não uso o Chrome como browser principal há tempos. Escrevi semana passada sobre roteamento de links, e no setup que descrevo lá os browsers que abrem cada link são Chromium-based ou Firefox-based (Brave, Vivaldi, Edge, Opera, Helium), não o Chrome do Google em si. Os mesmos nomes, que o Brichter recomendou em 2020, continuam servindo bem em 2026.

A regra que adotei é simples. Não dá pra confiar num programa que decide instalar 4GB de IA, ou um daemon updater em background, sem te perguntar. O que tá em jogo não é só espaço em disco, é o controle sobre o que o seu computador faz quando você não tá olhando.

E lá vamos nós pela terceira vez

Em 2009 a Wired publicou que o Keystone era evil quando o Google enfiou ele junto com o Google Earth. Em 2020 o Brichter publicou o chromeisbad porque o mesmo Keystone tava dentro do Chrome. Agora em 2026 o Hanff mostrou que são 4GB de IA, instalados do mesmo jeito. Entre essas datas o Google só ficou maior, e a forma de empurrar coisa no PC dos outros sem perguntar não mudou.

Eu uso o Brave, e recomendo usar qualquer outro browser, menos o Google Chrome.

Fontes

Publicado originalmente em guilherme44.com.

For the third time, Google sneaks something onto your PC without asking

Guilherme Yamakawa de Oliveira — Fri, 08 May 2026 18:31:41 +0000

If you use Chrome, there are 4GB of an AI model sitting on your machine that you never asked for. And it is not the first time Google does this, it is the third. Privacy researcher Alexander Hanff published the report on May 4, 2026. The file is called weights.bin, lives in OptGuideOnDeviceModel inside the Chrome user data directory, and it is the Gemini Nano model. No prompt, no checkbox. Find it and delete it, and Chrome re-downloads it on the next restart.

The first reaction here was déjà vu, not surprise. In December 2020, Loren Brichter (@lorenb on X, the guy behind "pull to refresh" and Tweetie, the client Twitter bought in 2010 to become its official iPhone app) published chromeisbad.com, a one-page site explaining how Keystone, Google Chrome's updater on Mac, kept running in the background, dragging the system down even when Chrome was closed. His complaint came eleven years after Wired published "Google Software Update Tool is evil" about the same Keystone, when it showed up bundled with Google Earth, gathering hardware data and downloading things in the background without warning. Brichter's prescription was a manual uninstall guide for Chrome and Keystone, plus a list of replacements: Safari, Brave, Vivaldi, Opera.

What Hanff found

His discovery is more detailed than Brichter's was in 2020. Hanff cross-referenced macOS filesystem logs (.fseventsd), Chrome's Local State, feature flags, and GoogleUpdater logs to build a four-way evidence chain. On his test profile, weights.bin appeared on April 24, 2026 at 16:38:54 and took 14 minutes and 28 seconds to finish downloading. Silently. Each Chrome profile runs the process again.

The affected version is Chrome 147 onward. The model powers features like "Help me write" (text composition), local scam detection, and APIs that sites can call (Summarizer API, Translator API, Prompt API).

The frustrating part

That bright "AI Mode" pill that showed up in Chrome's omnibox, the visible AI feature of the browser, does not use the local model. Queries typed there are sent to Google's cloud. So the user pays 4GB of download and 4GB of disk for a model that does not run when they click the most prominent AI button on the browser. The cost lives with the user, the use lives with Google.

At scale

Hanff did the math: 0.24 kWh per device for the download and install, 0.06 kg of CO2e per device. At 1 billion installs, that is 240 GWh and 60,000 tonnes of CO2e, equivalent to the annual emissions of about 13,000 European cars. And with the European Union watching closely on GDPR, the ePrivacy Directive (Article 5(3) prohibits storing data on a user's device without prior consent), and the Corporate Sustainability Reporting Directive, the chance of this turning into a legal case is high.

How to remove it

Google added an opt-out in February 2026:

Chrome Settings > System > "Turn On-device AI on or off", if the option is showing up for you yet.
Alternative path: type chrome://flags in the address bar, search for "optimization guide on device", and set it to "Disabled". Restart Chrome.

Note that deleting weights.bin by hand is not enough. Without disabling the flag, Chrome downloads it again.

What I do in my daily setup

I have not been using Chrome as my main browser for a long time. I wrote last week about link routing, and in the setup I describe there the browsers that open each link are Chromium-based or Firefox-based (Brave, Vivaldi, Edge, Opera, Helium), not Google's own Chrome. The same names, recommended by Brichter back in 2020, still serve well in 2026.

The rule I keep is simple. You cannot trust a program that decides to install 4GB of AI weights, or a background updater daemon, without asking you. What is at stake is not just disk space, it is control over what your computer does when you are not looking.

And here we go for the third time

In 2009 Wired called Keystone evil when Google bundled it inside Google Earth. In 2020 Brichter published chromeisbad because the same Keystone was now sitting inside Chrome. Now in 2026 Hanff showed that 4GB of AI weights are being pushed the same way. Between those dates Google only got bigger, and the way it pushes things onto other people's machines without asking has not changed.

I use Brave, and my recommendation is any browser, just not Google Chrome.

Sources

Originally posted at guilherme44.com.

Awesome!!

Guilherme Yamakawa de Oliveira — Tue, 05 May 2026 02:22:44 +0000

Amanda Gama

May 5

A Live Activity isn't a notification

#showdev #ios #mobile #tutorial

6 min read

[PT-BR] Roteamento de links: a feature que SO e browser fingem não existir

Guilherme Yamakawa de Oliveira — Sun, 03 May 2026 21:57:23 +0000

Migrei do Mac pro Linux com Omarchy faz quase um ano. Quase tudo voltou ao lugar. Tem uma coisa que continua incomodando, e percebi que o problema é maior do que parecia. Existe uma funcionalidade simples que Sistema Operacional nenhum entrega e browser nenhum entrega: regra pra decidir qual browser ou app abre cada link clicado.

No Mac eu usava o Finicky pra isso. Pra quem nunca viu: ele deixa você criar regras que decidem qual browser abre cada link. Você coloca o Finicky como browser padrão do sistema, e ele aplica suas regras a cada link clicado em qualquer app, escolhendo o browser certo. As regras são pequenos scripts em JavaScript, simples ou mais elaborados conforme a necessidade. Dá até pra reescrever a URL antes de abrir, tipo forçar HTTPS, remover parâmetros de rastreamento, ou converter num link interno que abre o app desktop diretamente. Se nenhuma regra bater, ele cai num browser de reserva que você define.

Na prática, é assim. Link de github.com/empresa abre no browser do trabalho, github.com/pessoal no browser pessoal. meet.google.com cai logado no perfil certo. Vídeo de YouTube volta sempre pro browser principal. Qualquer link que não bater em nenhuma regra cai no de reserva, no meu caso o browser pessoal. Trabalho e vida pessoal separados sem ter que copiar URL e colar na outra janela.

E tem o caso dos apps que vêm com versão desktop e usam um endereço próprio que abre eles direto. Spotify, WhatsApp, Slack, Discord, Zoom, cada um tem um endereço interno tipo spotify:, whatsapp:, slack:, que o sistema entende como "esse link é desse app, abre aqui". Quando alguém compartilha um link público (open.spotify.com/track/..., wa.me/<numero>, chat.whatsapp.com/<convite>), o ideal é abrir direto no app desktop, não numa aba de browser que vai pedir login e perguntar "abrir no app?" toda vez. No Finicky você escreve uma regra que reconhece o link público e reescreve pro endereço interno do app (open.spotify.com/track/abc vira spotify:track:abc, wa.me/5511... vira whatsapp://send?phone=...), e o sistema entrega direto pro app. Aba intermediária zero.

Solução simples, efeito grande. É aí que tá o estranho.

O que existe no Linux

Procurei equivalente e o que mais aparece é o Junction: bonito, ativo, bem mantido. Mas ele só pergunta qual browser usar a cada link. Não tem regras, não decide sozinho. Tem pedido aberto na comunidade pra ele lembrar de uma escolha padrão e só perguntar quando você segurar Alt, mas ninguém pegou pra implementar. Junction só pergunta, não roteia.

O mimi é uma alternativa mais decente ao mecanismo padrão do Linux que abre links (xdg-open), mas também não traz regras de roteamento prontas.

Fora isso, sobra o caminho velho: criar um atalho próprio na pasta de apps do usuário (~/.local/share/applications/), marcar esse atalho como o programa que vai abrir os links do sistema, e escrever um pequeno script que faz o roteamento na mão. Funciona, mas é peça caseira que cada um tem que manter por conta própria, sem comunidade no meio.

O mais perto que tem hoje de Finicky no Linux é "monta o teu".

E no Mac?

No Mac a paisagem é viva. Finicky tá em desenvolvimento ativo, lançou v4.2.2 em outubro de 2025 com editor visual de regras. Tem Velja, Choosy, Default Tamer, Yojam. Mercado inteiro de ferramenta de terceiro tapando o mesmo buraco.

Editor visual de regras do Finicky

E mesmo no Mac essa cena tem casualty. O Browserosaurus, outro favorito da galera, foi arquivado em 2 de agosto de 2025. Mantenedor cansou, sem sucessor oficial. Comunidade tem fork, ninguém é o canônico.

É o que costuma acontecer com ferramenta de terceiro que vive pra cobrir o que SO e browser deixam aberto.

E no Windows?

No Windows a história é a mesma. Você define um único browser pra abrir todos os links do sistema, ponto. Não tem como dizer "esse site abre aqui, esse outro abre lá".

A novidade recente é que o Edge ganhou em 2025 uma opção pra quem tem conta corporativa Microsoft (Entra ID, antiga Azure AD): link externo cai automaticamente no profile de trabalho do Edge. É só uma opção global. Você escolhe um profile e acabou. Sem regra por URL, sem distinção de qual app abriu o link.

Fora do Edge, a cena de terceiro no Windows é até maior do que no Linux. O Hurl (ativo) e o BrowserPicker do mortenn (na Microsoft Store) lideram. O BrowseRouter é um fork ativo do BrowserSelector original, que foi arquivado em 2022. Tem também o Switchbar, comercial e que roda no Mac e no Windows.

Mesmo padrão de sempre. Terceiro tampa o que SO e browser não tampam, e quando o terceiro arquiva (oi, BrowserSelector) a comunidade aparece com fork, ninguém vira o canônico.

Por que nenhum Sistema Operacional entrega

O modelo que existe nos SOs hoje é o mesmo em todo lugar. macOS, Windows, Linux. Pra cada tipo de link, você escolhe um único app que vai abrir e pronto. Link de site (https)? Um browser. Email (mailto)? Um cliente de email. Música (spotify)? Um app. Não dá pra dizer "esse link específico vai pra outro app", nem "esse link veio do Slack, então abre em outro lugar". Cada SO chama esse mecanismo de um nome diferente (xdg-mime no Linux, LaunchServices no Mac, registry no Windows), mas a limitação é a mesma.

Linux teria espaço pra ir além já que esse mecanismo é convenção, não imposição, mas ninguém moveu. macOS e Windows nunca abriram uma forma oficial pra você definir regras de roteamento de link. Trinta anos de SO desktop, e a ideia de "esse link tem que abrir aqui, esse outro tem que abrir lá" continua fora do escopo do sistema.

Por que browser nenhum entrega

Chrome tem um seletor pra escolher qual perfil do próprio Chrome abre o link. Firefox tem "containers" (uma forma de isolar abas em compartimentos separados), e com extensão (Containerise, Auto Containers) dá pra rotear por padrão de URL, mas tudo isso só funciona dentro do Firefox. Nenhum browser quer mandar tráfego pra outro browser. Cada um quer ser o browser padrão do sistema.

Faz sentido pelo incentivo. Mandar link pra outro browser primeiro reduz a métrica que importa pra cada empresa, que é link aberto no produto deles. Pelo lado da segurança também tem desculpa: um único browser padrão de confiança é mais simples de auditar do que um esquema que decide pra onde mandar com base em regrinha de URL. Nada disso explica o tamanho do silêncio dos SOs.

Enquanto isso

Faz mais de dez anos que esse problema é o mesmo. SO e browser fingem que rotear link não é responsabilidade deles, e toda vez que aparece terceiro pra resolver, ele vira projeto solo até o mantenedor cansar. Aí volta todo mundo pra estaca zero (oi, Browserosaurus).

Separar link clicado por regra é tarefa básica de quem trabalha com mais de um contexto no mesmo computador. Devia estar na base do sistema, no mesmo nível de "qual app abre PDF". Faz dez anos esperando.

Seria muito bom essa era de IA finalmente trazer um multiplataforma decente para todos. Mac, Windows e Linux na mesma ferramenta. Eu, além de usar, seria o divulgador número um. Mercado pra ele a gente sabe que tem.

Fontes:

Publicado originalmente em guilherme44.com.

Link routing: the feature OSes and browsers pretend isn't there

Guilherme Yamakawa de Oliveira — Sun, 03 May 2026 21:57:19 +0000

I switched from Mac to Linux with Omarchy almost a year ago. Most things slid back into place. There's one thing still bothering me, and turns out it's not just a Linux problem. There's a simple feature no OS ships and no browser ships: rules for deciding which browser or app opens each link you click.

On Mac I used Finicky for this. For anyone who never saw it: it lets you write rules that decide which browser opens each link. You set Finicky as the system's default browser, and it applies your rules to every link clicked in any app, picking the right one. Rules are short scripts in JavaScript, simple or as elaborate as you need. It can even rewrite the URL before opening it: force HTTPS, strip tracking parameters, or convert it into an internal link that opens the desktop app directly. If no rule matches, it falls through to a backup browser you define.

In practice, it looks like this. A github.com/work-org link opens in the work browser, github.com/personal in the personal one. meet.google.com lands logged into the right profile. YouTube videos always come back to the main browser. Anything that matches no rule falls through to the backup, in my case the personal browser. Work and personal life kept apart without copy-pasting URLs into another window.

There's also the case of apps that ship a desktop client and use their own private address to open it directly. Spotify, WhatsApp, Slack, Discord, Zoom, each has an internal address like spotify:, whatsapp:, slack:, which the system reads as "this link belongs to that app, open it there". When someone shares a public link (open.spotify.com/track/..., wa.me/<phone>, chat.whatsapp.com/<invite>), the right move is to open it straight in the desktop app, not in a browser tab that asks for login and prompts "open in app?" every single time. With Finicky you write a rule that matches the public link and rewrites it to the app's internal address (open.spotify.com/track/abc becomes spotify:track:abc, wa.me/15551234567 becomes whatsapp://send?phone=...), and the system hands it straight to the app. No intermediate tab.

Simple solution, big payoff. That's the strange part.

What exists on Linux

Searched for an equivalent and the most common answer is Junction: pretty, active, well maintained. But it only asks which browser to use on every link. No rules, no auto-routing. There's a community request asking it to remember a default choice and only ask when you hold Alt, but nobody has picked it up. Junction only asks, it doesn't route.

mimi is a more decent replacement for the Linux mechanism that opens links (xdg-open), still without ready-made routing rules.

What's left is the old path: drop a custom shortcut file in the user's apps folder (~/.local/share/applications/), mark that shortcut as the program that opens the system's links, and write a small script that does the routing by hand. It works, but it's a homebrew piece each user has to maintain on their own, with no community in the middle.

The closest thing to Finicky on Linux today is "build your own".

And on Mac?

The Mac landscape is alive. Finicky is actively developed, with v4.2.2 out in October 2025 bringing a visual rules editor. There's Velja, Choosy, Default Tamer, Yojam. A whole third-party market plugging the same gap.

Finicky's visual rules editor

Even there it has casualties. Browserosaurus, another community favorite, was archived on August 2, 2025. Maintainer burned out, no official successor. Community has forks, none is canonical.

That's what tends to happen to any third-party tool plugging a gap that neither the OS nor the browser wants to plug.

And on Windows?

On Windows, same story. You set one browser to handle every link in the system, period. No way to say "this site opens here, that other one opens there".

The recent twist is that in 2025 Edge added a toggle for users on a Microsoft corporate account (Entra ID, formerly Azure AD): external links automatically land in Edge's work profile. It's just a global toggle. You pick a profile and that's it. No URL rules, no awareness of which app opened the link.

Outside Edge, the third-party scene on Windows is actually bigger than on Linux. Hurl (active) and mortenn's BrowserPicker (on the Microsoft Store) lead the pack. BrowseRouter is an active fork of the original BrowserSelector, which was archived in 2022. There's also Switchbar, commercial and running on both Mac and Windows.

Same old pattern. Third-party plugs what OS and browser won't, and when the third-party gets archived (hi, BrowserSelector) the community spins up forks, none becoming the canonical one.

Why no OS ships this

The model across operating systems is the same everywhere. macOS, Windows, Linux. For each kind of link, you pick one app that opens it, end of story. A web link (https)? One browser. Email (mailto)? One mail client. Music (spotify)? One app. No way to say "this specific link goes to a different app", or "this link came from Slack so open it somewhere else". Each OS calls this mechanism by a different name (xdg-mime on Linux, LaunchServices on macOS, the registry on Windows), but the limit is the same.

Linux has room to go further since this mechanism is convention, not enforcement, but nobody has moved. macOS and Windows never opened a public API for routing links by rule. Thirty years of desktop OS, and the idea of "this link belongs here, that other link belongs there" still sits outside the system's scope.

Why no browser ships this

Chrome has a selector for picking which profile of Chrome itself opens the link. Firefox has "containers" (a way to isolate tabs into separate compartments), and with extensions (Containerise, Auto Containers) you can route by URL pattern, but all of that only works inside Firefox. No browser wants to hand traffic over to another browser. Each one wants to be the system's default browser.

The incentive math is clear. Sending links to a different browser first reduces the metric that matters for each company, links opened in their own product. The security argument is also there: one trusted default browser is easier to audit than a system that decides where to send things based on URL-matching rules. None of that explains the size of the silence on the OS side.

Meanwhile

This problem has been the same for over ten years. OSes and browsers act like routing a link isn't their responsibility, and every time a third-party tool steps up to fix it, it ends up a solo project until the maintainer burns out. Then everyone goes back to square one (hi, Browserosaurus).

Splitting clicked links by rule is a basic task for anyone juggling more than one context on the same machine. It belongs in the base of the system, at the same level as "which app opens PDFs". Been ten years waiting.

It would be great for this AI era to finally bring a decent cross-platform one for everyone. Mac, Windows and Linux in the same tool. Beyond just using it, I'd be its number-one evangelist. The market is there, we all know that.

Sources:

Originally posted at guilherme44.com.

[PT-BR] Por que troquei meu "Opinionated Linux" autoral (DIY) pelo Omarchy

Guilherme Yamakawa de Oliveira — Sat, 02 May 2026 12:23:32 +0000

Tô usando o Omarchy como setup principal desde 26 de junho de 2025, dia em que o DHH lançou a primeira versão. Antes tinha meu "Opinionated Linux" autoral (DIY), o mclovin-ARCHived: um installer Arch + i3wm com tudo configurado do meu jeito. Era controle total sobre o SO: eu decidindo o que entra, mantendo cada peça (i3wm, polybar, picom, kitty, dotfiles) atualizada e fazendo elas conversarem entre si pra o SO inteiro funcionar. Servia bem, mas era custoso de manter atualizado: sempre desbravando algum TUI novo pra resolver um probleminha, e trocar de CPU ou notebook era ver compatibilidade de tudo e ajustar pra cada máquina.

O Omarchy resolveu isso entregando o mesmo tipo de setup, só que com uma comunidade inteira por trás, trabalhando e discutindo melhorias toda semana. Aprendo algo novo o tempo todo.

Tema: Osaka Jade

Por que o Omarchy

O Omarchy é uma distro Arch opinativa criada pelo David Heinemeier Hansson (DHH), criador do Rails, do Basecamp e do Hey. Por baixo é Arch Linux + Hyprland, mas vem com tudo pré-configurado: lock screen, menu bar, bluetooth, temas, atalhos. Nada de instalar pacote por pacote.

O que me convenceu: Hyprland puro é bonito mas cru. Sozinho ele te deixa configurando coisas básicas por semanas. O Omarchy escolhe defaults bons e te entrega um sistema pronto pra trabalhar poucos minutos depois do boot.

É irmão do Omakub, versão Ubuntu da mesma ideia. Quem quer Linux com curva mais suave vai pro Omakub, quem quer Arch sem perder dois dias configurando vai pro Omarchy.

Temas

Um dos pontos fortes do Omarchy é a comunidade de temas. O omarchythemes.com reúne dezenas de temas prontos pra instalar com um comando, e a paleta inteira muda junta: terminal, editor, status bar, lock screen, wallpaper. E a troca é instantânea. Um atalho, dois segundos, todo o sistema já tá com o novo visual. Impressionante toda vez. A hero shot lá em cima tá com o Osaka Jade. Abaixo, um dia a dia com o Rose of Dune.

Tema: Rose of Dune

De onde vim

Voltei pro Linux saindo de um MacBook M1 com 16GB de RAM. Vários fatores pesaram: o Docker estourava a memória e no Mac RAM é soldada, não dá pra subir, precisa comprar um novo (e configurar com mais memória vira coisa burocrática e cara); pra ter um tiling window manager precisava desabilitar parte da proteção do sistema (o SIP) pra forçar o Yabai (tiling WM pra Mac), e qualquer update do macOS quebrava algo; e queria saber o que tava rodando na máquina, já que Mac, Windows e até Ubuntu vêm cheios de coisa que você não pediu, mandando telemetria sem transparência. Até o Chrome no macOS instala um daemon silencioso chamado Keystone por trás (vale ler o chromeisbad.com). Trocar pra Arch era o caminho natural.

Construí o mclovin-ARCHived pra automatizar a instalação do meu setup Arch + i3wm + polybar + neovim + dotfiles. O nome era referência ao McLovin do filme Superbad, era basicamente meu "script superbad".

A referência inicial foi o Omakub do DHH, que mostrou o padrão "rodar um script e ter tudo pronto". Não fui pro Omakub direto porque anos atrás já tinha usado muito Ubuntu e não curtia o estilo do GNOME, queria algo mais personalizável e tiling. Mas a ideia ficou.

Outras inspirações:

ML4W, outro projeto de automação de Arch que cheguei perto de adotar
typecraft_dev no YouTube, com tutoriais de Hyprland, i3wm, Neovim e Arch
caffeine.wiki/x220, onde o Rodrigo Franco (caffo) personalizou o Arch + dwm num Thinkpad X220 pra ter uma máquina barata, durável e discreta pra trabalhar em qualquer canto (cafezinho de bairro suspeito incluso)

O installer fazia o trabalho. Mas era trabalho de manter sozinho.

Por que migrei

Ter installer próprio é divertido até o dia que você precisa fazer o display manager funcionar com a webcam nova. Ou descobrir que aquele AUR helper que você escolheu três anos atrás virou abandonware. Ou ver que o tema do polybar quebrou porque a fonte mudou de nome num update.

Tudo isso é resolvível. Mas resolvível por uma pessoa só não escala bem.

Como uso Ruby on Rails, sempre acompanhei o trabalho do DHH. O Rails é o que ele chama de omakase (em japonês, "deixa comigo, eu escolho"): você usa os defaults bons que vieram com a caixa, sem ficar configurando cada peça. Omakub levou a mesma ideia pro Ubuntu, e em junho de 2025 saiu o Omarchy, omakase pra Arch + Hyprland. Continuação natural. Entrei no dia 1.

Acompanhar cada release desde o início faz parte da graça. O sistema fica mais redondo a cada versão, e a vista de perto da evolução compensa uns perrengues no caminho.

Quando faz sentido pra você

Antes da checklist prática: o Omarchy faz sentido se você é curioso pra entender como Linux funciona na prática. Vai acompanhar o projeto, atualizar, eventualmente quebrar o SO e ter que formatar pra arrumar. Não é caminho pra qualquer um. Mas é assim que se ganha conhecimento real de como o sistema funciona, em vez de só usar de longe.

Omarchy é ótimo se você:

Quer Arch + tiling WM mas não quer gastar dias configurando
Curte a pegada omakase: defaults opinativos, convenção sobre configuração
Tá disposto a aprender Hyprland (ele tem suas pegadinhas)

Sobre hardware: roda bem até em máquinas antigas. Vários Macs com Intel que estavam parados em gaveta voltaram pra ativa rodando Omarchy. Alguns hardwares ficam mais difíceis de configurar, mas a comunidade no Discord e no GitHub do projeto geralmente já passou pelo problema e ajuda a resolver.

Não é pra você se quiser configurar cada bit do sistema na mão (nesse caso, Arch puro é o caminho), ou se prefere KDE/GNOME (Omarchy é Hyprland-only por design).

Finalizando

Manter um installer próprio de Linux foi uma fase boa, aprendi muito. Mas chegar no Omarchy é poder usar a mesma filosofia sem ser o único responsável por mantê-la.

Formato o computador e em poucos minutos tenho tudo configurado de novo. Mac não funciona bem assim, Windows muito menos.

E nem tudo é escrito em pedra. Ainda quero montar um "Opinionated Script" pro macOS com keybindings e tiling window manager parecidos com o do Omarchy, já que preciso do macOS pra usar Xcode e publicar pra iOS. Faz sentido deixar a máquina configurada na mesma pegada, sem ter que viver dentro dela. Com IA hoje, montar um script desse é tranquilo.

Pra quem quer Arch produtivo no dia a dia sem virar o mantenedor solo, Omarchy é a melhor pedida.

Fontes:

Publicado originalmente em guilherme44.com.