You liked my app map viewer, so I built a proper CI tool for it ➡️ one click map previews from a comment in your PR ➡️ supports @expo EAS ➡️ deterministic on CI without burning tokens (or bring your own LLM key) ➡️ free, customizable, open source screenmap.dev

Funny enough, @kzzzf was still here!

Here's what I think about the @ShopifyEng RN → native migration article: When I rebuilt the Expo Go UI using Jetpack Compose last year, I already felt that all declarative UI frameworks are fairly similar in use, and that agents do a good job migrating between them when it comes to presentation layers. So I'm not surprised Shopify found it possible to fairly quickly rewrite an existing RN app into two separate native codebases. That was always the easier part. I think the main problem lies in making sure the business logic layer doesn't diverge when there's nothing keeping it together. We introduced a few minor differences between the two Expo Go platforms despite trying very hard not to. And consistency vs platform feel is one more question of taste, not something an agent will always solve for you. I don't think react-native will go away, but I definitely feel react-native is evolving, will evolve further, and I have a couple of predictions: ➡️ More and more low level UIs as native components (either ExpoUI or local expo modules with native code files mixed with JS). Agents are great at writing presentation layers, so why bother having JS lists with all that complexity and perf costs? ➡️ OTAs are more important than ever, prepare for changes ahead of time. Slow app store review times vs cheap code push people to allow more customisability from JS, essentially treating the JS layer as server driven UI. ➡️ New UI paradigms mean RN remains valuable. Think custom, per-user interfaces (made for you UIs streamed inside chat, customizable apps etc.) – you need an interpreted higher level abstraction layer that's easier to define and has an SDK. ➡️ Focus on brownfield with no clear set boundaries. Agents pick and choose if they want to build experiences in native or in JS, with most components/APIs/libraries available both as JS and native entrypoints. In general: I don't think the falling cost of writing lower level code makes abstractions automatically obsolete. You get for free a lot of community effort on deciding/mapping platform quirks, stuff that would cost tokens and engineering effort otherwise, or even worse, would be missed and be a long-running paper-cut in your app. I think it makes it necessary to make abstractions lock-in free. Use these opinions and higher level components when they make sense and give value, use lower level super easily and cheaply otherwise. That's why I'm excited about stuff like Expo UI, the new modules API, our @swmansion libraries that work for both RN and native, and all the other effort we did as a community to make mixing those approaches possible and pain free.

screenmap.dev now supports android! Screenmap is a tool that runs in your CI and captures your entire navigation flow and how each screen changes – ship PRs with confidence.

Me when my PRs document themselves

anyone else always sees a typing indicator here?

my current pattern: work on 5 different things spawn 10 agents forget what 7 of them are supposed to do land only 1-2 things instead of 5 we really need better "keep track of things" tools

Want to see this on all your PRs? Use screenmap.dev

here’s the MVP i shared 2 weeks ago:

TIL: if you tell claude a piece of copy feels "claudish", it will fix most issues with it and make it actually reasonable