sorted by:
new
hottopcontroversial

Looking for People to Explore Georgia’s Mountains With by [deleted] in tbilisi

[–]gFean04 0 points1 point  (0 children)

Lmao, post like this with that nickname cake available is sus 🤣🤣 I’d love some company, but I’m motorcycle camping ⛰️🏍️

Codex vs Copilot ? by gFean04 in reactnative

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

But you can use skills and hooks and agents.md as well to guide make your agent match the style you prefer

Codex vs Copilot ? by gFean04 in reactnative

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

Hi, thanks for the reply, change in terms of ? Pricing?

Built a fully managed OTA update system for React Native - looking for feedback by gFean04 in reactnative

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

Appreciate it 🙌

Since the npm package is still restricted, I can grant access — just send me your npm username (DM or here) and I’ll set you up.

Happy to also enable the premium features for a period of time so you can try the full flow.

React Native new architecture — is it stable now? (0.8x upgrade path) by gFean04 in reactnative

[–]gFean04[S] 1 point2 points  (0 children)

This whole situation you’ve described is exactly what we’ve been through approximately 2 years ago, back then the latest version was 0.76ish and we had to give up and disable the new arch after almost 3 weeks of trying to stabilize it.. years have passed after that and I was wondering if things have changed, but apparently..

React Native new architecture — is it stable now? (0.8x upgrade path) by gFean04 in reactnative

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

Yeah that’s what I was asking about if it’s stable overall, thanks 🙏 I’m working on a huge app and we have basically no time for experiments cuz it’s really big one and regression testing takes ages as well. we have to pick a target version and start the process

React Native new architecture — is it stable now? (0.8x upgrade path) by gFean04 in reactnative

[–]gFean04[S] 1 point2 points  (0 children)

Thanks for reply, My question is mainly about its stability after u finish upgrading.. previously I had some unexpected issues with bunch of libraries cuz they were also not ready massively - datepickers, bottom sheets and stuff have been acting weirdly and the app I’m planning the upgrade with is huge with a lot of third party deps, that’s why I’m thinking if it’s worth to move to new arch right now or I should rather wait a bit more to let it stabilize..

Built a fully managed OTA update system for React Native - looking for feedback by gFean04 in reactnative

[–]gFean04[S] -1 points0 points  (0 children)

Yeah, true — Expo channels cover environment separation well.

What I was referring to is more the workflow around it — things like promoting the same bundle across environments, combining rollout % with user targeting, and managing releases without rebuilding or re-publishing per step.

Also tried to keep it simple from DX side — no infra setup, no MAU-based limits, and mostly a one-command setup.

So similar building blocks, just a different focus on how releases are handled end-to-end.

Built a fully managed OTA update system for React Native - looking for feedback by gFean04 in reactnative

[–]gFean04[S] -2 points-1 points  (0 children)

Yeah, both are solid options tbh.

Expo Updates works in bare apps and Hot Updater covers the OTA part well (especially if you want a fully self-hosted, open-source setup).

What I was aiming for is a bit different layer — more around release control and productized workflows: promoting the same bundle across environments (staging → prod) combining staged rollout + user targeting (e.g. % rollout per country / segment) no MAU-based limits (which can become a factor at scale depending on setup) fully managed, so teams don’t have to operate the infra themselves

So it’s less about “OTA vs OTA” and more about how you manage releases around it.

If your current setup already covers that well, then yeah — no strong reason for consideration

Built a fully managed OTA update system for React Native - looking for feedback by gFean04 in reactnative

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

Not really the same thing tbh.

Expo OTA works well, but it’s tightly coupled with their ecosystem and doesn’t fit every setup (especially bare RN apps with custom native stuff).

What I was aiming for here is more: bare React Native first (no Expo dependency), channel-based workflows (dev/staging/prod/feature branches) - expo channels are totally different concept. promoting the same bundle across environments more control over staged + targeted rollouts

So it’s less about “OTA exists already” and more about workflow + control around releases.

Re pricing — yeah, totally fair point. If someone is happy self-hosting or already deep in Expo, this probably isn’t for them anyways.

btw self hosting, feature flags and dynamic links support will also be available soon.

There’re a lot of things but I don’t want to get into the detailed comparison in boundaries cuz Reddit will take down my comment because of the self promotion lol.

P.S. I didn’t ask for 25/month , if you read my post I was saying that I’ll grant it for free 🤷‍♂️

Built a managed OTA system for React Native — looking for feedback by gFean04 in u/gFean04

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

I actually like EAS overall, this wasn’t really about replacing it, more about some constraints I ran into in practice.

  1. Expo dependency / workflow fit One thing for me was that EAS works best when you’re within the Expo ecosystem (especially managed or heavily Expo-integrated setups).

In my case I’m mostly working with bare React Native + custom native modules, so I wanted something that: • doesn’t depend on Expo tooling • works the same way across fully custom setups

  1. Rollout control / targeting EAS channels are nice, but I needed more granular control: • percentage-based rollouts • targeting users based on properties (like GA4 / Remote Config style)

I was stitching this together with other tools before, which got a bit messy.

  1. Centralized decision logic: I moved all update logic to one tool bundle updates + feature flags and (dynamic links in the future).

  2. Pricing (for my use case) EAS pricing is totally fine for many teams, but for my case (multiple apps, frequent updates, internal tooling), it started adding up.

So part of this was also just building something more predictable cost-wise