Hmm, where to even start? Some off the top of my head:
- Web doesn't have access to the camera. Uploading a photo to Facebook is easy because you can launch the camera directly in-app, without having to use a separate camera app, save the image to disk locally, and then picking it for upload. Importantly also is the rise of photo filters, which would be impossible to live preview on a website.
- Importantly also, there is an increase in live streaming, which would be impossible from a mobile site.
- Uploading photos/videos is also easy because you can leave the app as soon as the upload begins, the upload will be finished in the background. This is flat-out impossible via a mobile website. With a mobile site you'd at least have to keep the app around and be unable to do anything else with your phone until any uploads are complete.
- Offline/semi-offline interactions are actually possible in a native app. The nature of phones is that it can be out of connectivity, or be in areas with unreliable connectivity, and should still function. With a native app actions performed while offline/marginally online (posting, commenting, liking, etc) can be cached and performed in the background once the phone has better connectivity. A website cannot do this.
- On the consumption side, there are many advantages to the native app:
- The incremental page loads that FB does (and Twitter, and Instagram, and everone else) bog down a browser quickly. Laying out the entire DOM is extremely resource intensive and a major source of poor scrolling performance. Even on modern desktops, try scrolling down a bunch of pages in your FB feed (or Twitter feed), and watch the performance tank quickly until scrolling is like pulling teeth. The native apps are immune to this kind of limitation, since there is no DOM and only what's on screen is actively being laid out (all off-screen content has no impact on render performance).
- No whole-DOM layout also means that the app is more responsive on launch. In app dev we have a concept known as the "cold start time" - which is the latency between tapping on an app's icon and having the app be fully interactive and ready for the user. Webapps do a lot worse in this regard for many reasons: needing to transmit the entire DOM, JS performance issues, layout CPU consumption, etc, that native apps are less susceptible to, or fully immune to.
- In bandwidth constrained situations (which is, well, a lot of the world), a native app passing purely semantic data consumes a lot less data than a webapp that needs to transmit semantic and presentational data. A JSON or Protobuf payload is a lot smaller than a HTML/JS/CSS payload.
- Media is more effectively fetched in native, which is aware of cell vs. wifi, and can customize the resolution/size of content fetched based on network conditions. The browser provides no access to the primitives that it would take to implement this.
- Videos can be inlined in the stream, which is impossible on most mobile browsers, allowing users to quickly preview video content before deciding whether or not to watch it.
- Web does have access to the camera. I regularly upload images to the Facebook mobile site. You can also do live previews of images and allow users to experiment with filters before uploading.
- Live streaming on mobile web is also possible. If you support DASH and HLS you can reach the vast majority of mobile users [0]
- It's possible to support offline apps with mobile web, but it's definitely tricky. The biggest issue for most people is that you can't perform work in the background. Service workers are an attempt at improving on that. But you can still save data in localStorage or IndexedDB and push it up when the user reconnects. There's an offline and online event you can hook into.
- Native apps aren't magical. If you're dealing with large collections on the web you can also virtualize em, look at react-virtualized for an example [1]. That lets you avoid having to create as many DOM nodes all at once.
- You can achieve the same thing by writing your web app as a shell that later loads additional content. That way the initial load feels faster. Check out Progressive Web Apps to see the direction that's headed.
- Mobile web apps usually use JSON too. Nothing special about native apps here.
- Both DASH and HLS fully support dynamic quality. Heck, DASH literally means "Dynamic Adaptive Streaming over HTTP". By supporting both you can target most mobile web browsers. Native apps use these same protocols. It's already implemented by the browser vendor or by native APIs.
- You can jump to the middle of a video stream on mobile web. It's exactly the same as with a desktop browser. Go open up YouTube and skip a few minutes ahead.
- Web doesn't have access to the camera. Uploading a photo to Facebook is easy because you can launch the camera directly in-app, without having to use a separate camera app, save the image to disk locally, and then picking it for upload. Importantly also is the rise of photo filters, which would be impossible to live preview on a website.
- Importantly also, there is an increase in live streaming, which would be impossible from a mobile site.
- Uploading photos/videos is also easy because you can leave the app as soon as the upload begins, the upload will be finished in the background. This is flat-out impossible via a mobile website. With a mobile site you'd at least have to keep the app around and be unable to do anything else with your phone until any uploads are complete.
- Offline/semi-offline interactions are actually possible in a native app. The nature of phones is that it can be out of connectivity, or be in areas with unreliable connectivity, and should still function. With a native app actions performed while offline/marginally online (posting, commenting, liking, etc) can be cached and performed in the background once the phone has better connectivity. A website cannot do this.
- On the consumption side, there are many advantages to the native app:
- The incremental page loads that FB does (and Twitter, and Instagram, and everone else) bog down a browser quickly. Laying out the entire DOM is extremely resource intensive and a major source of poor scrolling performance. Even on modern desktops, try scrolling down a bunch of pages in your FB feed (or Twitter feed), and watch the performance tank quickly until scrolling is like pulling teeth. The native apps are immune to this kind of limitation, since there is no DOM and only what's on screen is actively being laid out (all off-screen content has no impact on render performance).
- No whole-DOM layout also means that the app is more responsive on launch. In app dev we have a concept known as the "cold start time" - which is the latency between tapping on an app's icon and having the app be fully interactive and ready for the user. Webapps do a lot worse in this regard for many reasons: needing to transmit the entire DOM, JS performance issues, layout CPU consumption, etc, that native apps are less susceptible to, or fully immune to.
- In bandwidth constrained situations (which is, well, a lot of the world), a native app passing purely semantic data consumes a lot less data than a webapp that needs to transmit semantic and presentational data. A JSON or Protobuf payload is a lot smaller than a HTML/JS/CSS payload.
- Media is more effectively fetched in native, which is aware of cell vs. wifi, and can customize the resolution/size of content fetched based on network conditions. The browser provides no access to the primitives that it would take to implement this.
- Videos can be inlined in the stream, which is impossible on most mobile browsers, allowing users to quickly preview video content before deciding whether or not to watch it.