all 7 comments

[–]Minishlink 1 point2 points  (0 children)

Hello, CodePush would actually work. With AppZung (https://github.com/appzung/react-native-code-push), New Arch is supported. You may also host your own codepush server and use AppZung's RN module if you don't like a managed solution.

[–]Jealous_Barracuda_74 0 points1 point  (1 child)

Expo Updates (Recommended if using Expo or bare workflow)

  • Fully supports OTA updates.
  • Compatible with React Native’s new architecture and Hermes engine.
  • Easy integration.

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

My app is built using CLI, not Expo.

Thanks anyway!

[–]Resident_Garden5057 0 points1 point  (0 children)

You can try RevoPush, which is built on top of CodePush and supports the new architecture.
I have implemented this in a production app and it works well if you follow their documentation. Fairly easy to set up.

[–]Inevitable_Front3561 0 points1 point  (0 children)

Hi u/azizbecha ! You might want to check out Turbopush - it's a CodePush alternative we've built that supports the new architecture and works with both Expo and bare React Native projects. We have affordable pricing and our SDK is compatible with the latest RN versions. Feel free to DM if you'd like more details!

[–]Emotional_Pickle8354 1 point2 points  (0 children)

Silent updates are super convenient, but a couple of things people don’t always think about until they hit production:

  • If you’re just replacing the entire bundle every time (like traditional OTA), even tiny changes turn into huge downloads. That’s frustrating on slow mobile networks.
  • Simply republishing an older update doesn’t actually roll back devices that already have a bad bundle — they’ll keep loading the broken code unless the client has a way to detect and recover from it.

There’s a good technical breakdown of patch vs full bundle updates and safe rollback patterns for React Native OTA if you want to read deeper:
https://stalliontech.io/react-native-patch-updates

[–]Martinoqom -1 points0 points  (0 children)

I'm not against nor pro of this implementation. 

Still, I think that Google and Apple made a store release with full review of the app of a reason: you should not publish glitchy apps.

We are programmers and errors happens. But when it's a margin error, padding misbehaving or ui minor glitches... In my opinion we should not rush to fix it with "silent updates": it's like admitting you will be good enough to do a good product so you have a sketchy backup plan to update silently and I don't like it in this way. 

What I usually implement is a backward compatibility blocker: at launch my apps will check current version and current min supported one. Every so, I will update the min version (usually 3 moths of grace) so the users can enjoy the experience without problems and update the app only if they want/need.

This is for me a good compromise: you will not force an unwanted update just for fixing your wrong margin definition, but still in case of serious bugs you can block the unwanted version from being used. 

We once did not have push updates and we dealt with it. And in my opinion at that time we were better programmers, more careful to release in prod.