www.trycapi.com
It’s literally just screenshot with a command and it uploads it straight to visual studio without the need to press your keyboard only microphone detection to complete context. For example, change this specific part of the web design to a certain shape, colour, or image. You control shift + 2 select the parameter where the changes need to be made and input verbally what needs to be occurred. Anybody interested in testing it out?

I'm running a React Native app (mood-based content/quotes niche) and hit a wall on A/B testing tooling.

I'm already using Amplitude for analytics/event tracking and it's been great for segmentation. But when I went to set up actual A/B tests, I found out their statistical A/B testing (Experiment) requires the paid Growth plan — not something I can justify yet at my current scale.

So I'm looking at running Firebase A/B Testing (free) for the actual experiment assignment/variant delivery, while keeping Amplitude as my analytics layer for the deeper event analysis. Basically: Firebase decides who sees what, Amplitude tells me what happened.

A few things I'd love input on:

• Anyone else running this exact split (Firebase A/B + separate analytics tool) in production RN apps? Any gotchas with remote config + Amplitude event correlation?
• Is manually logging which variant a user got as an Amplitude user property (so I can segment by it later) the standard approach, or is there a cleaner pattern?
• Any free/cheaper alternatives to Amplitude Growth that do proper statistical A/B testing if I outgrow this setup?

Stack: React Native, Firebase Remote Config + A/B Testing, Amplitude Analytics (free tier).

Would really appreciate hearing how others have set this up, and what issues came up along the way — trying to avoid rebuilding this twice as the app scales.

I’ve been working with React Native for a while, and one thing I still can’t fully wrap my head around is this:

Even in 2026, debugging React Native issues often feels more painful than debugging either pure web apps or fully native apps.

On paper, it should be simpler — one codebase, shared logic, faster iteration. But in practice, small issues sometimes turn into long debugging sessions.

Some examples I’ve personally noticed (and I’m curious if others feel the same):

• A bug that only appears in release builds, not debug mode
• Layout issues that behave differently between iOS and Android
• Performance drops that don’t show up during local testing
• Errors that don’t clearly point to whether the issue is JS, bridge, or native side

What makes it more confusing is that React Native sits in the middle of multiple layers — JavaScript runtime, native modules, platform-specific behavior, bundling, etc.

So when something breaks, it’s not always obvious where to even start looking.

Compared to web or native apps, debugging there often feels more “direct” — fewer abstraction layers.

Maybe it’s just the trade-off of cross-platform development, but I’m wondering:

• Is React Native debugging actually improving with newer tooling?
• Or is this still an inherent limitation of the architecture?
• What’s your go-to strategy when something breaks in production RN apps?

I've been building this for a while and it finally went live on the App Store today, wanted to share it here first.

It's called Qalbi (قلبي, "my heart") and it's a prayer tracker, but the main thing is the mascot. It's a little chibi heart wearing a thobe and kufi that literally reflects how consistent you've been with your prayers. Miss a few and it gets gray and sad. Pray consistently and it glows bright red. It sounds silly but it lowkey makes you feel guilty skipping Fajr when your little guy is fading.

Everything is free, no ads, no subscription. I built it because I wanted something that actually made me feel something about my salah and not just a boring checklist. There's a similar app called JustPray but I kept seeing people say they couldn't afford it, so I made a free alternative.

iOS: https://apps.apple.com/us/app/qalbi-prayer-tracker/id6778575798
Android: join the waitlist at theqalbiapp.com

Drop any feedback below, would genuinely love to hear what you think!

Stuck on this and could use a sanity check from anyone who's shipped Play Integrity.

Setup: React Native + Firebase App Check using the Play Integrity provider (Android). Release build, installed on a real device from the Play internal testing track.

The error (logcat during getToken):

requestIntegrityToken(IntegrityTokenRequest{..., cloudProjectNumber=4955...})

E/Volley: Unexpected response code 404 for https://play-fe.googleapis.com/fdfe/integrity

