> ## Documentation Index
> Fetch the complete documentation index at: https://docs.attio.com/llms.txt
> Use this file to discover all available pages before exploring further.

# The publication lifecycle

> Understand how to develop your app and share it with users

This guide will walk you through the three phases of app development: developing, sharing privately, and publishing. By the end of this guide, you'll know exactly how to set up the ideal development environment and share your app with users when you're ready to go live.

<Steps>
  <Step title="Develop">
    Build and test your app in an isolated development workspace.
  </Step>

  <Step title="Share privately">
    Share your app privately with a small group of users.
  </Step>

  <Step title="Publish">
    Submit your app for review to make it available to all users through the Attio App Store.
  </Step>
</Steps>

## Who is your app for?

Not all apps need to go through all three phases. To determine which phases are relevant for your app, you should first ask yourself who your app is for.

Attio apps are generally built for one of the following audiences:

* **Internal users only** - You want to extend Attio with specific functionality for one or only a handful of workspaces. Ideal for internal tools and custom workflows.
* **All workspaces** - You want your app to be used by any workspace and list it publicly in the Attio App Store. Ideal for public integrations aimed at a wide audience.

Both internal and public apps should set up an isolated development environment.

Internal apps should share access to a production version of the app with a single or select few workspaces. They do not require review from the Attio team.

Public apps need to prepare a high-quality App Store listing and are subject to review by the Attio team. Once approved, any workspace can install the app from the App Store. Public apps may also use preview versions to test functionality with a small group of users before publication.

## Developing your app

How to develop and test your app differs depending on which features of the Attio platform it uses.

### Development mode

If you are using [the App SDK](/sdk/guides/creating-an-app) and the `attio` CLI, you can run your app locally in development mode using the `attio dev` command. This pushes local changes to a specific Attio workspace in realtime. Updates will be available immediately to all users in the workspace and will persist after the dev command is stopped.

We recommend that development mode is used for development and testing purposes only. For apps you wish to use in production, we recommend building the app in a development workspace and then using private invites (see below) to share with your main production workspace(s).

We recommend that each developer use an isolated development workspace. As app functionality exists globally across the workspace, two instances of `attio dev` running simultaneously in the same workspace may result in unexpected behavior.

We are happy to provide your team with development workspaces as needed. Please reach out to [support@attio.com](mailto:support@attio.com) or use the chat widget in the bottom right of the screen to request a development workspace.

### API keys

If your app interacts with Attio's REST API and only needs access to a single workspace, you can use [API keys](/rest-api/guides/authentication#api-key) to authenticate your requests. This is the simplest option for internal apps.

During development, generate an API key for an isolated test workspace. When you're ready to use the app in production, generate a separate API key for your production workspace.

### External infrastructure

If your app runs on your own infrastructure and makes requests to Attio's REST API, you may want to configure separate development, staging, and production environments within your service.

## Sharing your app privately

### Private invites

If using the [App SDK](/sdk/guides/creating-an-app), you can share an unpublished version of your app with specific workspaces using a private link.

Internal apps should use private invites to share finalized versions of their app with specific workspaces. Public apps can use private invites to share preview versions with alpha users before publication.

As apps shared via private invite links have not been approved by the Attio team, users will see a warning before installing the app.

See [private invites](/share/private-invites) for more information.

### OAuth flows for unpublished apps

If your app uses OAuth, users can install it via the standard OAuth flow even before the app has been published. However, they will see a warning that the app has not yet been approved by the Attio team.

To remove these warnings, submit your app for review. See [publishing to the App Store](/share/publishing-to-the-app-store) for more information.

## Publishing to the Attio App Store

Publishing makes your app available to all Attio users through the [in-product](https://app.attio.com/_/settings/apps) and [public](https://attio.com/apps) App Stores.

This works for both OAuth/API apps and App SDK apps. Publishing requires a review from the Attio team, which can take up to 1 week.

Before submitting, you'll need to meet our requirements for [listing content](/share/app-listings), [code](/share/code-review), [logos](/share/logos), and [App Store images](/share/listing-images). See [publishing to the App Store](/share/publishing-to-the-app-store) to learn more.

## Summary

| Feature  | Audience | Development usage             | Private usage      | Public usage           | Review |
| -------- | -------- | ----------------------------- | ------------------ | ---------------------- | ------ |
| App SDK  | Internal | Development mode              | Private invites    | n/a                    | No     |
| App SDK  | Public   | Development mode              | Private invites    | Install from App Store | Yes    |
| REST API | Internal | API keys                      | API keys           | n/a                    | No     |
| REST API | Public   | OAuth (unapproved) / API keys | OAuth (unapproved) | OAuth (approved)       | Yes    |
