How to Add Apple Login (Sign in with Apple) to a Mobile App: A Practical Guide for Nigerian Businesses

What Sign in with Apple is and when Apple requires it

Sign in with Apple is Apple's federated login service. The user authenticates with Face ID, Touch ID or their device passcode, Apple confirms their identity, and your app receives a signed identity token plus a stable user identifier. The user can choose to share their real email address or a private relay address that forwards to their inbox. Two facts shape every decision about it:

• It is a requirement in specific cases, not a general one. As of 2026, App Review Guideline 4.8 (Login Services) says that apps using a third-party or social login service (Google, Facebook, X and similar) to set up or authenticate a user's primary account must also offer an option that limits data collection to name and email, lets users keep their email private, and does not collect interaction data for advertising without consent. Sign in with Apple satisfies this, and in practice it is the option most teams choose. Apps that only use their own email-and-password or phone-and-OTP accounts are not obliged to add it. Apple revises the guideline text from time to time, so verify the current wording before you rely on this summary.
• It only works from iOS 13 onwards and requires an Apple Developer Program membership. That membership is a yearly US-dollar fee (historically US$99; verify the current amount) which a Nigerian business will already be paying if it publishes on the App Store.

The difference between Apple login and Google login from an implementation point of view is small: both give you a signed token to verify and a stable user ID to store. The differences that matter are the private relay email, the fact that Apple only sends the user's name and email once, and the token-revocation duty when a user deletes their account.

Should your app support Apple login? A decision framework

For a Nigerian business app, the decision usually comes down to three questions.

Two further points help the decision. Phone-first accounts are common in Nigeria for good reasons: OTP by SMS or WhatsApp gives you a verified phone number, which is what your sales and support team will use, whereas Apple login gives you an email (possibly a relay address) and no phone number. And avoid offering five login methods; each one is a support burden and a source of duplicate accounts. A sensible pattern for a Nigerian consumer app is phone number plus OTP as the primary method, with Sign in with Apple and Google as optional shortcuts linked to the same account.

What you need before you start

Have these ready before a developer starts the integration. Several of them sit with the business, not the developer.

