The easiest option is to keep the apps separate and make sure your webserver knows which one to serve for each URL. Links between the apps become plain <a href=...>. The benefit of this solution is that you get to develop and deploy the two apps independently. The downside is that if users go between them a lot and your app doesn’t boot very fast, it may feel slower.
The alternative is to port one into the other. If both apps are going to be maintained by the same team anyway, this is probably worth doing, as separation (whether with engines or separate apps) is not really helpful in that situation. First work to get both apps using the exact same set of dependencies. Then search for any places where they’re using the same name for different things (like two different components with the same name, or two different routes with the same name) and change those to stop colliding. Then combine the router maps, copy all the routes, templates, components, etc, and test.
The hardest part may be the CSS, unless both apps have done an above-average job of maintaining clean style isolation.
It’s possible, but whether it’s a good idea depends on your app.
If the parts of app1 that wrap “around” app2 are not very complex, you can make them into shared components that are used by both standalone apps.
For example, if you have a tab bar and some of the tabs render routes in app1 and others in app2, you would make the tab bar into a component that both apps use, and when the tab bar is rendered in app1, the app2 tabs become plain links to the other app, and vice versa.
But if there’s a lot more entangling than that, you may be better off with the second alternative (porting app2 into app1 and having a single app).
You would show app2, and make it look like it’s inside a tab by actually rendering all the stuff outside the tab as components that are used in both app1 and app2.
Or an iframe, but that has a lot of other challenges.