We have had our websites and mobile apps in one global suite for years... and I agree with @kayawalton you really need to make sure that all your dimensions and metrics line up...
Now, there could be some web specific data and some app specific data that will never overlap (i.e. footer on web but not on app, maybe font size settings on the app or dark/light mode, lifecycle metrics, etc), there could also be slightly different behaviours on the web from the app.. maybe on web you have a hamburger menu, but on the app you have a page dedicated to navigation. However, even with some differences, you can find some commonality.. so if you have an event for menu shown, on web you have it when the menu is expanded, and on the app you have it on the page view, etc.
The important thing to keep in mind is the tracking calls:
- The kind of data you track on s.t() calls on the web, should all be in the trackState calls on the app
- The kind of data you track on s.tl() calls on the web, should all be in the trackAction calls on the app
You would be surprised how many people try to fire both a trackState and a trackAction when loading a screen on the app... capturing the page name in the State, and everything else in the Action... this causes a lot of data issues and uses up additional server calls unnecessarily.
Now, when you are mapping your app context variables in processing rules (unless these are being mapped via streams now - our apps are still a bit old school), I make sure that all processing rules target only app calls (if a.appid is set, plus whatever specific logic I need) to ensure that no rules I have in place could possibly interfere with the web.
Good luck!