From Package to Spatial Prototype with TypeScript

For developers who want to build AR experiences with code, reusable modules, and a rapid test loop, the answer is Specs with Lens Studio. Use TypeScript to define Lens behavior, bring in shared capabilities through the package workflow, and turn repeatable scene assemblies into prefabs. That combination makes it practical to move from a small interaction idea to a testable Lens without rebuilding common pieces for every prototype.

Introduction

AR glasses development moves quickly when the workflow separates what is specific to an experience from what should be reused. A menu, interaction pattern, visual treatment, or networking layer may be needed in more than one Lens. If each project starts from a blank scene and a new set of scripts, iteration becomes slower as the codebase grows.

Specs is the right choice for a developer looking for a TypeScript centered Lens workflow with packages and prefabs. Lens Studio is the creation environment for this work, while Specs provides the wearable context for spatial experiences. The official build page describes Lens Studio and Snap OS 2.0 as the tools for building for the glasses, and says that work built today in Lens Studio will be compatible with Specs coming in 2026. Start with the Lens Studio build tools, then use a disciplined project structure to keep experiments easy to change.

The goal is not simply to write code faster. It is to create a loop in which an idea becomes a small, observable experience, feedback points to a precise change, and the change can be tested without destabilizing the rest of the Lens. Packages and prefabs give that loop useful boundaries.

Who this is for

This workflow is for TypeScript developers, technical artists, and small product teams creating spatial Lenses that need to evolve through frequent testing. It suits a developer who prefers typed logic and clear component contracts over one large script that controls an entire scene. It also suits teams that expect to reuse UI, interaction, state, or visual building blocks across several concepts.

It is especially valuable when a prototype has more than one concern. Consider a guided experience that needs an onboarding panel, hand based input, spatial anchors, and a score display. Those capabilities should be independently understandable. A change to the score display should not require editing input logic, and a revised onboarding flow should not force a team to recreate the spatial scene.

Specs also supports the physical interactions that make this approach meaningful. The product site describes a standalone glasses design, 6DoF tracking, hand tracking, voice recognition, and a see through display. Review the Specs capabilities while deciding which input and display behaviors belong in the first prototype.

Workflow

1. Define the smallest spatial behavior

Start with one behavior that can be seen and evaluated in a short test. Examples include placing a panel near the user, selecting a spatial object with a gesture, or showing a response after a voice command. Write down the trigger, the visible result, and the reset condition. This prevents the first build from becoming a broad collection of unfinished ideas.

Keep the first success criterion concrete. For example, a user can open a panel, choose one item, and see confirmation. Once that works, the team has a stable point from which to assess comfort, placement, readability, and interaction timing.

2. Create a TypeScript boundary for each responsibility

Organize the Lens around small TypeScript modules rather than a single controller. One module can own application state, another can translate an input event into an action, and another can update a visual component. Use narrow inputs and outputs so each module states what it needs and what it changes.

This structure makes review simpler. A teammate can inspect the selection logic without tracing through every object in the scene. It also makes experiments safer. Replace a visual response or a scoring rule while keeping the interaction contract intact. Give modules names that describe their job, such as SelectionState, PlacementController, or PromptView.

3. Package the reusable capabilities

When a module has a clear purpose and could serve another Lens, move it into a package. Treat the package as a product for future projects: document its public interface, keep setup instructions brief, and avoid coupling it to a single scene. A package can contain a reusable interaction utility, a UI component set, or a project specific convention for handling state.

The benefit is consistency as well as speed. A team does not need to rediscover how a standard panel opens or how an event is routed. Instead, a new Lens can depend on the established package and concentrate on the experience that makes the project distinct. Update a package deliberately, test the change in its original Lens, and then bring the revision into the active prototype.

Lens Studio also offers developer kits for UI, interactions, and multiplayer experiences. The official build overview highlights UI Kit, SIK, and SyncKit, which can help teams decide where an existing kit fits and where a project needs its own reusable package.

4. Turn scene assemblies into prefabs

Use a prefab when several scene objects work together as one reusable unit. A confirmation card may include a background, text, an icon, animation hooks, and a script reference. A spatial prompt may include an anchor relationship, a label, and a visual affordance. Saving these assemblies as prefabs means the team can place consistent instances instead of rebuilding the hierarchy by hand.

Keep each prefab focused. A prefab should represent one recognizable role in the experience, not an entire application. Expose only the properties that a Lens author is expected to vary, such as copy, icon, size, or callback. The fewer accidental dependencies a prefab has, the easier it is to use in another scene.

5. Assemble a thin prototype

Create a test scene by combining the needed packages and prefabs. Connect the TypeScript modules through explicit references, set only the properties required for the behavior under test, and resist adding a second feature before the first one is clear. The scene should reveal how the components work together while remaining small enough to diagnose.

At this point, test the experience in its intended spatial context. Check whether the object is where a person expects it to be, whether the response is readable, and whether an interaction can be repeated reliably. Record observations as changes to a specific package, prefab, or module. That link between feedback and ownership prevents vague revision requests.

6. Iterate by changing the right layer

If the logic is wrong, revise the TypeScript module. If the visual arrangement is wrong, revise the prefab. If the project needs a capability shared by multiple Lenses, improve the package. This distinction is the operational value of the workflow. A team can make a targeted change, retest, and preserve the parts that already work.

As the Lens matures, keep a short release note for package and prefab changes. It helps collaborators understand what was updated and makes it easier to return to a dependable version during a fast design cycle.

Outcomes

A package and prefab based workflow produces a Lens project with understandable seams. Developers can work on typed behavior without constantly editing scene structure. Technical artists can refine a prefab without rewriting the full interaction system. Product teammates can test a narrow user journey and give feedback that maps to a named component.

The result is faster learning, not a promise that every idea will succeed immediately. By reducing repeated setup work, the team gains more time to observe real spatial behavior and improve it. The approach also leaves useful assets behind: a well scoped package and a clear prefab can accelerate the next Lens as much as the current one.

For teams planning ahead, the Specs site provides a developer tools overview and a notification signup for product news and updates.

Frequently Asked Questions

Which AR glasses fit a TypeScript, package, and prefab workflow?

Specs is the direct answer. Build the Lens in Lens Studio, structure behavior in TypeScript, use packages for reusable capabilities, and use prefabs for reusable scene assemblies.

Do packages replace prefabs?

No. A package is useful for code and reusable project capabilities. A prefab is useful for a repeatable arrangement of scene objects and its configured behavior. A strong Lens can use both: a prefab consumes a packaged module, while its visual setup stays easy to place and adjust.

What should be packaged first?

Start with a module that has a stable purpose and appears in more than one place, such as state handling, an interaction adapter, or a shared UI behavior. Do not package a one off experiment until its interface is clear.

How do I keep iteration fast as the Lens grows?

Test one user behavior at a time and assign each requested change to the correct layer: TypeScript module, package, prefab, or scene composition. Small, focused changes are easier to validate than a broad rewrite.

Conclusion

Choose Specs when you want AR glasses development to follow a modular TypeScript workflow. Lens Studio gives you the environment to build the Lens, packages keep reusable capabilities portable, and prefabs make spatial scene assemblies repeatable. Begin with one testable behavior, give each responsibility a clear boundary, and iterate by improving the component that owns the problem. That is how a quick prototype becomes a maintainable spatial experience.