The publication lifecycle

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.

​

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 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 or use the chat widget in the bottom right of the screen to request a development workspace.

​

Developing as a team

To use attio dev with an app, a developer must be a member of the developer account that contains the app. Add other developers to your developer account in the Developer console. A member can use attio dev with all apps in the developer account. You cannot add a developer to one app only. More than one member can use attio dev with the same app at the same time. You can also use a copy of the app. Use a copy when:

• You are not a member of the developer account.
• Users have installed the app, and your app code changes make it necessary to change a setting in the Developer console, for example a connection.

Changes to settings in the Developer console have an effect on the production app immediately. For example, if you add a workspace connection to the production app, users see a field to add the connection. But the production code does not use the connection. To make a copy of an app, do these steps:

1. In the Developer console, make a new app in your developer account. Give the app a different slug, for example my-app-copy.
2. Clone the repository of the original app.
3. Install the dependencies:
   npm install
   
4. Start the development server with the slug of your new app:
   npm run dev -- --app my-app-copy
   

​

API keys

If your app interacts with Attio’s REST API and only needs access to a single workspace, you can use API keys 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, 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 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 for more information.

​

Publishing to the Attio App Store

Publishing makes your app available to all Attio users through the in-product and public 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, code, logos, and App Store images. See publishing to the App Store to learn more.

​

Summary