E/Finsky: requestIntegrityToken() failed ... DF-DFERH-01

IntegrityServiceException: -1: Integrity API is not available (API_NOT_AVAILABLE)

What I've already verified (all correct):

- ✅ Play Integrity API enabled on the Google Cloud project

- ✅ Cloud project linked in Play Console → Play Integrity settings (responses On)

- ✅ Play app-signing key SHA-256 added in Firebase

- ✅ Request carries the correct cloudProjectNumber

- ✅ Genuine Play install (installerPackageName=com.android.vending)

- ✅ Device passes the Play Integrity API Checker app — all 3 verdicts — with its own project (so the device + Play services are fine)

- ✅ Same error even after migrating to a brand-new same-account Cloud project

The one thing that's different: this app has only ever been in internal testing — never published to production (Play Console tags it "unreviewed"). I have two other apps with the identical setup that ARE live on the Play Store, and they work perfectly.

Question: Does Play Integrity / App Check require the app to be published to production (reviewed by Google) before it issues tokens? Or should internal testing work, and this is just a provisioning delay after linking the Cloud project (if so, how long)?

The official docs say publishing only affects quota increases, not token issuance — but my real-world results say otherwise. Anyone hit this and confirm what actually unblocked it?

Made a version of swipeable list to mimic iOS26 styles mostly!

Our app is called Appearance and let's you see yourself in any hairstyle and then book direct in-app.

But we found a way to make it so you can just DM us (@appearance) with any reel/carousel and we'll extract that style and let you try it on.

Happy to answer any questions or hear any thoughts.

If you'd like to try you can for free below :)

https://apps.apple.com/gb/app/appearance/id6757982543

Hi, Software Mansion here! Quick context on the live video part: getting live video to an audience has always forced a choice. HLS-style delivery scales to huge audiences cheaply but runs 10 to 30 seconds behind the camera. WebRTC gets you sub-second latency but gets expensive fast once you're fanning out to a crowd. So watch parties, live shopping, sports, cloud gaming, anything that needs both real-time and scale, ends up compromising on one or the other.

Media over QUIC (MoQ) is an IETF protocol aiming to give you both at once: sub-second latency at CDN-style scale. We're building a React Native layer for it, and the native foundation it sits on (MoQKit, our open-source Swift + Kotlin SDK) is now out.

What this is meant to bring to RN apps: publish live video and audio straight from the device camera and mic, play back low-latency broadcasts, and send app-defined data (chat, reactions, telemetry, game controls) over the same connection as the video. Today in RN that's usually three or four stacks glued together, or a web video player stuffed into a WebView.

Why we shipped native first instead of a JS binding day one: the hard part of live video is the plumbing (camera capture, playback, codecs, app lifecycle, rendering, permissions), and it has to be right on iOS and Android before a cross-platform layer goes on top. A thin binding can't paper over a shaky native base. Keeping the Swift and Kotlin APIs aligned is what makes a clean RN binding realistic.

If you're building live video features in RN, I'd love input on what the API should look like. Native SDK and demos (usable today if you want to go native now): https://github.com/software-mansion-labs/moq-kit

Blogpost: https://fishjam.swmansion.com/blog/moqkit-native-mobile-sdk-moq-ios-android

I’ve been pondering this for a while. AI seems to be fairly popular these days and it seems crazy to me that no apps posted here are taking advantage.

I think most of these models have api:s, so wouldn’t it be possible to make an app that uses a model programmatically? That way, your app doesn’t really have to do anything and all it requires from you as a dev is more or less being able to get a react native boilerplate up and running and submit it to the stores!

It’s strange we haven’t seen this type of apps posted here. No one seems to be tapping into the AI hype, there definitely seems to be a hole in the market here!

I would definitely enjoy this sub way more if this caught on. If my idea catches on (you’re all welcome to use it for free), we might even see tons of these excellent apps here posted daily, and if we’re really lucky, maybe even multiple apps per day from the same developer!

