--- title: "Test apps in developer mode" slug: "test-apps-in-developer-mode" updated: 2026-01-30T18:31:25Z published: 2026-01-30T18:31:25Z canonical: "support.tulip.co/test-apps-in-developer-mode" --- > ## Documentation Index > Fetch the complete documentation index at: https://support.tulip.co/llms.txt > Use this file to discover all available pages before exploring further. # Test apps in developer mode *Use Developer Mode to easily test different scenarios for apps without creating useless Completions and Table data.* In this article, you will learn... - How to use Developer Mode instead of the Tulip Player to test apps - How data is stored in Developer Mode Note Developer Mode is meant to run in Google Chrome. If you want to test the entire experience of using an app (or just one section of it), you probably don't want to download the Tulip Player and use the app just like an operator would use it in production. Instead, you can use a simple testing tool called **Developer Mode** to run through the app using different scenarios- for example, running the app at different Stations or with different operators. Even better, Developer Mode will not log any Completions or update the records within Tables- so there is no need to worry about messing up production data. Here's how to use Developer Mode to test your apps. ## Opening Developer Mode Open up any app with the App Editor, and press the **Test** button in the upper righthand corner. ![](https://cdn.document360.io/7c6ff534-cad3-4fc8-9583-912c4016362f/Images/Documentation/How%20to%20Use%20Developer%20Mode%20To%20Test%20Apps_257247595.png) This will open the app to the **Splash Screen**, which is the default first screen that the operator will see when they open the app for the first time. Press **Begin** on the splash screen to go to step 1 of the app. ## A Tour of Developer Mode The app is displayed in the middle of the screen. This is what the operator sees when they use the app within the Tulip Player in production. On the left side of the screen, there are two panels: - **Session Parameters:** Test the app in different scenarios. - **Live Data:** See the Variables and Record Placeholders as they are updated by the app ## Session Parameters Use the dropdown menus in the top left side of the screen to test the app with different combinations of other features in Tulip. As soon as you update one of the dropdowns, the changes will be reflected in the app running in the middle of the screen. ### Station Change the station where this app will be running. This also changes the connection to any Edge Devices attached to that station. In other words, if you want to test the app with different Edge Devices, attach them to a station and then toggle to the station using the dropdown in the top left. Also, when you change the station, the Player menu will appear on the screen and prompt you to select an app. You can select any app from this screen. ### User Select any active user from your Tulip account. This will change the user that is running the app within the session. It will not change the step. ### Connector Environment Change the version of all connectors that will be used within the app. By default, this is set to the Development Version of connectors. For example, let's say you have an SAP Connector that runs many GET requests, and you want to test the development version of the app with the production version of the connector. This would not affect any production data in SAP. You can toggle the dropdown to "production" to test the production version. To enable multiple connector environments on your account, navigate to the **Connectors** tab via the **Account Settings** page of your instance. Toggle the switch under "Allow Selection of Connector Environment in Developer Mode". ![Toggle Connector Environments.gif](https://cdn.document360.io/7c6ff534-cad3-4fc8-9583-912c4016362f/Images/Documentation/Toggle%20Connector%20Environments.gif) ### Step Navigate between Steps within the app. ## Live Data In the panel on the bottom left of the screen, you can see the live values of all variables and record placeholders. As soon as one of those values is updated in an app, it will be updated in this panel. For example, here is what a record placeholder called "Machine Audit" would look like after a Table Record is loaded into that placeholder: ![](https://cdn.document360.io/7c6ff534-cad3-4fc8-9583-912c4016362f/Images/Documentation/How%20to%20Use%20Developer%20Mode%20To%20Test%20Apps_257260063.png) ## Simulating Production Data within Developer Mode One goal of Developer Mode is to split testing data from production data. Within Developer Mode, all new app Completions and table record updates are stored within the "session", or the tab of Google Chrome that is running Developer Mode. If you close the tab that is running Developer Mode, all app completions and updated Table Records will also disappear- you will not be able to access them in future sessions of Developer Mode. But, this should be helpful in the app testing process- you can load records from Tulip Tables and update them within the session without making any changes to the live tables. You can see all Completion data in the panel at the bottom of the screen. This will update based on the app that is running. You can see the real-time version of Table Records via the Record Placeholder tab on the left side of the screen. These will persist across multiple apps- so if you make changes to a table record in one app, and then open another app within the same session of Developer Mode (the same tab of Chrome), then you can access these updated Table Records. ### Developer Mode Limitations Because Developer Mode splits testing data from production data, there are a few limitations to note that impact assets within your apps. #### Data written to tables won't save. In order to avoid interference with tables used in production, any data that you write to a table in Developer Mode won't save to that table. The table initially mirrors its current state and acts as a copy of the real table. This is why any data written in Developer Mode erases after exiting. #### Aggregations don't update. Since Aggregations are linked to tables, any data written to a table in Developer Mode will not impact your aggregation values. #### Current Date and Time may not reflect the set account timezone. When using data from the App Info -> Current Date and Time selection, Developer Mode will reflect the date and time of the current system rather than the timezone of the account or station. #### Machine timeline widget downtime review is disabled. The **Review Downtime** button in developer mode is disabled. This is because the machine activity table is not mirrored when developer mode opens and being able to edit this table would affect the production data. #### Printing using the system dialog option is not functional. Using the Print Steps action in a trigger to print a specific step opens the system print dialog window, which is not functional in developer mode. ### Notes on User Fields You must select an individual user via the dropdown in the top left of the screen in order to access an individual user's User Fields. Once you do this, you will be updating the live version of their User Fields, unlike Table Records. So, if you want to test the ability to update User Fields via app logic, we recommend you select the fake "John Smith" user that comes with every account. ## Further Reading - [How to Troubleshoot App Logic](https://support.tulip.co/docs/how-to-troubleshoot-logic-in-the-app-editor) **Developer Mode** **Developer Mode**is a dedicated interface to test your applications. Dev mode doesn't write to **Tables**or create **Completions**so production data isn't impacted. **App Completion** **App Completions**are a mechanism to store immutable data from a Tulip app. When an app is completed, all **Variable's**current values will be stored in the app completions tab.****This completion data can be analyzed in **Analytics.** By default, after a Completion users will be brought back to the **Begin Screen**of your application. This behavior can be adjusted with other **Transition**types. **Tulip Tables** **Tulip Tables** are a global location to store your production data. **Tables** are made up of **Records** (rows). A single can be accessed from multiple apps or stations at the same time. ![](https://cdn.document360.io/7c6ff534-cad3-4fc8-9583-912c4016362f/Images/Documentation/Tulip%20Tables%20Overview%20-%20Feature%20Overview(1).gif) **Tulip Player** **Tulip Player** is the Windows/Mac executable program where users can run Tulip apps. Tulip player allows you to create a more seamless user experience by removing the need for a web browser and allows increased IT controls. **Station** **Stations**are a digital representation of a physical place or device in your facility. Stations are 1:1 with **Interfaces (display devices)** running Tulip Player, but Stations can also be assigned **Edge Devices,**Tulip Vision Camera Configurations, Machines,****and more. **Tulip Tables** **Tulip Tables**are a global location to store your production data. Tables are made up of Records (rows). A single can be accessed from multiple apps or stations at the same time. ![](https://cdn.document360.io/7c6ff534-cad3-4fc8-9583-912c4016362f/Images/Documentation/Tulip%20Tables%20Overview%20-%20Feature%20Overview.gif) **App Editor** The web interface used for building applications. Where you design a user interface, add logic, and connect your applications to **Tables**. ![](https://cdn.document360.io/7c6ff534-cad3-4fc8-9583-912c4016362f/Images/Documentation/Screen%20Shot%202022-09-13%20at%207.50.23%20AM.png) **Variables** **Variables**are a location to store app information. Variables have a specific type that must match the contents they can store. Variables are only accessible within a single application and are cleared when the app is restarted or completed. **Table Record Placeholder** A **Table Record Placeholder** is a reference to a row in a **Tulip Table**. Table Records can be created either from the Table UI or from an App Trigger. **Edge Devices** **Edge Devices** are any hardware intended to connect physical things to the cloud. This can include entirely mechanical devices, older machines without network functionality, PLCs, and more. Tulip sells the **Edge IO** and **Edge MC** that interface directly into **Triggers** in a breeze, but Tulip can also support other Edge Devices. **User** **User**is a Tulip Datatype. Users represent a single user in your Tulip **Instance.**User****variables include attributes like **Badge Id, Name, and Shift.** **Connectors** **Connectors** enable real-time connectivity between your Tulip solution and a transactional system (e.g. an ERP). The output of a Connector Function can be used in Tulip Apps, Automations, and Functions. - **HTTP Connectors** utilize HTTP API endpoints. - **SQL Connectors** can enable connectivity with certain SQL databases. - **MQTT Connectors** can connect to MQTT brokers for machine monitoring. ![](https://cdn.document360.io/7c6ff534-cad3-4fc8-9583-912c4016362f/Images/Documentation/connector.gif) **Development Version** The **Dev Version**of a Tulip app is the work-in-progress of your application after an app has been published. If a **Station**is assigned to run the Development version of an application, it will see live changes as they are made in the app editor. Generally, **Stations**running in production will be running the **Published Version**of an Application. **Steps** A view your users will see within an application. **Steps** can be viewed chronologically or in whatever order best fits your process. Steps can be grouped into **Step Groups**to manage and organize your app Steps. **Table Record** A **Table Record** is a reference to a row in a **Tulip Table**. Table Records can be created either from the Table UI or from with an App Trigger. To edit a record it must be loaded into a **Table Record Placeholder.** **Table Aggregations** **Aggregations**are calculations on top of table data, this can include things like the average value of a column within a **Tulip Table.**