If you strip everything else away, the single biggest thing a mobile app can do that a website cannot is push a notification to the user's lock screen. That is the power. That is the differentiator. And most apps waste it.
The default approach to notifications is: send a lot. Send every update. Send every "hey check this out." Within two weeks, the user has either turned off notifications for your app or deleted it. Either way, you have lost the main event.
The design problem is the opposite of what most teams think. The question is not "how many notifications should we send." The question is "which notifications earn their place on the user's lock screen." Every notification is a check. You have to be net positive across all of them or the user disables you.
A useful notification is one where the user is glad they got interrupted. An order shipped. A message arrived. A meeting starts in 10 minutes. A flight delay. Something relevant, personal, and actionable.
A bad notification is generic. "Your daily tip is ready." "Check out our new feature." "We miss you, come back." These are the notifications that train the user to stop looking, and eventually to turn off notifications entirely, at which point your app has lost its only real edge over the web.
The specific tactic that works is aggressive segmentation and timing. Not "every user gets the weekly digest Monday at 9 am." More like "each user gets the digest at the time they actually check the app most often, with content personalised to them, only if there is something meaningful to say." This is harder to build. It is also the difference between notifications that retain users and notifications that churn them.
We do not ship an app without a notification strategy, and the strategy is almost never "send more." It is usually "send less, and make each one matter." Some of our client apps send fewer than two notifications per user per week. Their open rates are multiples of what the industry reports as average. The correlation is not accidental.