Skip to main content

Publishing Apps

Publishing an app in DynaMaker is straightforward. In this tutorial you learn the basics.

Use any app you have built that already has a working User Interface (UI), no matter how polished it is. This tutorial does not require coding, only a few clicks.

You complete three steps:

  1. Prepare app
  2. Publish app
  3. Understand publishment

1. Prepare App​

To publish an app you need:

A. Working App​

First you need the UI working. It can be a standalone DynaMaker app or integrated with other software. In this example the staircase app from the Assemblies tutorial is used:

B. Subscription​

You need at least one DynaMaker subscription:

  1. Go to your team dashboard (where all apps are listed).
  2. In settings (⚙️), open Subscriptions.
  3. Make sure you have at least one subscription (click Handle Subscriptions to see pricing details).

The example above has:

  • 1 Pro subscription, with 1 app published (i.e. Conveyors).
  • 2 Standard subscriptions, with just 1 app published (i.e. Standard) and therefore a slot available.
  • 0 Lite subscriptions.

Publishing an app allows any user (with access) to open the autogenerated URL. For the staircase app the URL is:

info

Essentially: 1 published app = 1 DynaMaker subscription. However you can have as many unpublished apps as you want.

2. Publish App​

Now publish your first DynaMaker app. As a best practice, first publish to Test, then to Production:

A. Test Site​

Publish to the Test site:

  1. In your app dashboard, click Publish/Publish to web.
  2. In the Publish to web popup, click Assign Subscription when you publish the publish for the very 1st time.
  3. Click Publish to Test.

  1. A new browser tab opens with the published app. Note the word "test" in the URL before the app ID SqyYLALsv4Q:
  1. The dashboard updates and the Test site button is now enabled in Publish. If you hover over the timestamps of the User Interface, you see the exact date when the last publishment took place:

B. Production Site​

After testing and fixing any bugs, publish to Production so customers can start configuring staircases:

  1. Click Publish/Publish to web.
  2. Notice that you do not need to assign an application subscription again (this is only needed once).
  3. Enter the name of the app in the input field: Tutorial 7.
  4. Click Publish to Production.

  1. A new browser tab opens with the published app. The word "test" is no longer in the URL:

You now have a Test and Production environment for the app. Whenever you want to update the published app, publish to the corresponding site to override the version there.

3. Understand Publishment​

Your application can exist in three environments:

  • Editors: what you as an engineer work with continuously, and what the user never sees.
  • Test site: published app meant to show experimental changes, typically for user testing.
  • Production site: published (error-free) app meant to be used by the user, it must be polished.

The typical workflow of publishing an app (see picture above) is:

  1. Building App: Engineer builds the app based on requirements (editors v1).
  2. Implementation: Engineer adds the feature (editors v1 → v2).
  3. Internal Testing: publish to the Test site (test v1) and share the URL with e.g. Sales for feedback.
  4. Bug Fixing & Improvements: if Sales reports issues, engineer fixes them, improves code (editors v2 → v3 → v4), and republishes to Test site (test v2) for re-review.
  5. Approval & Release: once approved, publish to Production site (prod v1) and give Sales the customer-ready link.
  6. Next Cycle: Sales gathers new feature requests while customers use the current version; engineer works on them in editors (v4 → v5), then repeats the cycle.

This is how the published app looks when embedded:


Have you found bugs and have no clue where they are coming from? In the next tutorial (Debugging) you learn how to find, isolate, and fix errors yourself by debugging your code.