Get to know our frameworks

Select an app template built on your preferred framework.

Build apps on our native app editor. Use drag and drop elements, Velo code and Wix APIs to develop custom features.

Streamline your app development process with the Wix CLI. Get a familiar developer experience with minimal setup and configuration.

Take full control over your app's tech stack, deployment, and hosting.

App templates

Wix Blocks templates

Wix CLI templates

Self-hosted templates

Kickstart your app development with templates built on your preferred Wix developer tool. Browse templates for practical foundation and get to know the Wix ecosystem.

Wix App Templates for Developers

This example apps can be used as a starting point for building your own app, for concrete examples of how to use Wix framework, or for inspiration.

Choose a template.<0 />Build an app.

Browse by:

How to build it step by step:

This template is built with:

Read how this template was built, step by step.

How we built this template

Deployment instructions:

Choose a package manager and run the command in your terminal.

Copy command

Before you get started, make sure you have the following:

Prerequisite steps

Get started with Wix CLI

Begin by setting up your Next.js project with your preferred hosting platform.

Select your hosting service

Start the deployment flow and set up your template repo on Netlify. After you finish set up, come back here and add your Netlify custom domain.

Copy the code from our Git repo to deploy your app on any platform that supports Next.js.

Start the deployment flow and set up your template repo on Vercel. After you finish set up, come back here and add your Vercel generated URL.

Add the base URL and give your app a name.

App details

Go to the app dashboard and test your app to ensure a smooth integration within the Wix ecosystem. <0>Learn more about app checks and testing</0>

Define your environment

Terminal

Related templates

Note

Warning

Your app name will be used as the namespace suffix.

Name your app to generate a namespace. This lets you refer to your app in code later on.

Go Headless

Build Apps

Client

API Preview

Develop Websites

REST

Velo

GraphQL (Alpha)

# Test Site Considerations

When using [test sites](fallback::https://support.wix.com/en/article/about-test-sites) on a site with code, it is important to understand how the different versions of your site work with the following features.

## Database collections

When you have both a published revision and a test site revision of your site, you still only have 1 version of your site's database collections that both revisions access. That means, when you perform a data operation such as updating an item from either your published or test site revision, the change affects both of your site revisions.

While your data does not change based on the site revision, your database [schema](fallback::https://support.wix.com/en/article/about-database-collection-schemas) may differ from revision to revision. This means that a field that exists in the schema in the test site revision may not exist in the schema in the published revision. Because collection data itself is maintained regardless of whether a field is in the schema, this should not affect the functionality of your site revisions.

## Backend events

Currently your site must be published at least once for the version of the event handler in your test site to run when a [backend event](resourceId::595cc6cb-bc5d-484b-8f70-fac8a3abae87*fallback::https://github.com/wix-private/developer-docs/blob/master/velo-articles/Coding%20with%20Velo/Velo%20Backend%20Events.md*original::../Coding%20with%20Velo/Velo%20Backend%20Events.md) on your test site is triggered. 

For example, let's say you have a `onNewOrder` event that handles new events in your store. In your published site your event handler sends an email to `p@supplier.com` for each order received, but in your test site the same event handler sends an email to `rc@supplier.com`. Whenever a site visitor places an order on your test site, an email is sent to `rc@supplier.com`.

If you define a backend event handler in your test site revision without ever publishing the site, messages in backend code are not logged to the browser's console and the event handler never runs.

Keep in mind that messages in backend code are not logged to the browser's console. 

## Scheduled jobs

When you [schedule jobs](fallback::https://dev.wix.com/docs/velo/articles/getting-started/schedule-jobs) in your site's backend, only the jobs scheduled in your published site revision run. The jobs scheduled in your test site revision do not run.

## Service plugins

To use [service plugins](resourceId::1faa11b0-b2be-4d78-a100-8016cf8b1fb8*fallback::https://github.com/wix-private/developer-docs/blob/master/velo-articles/Coding%20with%20Velo/Custom%20App%20Extensions%20Using%20SPIs.md*original::../Coding%20with%20Velo/Custom%20App%20Extensions%20Using%20SPIs.md) in your test site revision, make sure to publish your site once after implementing the plugin. After that first initial publish, the service plugin implementation works on your test site revision. 

If the site hasn't been published, the published revision's implementation runs. Neither the published revision nor the test site revision runs your latest service plugin code.

## The Realtime API

Currently the [Realtime API](fallback::https://dev.wix.com/docs/velo/api-reference/wix-realtime-backend/introduction) is partially supported for test sites. Keep the following considerations in mind: 

- [realtime_check_permissions](fallback::https://dev.wix.com/docs/velo/api-reference/wix-realtime-backend/realtime-check-permission) and [PermissionsRouter](fallback::https://dev.wix.com/docs/velo/api-reference/wix-realtime-backend/permissions-router/introduction) are not supported on test site revisions. 

- When publishing/subscribing to messages on a channel in both test site and published revisions, both sites receive messages from both versions. This means that the published site receives the messages from both the published site's backend and the test site's backend. Similarly, the test site receives the messages from the test site's backend and the published site's backend. It isn't possible to add new message types on the same channel with the aim to test it only in the test site revision because the published revision also receives the new message. This might cause unexpected behavior.