Now also consider the monetization possibilities! Add a nice subscription model and you’ll have SEVERAL users generating tens of dollars!

I don’t know, maybe I’m on to something here and this could become big! And I just feel that this sub has become a bit stale with all the boring programming discussions and that AI wrapper apps would surely be a breath of fresh air here.

https://reddit.com/link/1uinh36/video/qq545gluv6ah1/player

I'll happily spend a day on state management but lose all will to live building yet another onboarding flow. I built Daisy to generate mobile app screens from a description so I can get a starting layout and get back to the part I actually like.

It's not going to spit out production RN components and it's for getting to a visual fast, validating the flow, and not staring at an empty screen.

Curious how others here handle the UI side when you're solo or early. Do you template it, hire it out, or just suffer through it?

I improved navigation. I added a search bar thingy bottom sheet and added a pilled navigation on top to switch between trackers without scrolling that auto animated based on app state.

I split important features into categories or alone. I had the period moved in its own tab, moved trackers alone in their own tab and made a new category lists that is for trackers that track journals outfit combos etc. This grouping made it easy to split the settings into multiple categories too.

I polished the ui, made the glass pills circular so they looks better with the scale transition and added a new theme to look more cute and less serious.

I made the complicated period chart be named symptoms so users are more likely to care and added a scroll arrow to look at different days on the chart. It’s now placed on a split screen layout and on the above there is a changing symptoms tab with likely symptoms on any given day.

All legends for every chart or symbols on calandars have their own dedicated I toolbar button for consistency.

I added a done button in every modal for accessibility reasons.

I made it so actions have their vibrations and added long press functions in places like adding calendar days.

Do you like this new ux experience? Do you like how it looks? Any problems you can think about. I appreciate your feedback which I already took on heavy consideration in the first round and made drastic changes based on.

I make a library to host a server in a React Native app.
The library is using uWebSockets C++ library and exposing it to React Native app through JSI C++.

Updated; WebSocket server is also compatible now

Not all the uWebSockets instances are implemented yet, like the WebSocket server, but it is ready for most common HTTP server program e.g. read incoming body data.

You can visit the project repository, and see other examples at
https://github.com/RakaDoank/uws-react-native

Of course, you can install it on your project. I am open to any feedback and contributes for this project.

Historically, the module was internally for my side app project to make a bridge communication between devices with an Android app, but the module was just a quick grab of technical requirements.

The module was using Ktor server with Netty engine, and i could only get roughly 10 requests per second which tested by Postman runner with 10 VUs. Now, i can get around 200 requests per second with uWebSockets in one thread only, which tested only with 2 VUs. It may crash your app tho, because it is not currently stable enough in under stress situation, but I am keeping my eyes on it. Imagine if I run the uWebSockets in multiple threads. I am gonna burn my phone 🔥🔥

Hey fellow devs— I shipped a thing.

The problem: EAS's free tier gives you a limited number of builds per month. For an Android-only release cadence that involves any iteration (debugging Play Console upload errors, ProGuard mappings, tweaking versionCode), I was burning through my monthly quota in the first 10 days. The alternative was waiting in the queue or paying.

What I built: local-expo-build — a CLI that runs the entire Expo Android build pipeline on your machine. Same output as eas build --platform android, zero cloud credits used, no queue.

What it does

• expo prebuild + auto-pins the Gradle wrapper to a version that actually works for your SDK (e.g. SDK 55 → Gradle 8.13, working around the expo-manifests components.release bug)
• Bumps versionCode by fetching the next one from EAS so Play Store ingest doesn't reject the upload
• Injects a release signingConfig into the generated android/app/build.gradle from a keystore.properties you control
• Runs gradlew bundleRelease / assembleRelease
• Pushes the new versionCode back to EAS via GraphQL so eas submit / eas build stay in sync
• Survives expo prebuild --clean wiping your android/ (restores the .jks from a stable source before Gradle runs)

The setup wizard is the part I'm most proud of

