Web View workflows

Mobile Beta
1

What’s the reason of using a web view inside the native mobile if you can’t relate workflows between each other?

2

  1. If you already have responsive web pages, you can just drop them into a web view and they’ll work inside your native app—no need to rebuild everything from scratch using native elements.

  2. Shared backend logic. Even though workflows in native and web views are separate (so you can’t directly trigger a web workflow from a native page), they still use the same backend (database, API workflows, etc.), so all your data stays in sync.

  3. Phased migration. You can mix and match—build some screens natively, and keep others as web views for now. It’s a nice way to gradually move things over without redoing everything at once.

3

Hello Taras!! Thanks for your answer

I understand that the backend is shared between both web and native mobile. But at some point you’ll 100% need a way to relate a workflow or a custom state from the web view to the mobile view itself. If not, there’s no chance you can have a phased migration… You MUST be able to correlate a workflow or a custom state from a view to the other at some point of the process. Otherwise, you’ll be stucked in the same view forever…

At least for navigation reasons, you’ll need to correlate both views in some way. Even if the backend is the same for both. What would be the reason of making a mobile app with just 1 view with a “webview” that can’t interact with it?

4

Well, you can navigate from the webview - just write the path you want to go to to the database and then have a “When true” condition for when that field is not empty to navigate to that target.

In my head, I treat webview an iframe embed.