I have an app in production on Android and iOS built with Next.js 16 (App Router, Server Components, Server Actions) + Supabase, wrapped with Capacitor 8 loading the remote site through server.url. It also runs as a PWA (Serwist service worker, data cached in IndexedDB).
The requirement: users must open and use the app offline and on weak signal (the "connected but nothing loads" 4G case), like Spotify or Google Maps offline. Usage is mostly reading, with a few writes queued offline.
What I've learned so far: the Capacitor team says server.url is meant for development, not production. That matches our experience: on a cold start with weak signal the WebView sits on a black screen for 30s+ and falls into errorPath, because the app shell doesn't live on the device. Service-worker tweaks (NetworkFirst, CacheFirst, StaleWhileRevalidate, navigation preload) helped in some cases and broke others, and they behave differently on Android WebView and iOS WKWebView (App-Boun
The direction seems clear: embed the front-end in the binary and use Live Updates for OTA. My questions are about the migration:
How did you handle Server Components and Server Actions? Did you convert them to API routes on the hosted Next app called by absolute URL, reads to the Supabase client with RLS, or something els
output: 'export' or another setup? Any problems with dynamic routes like /events/[id]/...? 3. Which Live Updates provider do you use (Capgo, Capawesog to watch for with App Store and Play Store rules?
Does anything change between Android and iOS in this setup: storage limits, eviction, background sync? 5. Can the migration be done gradually (mobile embedded, d
Real-world experience, repositories or articles are very welcome. Thanks!
The user is seeking advice on migrating a Next.js app using Capacitor from a server.url setup to an embedded, offline-first build for Android and iOS. They face challenges with offline functionality and seek real-world experiences on handling Server Components, Server Actions, and Live Updates integration. The thread includes suggestions to replace Server Actions with API routes and considerations for static shell handling.
you’re gonna wanna for sure dump server actions in favor of api routes. we got out nuts handed to us on that one - surprised you haven’t already run into that with workbox. interested to see what replies you get though cause this is in the horizon for us
yeah server actions get weird fast when you take next offline, we hit the same wall and switched to api routes early on, saved a ton of headache
Server Components and Server Actions need a Node server at request time, so they can’t live in the embedded offline build. Start by listing which screens can render with no server at all; anything that depends on a Server Action or per-request data has to become a client fetch first. That list is your migration plan. For routes like /events/[id], if the IDs aren’t known at build time, move the ID into a query or hash parameter so the static shell can handle it.