I am terribly sorry that it took so long in getting back to you, and the inconvienience you have had so far.
Your scenario is pretty standard. However, this will impose using the hosted login page to login to the swift application. The details of what this imposes along with the pros and cons are documented at https://auth0.com/docs/tutorials/browser-based-vs-native-experience-on-mobile
Here is how the integration would work, in an ideal scenario where the applications are different and your SPA is actually living in a separate website in Safari View Controller / Chrome Custom Tabs (Embedded browser tab) or needs a server side session (Wordpress Website etc) or you have no access to the application living inside the webview and its conceptually a different app.
The user arrives to your app. Your app sees no session and initiates login using the WebAuth method in the iOS / Swift SDK. At this point your application will get a
refresh_token which the app use to keep the user logged in.
The user then goes to the webview say https://foo.com/ at this point foo.com will notice that there is no session that it has for the user, therefore it will redirect to Auth0 with
prompt=noneoptimistically (using the renewAuth method in Auth0.js).
Auth0 will then see the user’s session and immediately respond with a token for the webview. The webview can now show the user the required session.
This flow is documented in great detail at https://auth0.com/docs/api-auth/tutorials/silent-authentication. The above is under the assumption that the webview is being opened in the same browser (say safari view controller, which is the recommended way of doing it in applications).