---
title: "Sign In"
description: "Choose an authentication flow and test it without blocking development."
---
Add sign-in when the app needs to recognize a person, synchronize their information, or protect private data. For an Apple-platform app, Sign in with Apple usually provides the smoothest production experience.

## Start with Sign in with Apple

Sign in with Apple lets people use an account they already trust instead of creating and remembering another password. It reduces typing, supports Apple’s privacy controls, and feels native on iPhone, iPad, and Mac.

```
Add Sign in with Apple before the private part of the app.

Keep the person signed in between launches. After sign-in, open their dashboard.
Include a sign-out action and an in-app account deletion flow.
```

## Connect identity to app data

Signing in tells the app who the person is. Your backend must use that identity when it reads or writes profiles, projects, uploads, and other private records. Make ownership rules explicit and test them with two different accounts.

-   Keep user-owned records private by default.
-   Restore the session safely when the app launches again.
-   Handle cancellation, connection failures, and expired sessions.
-   Provide sign-out and account deletion inside the app.

## Test Apple sign-in on a real device

Treat a physical iPhone or iPad as the reliable test environment for Sign in with Apple. Test the first sign-in, cancellation, relaunch, sign-out, and a second sign-in. Confirm that the correct user data returns after the app restarts.

:::note
A simulator is useful for most interface work, but it should not be the final proof that Apple authentication works. Always complete the sign-in flow on a real device before TestFlight or App Store submission.
:::

## Add a simulator-only skip button

If Apple sign-in blocks day-to-day simulator testing, ask Superapp for a temporary Skip sign-in button. It should create a predictable mock user so you can keep building screens beyond authentication.

```
For simulator development, add a Skip sign-in button that opens the app as a local mock user.

Show it only in debug simulator builds. It must never appear in TestFlight, App Store builds,
or connect the mock user to production data.
```

:::tip
Compile the skip path out of release builds. Hiding the button visually is not enough—the bypass itself must be unavailable in production.
:::

## Email and password sign-in

Traditional email and password authentication is easier to exercise in the simulator and does not depend on the native Apple sign-in sheet. It can be useful when the audience cannot use Apple accounts or the same credentials must work outside Apple platforms.

The tradeoff is a heavier user experience: people must create a password, confirm their email, recover forgotten credentials, and trust another service with account security. Use it when the product requires it, not merely because it is simpler to test.

### Sign in with Apple

_Recommended_

Less typing and a more familiar, private experience. Verify it on a real device.

### Email and password

_Alternative_

Easier to test anywhere, but adds sign-up, recovery, and password-management friction.

## Before release

-   Remove every debug authentication bypass from the release build.
-   Test with a new account and a returning account on a physical device.
-   Verify that signing out prevents access to private screens and cached data.
-   Confirm that deleting an account handles its associated data as promised.

:::note
If sign-in is not required for the app’s core value, consider letting people explore first and asking them to sign in only when they save, sync, or share something.
:::