Sign in with Apple in Unity (the iOS requirement, done right)

Sign in with Apple has a reputation among Unity developers, and it's earned. It's the one provider Apple can force into your game — and its client secret isn't a string you paste, it's a JWT you have to sign and keep re-signing. This guide covers both: why you probably need it, and how to add it without writing any token-signing code.

Why Apple, and why now

If your iOS game shows a "Sign in with Google" button — or Facebook, or Discord, or any third-party login — Apple's App Store Review Guideline 4.8 requires you to also offer a login with "equivalent" privacy. Sign in with Apple is the option that satisfies it: minimal data, an option to hide the email, no cross-app tracking. Skip it and you're risking a rejection at review, after the build is done.

So for a lot of studios this isn't a "nice to have." It's the thing standing between a finished build and an approved one. Worth getting right the first time.

The part that makes Apple different: the client secret

Every other provider hands you a client ID and a client secret string. Apple doesn't. Apple's "client secret" is a signed JSON Web Token: an ES256 JWT built from your Team ID, a Key ID, and a downloaded .p8 private key, with an expiry no longer than six months. You're expected to generate it, sign it correctly, and rotate it before it dies — from inside your game, which is exactly where you can't safely keep a private key.

This is the wall most Unity developers hit. It's also the wall Oathwall removes: you upload the Team ID, Key ID, Services ID, and .p8 key into the dashboard once, and Oathwall signs and refreshes that JWT on its servers for every login. Your build never holds the key.

Step 1: Set up your Apple identifiers

You'll do this in the Apple Developer portal, under Certificates, Identifiers & Profiles. Sign in with Apple keys the login to a Services ID, not your App ID — this trips people up, so go slowly.

1. Under Identifiers, make sure your App ID has the Sign in with Apple capability enabled.
2. Create a new Services ID (this becomes your client_id). Give it a description and identifier, then enable Sign in with Apple on it and configure the domain.
3. In that Services ID's configuration, add this Return URL exactly:

https://sso.oathwall.com/auth/callback

4. Under Keys, create a new key with Sign in with Apple enabled. Download the .p8 file — Apple lets you download it once, so save it — and note the Key ID.
5. Grab your Team ID from the top-right of the developer portal.

That's four pieces: Services ID, Team ID, Key ID, and the .p8 file. Apple's return URL is picky in the same way Google's is — https, no stray path, character-for-character. A mismatch here fails the login before Apple ever shows the sheet.

Step 2: Hand the pieces to Oathwall

In the Oathwall dashboard, open your app, add Apple as a provider, and upload the four items from Step 1. The .p8 key is stored server-side and used only to sign the client-secret JWT during the token exchange. From this point on, the six-month rotation Apple demands is Oathwall's problem, not something you'll get paged about mid-launch.

Step 3: Wire it up in Unity

Client-side, Apple looks like every other provider. Same base class, one string:

using PixitGames.SSOLoginKit;

public class LoginManager : SsoClientBase
{
    // Apple requires a form_post callback and deep-links
    // back into the game — both handled for you.
    public void OnAppleButton() => StartLogin("apple");

    protected override void OnLoginSuccess(LoginResult user)
    {
        // Capture user.name HERE — Apple only sends it once.
        SaveProfile(user.id, user.name, user.email);
    }
}

StartLogin("apple") opens Apple's sign-in sheet in the system browser. Apple returns the result as a POST (response_mode=form_post) rather than a normal redirect, which Oathwall's callback handles — you don't write anything for it. When it lands back in the game, OnLoginSuccess gets a LoginResult with the player's id, email, and provider.

The gotchas worth knowing

The name comes back exactly once. Apple includes the player's name only on their first authorization for your app, in the callback's user field. It's never in the id_token, and it never comes again on later logins. Oathwall captures it on that first sign-in and returns it, but if you don't persist user.name right there in OnLoginSuccess, you won't get a second chance — repeat logins arrive with an id and email but a null name. Store it immediately.

"Hide My Email" gives you a relay. Players can choose to hide their address, and Apple hands you a per-app relay like [email protected]. It's stable for your game, so it's fine as an account key. Just know that to actually email that player, you have to send through Apple's private relay service — a normal SMTP send won't reach them.

Email can be absent on repeat logins too. Like the name, the email is most reliably present on the first authorization. Treat the first sign-in as the moment you capture identity, and use the stable id as your player key afterward — the same discipline that Steam's no-email flow forces on you anyway.

It works beyond iOS. Apple only requires the button on iOS, but the flow runs in a browser, so Android and desktop players can use their Apple ID too if you want to offer it.

If you're adding Apple alongside other providers, the Unity authentication guide shows how one login class serves all of them, and access vs. refresh tokens explains how the session that Oathwall hands back stays alive between play sessions.

Oathwall is available on the Unity Asset Store — its free tier is enough to test the full Apple flow, sandbox mode and all, before you submit for review.