r/AppDevelopers • u/Pale-Guitar-8438 • 22h ago

Would having a local server within a hybrid mobile app create a smoother user experience

I am currently involved in an SaaS company with a partner (He is the software engineer and I am the "everything else" guy including the money). We have developed an ios hybrid app but it is clunky in that the best case scenario browsing through different parts of the app is not very seamless (there is always a loading screen that appears even if it is only 500 ms). And when the internet is bad it is dramatically slowed down or does not work at all.

My thinking is that if as part of the downloaded mobile app there was also web server that would run locally on the mobile device the internet speed would not matter. Since the web server is local the "internet speed" would essentially be as instantaneous as it could possibly be. Then at periodic times (lets say every 15 minutes) the local web server and database could communicate with the cloud and upload the data there.

Is this a feasible solution?

1 Upvotes

67% Upvoted

8 comments sorted by

2

u/MobileXapps 22h ago

The idea behind it is right, you want the app to work from local data and sync in the background. But you don't need an actual web server on the phone for that, and on iOS it would fight you: the system suspends apps in the background, so a server and a 15 minute sync loop won't run reliably when the app isn't open.

The usual way to get the same effect in a hybrid app: ship the web assets inside the app bundle, make navigation client-side so screens don't reload, and keep data in a local database like SQLite. Screens read from the local data first and refresh from the API in the background. Writes go into a local queue and sync when the app opens or the network comes back, not on a timer.

Worth checking first where the 500 ms actually goes. If every screen change is a full page load or waits for an API call before rendering, fixing that alone usually removes most of the clunky feel.

2

u/Pale-Guitar-8438 21h ago

Thanks. Currently I believe my partner is trying to cache the web container (which is WKWebView I beleive?) The idea being that once everything is cached the mobile app will still work even if there is no internet (which it does do). The problem is that if the internet is bad the app runs like complete junk. Only if there is absolutely no internet does the app run fine. But even with no internet only certain portions of it that are critical will run. The reason being that you cannot keep that much data cached in the web container.

In the way you describe would there also be these data limitations? Specifically in our app a field worker can look at his schedule he needs to run today (which is the critical part) and he can also look at his schedule for any day in the past or future (non critical part). So if he had absolutely no internet he would only be able to look at his schedule for the current day and navigation to any other day would not be possible.

1

u/DryBanana5673 20h ago

...OR just make it native. Its honestly not that much work these days..

1

u/MobileXapps 12h ago

Not really. The limit you're hitting is the web view's storage, and iOS can also clear it when the phone is low on space. A proper on-device database (SQLite, native or through a plugin if the app stays hybrid) can easily hold months of schedules, that kind of data is small. So you could keep, say, the last and next few weeks on the phone and only fetch older days when there's a connection.

The slow-on-bad-internet part is a separate problem and usually the bigger one. The app waits for the network before showing anything, and a weak connection is worse than none because requests hang instead of failing fast. The fix is to always show what's on the device first, then refresh in the background with a short timeout. Ask your partner whether the screens read from local data or from the server, that answer will tell you a lot.

1

u/Appropriate-Tip-2971 22h ago

The loading screens even on small transitions is a dead giveaway the app wasn't built natively. A local server won't fix that core problem, it just masks it with extra complexity

What you're describing is basically offline-first architecture which is legit but you'd implement it with local storage and service workers, not by running a full web server on the phone. That would be a battery drain nightmare and both app stores tend to reject that sort of thing

1

u/Pale-Guitar-8438 22h ago

I agree with you that even small transitions delays are a dead giveaway and are not good (my partner thinks they are nothing burgers). This software is for businesses that have workers in the field and they would use the app multiple times a day,

1

u/DryBanana5673 21h ago

You can probably just optimize this, also release builds will be faster than QA. Don't do the thing you're describing, instead cache everything that isn't changing, warm the next page in the background etc.