Ask HN: Why aren't modern mobile apps design to fail stable? | Hacker News Reader

Ask HN: Why aren't modern mobile apps design to fail stable?

34 pointsharshaw23 comments

I haven't built mobile apps in years. These days I carry an Android phone and am generally unhappy with how poorly these applications require a network connection to do anything. Many apps don't fail stable in the sense that if there is a server error they don't present the last known good view of data. What this means in practice is if there is low network availability (on a train, at a concert or festival, a sporting event) many of these apps completely break.

Back years ago I would design apps to sync to a local database (which was relatively easy to do on IOS). Apps would maintain consistent state on the device and leverage local storage. I haven't looked under the hood but many apps appear to be using HTMLish front ends that are stateless, except for some cached login information. As a user - what I see is that the app repeatedly tries to login and fetch all information every time you load it. Which if you have perfect LTE/5G/WIFI is sort of ok, but in other situations sucks. if the app can't talk to the network it really doesn't work at all.

Example apps that generally fail stable: gmail, text messaging Sort of fail stable: slack, although if you get a push message slack requires talking to the network to get the message even though it came through the push message. In practice this means significant latency between seeing the message on the phone and then going to the conversation view (which can take forever to load under poor networking). Back when I built apps we stuck the contents of the push message in the local DB so it was visible for users Apps that don't fail stable: Hyundai blue link, Electrify America

> Why aren't modern mobile apps design to fail stable?

Laziness and/or poor software engineering practice; usually because the business just doesn't prioritise app stability under less-than-ideal network conditions. I strongly suspect a lot of developers are used to having good-quality mobile data and WiFi connectivity at all times, too.

It's also why folks are using the "HTMLish front ends" you refer to, instead of properly investing engineering effort in making a real native app. All too often the business is more focused on speed of feature delivery, sacrificing the user experience, appearance/'feel' of the app and ability to provide richer functionality/OS integration along the way.

Even HTML apps have the option of local storage.

The challenge wherever showing cached data is communicating that clearly. Imagine a bank app showing an old balance where connectivity is poor. It could cause overdrafts.

Then all the write operations need to be disabled or hidden.

"Your balance has changed since you last connected, and is now $0.02. Are you sure you wish to transfer $10,000.00?"

A fast hack I did with native Android is to use the shared preferences for caching API responses. You can store entire objects as string with libraries like GSON.

Yes, they do. Still all the OP points apply.

I have been at a few companies now that seem to have drank the "server-driven UI" punch and were actively architecting their mobile applications to be entirely dependent upon a stable connection to their backend to display anything beyond a splash screen. The argument for the architecture always falls along the lines of "enabling rapid deployment" and have had systems architects directly convey that they did not cache any data as it could result in displaying outdated or undesired content.

Personally, I have come to despise this architecture as, in my experience, it provides marginal gains in process for a developer while increasing technical complexity, backend scale/dependence, and a sub-optimal user experience.

I don’t know if things have changed but when I started developing apps about 3 years ago, none of the docs or tutorials mentioned persistent storage until the very end, and it would touch on it very lightly.

So when you have developers learning about app dev assuming they will have an internet connection, and most of the time really fast since it’s their dev machine the apps are being built on. Caching sort of becomes and after thought and doesn’t get much attention.

Also, I do recall the api for doing this sort of stuff was very SQL like, at least in the iphone. This probably adds another layer to most devs knowing frontend only and being exposed to CRUD apis.

If you use Firebase the syncing and offline access comes for free.

I suspect most of the first mobile developers used to be web developers and then they taught the future generations of mobile developers to also be like web developers. Query endpoints from the backend for individual features without building a local view in the javascript of the whole world. And slap some spinners and error messages on to give the illusion of responsiveness.

As for the backend, they just use whatever database they prefer.

There's a bit of a joke about mobile dev interviews these days. A company with no experience in mobile dev will ask you if you've ever integrated analytics. A company with a mobile dev team will ask you to write a movie app with pagination and caching. An experienced company will ask about declarative UI and reactive programming.

"the api for doing this sort of stuff was very SQL like"

Android these days do it via Jetpack/Room. It's still SQLish, but much less room (heh) for typos and similar bugs, and it even does syntax highlighting for common mistakes.

The real answer is they want to reduce the chance of someone intentionally using it offline because it’s more convenient or easier in a specific situation.

Also can't serve advertisements if the end user is offline.. even if the app otherwise requires no Internet connection (e.g. solitaire, sudoku, etc)

There's no financial incentive to add extra error handling code in this case.

This is especially annoying with single player games for kids. Half the games on their tablets don't work in the car unless there's a hotspot.

I do build apps. This is actually taught as best practice to beginners in many classes. A standard design is pulling everything from a Repository pattern, which either points to local data or network as needed.

This kind of architecture is costly, especially combined with TDD and such needing to cover every possibility on every layer. Adding the repository layer with two data sources is basically 3x tests to write. If time is short (and it always is) adding the repo layer doubles the tests to write/maintain for absolutely no gain. Adding it as needed later isn't so bad, but it's just put off forever.

Also, ads don't run if the network is disconnected. Users soon realise that disconnecting is like running ad blockers.

Same with some anti-cheat, e.g. changing the time to move forward in idle games.

Often the intended purpose of the app is to take your data and sell it to third parties. It can't do that without a network connection. If the app works well without a network connection that fact will diminish its ability to serve its intended purpose.

It can cache the data and upload whenever there is a connection.

Not if you never give it access!

Some apps are developed in some cross-platform solutions so it can’t leverage the native features like Android’s Service (background) for example.

In terms of the finance world, it’s cause it’s a security risk to have any important information on your device that persists.

This is just lazy reasoning, really. Android has sandboxed per-app internal storage/database persistence. If that's not good enough, you have the hardware-backed keystore and you can require the user to unlock e.g. a decryption key. I have no interest in iOS, but I'm sure it has equivalent or better functionality.

In my experience historically working with various financial orgs as a consultant, "security" is often cited as an excuse for poor UX and poor software engineering practices.

My own bank will happily show me the last-retrieved transactions and balance when I'm offline in their app. I have more confidence in their security given their policy of publicly talking about security architecture and use of open source tech than the dozen banks that are still using mainframes at the core of their stack and think that preventing the user switching away from/back to their app helps security.

I never said it wasn’t a stupid reason. Everything you said is accurate but… it’s the reason the decision makers who decide what features the app would have give to us. And so, that’s why our app doesn’t have that that.

"Those who would give up essential User Experience, to purchase a little temporary Security, deserve neither User Experience nor Security." - Benjamin Gates

Probably applies to less than 1% of the apps with this issue.

Reply on news.ycombinator.com