[tadfisher]

The solution here is to show an error notification after the fact. A good way to handle this is to bake a failed-request queue into the network layer, and to ensure requests are serializable and replayable. Obviously, mobile designers need to consider failure cases and the best user experience to deal with these.

[crazygringo]

On mobile, that isn't always possible. If I'm on my iPhone, and I upload something, the app indicates it's done (lying to me), then I close the app... and don't open it again for three weeks... how is it supposed to give me an error message? And replaying a network queue three weeks later might be even worse.

The app can't, because it's been closed. And the server can't e-mail me with an error or anything, because it might never have even known about the action.

At least on webpages, the page can intercept the close action with a modal dialog, then fires when you try to quit the browser or close the tab, warning that you have unsaved data. Mobile apps have no such last-case warning mechanism.

Because of this, I agree that lying to your users about successfully completed actions, on mobile, is bad advice. You're abusing users' trust, and once they discover that (and remember just how unreliable mobile connections are, so they're bound to discover it sooner or later!), don't be surprised if they don't come back.

[lnanek2]

I think you are a little out of date on mobile development. This has always been easy on Android, and many apps show a notification while they are upload large images, like Facebook. Any Android app showing a notification can request foreground scheduling priority for a background process. iOS7 recently caught up as well with background app refresh letting you make requests to a content server in the background without being started, just the system starting you regularly. Not that the iOS4 ten minutes after use background task was usually insufficient and the server failing to see it complete could have been used to send a push anyway...