I build something I thought you might like:

Ship a mobile app and suddenly you need screenshots everywhere. App Store listings. Your website's feature pages. FAQs. Social media. Each one lives in a different place, and each one goes stale the moment you push an update.

My app's theme engine (powered by Monkeytype) supports 190 themes. I'm working towards making the website available in all of them, which means every screenshot on every feature page needs a variant per theme. That's 50 screenshots across 13 features. At 190 themes, that's 9,500 screenshots total. And that number grows with every new feature and every new theme added.

I needed the screenshots to live in the codebase, regenerate on demand, and flow into everything downstream without me touching Canva or Figma.

The Setup: A TypeScript Monorepo

The prerequisite is a monorepo. Mine is TypeScript with a React Native app alongside a web app, but the principle applies anywhere your mobile code, web code, and asset pipeline can share context.

The relevant structure looks something like this:

monorepo/
├── apps/
│   ├── mobile/       # React Native app
│   ├── web/          # Website
│   ├── remotion/     # Remotion compositions
│   └── maestro/      # Test flows + screenshot automation
├── packages/         # Shared UI, themes, config
└── assets/           # Screenshots, icons, media

The important bit: themes, typography tokens, SVG assets (muscle illustrations, exercise videos, etc.), and the component library are all importable from anywhere in the project. That matters later.

Maestro

Maestro is a mobile UI testing framework. I use it for testing, but it has a feature most people overlook: it can take screenshots as part of any test run.

Here's what I did:

• Wrote a flow for every feature in the app.
• Added screenshot commands at the key moments in each flow.
• Built a deterministic seed that makes every screenshot consistent and reproducible.

Flow used for the cover image:

appId: com.tom.logro
---
- launchApp
- runFlow: ./setup/seed-data.yaml

- tapOn:
    id: "tab-progress"
- takeScreenshot: screenshots/features/progress-dashboard/${THEME_ID}/dashboard

The Seed

The seed is what makes this work. Before any flow runs, a setup script populates the app with deterministic data: specific exercises, programs, workout history, and stats. Because the data is idempotent, screenshots come out identical every run. Same numbers, same layouts, same everything.

Each flow opens the app with a deep link that triggers the seed and sets the theme:

appId: com.tom.logro
---
- openLink: "volm://?seed=true&theme=${THEME_ID}"
- waitForAnimationToEnd:
    timeout: 60000
- assertVisible:
    id: 'tab-home'

The seed=true parameter tells the app to populate itself with deterministic data on launch. THEME_ID is passed in when running the suite, so the same flows produce screenshots for any theme.

This also means the screenshots look good, because the data was designed to look good. You're not screenshotting a blank app or a test account with three entries.

For theme switching, I pass a theme parameter when running the flows. Maestro runs the full suite once per theme, and I get a complete set of screenshots for each.

Now when I update a screen, I run the Maestro flows and everything updates:

• App Store screenshots regenerate automatically.
• The website pulls the same images for feature pages and FAQs, across all 190 themes.
• Everything stays in sync because there's one source of truth: the flows.

No re-screenshotting. No re-exporting. No "wait, is this the latest version?" I trigger this manually for now. It's not wired into CI. But even running it by hand saves a stupid amount of time. I can be genuinely confident in this part of the pipeline.

Caveat: Seeded Data Doesn't Always Look Real

The tricky part is that the flow has only been running for seconds. So your "active workout" screenshot shows a timer at 0:10 because Maestro literally just navigated there. Real users don't have a workout that's ten seconds old. You can work around some of this with clever seed design, but certain screens will always betray the fact that no human was actually using the app. It's a trade-off I'm fine with, but worth knowing.

Remotion

Remotion is a React-based framework for generating images and video programmatically. Because compositions are just React components, they can import everything from the monorepo: design tokens, components, and those Maestro-generated screenshots.

So far I've used it for:

• App Store screenshot slides. Composing the raw screenshots into device frames with marketing copy.
• One social media post. A branded carousel for Instagram. I've only made one so far, so I can't claim this is a proven workflow, but I was happy with how it turned out.
• The cover image for this post. The Maestro flow above ran once per theme, Remotion composed all 190 screenshots into a single grid sorted by color.

Remotion without an LLM in the loop is painful compared to visual tools. The feedback cycle is just too slow. Where it works is when you point something like Claude Code at your repo and iterate on compositions, because the LLM already has access to your actual tokens and assets. That makes the loop fast enough to be worth it. Without that, I'd probably just use Canva.

The real value isn't the output quality. It's that the assets are generated from the same source as everything else. Update the app, run the flows, regenerate the Remotion compositions. Nothing drifts.

The Pipeline

Here's how it connects:

1. Develop a feature in the monorepo.
2. Run Maestro flows. Tests pass, screenshots land in the repo.
3. Remotion compositions pick up those screenshots to generate App Store slides and social content.
4. The website pulls the same screenshots for feature pages and FAQs.
5. Update anything upstream, everything downstream regenerates.

One repo. One set of screenshots. No duplicated assets. Update anything upstream, everything downstream regenerates.

Trade-offs

Maestro setup is a real investment. Building deterministic test data and configuring flows for every screen took serious time. Keeping the seed up to date as the app evolves is ongoing work too. This is infrastructure, not a weekend project.

Remotion is only practical with AI tooling. If you're not using an LLM to write and iterate on compositions, the feedback loop is too slow compared to Canva or Figma. They exist for a reason.

