capacitor.config server.url is not intended for use in production

[howlettt]

The capacitor.config in these projects use server.url, which according to the documentation is not intended for use in production

[elliottdaviess]

Is anyone able to provide clarity on the use of server.url, please? I'm a little unclear on whether its discouraged based conservative guidance relating to potential issues with app store reviews, or whether its a performance concern (or other).

We'd really like to use an externally hosted NextJs app to get the benefits of SSR on native platforms, however, I'd need to understand the technical justifications as to why this approach is discouraged on the docs in order to make an informed decision as to whether its viable for us or not. Thanks!

[Jarrodsz]

Also interested. This repro could use some more love🙏

[maiieul]

Seems like some people are using it in production.

See these discussions: https://github.com/ionic-team/capacitor/discussions/4080 https://github.com/ionic-team/capacitor/discussions/5075

And this comment: https://github.com/ionic-team/capacitor/discussions/1478#discussioncomment-1344330

I haven't seen anyone reporting getting blocked by an app store reviewer.

The more a think about it, the more I start to think that server.url is a tradeoff that seems worth it.

The pros:

1. No need to patch browser APIs. So you don't need to use things like the Http, Browser, or Share plugins (but you still can), and things like Auth becomes much much easier since you can easily use cookies.

2. Live updates become much easier - though I guess you will have to resubmit your app for review when introducing new features and not just patching something.

3. you can use SSR frameworks (Remix, Next.js with the app router, Qwik, SvelteKit?, SolidStart?, etc.) which I think bring better performance, and arguably DX for web apps.

The cons:

1. You have to load the html from the server, instead of having the shell directly served from a build bundle. But if it means having a unified API for queries and mutations, the tradeoff seems worth it to me. You might even get better perf with data loading and you're doing it for your web app anyway.

2. It might not be as straight-forward with an SSR app (ex: Remix) to implement page transitions as it would be with an SPA (ex: Ionic) or with an SSG app (ex: Next.js with static export) for a native app like experience.

3. You theoretically risk getting refused by the app store reviews. My understanding is that the app store guidelines say that: 1), your app should not be just a repackaged website (which I interpret, and this is purely my interpretation, as "should not be a simple website like a blog, portfolio docs site, etc., with no dynamic data repackaged as a native app"); 2), everything you can do in your native app must be doable on your web app. See https://developer.apple.com/app-store/review/guidelines/#third-party-software for reference. I would bet that focusing on your app's UX/UI would increase your chances of approval to the app store more than not using server.url.

So the cons don't seem too big of a deal to me. Perhaps the community has been held back by the somewhat blurry app store guidelines, but I think that we shouldn't be too afraid of doing it, given not many people seem to have reported getting blocked, given that we get to publish our app on android and ios much more easily, and given that you have to make the choice between going for a performant web app with SSR (Remix, but also Next.js app router, Sveltekit, Solidstart, Qwik...) and a server.url capacitor app, or going for a "normal" capacitor app with an SPA (ex: Ionic) or with an SSG app (ex: Next.js with static export) - which are going to be less performant on the web than SSR. I think I prefer going with SSR.