apple-signin-unity: putting Sign in with Apple inside a Unity game

Why this plugin exists at all: an App Store review requirement

The plugin's stated main purpose is to expose Apple's Sign in with Apple to the Unity game engine, and the reason it was written is a policy rather than a preference.

On WWDC19, Apple announced Sign in with Apple, and on top of that, they announced that every iOS, tvOS and macOS application that used any kind of third party sign-ins, like Sign in with Facebook or Sign in with Google, will have to support Sign in with Apple in order to get approved for the App Store, making it mandatory.

That is the whole reason this exists. Nobody builds a Unity plugin for Apple sign-in because Unity games love Apple's identity system. They build it because a game with a Google login cannot ship without it.

The plugin is by Daniel Lupiañez Casares, and it is MIT licensed. The current stable version is 1.5.0, and it is published on OpenUPM under the package name com.lupidan.apple-signin-unity, which is the registry Unity's newer package tooling uses.

The release history shows steady work rather than a one-off. Version 1.5.0 came on 2025-06-08, v1.4.4 on 2024-11-03 and v1.4.3 on 2023-09-30, and the last push to the repository was on 2026-09-13.

So this is a maintained integration, not a weekend patch, and for a plugin whose whole purpose is to satisfy a review requirement, that continuity is the point.

Platform support, and the honest labels on it

The platform list is short and the labels on it are the useful part.

The plugin supports iOS. It supports macOS on Intel x86_64 and on Apple Silicon arm64, with the arm64 build marked Experimental and pointing at a NOTES document. It supports tvOS, marked Experimental. And it supports visionOS, marked Experimental.

So one platform is production, one is partly production, and two are experimental. That is a reasonable way for a plugin to be honest, and it is worth respecting the distinctions when you plan a project. If you are shipping a mobile game, this is a solved problem. If you are building a Mac or a vision app, you are an early adopter of a path the author is still working on.

The macOS notes are linked from both the overview and the features list, which suggests the macOS story has its own wrinkles that the main documentation does not try to hide.

The features section is more detailed than the platform list, and it is where you can see the scope of the work. Beyond the basic sign-in, the plugin supports Sign in with Apple with customizable scopes for Email and Full name. It supports getting credential status, with the three states Authorized, Revoked and Not Found. It supports quick login, including iTunes Keychain credentials, which is the path where a returning user who has already authorised the app gets signed in without a prompt. It supports adding the Sign In with Apple capability to the Xcode project programmatically in a PostBuild script. It supports listening to credentials revoked notifications. And it supports setting a custom Nonce and State for authorization requests, both when signing in and when attempting a quick login.

That last one matters more than it sounds. Nonce and State are the two values you put in an authorization request and then check in the response, and they are how you tie a sign-in to a particular request rather than accepting whatever comes back.

Installing it, and the two routes into a Unity project

There are two options available to install this plugin, either using the Unity Package Manager, or the traditional .unitypackage file.

The Package Manager route has two sub-routes of its own. The first is installing via a Git URL, which is available starting from Unity 2020.3, and it works by adding a line to the Packages/manifest file in your project. The second is installing via OpenUPM, which is the registry the package is published to and which requires adding the registry to your project settings before the package appears in the list.

The .unitypackage route is the older one and it is what you want if your project is not on a Unity version that supports the Git URL flow, or if your team has a convention of vendoring packages as files.

The practical difference between them matters for a project with more than one person in it. The Git URL route means every clone of your project pulls the plugin at the version your manifest pins, and updating it is a manifest change that shows up in a diff. The .unitypackage route means the plugin is a binary file in your repository that two people can end up on different versions of, and the fix is a version bump you do by hand.

The documentation also mentions OpenUPM as a first-class path rather than an afterthought, and there is a package badge for the OpenUPM registry, which means the author is publishing to the registry rather than only documenting it.

The repository layout backs up the story of a real project rather than a single source folder. There is a Source/ directory with the plugin code, a SampleProject/ directory so you can see the integration working before you wire it into your own game, an Xcode/ directory, and an Img/ directory holding the screenshots and icons that appear in the README. The CHANGELOG lives inside Source/ as Source/CHANGELOG.md, and the macOS notes are at Source/docs/macOS_NOTES.md.

The setup steps, and the part that has to be done in Xcode

The plugin setup section is split into two halves, one for iOS and tvOS and one for macOS, and the iOS half has four subsections that tell you what the plugin can and cannot do for you.

