Skip to main content

Applet Development Workflow

You do not need to generate a native deployment app every time you make a code change. Smart Builder is only the final step — used once you are ready to deploy to production. Everything before that point — developing, testing, uploading new applet versions, assigning them to devices — is free and does not count against your build quota.

Key takeaway

Uploading applet versions via CLI or REST API is unlimited and free. Only generating native apps through Smart Builder consumes your build quota.

Development Lifecycle Overview

The diagram below shows the complete workflow. The Development Loop is where you spend most of your time — and it is entirely free to repeat as many times as needed.

Step-by-Step Development Flow

1. Set Up Your Project

Install the signageOS CLI and scaffold a new applet:

npm install @signageos/cli -g
sos applet generate

Or integrate the signageOS JS SDK into your existing web application.

2. Develop and Build Locally

Write your applet code using your preferred editor and framework. Build the applet when ready to test:

npm run build

3. Test in the Emulator

Run the local development server with the built-in Emulator. This simulates a signageOS device directly in your browser — no hardware required:

npm run start

The emulator is available at http://localhost:8090 by default. Source file changes are watched and reloaded automatically.

4. Upload to signageOS

Once your applet works in the emulator, upload it to signageOS. This creates a new applet version — identified by the version field in your package.json:

npm run upload
info

You can upload as many applet versions as you need. Each upload creates or overwrites a draft version. This does not consume your build quota.

5. Test on Real Devices

Deploy your uploaded applet version to physical test devices using CloudControl Timings. This lets you verify behavior on real hardware and different platforms — without generating a native app.

For rapid local debugging, you can also connect a device directly via CLI with hot-reload support:

sos device connect --device-uid <deviceUid> --hot-reload

6. Iterate

Repeat steps 2–5 as many times as needed. Create as many applet versions and iterations as your development process requires. Every upload, every version, every assignment to a test device is free.

7. Generate Native App with Smart Builder (Production)

When you are satisfied with your applet and ready to deploy to production, go to Smart Builder and generate the native deployment app for your target platforms.

This is the only step that counts against your build quota. Read more about Smart Builder and deployment options.

warning

Do not use Smart Builder for testing iterations. It is designed for final production deployment only.

CI/CD Integration

The signageOS CLI and REST API are designed to integrate into your existing CI/CD pipelines. You can fully automate the development loop — from building and testing to uploading applet versions and assigning them to test devices — without any manual steps.

Key Capabilities

  • Non-interactive CLI: Use the --yes flag with CLI commands to skip confirmation prompts, making them safe to run in automated pipelines.
  • REST API: Use the signageOS REST API for programmatic applet management, version uploads, and device assignments.
  • Applet versioning: Automate version bumps in package.json as part of your pipeline to track each build.

Pipeline Concept

The following diagram illustrates how signageOS fits into a typical CI/CD workflow. Adapt it to your specific CI platform and tooling:

Example: Automated Upload in a Pipeline

# Install CLI
npm install @signageos/cli -g

# Build the applet
npm run build

# Upload to signageOS (non-interactive)
sos applet upload --yes

The --yes flag ensures no interactive prompts block your pipeline. Combine this with your existing test runners, linters, and quality gates — signageOS does not require any changes to your testing strategy.

Understanding Build Quota

Do development uploads count against my quota?

No. Uploading applet versions via CLI (sos applet upload) or the REST API does not consume your build quota. Only generating native deployment apps through Smart Builder counts toward your quota.

Can I create unlimited applet versions?

Yes. You can upload as many applet versions as your development process requires. There is no limit on the number of versions you create, upload, or assign to test devices.

When exactly is Smart Builder needed?

Smart Builder is needed only when you are packaging your applet as a native application for production deployment — for example, generating a Tizen .wgt, a webOS .ipk, or an Android .apk. During development and testing, your applet versions are deployed directly through CloudControl without any native app generation.

What if I need to update my applet after it is already deployed?

If you use CloudControl for deployment, you can assign a new applet version to your devices at any time — without regenerating a native app. The device will automatically pick up the new version. Smart Builder is only needed again if you need a fresh native package for manual provisioning or distribution.