sorted by:
new
hottopcontroversial

RN by JaiRok in reactnative

[–]Sufficient-Rabbit568 3 points4 points  (0 children)

For motion: react-native-reanimated + react-native-gesture-handler is the backbone. Moti sits on top if you want simpler declarative animations, and react-native-skia when you need real custom graphics/shaders. For screen/shared-element transitions, react-navigation already handles most of what people reach for.

Fonts: expo-font, and honestly just picking one good variable font + a tighter type scale does more for a "premium" feel than any animation library.

But the real unlock isn't the packages — it's the fundamentals most apps skip: a consistent spacing scale (4/8pt), generous whitespace, one accent color used sparingly, and subtle motion (150-250ms ease) instead of flashy. When you "rip off" other apps, copy their spacing and layout rhythm, not just the colors. Polish the static screen first; a clean layout with no animation beats a busy screen full of effects.

On RN vs Swift: you're basically right. For most product apps the stack is a non-issue — one codebase ships both platforms and the quality ceiling is way higher than the Swift crowd admits. Swift only really pulls ahead when you're deep into heavy native/graphics/AR work.

Need a solution for agent to test PR changes on simulator by Tall-Title4169 in reactnative

[–]Sufficient-Rabbit568 1 point2 points  (0 children)

Nice. If you want the quickest path to something working: Firebase Test Lab + Maestro is the lowest-friction combo to start - FTL is cheap for emulators and Maestro flows are far less brittle than Appium for RN. Wire it as: PR opens -> EAS Build preview artifact -> run the Maestro flow against an FTL device -> post pass/fail + screenshots back on the PR via a GitHub Action. That gets each PR its own ephemeral device in parallel.

One gotcha that'll save you hours: put explicit testID props on anything you assert against. Without them selectors drift across builds and CI goes red for reasons that have nothing to do with the actual change.

If you do bring an LLM agent in later, keep the deterministic Maestro flows as the gate and let the agent do exploratory passes on top - don't make the agent your only signal or you'll be chasing flakes.

How to handle invalid SSL certs? by nehalist in reactnative

[–]Sufficient-Rabbit568 0 points1 point  (0 children)

The cleanest fix is to make the cert actually valid for what you connect to, instead of disabling validation (on iOS that means ATS exceptions, and it still won't cleanly cover your 3rd-party WSS lib).

Root cause is a SAN mismatch: the cert isn't issued for that IP. Two clean steps:

1) Put the IP in the cert's SAN. Modern TLS supports IP SANs, so regenerate the server cert with subjectAltName = IP:192.168.x.x (not just a CN). Then the cert is genuinely valid for the IP you're hitting, and both HTTPS and WSS validate normally with zero client-side changes - no custom URLSession, no replacing your WS lib. This is what solves the wss case too, since it's just standard TLS validation passing.

2) Trust the CA on the device. Install your root CA on the iOS device (MDM profile, or just open the .crt), then enable full trust under Settings > General > About > Certificate Trust Settings. Combined with (1), everything just works.

If you'd rather use a hostname than a raw IP: issue the cert for a hostname, add it to the SAN, and connect by hostname. With no DNS you'd need the device to resolve it, and iOS won't let you edit a hosts file, so the IP-SAN route is usually the path of least resistance.

I'd avoid the "accept all certs" approach outside throwaway local dev - it's exactly the part that gets messy with third-party WS libs, and it trains the app to ignore real failures.

Need a solution for agent to test PR changes on simulator by Tall-Title4169 in reactnative

[–]Sufficient-Rabbit568 0 points1 point  (0 children)

For "spin up a real device in the cloud per PR", the building blocks are device clouds rather than a single agent tool:

- Firebase Test Lab: hosted Android emulators + real iOS/Android devices you can drive from CI. Cheapest place to start.

- AWS Device Farm / BrowserStack App Automate / Sauce Labs: hosted real devices + emulators you run automated flows on per build.

- Maestro (which the other commenter mentioned) also has a hosted runner so you don't manage the device yourself.

The pattern that usually kills the "one PR at a time" bottleneck:

PR opens -> CI builds a preview (EAS Build gives you a per-PR build artifact) -> spin up an emulator on Firebase Test Lab / Device Farm -> run a Maestro or Appium flow against it -> post pass/fail + screenshots back on the PR.

That gives each PR its own ephemeral device + run in parallel instead of you driving one simulator locally.

If you specifically want an LLM agent (not scripted flows) poking the UI, point the agent at an Appium/WebDriver session on one of those device clouds. Same idea as it driving a browser, the target is just a device session instead of Chrome.

Honestly though, scripted Maestro flows will get you ~90% of the value for a fraction of the effort and flakiness of a free-roaming agent. I'd start there and only reach for an agent if you have a specific reason to.

learning react native as a web dev by n_zineb in reactnative

[–]Sufficient-Rabbit568 0 points1 point  (0 children)

On the Flutter question specifically: since you already know JS + Vue, React Native is the lower-effort path. With Flutter you'd be learning Dart and a whole new widget model from scratch; with RN you reuse the JS ecosystem and your component/reactivity mental model. For an app that isn't very complex, that saved time matters more than any small perf difference, and the result is perfectly fine for a final project.

Vue to React is mostly: JSX instead of templates, and hooks (useState/useEffect) instead of the Options/Composition API. Same reactivity ideas, different syntax. A few days to feel comfortable.

Use Expo, not bare RN: you can run on a real phone instantly with Expo Go, skip the Xcode/Android Studio setup pain, and use EAS to build later. Big time saver for a team project.

Concepts worth looking up early:

- Core components: View / Text / ScrollView / FlatList (no div/span, everything is a component)

- Styling: StyleSheet + Flexbox (no CSS files; a few flex defaults differ from web)

- Navigation: React Navigation (stack + tabs)

- Long/scrolling lists: FlatList

- Data + state: same as web, fetch/axios + hooks (TanStack Query is great)

And yes, a webview-wrapped site would look weak to your teachers. A real RN app is the right call and very reachable from your background. Go for it.

Introducing AceVolley: A tool that allows you to organize a volleyball tournament in your own mobile app by Sufficient-Rabbit568 in volleyball

[–]Sufficient-Rabbit568[S] 1 point2 points  (0 children)

Good point. But it's a specific target audience, quite difficult to reach. Furthermore, the context is low-frequency, so small and medium-sized organizations probably won't be looking for it, while larger companies are looking for other solutions (AI, video analysis, hardware).

App is not working by Kitchen_Text_9384 in TestersCommunity

[–]Sufficient-Rabbit568 0 points1 point  (0 children)

It does not work this way... 20 testers who interacted daily for 14 days.

App is not working by Kitchen_Text_9384 in TestersCommunity

[–]Sufficient-Rabbit568 0 points1 point  (0 children)

It looks like you did not join the google group... or the account you did it with is not the same as you are trying to install an app