Programmatic setup with a script is the first, and the features list calls it adding the Sign In with Apple capability to the Xcode project programmatically in a PostBuild script. That is the most valuable single feature here, because the Apple capability is what lets your app call the sign-in API at all, and adding it by hand in Xcode is a step that every developer on the team has to repeat and every fresh clone has to redo. Doing it in a post-build script means the project file carries the capability in source control.

Manual entitlements setup is the second subsection, and the wording implies it is the fallback. The manual path is the one every project starts with, and the plugin exists to make it possible to stop doing it.

Enabling the Apple capability is the third, which is the Xcode-side half of the same requirement. Final notes regarding setup is the fourth, and its presence suggests there are caveats that belong with the whole sequence rather than with any one step.

For macOS there is a separate setup section, and given that the macOS build is the one with an Intel path, an Apple Silicon path and its own notes document, you would expect the requirements to differ between a native mac app and an iOS build embedded in a Catalyst-style project.

One FAQ entry is a warning sign worth reading before you build: a CFBundleIdentifier Collision error when uploading to the macOS App Store. That is the kind of thing that only appears at submission time, and it is the kind of thing a plugin cannot fix for you, because it comes from how the app is bundled.

The API, from initialising to handling revocation

The implementation section is broken into the parts of a real sign-in flow, and reading the headings tells you what the library thinks the hard parts are.

Initializing comes first, which is the step that sets up the AppleAuthManager instance on your side. Then Perform Sign in With Apple, which is the interactive flow where the user sees Apple's own sheet.

Quick login is the third, and it is the one that has a FAQ entry of its own about a refresh token after the first user authorization. The answer implied by the feature list is that there is none, because once a user authorises an app, Apple does not hand you a refresh token, and the keychain credential is the mechanism instead. The features list says the plugin supports quick login including iTunes Keychain credentials, so a returning user is signed in from the keychain rather than through a new authorisation.

Checking credential status is the fourth, and it has the three states Authorized, Revoked and Not Found. That is the state machine you need for a game that wants to know whether the account is still valid before it lets you into a save.

Listening to credentials revoked notification is the fifth, and this is the one that is easy to get wrong in your own integration. A player can revoke your app's access in the iOS Settings app at any time, including months after they signed in, and if your game only checks at launch you will keep letting a revoked user play. A notification lets you react at the moment it happens.

Nonce and State support for Authorization Requests closes the list, and as noted earlier it is what ties a response back to a specific request.

The mutability question is covered too. The FAQ says the plugin does not use UnitySendMessage, and it explains why you have to call Update manually on the AppleAuthManager instance, which is the kind of detail that would otherwise cost an afternoon.

The questions the FAQ actually answers, and what they reveal

The FAQ headings are the best guide to what will actually bite you, so it is worth listing what is there rather than what is not.

There is a question about rotated screen orientations, which is a layout question, and one about logging out, where the heading asks whether the plugin provides any Logout option. The framing of the question is itself informative, because Apple does not offer a logout for third-party sign-in in the way a web app does, so the answer is likely that there is no plugin-level logout and you have to handle it yourself.

Then there is the one that will confuse every new user. I am not getting a full name, or an email, even though I am requesting them in the LoginWithAppleId call. The reason is an Apple behaviour rather than a plugin defect: Apple returns the name and email on the very first authorisation only, and on subsequent sign-ins it returns an identifier, so a second-time player never sees their name. A plugin that promised to deliver the name every time would be lying. There is a companion question about whether it is possible to NOT request the user's email or full name, which is the reverse case.

Then the technical ones. Does the plugin use UnitySendMessage, which is answered in the negative and is a good sign, since UnitySendMessage is the string-based global callback mechanism that most Unity plugins use and that produces untyped callbacks. Why do I need to call Update manually on the AppleAuthManager instance, which is a hint that the plugin does not hook into Unity's update loop for you. What deserialization library does it use by default, with the answer that it uses Unity's default serialization but you can add your own implementation.

And then the submission-time one about the CFBundleIdentifier collision on the macOS App Store.

Taken together, the FAQ is the profile of a plugin that has been through real review submissions, and each answered question corresponds to something a developer would otherwise file an issue about.

Editorial conclusion

Adopt apple-signin-unity if you are shipping a Unity game to the App Store and need Sign in with Apple, since Apple makes it a review requirement when you offer any other social sign-in. Do not adopt it expecting the macOS, tvOS or visionOS builds to be production ready, because the documentation marks all three as experimental. Before you start, read the FAQ entries on credentials revocation and on the missing name and email, since both are Apple behaviours rather than plugin bugs, and set up the Apple capability in Xcode early, because the plugin can only add it programmatically in a PostBuild script.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. lupidan/apple-signin-unity on GitHub
4. README
5. Releases