Most mobile design advice concerns the happy path, where the network is fast and the phone is in two hands and the person is paying attention. The happy path is not where apps are lost. They are lost in a lift, in a queue, at 4% battery, in the ninety seconds before someone gives up and does the thing another way.
The thumb decides the layout.
Hold your phone the way you actually hold it. One hand, thumb anchored at the bottom corner, and a comfortable arc that covers the lower half of the screen and not much else. The top corners, where desktop instincts put the primary action, are the hardest place on the device to reach.
So the main action goes low, destructive actions stay away from where the thumb rests, and anything a person repeats goes in the arc rather than at the top of a long scroll. This is well known and still routinely ignored, usually because the design was reviewed on a laptop where every part of the mockup is equally easy to click.
Design the wait, not just the result.
A phone is a device for using in bad conditions, so the loading state is not an edge case, it is a screen people will see hundreds of times. Left undesigned it becomes a spinner in the middle of an empty page, which tells the person nothing except that something might be happening.
The better version answers two questions: is it working, and how much longer. A skeleton of the layout that is coming answers the first by showing the shape of the result. Anything that streams in progressively answers the second. Neither is technically demanding. They just have to be decided rather than defaulted to.
What happens with no signal.
Explore Malaysia is for the first hour after a visitor lands, and in that hour a lot of people have not sorted out local data yet. An app built on the assumption of connectivity is useless at precisely the moment it was made for.
So the question stops being whether to handle offline and becomes which parts have to survive it. What has been saved already should still be readable. Anything the person typed should still be there when the connection returns. And when something genuinely cannot be done offline, the app should say so plainly rather than failing in a way that looks like the app is broken.
An app that behaves well with no signal is trusted more than one that is merely fast.
The number must not move.
The Hotels.com flow was rebuilt around one rule: the total price shows before checkout and does not change. No fees appearing at the last step, no surprise at the moment of payment.
That matters everywhere and it matters most on a phone, where the person cannot see the whole flow at once and is often part way through something else. A price that moves at checkout does not just cost you that booking. It teaches the person to distrust every figure the app shows them afterwards.
What actually keeps an app installed.
Not delight, and not the feature list. An app stays on the phone when it behaves predictably on a bad day: it opens fast, it holds on to what you typed, it tells you what it is doing, and it never changes a number after you have made a decision based on it.
None of that photographs well. All of it is the difference between an app somebody keeps and one they meant to come back to.
