diff --git a/docs/pages/getting-started/deployment.mdx b/docs/pages/getting-started/deployment.mdx
index 13a4c7684e..bcfe4f3031 100644
--- a/docs/pages/getting-started/deployment.mdx
+++ b/docs/pages/getting-started/deployment.mdx
@@ -49,6 +49,8 @@ This environment variable is mostly unnecessary with v5 as the host is inferred
 
 ### `AUTH_REDIRECT_PROXY_URL`
 
+> **_NOTE:_** Some providers (eg Apple) do not support [redirect proxy](https://github.com/nextauthjs/next-auth/blob/3ec06842682a31e53fceabca701a362abda1e7dd/packages/core/src/lib/utils/providers.ts#L48) usage.
+
 This environment variable is designed for advanced use-cases only, when using Auth.js as a proxy for preview deploys, for example. For more details, see the [securing preview deploys](#securing-a-preview-deployment) section below.
 
 ## Serverless
@@ -163,12 +165,14 @@ CMD ["node", "server.js"]
 
 ## Securing a preview deployment
 
+> **_NOTE:_** Some providers (eg Apple) do not support [redirect proxy](https://github.com/nextauthjs/next-auth/blob/3ec06842682a31e53fceabca701a362abda1e7dd/packages/core/src/lib/utils/providers.ts#L48) usage.
+
 Most OAuth providers cannot be configured with multiple callback URLs or using a wildcard.
 
-However, Auth.js **supports Preview deployments**, even **with OAuth providers**. The idea is to have one deployment which proxies authentication requests to the dynamic URLs of your main application. So you could have 1 stable deployment, like at `auth.company.com` where you would point all your OAuth provider's `callbackUrl`s, and this application would then, upon successful authentication, redirect the user back to the preview deploy URL, like `https://git-abc123-myapp.vercel.app`. Follow these steps to get started with securing preview deploys with Auth.js.
+However, Auth.js **supports Preview deployments**, even **with most OAuth providers**. The idea is to have one deployment which proxies authentication requests to the dynamic URLs of your main application. So you could have 1 stable deployment, like at `auth.company.com` where you would point all your OAuth provider's `callbackUrl`s, and this application would then, upon successful authentication, redirect the user back to the preview deploy URL, like `https://git-abc123-myapp.vercel.app`. Follow these steps to get started with securing preview deploys with Auth.js.
 
 1. Determine a stable deployment URL. For example, a deployment whose URL does not change between builds, for example. `auth.yourdomain.com` (using a subdomain is not a requirement, this can be the main site's URL too, for example.)
-2. In both the preview and stable environment, set `AUTH_REDIRECT_PROXY_URL` to that stable deployment URL, including the path from where Auth.js handles the routes. Eg.: (`https://auth.yourdomain.com/api/auth`)
+2. In **both the preview and stable environment**, set `AUTH_REDIRECT_PROXY_URL` to that stable deployment URL, including the path from where Auth.js handles the routes. Eg.: (`https://auth.yourdomain.com/api/auth`). If the variable is not set in the stable environment, the proxy functionality will not be enabled!
 3. Update the `callbackUrl` in your OAuth provider's configuration to use the stable deployment URL. For example, for GitHub it would be `https://auth.yourdomain.com/api/auth/callback/github`.
 
 Fun fact: all of our example apps are using the proxy functionality!
diff --git a/docs/pages/getting-started/providers/apple.mdx b/docs/pages/getting-started/providers/apple.mdx
index 7d2a2d5377..1fbb0db8d1 100644
--- a/docs/pages/getting-started/providers/apple.mdx
+++ b/docs/pages/getting-started/providers/apple.mdx
@@ -10,6 +10,8 @@ import { Code } from "@/components/Code"
 - Sign in with Apple [REST API](https://developer.apple.com/documentation/sign_in_with_apple/sign_in_with_apple_rest_api)
 - [How to retrieve](https://developer.apple.com/documentation/sign_in_with_apple/sign_in_with_apple_rest_api/authenticating_users_with_sign_in_with_apple#3383773) the user's information from Apple ID servers
 
+> **_NOTE:_**  Apple currently does not support [RedirectProxyUrl](https://github.com/nextauthjs/next-auth/blob/3ec06842682a31e53fceabca701a362abda1e7dd/packages/core/src/lib/utils/providers.ts#L48) usage.
+
 ## Setup
 
 ### Callback URL
diff --git a/packages/frameworks-sveltekit/src/lib/index.ts b/packages/frameworks-sveltekit/src/lib/index.ts
index e1007b4719..532ca2149d 100644
--- a/packages/frameworks-sveltekit/src/lib/index.ts
+++ b/packages/frameworks-sveltekit/src/lib/index.ts
@@ -65,12 +65,14 @@
  *
  * ### Server-side
  *
- * `<SignIn />` and `<SignOut />` are components that `@auth/sveltekit` provides out of the box - they handle the sign-in/signout flow, and can be used as-is as a starting point or customized for your own components. This is an example of how to use the `SignIn` and `SignOut` components to login and logout using SvelteKit's server-side form actions. You will need two things to make this work:
+ * `<SignIn />` and `<SignOut />` are components that `@auth/sveltekit` provides out of the box - they handle the sign-in/signout flow, and can be used as-is as a starting point or customized for your own components. This is an example of how to use the `SignIn` and `SignOut` components to login and logout using SvelteKit's server-side form actions. Another example is available on [our svelte-auth-example repo](https://github.com/nextauthjs/sveltekit-auth-example).
  *
- * 1. Using the components in your SvelteKit app's frontend
+ * You will need two things to make this work:
+ *
+ * 1. Using the components in your SvelteKit app's frontend (for instance `src/routes/+page.svelte`)
  * 2. Add the required `page.server.ts` at `/signin` (for `SignIn`) and `/signout` (for `SignOut`) to handle the form actions
  *
- * ```ts
+ * ```ts title="src/routes/+page.svelte"
  * <script>
  *   import { SignIn, SignOut } from "@auth/sveltekit/components"
  *   import { page } from "$app/stores"
@@ -123,8 +125,11 @@
  *
  * We also export two methods from `@auth/sveltekit/client` in order to do client-side sign-in and sign-out actions.
  *
- * ```ts title="src/routes/index.svelte"
- * import { signIn, signOut } from "@auth/sveltekit/client"
+ * ```ts title="src/routes/+page.svelte"
+ * <script>
+ *   import { signIn, signOut } from "@auth/sveltekit/client"
+ *   let password
+ * </script>
  *
  * <nav>
  *   <p>
@@ -152,7 +157,7 @@
  *       <button on:click={() => signIn("credentials", { password })}>
  *         Sign In with Credentials
  *       </button>
- *       <button on:click={() => signOut()})}>
+ *       <button on:click={() => signOut()}>
  *         Sign Out
  *       </button>
  *     </div>
@@ -177,7 +182,7 @@
  * ```
  *
  * What you return in the function `LayoutServerLoad` will be available inside the `$page` store, in the `data` property: `$page.data`.
- * In this case we return an object with the 'session' property which is what we are accessing in the other code paths.
+ * In this case we return an object with the `session` property which is what we are accessing in the other code paths.
  *
  * ## Handling authorization
  *
@@ -186,7 +191,7 @@
  * ### Per component
  *
  * The simplest case is protecting a single page, in which case you should put the logic in the `+page.server.ts` file.
- * Notice in this case that you could also await event.parent and grab the session from there, however this implementation works even if you haven't done the above in your root `+layout.server.ts`
+ * Notice in this case that you could also `await event.parent` and grab the session from there, however this implementation works even if you haven't done the above in your root `+layout.server.ts`
  *
  * ```ts
  * import { redirect } from '@sveltejs/kit';
@@ -202,7 +207,7 @@
  * :::danger
  * Make sure to ALWAYS grab the session information from the parent instead of using the store in the case of a `PageLoad`.
  * Not doing so can lead to users being able to incorrectly access protected information in the case the `+layout.server.ts` does not run for that page load.
- * This code sample already implements the correct method by using `const { session } = await parent();`. For more information on SvelteKit's `load` functionality behaviour and its implications on authentication, see this [SvelteKit docs section](https://kit.svelte.dev/docs/load#implications-for-authentication).
+ * For more information on SvelteKit's `load` functionality behaviour and its implications on authentication, see this [SvelteKit docs section](https://kit.svelte.dev/docs/load#implications-for-authentication).
  * :::
  *
  * You should NOT put authorization logic in a `+layout.server.ts` as the logic is not guaranteed to propagate to leafs in the tree.