Plantilla de pasos

Set step_weights to render the steps as a single row of proportional segments instead of the equal-width matrix. Each weight is that step's relative share of the bar width, so [1, 2, 1] gives a narrow-wide-narrow layout. This suits a linear process whose stages take different amounts of time (a wash cycle, a multi-part checkout) more than a CI matrix.

In this layout the shared progress field fills the current segment fractionally: completed steps are filled solid, the current_step segment fills to progress (0.0-1.0), and later steps stay empty. Pair it with step_colors to give each stage its own tint; leave an entry blank to fall back to accent_color.

{
  "state": "ongoing",
  "content": {
    "template": "steps",
    "state": "Drying",
    "icon": "dishwasher",
    "subtitle": "Eco cycle",
    "current_step": 3,
    "total_steps": 3,
    "progress": 0.5,
    "step_labels": ["Wash", "Rinse", "Dry"],
    "step_weights": [1, 2, 1],
    "step_colors": ["blue", "teal", "orange"],
    "accent_color": "teal"
  }
}

Weighted matrix

Send step_weights alongside step_rows to keep the parallel-jobs matrix but size each column by how long its step runs. Below, Build and Test dominate the width, Test fans out to three jobs, and each column is tinted by step_colors.

{
  "state": "ongoing",
  "content": {
    "template": "steps",
    "state": "Test",
    "icon": "arrow.triangle.branch",
    "subtitle": "my-app / CI/CD",
    "current_step": 3,
    "total_steps": 6,
    "progress": 0.5,
    "step_labels": ["Lint", "Build", "Test", "Scan", "Publish", "Deploy"],
    "step_rows": [1, 1, 3, 1, 1, 1],
    "step_weights": [15, 180, 90, 45, 20, 60],
    "step_colors": ["purple", "blue", "yellow", "orange", "green", "green"],
    "accent_color": "green"
  }
}

By default the bar only moves when you push an update, so a long step looks frozen in between. If you know how long the current step takes -- a 90-minute wash cycle, a 4-minute test suite -- set live_progress: true and tell the server when that step ends. iOS then fills the current step and counts an ETA down natively on the device, with no extra pushes.

The easiest way is duration, which the server turns into start_date = now and end_date = now + duration. Send it again whenever you advance current_step, and the animation re-anchors to the new step.

• The ETA describes the current step, not the whole run. Steps before it stay filled solid; steps after it stay empty.
• While it is counting, the ETA takes the header and the current_step/total_steps counter moves down beside the step name. Leave live_progress off and the counter keeps the header.
• It works in every layout: the matrix column, the weighted column, and the segmented bar. In a fan-out column all the parallel jobs fill together, since they share one step deadline.
• If a step overruns its estimate without an update, its bar stops at full rather than racing ahead -- a stuck step never advances the counter on its own.
• Updates are merge-patches, so the anchors carry forward. Ending the activity clears them for you; on a mid-run update that should stop the animation, clear them explicitly with "end_date": null, "live_progress": null.
• Send duration only when current_step changes. Restamping the window on every update makes each one a high-priority push that skips update coalescing, and snaps the bar back to empty.

{
  "state": "ongoing",
  "content": {
    "template": "steps",
    "state": "Heating water",
    "icon": "dishwasher",
    "subtitle": "Eco 50",
    "current_step": 2,
    "total_steps": 4,
    "step_labels": ["Pre-wash", "Wash", "Rinse", "Dry"],
    "step_weights": [1, 6, 1, 2],
    "live_progress": true,
    "duration": "90m",
    "accent_color": "teal"
  }
}