On this page · 11 sections
Summary. Apple open-sourced the Temporal Swift SDK on 10 November 2025, and release 1.1.0 landed on 21 May 2026, giving server-side Swift a way to run durable workflows: code that finishes even when a server crashes mid-run. It needs Swift 6.2+ and runs on Linux, macOS 15.0+, and iOS. The model splits a process into deterministic workflows and idempotent activities, with @Workflow and @Activity macros to cut boilerplate. You can self-host the open-source Temporal server for free under the MIT license, or use Temporal Cloud, which bills per Action at $50 per million ($0.00005 each), with an Essentials plan from $100 per month and a Business plan from $500 per month. This guide covers the architecture, a working code example, the determinism rules that trip people up, and when durable execution beats a queue or a cron job.
What durable execution solves
Most backend failures are boring and expensive. A payment charges, then the server dies before it records the order. A data pipeline processes 9,000 of 10,000 rows, then the pod restarts and you cannot tell which rows finished. The usual fix is hand-written retry logic, a state table, and idempotency checks bolted onto each service.
Durable execution moves that burden into the platform. Your workflow code runs to completion even when infrastructure fails, and when a worker crashes or restarts, Temporal resumes the workflow from where it stopped, with no lost state, per the Swift.org announcement by Franz Busch of the Swift Server Workgroup. Temporal has done this for other languages for years. The 2025 SDK brings it to Swift teams building production cloud services, and the repository had 297 stars by August 2026.
The value shows up in multi-step processes that must survive failure: order fulfilment across inventory, payment, and shipping; ETL pipelines with resumption; approval flows with a human in the loop; and scheduled operational tasks, as the project README lists. If your process is a single request-response with no long-running state, you do not need this. If it spans services and minutes or days, you probably do.
How Temporal is structured
Temporal separates orchestration from work. Three pieces matter, plus a client to start things.
A workflow defines the business logic and the order of steps. It must be deterministic: given the same inputs and history, it must always make the same decisions, because Temporal replays workflow code to rebuild state after a crash. An activity performs the actual work that touches the outside world, such as calling an API or writing to a database, and it should be idempotent so a retry causes no duplicate side effect. A worker is the process that hosts your workflows and activities and polls a task queue. The client starts workflows and reads their results.
| Concept | Role | Key rule |
|---|---|---|
| Workflow | Coordinates steps and decisions | Must be deterministic, no direct IO |
| Activity | Does the real work, calls APIs | Should be idempotent, safe to retry |
| Worker | Hosts workflows and activities | Polls a named task queue |
| Client | Starts and queries workflows | Runs outside the workflow sandbox |
| Task queue | Routes work to workers | Names must match on both sides |
The Swift SDK adds compile-time safety on top. Workflow and activity definitions are type-checked, struct-based workflows stop queries and validators from mutating state, and observability through logging, metrics, and tracing is built in, according to the README.
A minimal Swift example
Add the package to Package.swift, pinning to the current release.
dependencies: [
.package(url: "https://github.com/apple/swift-temporal-sdk.git",
.upToNextMinor(from: "1.1.0"))
]
Define an activity and a workflow with the macros, then run a worker and client. This mirrors the SDK's own greeting example.
import GRPCNIOTransportHTTP2Posix
import Logging
import Temporal
// An activity does the real work and can be retried safely.
@ActivityContainer
struct GreetingActivities {
@Activity
func sayHello(input: String) -> String {
"Hello, \(input)!"
}
}
// A workflow coordinates steps and must stay deterministic.
@Workflow
struct GreetingWorkflow {
mutating func run(context: WorkflowContext<Self>, input: String) async throws -> String {
let greeting = try await context.executeActivity(
GreetingActivities.Activities.SayHello.self,
options: ActivityOptions(startToCloseTimeout: .seconds(30)),
input: input
)
return greeting
}
}
The worker hosts the code and polls a task queue; the client starts the workflow and reads the result.
let worker = try TemporalWorker(
configuration: .init(
namespace: "default",
taskQueue: "greeting-queue",
instrumentation: .init(serverHostname: "127.0.0.1")
),
target: .ipv4(address: "127.0.0.1", port: 7233),
transportSecurity: .plaintext,
activityContainers: GreetingActivities(),
workflows: [GreetingWorkflow.self],
logger: Logger(label: "worker")
)
let result = try await client.executeWorkflow(
type: GreetingWorkflow.self,
options: .init(id: "greeting-1", taskQueue: "greeting-queue"),
input: "World"
) // "Hello, World!"
Note the startToCloseTimeout on the activity. Timeouts and automatic retries are configuration, not code you write by hand, which is the point of the model.
Determinism rules and common mistakes
The rule that catches new users: workflow code is replayed, so it cannot do anything non-deterministic. Do not read the wall clock, generate random numbers, call the network, or read a file inside a workflow. Each of those can return a different value on replay and corrupt the rebuilt state. Push every side effect into an activity, where retries and non-determinism are expected and handled.
Time and randomness have workflow-safe equivalents through the workflow context rather than the Swift standard library. Long waits use a durable timer, not Task.sleep against the system clock. Because activities can run more than once, make them idempotent: use a stable key so a repeated call updates the same record instead of creating a second one, the same discipline described in idempotency keys for safe API retries. For failures you surface to callers, a structured error shape such as RFC 9457 problem details keeps activity errors readable across services.
When to use Temporal, a queue, or cron
Durable execution is not free complexity. Match the tool to the job.
| Need | Cron job | Message queue | Temporal |
|---|---|---|---|
| One periodic task, no state | Good fit | Overkill | Overkill |
| Fire-and-forget async work | Weak | Good fit | Overkill |
| Multi-step process, must resume | Poor | Manual state needed | Good fit |
| Long-running, days to weeks | Poor | Hard | Good fit |
| Human-in-the-loop approvals | Poor | Hard | Good fit |
A queue moves a message and forgets it; you still build the retry and state logic. Cron fires on a schedule with no memory of the last run. Temporal earns its keep when a process has several steps, must survive a crash mid-way, and you would otherwise hand-build a state machine. For the runtime underneath a Swift service, the trade-offs sit alongside a Bun versus Node.js backend runtime decision, and Swift teams weighing reach can read the Swift 6.3 cross-platform guide.
Cloud versus self-host cost
Temporal is free to self-host under the MIT license, but a production cluster is a distributed system you deploy, scale, monitor, and upgrade, so the real cost is engineering time. Temporal Cloud removes that operational load and bills per Action, where an Action is a discrete step such as starting a workflow, scheduling or completing an activity, recording a heartbeat, firing a timer, or sending a signal.
| Option | Price | Includes | Best for |
|---|---|---|---|
| Self-hosted | Free (MIT) | You run the cluster | Teams with platform capacity |
| Actions (Cloud) | $50 per million ($0.00005 each) | Pay per step | Variable workloads |
| Essentials | From $100/month | 1M Actions, 99.9% SLA | Small production apps |
| Business | From $500/month | 2.5M Actions, more storage | Scaling teams |
The pricing is on the Temporal Cloud pricing docs and the Temporal pricing page. For most teams the honest calculation is engineering time against the managed fee: if you do not already run distributed infrastructure, the Cloud plan is usually cheaper than the staff hours to operate a cluster.
Getting started
Install the Temporal CLI, start a local development server, then build and run an example.
temporal server start-dev # local server on port 7233
git clone https://github.com/apple/swift-temporal-sdk.git
cd swift-temporal-sdk && swift build && swift test
cd Examples/Greeting && swift run GreetingExample
The SDK targets Swift 6.2+ and macOS 15.0+, and the API documentation on Swift Package Index plus the Examples directory cover patterns from simple orchestration to multi-step business processes.
India-specific considerations
For Indian teams and global capability centres standardising on Swift for both apps and backend services, durable execution reduces the custom retry and reconciliation code that usually accumulates in fintech and logistics systems. Where a workflow stores personal data in its history, treat that store like any other data system under the Digital Personal Data Protection (DPDP) Act 2023: control where the Temporal cluster and its persistence run, and keep activity inputs free of unnecessary personal data so replay history does not retain more than it should.
FAQ
How eCorpIT can help
eCorpIT is a senior-led engineering organisation in Gurugram, founded in 2021 and certified for CMMI Level 5, MSME, and ISO 27001:2022. We build server-side Swift and cross-platform backends, and we design durable workflows for payment, logistics, and data-pipeline systems where a mid-run failure cannot be allowed to lose state, with data handling designed aligned with DPDP Act 2023 requirements. To scope a durable execution architecture for your product, contact our team.
References
- Swift.org, Introducing Temporal Swift SDK: building durable and reliable workflows, 10 November 2025.
- Apple, apple/swift-temporal-sdk on GitHub, accessed August 2026.
- Temporal, Temporal now supports Swift, 2025.
- Temporal, Temporal Cloud pricing, accessed August 2026.
- Temporal, Temporal platform pricing options, accessed August 2026.
- Temporal, Temporal documentation, accessed August 2026.
- Swift Package Index, swift-temporal-sdk API documentation, accessed August 2026.
- Apple, swift-temporal-sdk Examples, accessed August 2026.
- Swift Forums, Temporal Swift SDK 1.0.0, 2026.
- Temporal, Durable Digest: May 2026, May 2026.
Last updated: 2 August 2026.
