Back function in (mobile) native apps vs. web apps

Question

I'm currently prototype a search / result workflow for a web app.
You search something, click on a result and be able to go back to the search result.

Now how do I display that? Do I implement a back-button or should I rely on the browser back-button?

But first some information on the web-app & what I've already tried / searched:

The web-app
The web-app is a tool for work. It means that there are no alternatives and the users will use the tool multiple times everyday. So they could learn complex interaction-systems overtime.

The user
The users will mostly use the web-app on Android devices. But it needs to be able to acces the tool over desktop & iPad too. The device-usage is about the following:
Samsung Galaxy S4 mini: 80%
Desktop: 10%
iPad: 8%
others: 2%

Analysis
So I started trying out some websites and searched for best practices and I came across an intresting fact: native mobile apps are implementing back-buttons / -links while web-apps don't.
Here are some examples (left web-app, right native app. Only Android, no iOS examples):

Zalando
The web-app doesn't offer a back-button while the native app offer a back-arrow top left but removes the navigation completly. So while a mobile user need to rely on a browser back-button or Android back-button, he is able to still navigate and search. The Native App user on the other hand is able to quickly go back to the result, but can't navigate further.

If you scroll down, the native app have a fixed header where you can go back all the time, while the web-app don't have a fixed header at all.

Pinterest
Similar to Zalando, Pinterest have no back-button on the web-app while the native app provides a back-arrow.

More examples for native Apps can be found here on mengto.com.

Conclusion
Native apps are 100% mobile optimized, because it's the only focus. I'm aware that there is also a difference between Android and iOS since iPhone doesn't have a back-button on the hardware and need such a back-button in the UI. But most of the Android-Apps still provide a back-button in the application itself.
So why do web-apps don't provide such a back-button on the mobile size, since it's integrated in most native-apps?

And what should I use in my web-app? Should I provide a additional back-button or not? (As I mentioned earlier, we focus on Android User).

Article I read but didn't satisfy me completly
UX-SE Q&A:
Should a web-based UI rely on the browser back button?
Any Research on User Experience Perceptions of Native Apps vs Web or Hybrid Apps
Back button on mobile web app
Is a back button a good idea for mobile?

Blogs / Articles:
6 UX Mistakes to Avoid When Designing a Native Mobile App
4 Design Patterns That Violate Back-Button Expectations

Answer 1

This answer is focused on Android, it might or not be applicable to iOS.

Google Material Guidelines has a very complete section on Navigation which describes how a user interacts with the navigation history in apps. It is clearly explained there so I'll mostly use references to it and some thoughts.

---

The two main navigation buttons are:

• The App specific Up button:

The Up button returns users to the previous screen they viewed. It navigates upward in the app’s hierarchy until the app’s home screen is reached.

• Android OS main Back button:

The Back button navigates in reverse chronological order through the history of recently viewed screens.

.

Whereas the Up button ensures the user remains in your app, the Back button may take the user back through recent screens outside of your app.

For this reason it is a good idea to have an Up button in an App.

---

In the examples you propose the two cases are:

• Browser App

• Native App

In both cases the App provides an Up button. The App in the Web case is the Browser, which already has an Up button.

---

The way the App responds to the user scrolling is probably dependant on the decision of the developer. Google describes different ways of how the Toolbar could react to the scroll.

When sheets scroll underneath toolbars, they are clipped and cannot pass through to the opposite side.

Sheets can also cover the toolbar as they move offscreen.

(...) Toolbars can share a seam with another sheet.

In cases where they share a seam that transforms into a step, it is called a waterfall.

---

I hope this answered your main question.

About the second one: What should I use in my web-app? Should I provide a additional back-button or not? (As I mentioned earlier, we focus on Android User).

I don't think providing an extra Up button to the browser's one is a good idea. It might create confusion as the user will not know what is the difference between both (as both should be doing the same).

You might want to check how to prevent the address bar from hiding.

---

Edit:

To me it is a little bit confussing how the buttons actually work:

Up button: The up button sometimes brings me to the App parent (ascending navigation), and in some others to a sibling (lateral navigation) and after to the parent (ascending navigation).

Back button: The back button in some apps brings me to the App parent, whether the parent was the previous history screen or not. In some others it respects the history line. For example:

In Play books App if from the Home screen I open the App and it shows the page of a book, pressing the back button will bring me to the Home screen.

In Google Keep App if from the Home screen I open the App and it shows a certain note (single view), pressing the back button will NOT bring me to the Home screen, but to the parent (ascending navigation).

The key difference is that the Up button won't let the user go out of the App, but the Back button might.

---

Answering to your comment, in the Chrome App the Back button brings the user back in history inside the App (only in the actual Tab). When the "first accesed page" of that Tab is reached it will bring the user to the OS Home screen.

My guess is that as there are no parents in the Chrome App there is no need to display an Up button. The back button will navigate all Tab history.