• An active Apple Developer Program membership owned by the business, with the developer given the appropriate role in App Store Connect.
• The App ID for your app with the Sign in with Apple capability enabled in Certificates, Identifiers and Profiles.
• If you will support Android or the web: a Services ID (Apple's identifier for non-iOS clients), a verified domain, and a return URL on that domain.
• A Sign in with Apple private key (a .p8 file) with its Key ID, plus your Team ID. Your backend uses these to create a client secret when it talks to Apple's token endpoint.
• A backend able to fetch Apple's public keys and verify JSON Web Tokens (JWTs). Firebase Authentication, Auth0, Supabase and most auth libraries do this for you.
• A decision on your account model: what identifies a user (phone, email, Apple ID, Google ID) and how you link a new Apple login to an existing customer record.
• A privacy policy and a working in-app account deletion flow, both of which App Review checks.

Keep the .p8 key on the server only. It should never be shipped inside the app.

Step-by-step: adding Sign in with Apple to an iOS app

The steps below describe a native Swift implementation. Flutter (for example the sign_in_with_apple package) and React Native (a community Apple authentication library) wrap the same system APIs, so the sequence is identical; only the syntax changes.

1. Enable the capability in Xcode. In the target's Signing and Capabilities tab, add Sign in with Apple. Xcode updates the entitlements file and, with automatic signing, the provisioning profile.
2. Add the button. Use ASAuthorizationAppleIDButton from the AuthenticationServices framework. Apple's Human Interface Guidelines specify the button's appearance and require it to be at least as prominent as other sign-in buttons. Do not draw your own logo.
3. Request the scopes you need. Create an ASAuthorizationAppleIDRequest and ask for fullName and email. Also generate a random nonce, hash it, and attach it to the request; your backend will check that the same nonce appears in the token, which prevents replay attacks.
4. Present the authorisation controller. ASAuthorizationController shows Apple's sheet. The user confirms with Face ID or Touch ID and chooses whether to share or hide their email.
5. Handle the result. On success you receive an ASAuthorizationAppleIDCredential containing the user identifier (a stable string unique to your team), an identity token (a JWT), an authorisation code, and, on the first authorisation only, the user's name and email.
6. Send the identity token and authorisation code to your backend. Do not trust anything in the app; the backend verifies and creates the session.
7. Store the name and email immediately. Apple sends them only the first time the user authorises your app. If your backend call fails and you lose them, the user will have to revoke access in their Apple ID settings and sign in again before Apple sends them a second time.
8. Check credential state on launch and test on a physical device. ASAuthorizationAppleIDProvider's getCredentialState tells you whether the user has revoked access, in which case sign them out. Test with a real Apple ID, with and without Hide My Email; the simulator behaves differently in some iOS versions.

Backend verification: the part you cannot skip

A surprising number of apps accept the Apple credential in the app and treat the user as logged in without any server check. That is not authentication; it is trusting whatever the phone sends. The backend must do the following.

1. Fetch Apple's public keys from Apple's JSON Web Key Set endpoint and cache them.
2. Verify the identity token's signature using the key whose ID matches the token header.
3. Check the claims: the issuer must be Apple's ID service, the audience must be your bundle ID (or your Services ID for web and Android sign-ins), the token must not be expired, and the nonce must match the one the app generated.
4. Read the subject claim. This is the stable Apple user identifier. Look it up in your users table.
5. Create or link the account. If the identifier is new, create a user. If an account with the same verified email exists, follow your linking policy (see below). Issue your own session token or JWT to the app.
6. Optionally exchange the authorisation code at Apple's token endpoint for a refresh token, using a client secret JWT signed with your .p8 key. You need this refresh token later to revoke the user's tokens when they delete their account.

If you use Firebase Authentication, Supabase Auth, Auth0 or a similar service, steps 1 to 4 are handled for you and you receive a verified user record. You still own step 5 and the account-linking logic.

Supporting Apple login on Android and the web

Apple login is not confined to iPhones. Apple provides Sign in with Apple JS for web pages and a web-based OAuth flow that Android apps can use through a browser tab; Firebase Authentication supports this on Android out of the box. On non-Apple platforms you authenticate against a Services ID rather than the bundle ID (so your backend must accept either as the audience claim), Apple redirects to a return URL on a verified domain, and the experience is a browser sheet rather than a Face ID prompt. Most Nigerian Android users will never choose it. Support it only if a meaningful share of customers sign up on iPhone and later switch devices or use your web app. For most Nigerian business apps the pragmatic scope is Apple login on iOS, Google login on both platforms, and phone-and-OTP everywhere, all linked to one account.

Hide My Email, account linking and account deletion

These three topics are where Apple login differs most from other login methods, and where support problems originate.

Hide My Email relay addresses

When a user hides their email, you receive an address on Apple's private relay domain that forwards to their real inbox. Consequences:

• Emails you send to that address only arrive if your sending domain and sender address are registered with Apple's Private Email Relay Service in the developer portal. Register your transactional email domain before launch.
• Support staff will see unfamiliar relay addresses in the CRM. Train them that the address is valid and that the customer may not recognise it if asked to confirm it.
• The relay address is unique to your app, so it cannot be used to match the same person across your other systems. Treat it as an identifier for this app only.

Account linking

Suppose a customer signed up last year with their email and password, and today taps Sign in with Apple using the same email. Your options are:

• Auto-link on verified email. Apple marks whether the email is verified; if it is and matches an existing account, link them. This is convenient but must be limited to verified emails to avoid account takeover.
• Prompt to link. Ask the user to enter their existing password once, then link. Safer, slightly more friction.
• Never link automatically. Creates duplicate accounts and confused customers; avoid.

Relay addresses never match an existing email, so a user who hides their email and later tries to log in with a password will have two accounts unless you offer a "link accounts" option in settings. Design that screen from the start.

Account deletion and token revocation

App Review Guideline 5.1.1 requires apps that support account creation to let users delete their account from within the app. For apps using Sign in with Apple, Apple additionally expects you to revoke the user's Sign in with Apple tokens through its REST API when the account is deleted. Practically, that means your backend must have stored the refresh token from the authorisation-code exchange, and your deletion flow must call Apple's revoke endpoint before removing the user record. Build this before submission; missing it is a common rejection reason.

What changes for Nigerian businesses

For a Nigerian business, the technical steps are the same as anywhere else. The commercial and operational context is different in five ways.

• Android dominates, but iPhone users matter disproportionately. Many Nigerian apps see a smaller share of iOS installs, yet those users are often corporate customers, premium buyers or diaspora relatives paying for family. A frictionless iOS sign-up is worth the few days of work when those are the customers you most want to keep.
• Phone numbers drive Nigerian operations. Sales follow-up, delivery confirmation and dispute resolution happen on WhatsApp and by phone. Apple login provides no phone number. Add a verified phone-number step immediately after the first Apple sign-in for any app that ships goods, books services or handles money.
• Relay emails complicate customer communication. If your team uses a shared Gmail or a marketing tool that is not on your registered domain, emails to relay addresses will silently fail. Send transactional email from a domain you control and register it with Apple.
• Dollar costs are recurring, and NDPA applies. The Developer Program fee and any hosted authentication service beyond its free tier are billed in US dollars, which move with the naira. The Nigeria Data Protection Act 2023 governs the identifiers, names and emails you collect at login: keep them minimal, state the purpose in your privacy policy, honour deletion requests, and verify your obligations with the Nigeria Data Protection Commission's current guidance.

Example (hypothetical): a Lagos gym membership app

Example (hypothetical): a chain of three fitness centres in Lekki, Ikeja and Victoria Island launches a membership app for class bookings and renewals. The Android version shipped with phone-and-OTP plus Google login. Six weeks later, the iOS build is rejected under Guideline 4.8 because Google login is offered without an equivalent option. The team adds Sign in with Apple in one sprint:

• Day 1: enable the capability, add the button, request name and email, generate the nonce.
• Days 2 to 3: extend the backend (already verifying Google tokens) to fetch Apple's keys, verify Apple tokens, and link on verified email; store refresh tokens for later revocation.
• Day 4: add a "confirm your phone number" step after first Apple sign-in, because the front desk calls members about class changes; register the gym's transactional email domain with Apple's relay service.
• Day 5: extend the account-deletion flow to call Apple's revoke endpoint; test with Hide My Email on two physical iPhones; resubmit.

The lesson is not the five days. It is that the account model, phone-number step and deletion flow were already designed to accommodate a second login provider, so the addition was routine rather than a rebuild.

How much does it cost to add Apple login?

Apple login is a feature-level cost inside a wider app budget. The figures below are indicative 2026 ranges; actual quotes vary with scope, vendor and exchange rate, and you should compare two or three written quotations on identical scope.

Recurring costs: the Apple Developer Program fee (yearly, in US dollars), and any hosted authentication service usage above its free tier. When Apple login is part of a new build, most agencies price it within the authentication module rather than as a separate line; ask for it to be listed so you can see what is included.

Mistakes to avoid

• Verifying the token only in the app. Without server-side signature and audience checks, anyone can forge a login request. Always verify on the backend.
• Losing the name and email on first sign-in. Persist them before doing anything else, and handle the case where a user reinstalls after an earlier failed sign-up.
• Auto-linking on unverified email. This allows someone to claim an existing account by using a matching email at a different provider. Link only on verified emails or after password confirmation.
• Emailing relay addresses from an unregistered domain. Receipts and OTP emails vanish without error. Register your sending domain with Apple's relay service.
• Skipping token revocation on account deletion. It is both a guideline expectation and a courtesy: it removes your app from the user's Apple ID settings.
• Making Apple login the only method. Customers who move to Android or use your web app are locked out. Keep phone-and-OTP or email as a universal method.
• Shipping the .p8 private key in the app bundle or restyling the Apple button. The key belongs on the server in a secrets manager; the button must follow Apple's published design, which reviewers check.

Conclusion

Adding Apple login is a bounded piece of work: enable the capability, add the system button, verify the identity token on your backend, and link the result to your account model. The decisions that deserve a business owner's attention are whether it is required for your iOS build, how you will capture a phone number afterwards, how relay emails will reach your CRM and email tools, and whether your account-deletion flow revokes Apple tokens. Get those four right and the feature is a few developer-days; get them wrong and it becomes a recurring source of App Review rejections and confused customers. If you are building or extending an app that needs Apple, Google and phone-based sign-in working together on one customer record, Linestech develops Android and iOS apps for Nigerian businesses and can design the authentication and account-linking approach alongside the rest of your product.

Frequently asked questions

Is Sign in with Apple mandatory for every iOS app?

No. It is required, as of 2026, when an app uses a third-party or social login such as Google or Facebook to set up the user's primary account and does not offer another option meeting Apple's privacy criteria. Apps that use only their own email, password or phone-OTP accounts are not required to add it. Verify the current wording of App Review Guideline 4.8.

Can I add Apple login to a Flutter or React Native app?

Yes. Both ecosystems have well-maintained packages that wrap Apple's AuthenticationServices framework on iOS and the web-based flow on Android. Firebase Authentication also supports Apple as a provider across platforms. The backend verification and account-linking work is the same regardless of the framework.

Why did my backend receive no email or name from Apple?

Apple sends the user's name and email only during the first authorisation for your app. If the first attempt failed to save them, later sign-ins will not include them. The user must go to Settings, open their Apple ID, choose Sign in with Apple, remove your app, and sign in again.

What is a private relay email and can I reply to it?

It is an address on Apple's relay domain that forwards to the user's real inbox. You can email it, but only from sender domains and addresses you have registered with Apple's Private Email Relay Service in the developer portal. Unregistered senders are dropped.

Does Apple login give me the customer's phone number?

No. Sign in with Apple provides a stable user identifier and, on first sign-in, the name and email. If your Nigerian business needs a phone number for WhatsApp or delivery calls, add a verified phone-number step after sign-in and explain why you need it.

What happens if a user revokes my app's access in their Apple ID settings?

Your app should detect it. On launch, check the credential state through Apple's API; if it is revoked, sign the user out locally and ask them to sign in again. Your backend records remain until the user deletes their account.

Sources and further reading

Figures, platform rules and regulations change. These are the primary references behind this article and the places to check before you act on it.

• Nigeria Data Protection Commission (NDPC)
• Apple Developer Program
• MDN Web Docs — web platform reference
• Firebase documentation
• Node.js documentation