It's not in CI yet. I run this manually when I need fresh screenshots. I'll wire it into a deploy pipeline at some point, but even running it by hand cuts out most of the work.

The ROI is in reuse. You won't see the payoff from the first asset you produce. You'll see it the fifth time you add a feature and everything updates without you thinking about it.

Who This Is For

If you're a solo developer or small team and your screenshots keep going stale across multiple surfaces, this is worth the setup cost. If you're already in a TypeScript/React monorepo, you have most of the foundation.

Start with Maestro. Get your screenshots automated and seeded. That alone will save you more time than you expect. Remotion can come later if you want it. App Store slides are a good first project.

See the results on the feature pages, Play Store / App Store, and Instagram.

A few weeks ago I posted about Koolbase, a BaaS built for mobile developers (Flutter + React Native). Got great feedback from this community, thank you all.

Since then I've shipped:

- Analytics: funnels, retention cohorts, DAU/WAU/MAU

- Cloud Messaging: FCM push notifications via the SDK

- Onboarding checklist: cleaner first-run experience

- Flutter SDK v2.4.0 on pub.dev

- React Native SDK v1.4.1 on npmjs.com

Still free to start, no credit card required.

If you tried it before and hit a wall, would love to know what blocked you. If you haven't tried it yet, would love to know why.

koolbase.com | docs.koolbase.com

Hey! 👋

I made the Coach Series — 10 sports team management

apps for amateur coaches.

Features:

✅ Visual lineup/formation builder

✅ Player availability tracking (injury/suspension/absent)

✅ Match results & season stats

✅ Custom uniforms

✅ No account required

Hey r/IMadeThis! 👋

I made the Coach Series — 10 sports team management

apps for amateur coaches. Built with Flutter.

Features:

✅ Visual lineup/formation builder

✅ Player availability tracking (injury/suspension/absent)

✅ Match results & season stats

✅ Custom uniforms

✅ No account required

I’ve been building react-native-google-maps-plus, a React Native library for Google Maps on iOS and Android.

The goal was to keep it focused on Google Maps instead of building a generic maps abstraction, and to make it fit better into modern React Native projects using the New Architecture.

Repo:
https://github.com/pinpong/react-native-google-maps-plus

If you are working on a React Native app and need a Google-Maps-focused library, this might be useful.

A fully native iOS QR scanner that bursts out of the Dynamic Island — many customizations and zero external dependencies.

https://github.com/ismnoiet/react-native-qrcode-scanner

#ReactNative #iOS #qrcode #qr #scanner #SwiftUI #DynamicIsland #OpenSource

I call it SwiftComposer and it's come a long way...

SwiftComposer is a React Native + Expo composer shell that hands most of its behavior to useSwiftComposerController, then assembles the UI from a SwiftUI-backed SwiftTextField, MarkdownToolbar, MentionSuggestionList, glass controls, and attachment previews inside index.tsx. Under the hood it mixes RNAnimated/LayoutAnimation, keyboard-aware positioning, formatting hooks, suggestion triggers, expansion logic, and a native text-field bridge via expo/ui + swift-ui, so the same composer can flip between integrated and floating toolbar modes while still feeling native on iOS.

A bit intimidated at the thought of open sourcing it, so this is more to show what is possible with expo/ui's new updates. If anyone has any suggestions for rendering inline markdown, I'm all ears; I see it is supported with the <Text /> component from expo/ui, but not so much the <TextField />

Snippet 1:

const {
  activeSuggestions,
  bottomAnim,
  handleSubmitButton,
  markdownToolbarController,
  shouldShowFloatingToolbar,
  shouldUseFloatingToolbar,
} = useSwiftComposerController({
  value,
  onChangeText,
  onSubmit,
  attachedImageUri,
  toolbarPlacement,
  forwardedRef: ref,
});

Snippet 2:

{shouldUseFloatingToolbar ? (
  <View style={styles.floatingComposerRow}>
    <GlassIconButton
      onPress={handleToggleToolbar}
      symbol={shouldShowFloatingToolbar ? 'minus' : 'plus'}
    />
    <SwiftTextField
      hasGlass
      hasSendButton={hasFloatingSubmitButton}
      onPressSend={handleSubmitButton}
      AttachmentComponent={attachmentComponent}
    />
  </View>
) : (
  <SwiftTextField
    hasGlass
    FooterComponent={markdownToolbar}
    onPressSend={handleSubmitButton}
    AttachmentComponent={attachmentComponent}
  />
)}

I’m a React Native developer with ~4 years of experience, currently based in India and actively targeting remote roles in Europe/US as my first priority.

I’d really appreciate honest feedback on my resume, especially from people working in international or remote teams.

Hey folks,

I built a small open-source package called yt-transcript-kit that makes it easier to work with YouTube transcripts.

It started because I wanted something simple I could use inside my own app, but I made it reusable as both:

• an npm package
• and a CLI

It can do things like:

• fetch YouTube transcripts
• search inside transcripts
• split transcripts into chunks for LLM / AI workflows
• return metadata
• help with batch usage

I tried to keep it lightweight and practical for real apps, especially agent-style or AI-powered tools.

Repo:
https://github.com/Asm3r96/yt-transcript-kit

Would love honest feedback:

• is this useful?
• anything missing?
• is the README/API clear enough?

Define your own mnemonic phrase and memorize it. Redefine the crypto wallet: Rust + Native + React Native, zero-trust JavaScript, custom mnemonic phrase + wallet destruction settings, an offline mobile cold wallet that requires no additional hardware purchases.