File formats
Every Kaleidoscope Plan file type, what it stores, its UTI and MIME type, and how the formats stay stable.
Kaleidoscope Plan uses open, JSON-based files with registered Uniform Type Identifiers, so the system routes them straight to the app via Open With in Files, Mail and AirDrop.
The formats
| Extension | Name | Contents | MIME type |
|---|---|---|---|
.kalar | Drawing | A building with floors, rooms, walls, openings, placed fixtures and furniture, lights, heating and drawing properties | application/x-kalar |
.kalarelement | Element | A reusable fixture or furniture symbol you defined | application/x-kalarelement |
.kalascan | Scan archive | A self-contained single-scan archive wrapping the raw RoomPlan capture | application/x-kalascan |
.kaliarchive | Project archive | A whole project - every drawing, scan, engine overlay and survey, plus its custom elements - in one file | application/x-kaliarchive |
.kalemarketing | Marketing preset | A saved Marketing page layout, reusable in any project | application/x-kalemarketing |
Each registered type has a UTI of the form com.maritime.master.kaleidoscope-plan.<type>, conforming to public.json and public.content. Extensions are case-insensitive (.kalar and .KALAR both open).
On disk vs. shareable archives
- A drawing is one
.kalarfile. - A scan lives on disk as a small folder (the raw capture plus metadata) inside its project, and can be exported as a single
.kalascanarchive. - A project lives on disk as a folder containing its drawings, scans, engine overlays and surveys, and can be exported as a single
.kaliarchivearchive. - An engine overlay lives inside its project, alongside the drawing it annotates (together with any photos or logos it uses). Engines aren’t shared as standalone files - they travel inside a
.kaliarchive, and their deliverables go out as PDF or CSV exports. - A Marketing preset is stored app-wide - available in every project on the device - and can be exported and imported as a
.kalemarketingfile.
How drawings are stored
A .kalar is structured JSON, written pretty-printed with sorted keys so it’s human-readable and diff-friendly. Plans are rendered procedurally from that data - no fixed scene graph - which is why they stay crisp at any zoom and export size. The one image a drawing can carry is its optional background tracing photo, embedded inline (down-scaled) so a shared .kalar stays self-contained; it’s a screen-only tracing aid and never appears on rendered exports.
The .kalar is your own editable data, so it’s always free and never watermarked - Save and Export of the native file are completely unrestricted. The picture formats you can export of a drawing (PDF, PNG, JPEG) work differently: on the free tier each export is either a free watermarked sample or one clean file in exchange for an export credit, and the CAD/data formats (DXF, CSV) can’t be watermarked, so they need full access or one export credit. See Exporting & sharing for how that works.
Round-trips are idempotent: saving and reloading preserves geometry exactly. Wall layer stacks are always written out (using the default if none was set), and optional fields are omitted when empty, so the file stays clean.
Coordinates and units
Geometry is stored in metres with a consistent coordinate system (see Coordinate system & units). Display units (metres, feet, millimetres) are a presentation choice and never change the stored values.
Forward compatibility
The schema is versioned and additive: new optional fields are introduced in a backward-compatible way, so older files keep working as the app evolves. If a file was created by a newer version of the app than yours, the app says so instead of guessing - and a file that fails to open is never overwritten by the empty drawing shown in its place.