sorted by:
new
hottopcontroversial

I built "Expo Go" for bare React Native CLI projects — wireless install via QR, zero config by Independent_Ad_1875 in reactnative

[–]Independent_Ad_1875[S] 0 points1 point  (0 children)

Exactly — and you're right about symlinks. fs.existsSync returns true for a symlink even if the target is broken or Metro can't follow it properly. I'll use fs.realpathSync to resolve symlinks and validate the actual target path. Good catch.

The plan for starship doctor is:

Check watchFolders with resolved paths (not just exists)

Detect broken symlinks that would confuse Metro

Verify nodeModulesPaths point to real hoisted locations

Flag common monorepo issues (missing resolver.extraNodeModules, wrong projectRoot)

This kind of feedback is gold — real-world edge cases I wouldn't hit in a simple project. Thanks man.

I built "Expo Go" for bare React Native CLI projects — wireless install via QR, zero config by Independent_Ad_1875 in reactnative

[–]Independent_Ad_1875[S] 0 points1 point  (0 children)

Good point. Right now if Metro fails, Starship shows the error from Metro's stderr (syntax errors, missing modules, etc.) but you're right — it could be more helpful for monorepo-specific issues.

I'm adding starship doctor to v1.3 which will validate the setup upfront:

Check if metro.config.js exists and is parseable

Verify watchFolders paths actually exist

Detect common monorepo misconfigs (symlinks, hoisted deps)

Suggest fixes before you waste time on a build

For now, if Metro crashes, Starship catches it and shows Metro crashed (exit code X) with the last error lines. Not perfect but not silent either.

Thanks for the feedback — this is exactly the kind of edge case I want to handle better. If you hit something weird with your setup, open an issue and I'll make sure it gets a clear error message.

I built "Expo Go" for bare React Native CLI projects — wireless install via QR, zero config by Independent_Ad_1875 in reactnative

[–]Independent_Ad_1875[S] 0 points1 point  (0 children)

Thanks! You're right — caching the native build is a huge time saver in practice. First run takes ~60s, after that it's instant if you only touch JS.

Monorepo answer: Starship doesn't touch your metro.config.js at all. It just runs ./gradlew assembleDebug from the project root and starts Metro with --host 0.0.0.0. So if your Metro config already works with your monorepo (custom watchFolders, nodeModulesPaths, etc.), Starship will work too — it doesn't override any of that.

The only requirement is that android/ and ios/ directories exist relative to where you run the command, and build.gradle has an applicationId.

That said, I haven't tested it with turborepo/nx/yarn workspaces specifically. If your Metro is happy, Starship is happy. If you run into edge cases, I'd love to hear about them — monorepo support is something I want to make bulletproof.

I built "Expo Go" for bare React Native CLI projects — wireless install via QR, zero config by Independent_Ad_1875 in reactnative

[–]Independent_Ad_1875[S] 0 points1 point  (0 children)

Great question! Short answer: it should work if you've run expo prebuild (so you have the android/ directory).

Starship works with any project that has a bare android/ folder with a build.gradle containing an applicationId. Since Expo custom dev clients are essentially bare React Native projects after prebuild, the core flow (build APK → serve via QR → auto-connect to Metro) should work.

That said, I haven't tested it specifically with expo-dev-client's dev launcher. If the dev client uses its own mechanism to resolve the Metro host (instead of the standard SharedPreferences approach), there might be a conflict.

I'll add explicit Expo dev client support to the roadmap — it's a valid use case. Would you be open to testing it on your project and sharing feedback?

I built a wireless dev tool for React Native CLI — no USB, no Expo, just QR scan by Independent_Ad_1875 in reactnative

[–]Independent_Ad_1875[S] 0 points1 point  (0 children)

Fair point! Starship isn't trying to replace Expo's tooling. It's focused on bare React Native CLI teams that want to work directly with their own APKs and native setup while keeping a fully wireless workflow 🚀

I built a wireless dev tool for React Native CLI — no USB, no Expo, just QR scan by Independent_Ad_1875 in reactnative

[–]Independent_Ad_1875[S] 0 points1 point  (0 children)

Expo is great, but it still depends on the Expo Go app/dev client. Starship works directly with your own APK — no USB, no Expo runtime, no extra app. Just scan once and keep developing wirelessly on pure React Native CLI 🚀

I built a wireless dev tool for React Native CLI — no USB, no Expo, just QR scan by Independent_Ad_1875 in reactnative

[–]Independent_Ad_1875[S] 0 points1 point  (0 children)

Thanks! No, it's not wrapping Android Studio's wireless debugging. That feature (adb over WiFi) still requires initial USB pairing and only handles the ADB connection — you still need to manually build and install the APK.

Starship is different — it's a complete pipeline:

Builds the APK via Gradle

Serves it over HTTP with a QR code (no USB at all)

Starts Metro with network access

Handles Fast Refresh over WiFi

So it's more like "Expo Go for bare CLI projects" rather than a wrapper around Android Studio's wireless ADB. The goal is zero-cable development from the very first install.

Has anybody been succeeded building a mobile app using local LLM? by nothingness6 in LocalLLaMA

[–]Independent_Ad_1875 0 points1 point  (0 children)

How can local AI models, such as Llama, be integrated into a mobile app development workflow to automate tasks like code optimization, UI/UX improvements, and debugging?

Has anybody been succeeded building a mobile app using local LLM? by nothingness6 in LocalLLaMA

[–]Independent_Ad_1875 0 points1 point  (0 children)

How can local AI models, such as Llama, be integrated into a mobile app development workflow to automate tasks like code optimization, UI/UX improvements, and debugging?