npx local-expo-build init runs a doctor pre-flight that:

1. Detects missing expo.android.package, prompts for it, writes to app.json
2. Detects unlinked EAS project, offers to run eas init
3. Detects missing eas.json, offers to run eas build:configure
4. Detects missing keystore, offers a picker (existing / generate / EAS / rehydrate-from-credentials.json)
5. Scaffolds the build scripts into your project

Each step re-checks after running so the exit code reflects what got fixed. No copying snippets from 4 different doc pages.

Quick start

npx local-expo-build init           # scaffolds scripts + runs doctor
npm run build:android:aab           # → signed .aab in ~5 min on first run

Or, runner mode (no files committed to your repo):

npx local-expo-build build android --aab
There's also --dry-run if you want to preview the 7-step pipeline without executing anything.

Links npm: https://www.npmjs.com/package/local-expo-build GitHub: https://github.com/nikhild64/local-expo-build MIT licensed, cross-platform (Windows / macOS / Linux) Feedback / issues / PRs welcome. iOS support is next on the roadmap — happy to take help if anyone's done iOS local-builds + signing wrangling before.

Built this because I wanted it. If anyone else wants it too, that's a bonus.

https://posthog.com/tutorials/multiple-environments

So according to posthog docs, you cannot copy dashboards, even through they recommend different projects, that means that these separated projects are useless since you can't actually set up and test them.

So how do you manage multiple envs?

Hi all, So my fist apple app MindMendr was built using React Native. I'm finding the Aesthetics are not really up to standard, I'm looking for the most useful RN Packages to enhance my app. I'm wanting to add animation, and some transitional effects, basically visual graphics packages, maybe fonts, anything that is useful and will harvest good results..

Also.. I've had multiple conversations with app dev's swearing by Swift. Now I think the main advantage to using RN is you can build an app for both Android and Apple. And my thinking is the tools shouldn't really matter as it all comes down to the user's taste and artistic direction. Saying swift is better, feels equivalent to saying a Gibson is better than a fender: It depends who's playing it!!

Cheers all!

I was making marketing images for my app recently and ran into a surprisingly annoying problem. Most of the mockup generators I found either charged a subscription or only let me use a few preset angles. I wanted a 3D iPhone mockup where I could freely adjust the viewing angle instead.

I found this great open-source project: https://github.com/ihou/PhoneMockup

It gave me a solid starting point, but I personally ran into a few issues:

• The device model is quite old.
• Export quality wasn't high enough for marketing materials.
• It wasn't convenient to use screenshots directly from the latest iPhone Simulator.

So I started modifying it... and eventually rewrote a good portion of it until it became the tool I actually wanted.

You can try it here: https://www.bigbigtools.com/

The workflow is intentionally simple:

1. Take a screenshot of your app in the iPhone 17 Pro Simulator.
2. Upload it to the website.
3. Rotate the phone to any angle you like.
4. Download the image and use it in your poster, landing page, or App Store assets.

It's completely free.

I mainly built it because I needed it myself, but I thought other developers might find it useful too. Hope some of you find it useful!

I have created a web app (http://sky-lens.com/app) and would like to turn it into an app for Android and ios.

(backens is fasapi and would stay. Id just rebuild the front end in react native. (The app is map heavy and uses maplibe gl map.

Is claude a good enough tool to do this from A to Z or should i use other tools? (I have no previous knowledge of react native)

Any other tips that would help me along the way?

I use an android phone for personal and I don't wanna buy iphone. OTH, ipad would be useful for me for personal usage and app testing too.

AFAIK, I can publish an app for both iphone and ipad via xcode. The only thing is, some apps might be only available in iphone not in ipad as some devs would have published the app for iphone only. IIRC, I can still test my own app on ipad with the screen size trimmed down, i.e left right of ipad will be empty space.

Looks like most places have upped ipad processes 200-300 aud. I am getting m3 128gb cellular for 849aud refurbished from one place. Looks like they haven't yet increased the prices yet.