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.
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
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.
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
--yesflag 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.jsonas 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.