DEV Community: ArshTechPro

Penpot for Developers: The Open-Source Design Tool That Speaks Your Language

ArshTechPro — Mon, 22 Jun 2026 21:58:38 +0000

Most design tools treat developers as an afterthought. You get handed a file, you squint at a spec panel, and you manually translate someone else's pixels into code that drifts out of sync the moment the design changes.

Penpot is an open-source design and prototyping platform where design is expressed as actual code — SVG, CSS, HTML, and JSON, the same web standards you already ship. No proprietary .fig lock-in, no "designer dialect" to interpret. It's MPL-2.0 licensed, written largely in Clojure/ClojureScript with a Rust WebAssembly renderer, and at the time of writing sits around 47k stars on GitHub.

Here's what's actually in it for you as a developer.

1. Inspect mode gives you real, ready-to-use code

Every design in Penpot has an Inspect tab that exposes the underlying SVG, CSS, and HTML. Because the design is web standards under the hood, what you copy is what you ship — not an approximation a plugin reverse-engineered. This removes the translation layer that usually causes design-to-implementation drift.

2. Layouts that behave like real CSS

Penpot supports native CSS Grid and Flexbox layouts. You design responsive interfaces using the same layout models that exist in the browser, so the structure you see in the canvas maps onto the box model you'll actually write. Less "why doesn't this reflow like the mockup" friction.

3. An MCP server for AI-driven design-to-code

This is the part worth paying attention to in 2026. Penpot ships an official MCP (Model Context Protocol) server, now integrated directly into the main repo under /mcp.

What it enables: any MCP-compatible AI client — Claude Code, Cursor, Claude Desktop, Copilot-style tools — can read and modify your Penpot design files programmatically. Because designs are already structured, machine-readable code, the agent isn't guessing from a screenshot. It works with the real component tree, styles, and tokens.

The workflows people are building with it include:

Translating a board into production-ready semantic HTML and modular CSS, honoring your design tokens
Generating interactive prototypes from existing designs
Turning a rough scribble into a component that respects your design system
Auto-generating design-system documentation from a file
Code-to-design (not just design-to-code) and design-to-documentation round trips

Quick start for Claude Code against a local server:

claude mcp add penpot -t http http://localhost:4401/mcp

The MCP core is written in TypeScript for type-safe interaction with the Penpot Plugin API, and supports both a hosted (remote) setup and a self-hosted local setup. One safety note worth repeating: the MCP key is a personal, non-recoverable token — treat it like a password, and start your agent with read-only prompts (list, inspect, analyze) before letting it write changes to a focused page.

4. Native design tokens as a single source of truth

Penpot has first-class native Design Tokens, plus Components and Variants. Tokens act as one source of truth shared between design and development, which means no manual token exports and no separate plugin to keep your color/spacing/type scales in sync. Combined with the MCP server, your design system can become a direct context source for AI-generated code.

5. An open API, plugins, and webhooks

If you want to automate or integrate, Penpot is programmable:

Plugin system with access to the full workspace — read and write designs programmatically
Open REST API accessible via access tokens
Webhooks to wire Penpot into your existing toolchain

No app-store review process or corporate gatekeeping to extend the tool.

6. Self-host it anywhere

Penpot is deployment-agnostic. Use the hosted SaaS at design.penpot.app, or run it on your own infrastructure with Docker, Kubernetes, Elestio, and other options. For teams under compliance constraints (healthcare, finance, government), this means your design IP can live entirely on servers you control — no third-party cloud required.

Why a developer might actually care

The short version: Penpot collapses the gap between design and development by refusing to invent its own format. Web-native output, real CSS layouts, native design tokens, an open API, and an MCP server that makes the whole thing AI-actionable add up to a design platform that speaks the languages you already work in — and that you can own end to end.

Figma still leads on polish, plugin breadth, and prototyping depth, so this isn't a "rip and replace" pitch. But if data ownership, design-code alignment, or AI-in-the-loop workflows matter to you, Penpot is worth a serious look.

Getting started

Reference: https://github.com/penpot/penpot

WWDC 2026 - Build Real-Time Apps and Services with gRPC and Swift

ArshTechPro — Mon, 22 Jun 2026 09:35:52 +0000

If you have ever hand-written networking code to talk to a backend, you know the pain. You read some documentation, design your request and response types, write the URL handling and JSON decoding, and eventually get something that seems to work. Then the API changes, the docs fall behind, a field gets renamed, and suddenly your app is silently failing in production.

gRPC removes most of that friction. Instead of treating server communication as a pile of HTTP endpoints and hand-rolled models, gRPC lets you define your API once, in a single contract, and generate the client and server code from it. With the release of gRPC Swift 2, this workflow has become genuinely idiomatic on Apple platforms and Linux, built around async/await and Swift 6 concurrency.

This article walks through what gRPC is, why it fits real-time apps so well, and how to use it in a Swift project from start to finish.

What is gRPC?

gRPC is a framework for making remote procedure calls.

The key mental shift is this: with a typical REST API, you think in terms of HTTP, like URLs, verbs such as GET and POST, status codes, and request bodies. With gRPC, you think in terms of functions with inputs and outputs. Calling the server feels like calling a local function, except the work happens on a remote machine.

A remote procedure call works like this:

The client builds a request message.
It sends that message to the server.
The server runs the function and produces a response message.
The response travels back to the client.

For example, a function to fetch a race schedule might be called listRaces. The client calls it with the number of races it wants, and the server returns the list. From the caller's perspective, it looks almost identical to invoking any other Swift method.

gRPC is not a niche tool. It runs deep inside large-scale infrastructure, including Apple's own services such as Private Cloud Compute, iCloud Keychain, Photos, and SharePlay file sharing, as well as inter-process communication in Apple's open source Containerization framework. The same library you would use in an iOS app is production-grade for backend systems.

The contract: Protocol Buffers

Most gRPC services describe their API using Protocol Buffers, usually shortened to Protobuf. This is the source of truth for the service. Because it is a neutral, cross-platform format, the same .proto file can generate a Swift client, a Go server, a Kotlin client, and so on. Everyone agrees on the same contract.

You define your service and its messages in a .proto file. Here is a small example for a racing app:

syntax = "proto3";

import "google/protobuf/timestamp.proto";

service SwiftKart {
  rpc ListRaces(ListRacesRequest) returns (ListRacesResponse);
}

message ListRacesRequest {
  int32 limit = 1;
}

message ListRacesResponse {
  repeated Race races = 1;
}

message Race {
  string name = 1;
  string location = 2;
  string championship = 3;
  int32 laps = 4;
  google.protobuf.Timestamp start_time = 5;
}

A few things worth noticing:

The service block declares one or more RPCs. Here, ListRaces takes a ListRacesRequest and returns a ListRacesResponse.
Every field has a unique field number (the = 1, = 2, and so on). These numbers, not the names, are what gets sent on the wire.
repeated means a list, so repeated Race races is the equivalent of an array of races.
Timestamp is one of Protobuf's "Well-Known Types," which is why it needs an import.

Why the field numbers matter

When gRPC sends a message, it serializes it to a compact binary representation and uses the field number rather than the field name to identify each value. The practical result is that a Protobuf message is roughly half the size of the equivalent JSON payload.

For a mobile app, smaller messages mean less data transferred and faster network calls, which matters most when the connection is poor. The same efficiency pays off in service-to-service communication on the backend.

Setting up gRPC Swift in your project

gRPC Swift 2 is distributed as a set of packages so you can pull in only what you need. The three you will most commonly use are:

grpc-swift-2 provides the core runtime types and abstractions (GRPCCore).
grpc-swift-nio-transport provides high-performance HTTP/2 networking built on SwiftNIO.
grpc-swift-protobuf provides the build plugin that generates Swift code from your .proto files, and integrates with SwiftProtobuf.

In a Swift package, your dependencies look like this:

// swift-tools-version: 6.0
import PackageDescription

let package = Package(
    name: "SwiftKart",
    platforms: [.macOS("15.0"), .iOS("18.0")],
    dependencies: [
        .package(url: "https://github.com/grpc/grpc-swift-2.git", from: "2.0.0"),
        .package(url: "https://github.com/grpc/grpc-swift-nio-transport.git", from: "2.0.0"),
        .package(url: "https://github.com/grpc/grpc-swift-protobuf.git", from: "2.0.0"),
    ],
    targets: [
        .executableTarget(
            name: "SwiftKart",
            dependencies: [
                .product(name: "GRPCCore", package: "grpc-swift-2"),
                .product(name: "GRPCNIOTransportHTTP2", package: "grpc-swift-nio-transport"),
                .product(name: "GRPCProtobuf", package: "grpc-swift-protobuf"),
            ],
            plugins: [
                .plugin(name: "GRPCProtobufGenerator", package: "grpc-swift-protobuf")
            ]
        )
    ]
)

Note: gRPC Swift 2 requires Swift 6 and recent deployment targets (macOS 15+, iOS 18+, tvOS 18+, watchOS 11+, visionOS 2+).

Generating the code in Xcode

If you are working in an Xcode app project rather than a pure Swift package, the flow is:

Open the Project Editor, go to the Package Dependencies tab, and add grpc-swift-nio-transport and grpc-swift-protobuf.
Select your app target, open Build Phases, and expand Run Build Tool Plug-ins.
Add the GRPCProtobufGenerator plugin.
Drop your .proto file and a small JSON config file into the target.

The plugin scans the target for .proto files and generates the Swift code when you build. The JSON config controls what gets generated. For an app, you typically only need the messages and the client, not the server code:

{
  "generate": {
    "clients": true,
    "messages": true,
    "servers": false
  }
}

The first time you build, Xcode will ask you to trust the plugin. After that, your generated client and message types are available to import.

Making your first call

With the code generated, calling the service from a SwiftUI view looks like ordinary async Swift. Here is the shape of it:

import GRPCCore
import GRPCNIOTransportHTTP2
import SwiftProtobuf

// Inside a view, using a .task modifier:
.task {
    do {
        try await withGRPCClient(
            transport: .http2NIOPosix(
                target: .dns(host: "localhost", port: 8080),
                transportSecurity: .plaintext
            )
        ) { client in
            let kart = SwiftKart.Client(wrapping: client)
            let response = try await kart.listRaces(.with { $0.limit = 50 })
            self.races = response.races.map(Race.init)
        }
    } catch {
        print("Request failed: \(error)")
    }
}

What is happening here:

withGRPCClient creates a client configured with a transport. The transport decides how the bytes move, in this case HTTP/2 over SwiftNIO, connecting to a local server.
The raw client only knows about the server, not your specific service. Wrapping it in the generated SwiftKart.Client gives you the typed listRaces method.
.with { $0.limit = 50 } is the SwiftProtobuf way of building a message and setting its fields.
The response is mapped into the app's own model types.

And that is a complete round trip: a typed request out, a typed response back, with no manual URL building or JSON decoding anywhere.

Reuse the client, do not recreate it

One important detail: do not create a new gRPC client every time a view appears. Each client establishes its own connection, which adds latency. Instead, create a single client and share it, for example through the SwiftUI environment, so connections can be reused across views.

It is also good practice to disconnect the client when the app moves to the background to free up resources. A small "client manager" object that connects lazily and tears down on scenePhase changes handles this cleanly.

The real power: streaming

So far we have looked at a unary RPC, which is a single request and a single response, just like a normal function call. This is where gRPC's standout feature comes in: every RPC can also stream messages. That opens up three more call types beyond unary.

RPC type	Client sends	Server sends	Good for
Unary	one message	one message	Fetching a list, a single lookup
Server streaming	one message	many messages	Live commentary feed, notifications
Client streaming	many messages	one message	Uploading telemetry, batching events
Bidirectional streaming	many messages	many messages	Live, two-way subscriptions

Think about a live kart race:

Server streaming is a live text commentary feed. The client asks once, the server keeps pushing updates.
Client streaming is each kart pushing its telemetry to the server continuously.
Bidirectional streaming is the richest case. The client tells the server which events it cares about and can change that subscription at any time, while the server streams back the matching events.

Defining a streaming RPC

You mark a streaming parameter with the stream keyword in the .proto file:

service SwiftKart {
  rpc ListRaces(ListRacesRequest) returns (ListRacesResponse);

  rpc FollowRace(stream FollowRaceRequest) returns (stream FollowRaceResponse);
}

message FollowRaceRequest {
  string race_name = 1;
  repeated EventType events = 2;
}

enum EventType {
  EVENT_TYPE_UNSPECIFIED = 0;
  EVENT_TYPE_KART_LOCATIONS = 1;
  EVENT_TYPE_STANDINGS = 2;
}

message FollowRaceResponse {
  oneof payload {
    KartLocations locations = 1;
    Standings standings = 2;
  }
}

That oneof is worth calling out: it maps neatly onto a Swift enum with associated values. A FollowRaceResponse holds either kart locations or standings, and you switch over it on the client just like any Swift enum.

Consuming a bidirectional stream on the client

A bidirectional RPC gives you two closures: one for writing requests to the server, and one for reading responses. Here is the shape of consuming the live race feed in SwiftUI:

.task {
    do {
        try await manager.withClient { client in
            let kart = SwiftKart.Client(wrapping: client)

            try await kart.followRace { writer in
                // Send a request whenever the user's interests change.
                for await showLeaderboard in leaderboardStream {
                    var request = FollowRaceRequest.with {
                        $0.raceName = "Finite Loops"
                        $0.events = [.kartLocations]
                    }
                    if showLeaderboard {
                        request.events.append(.standings)
                    }
                    try await writer.write(request)
                }
            } onResponse: { responses in
                // Handle each event the server pushes back.
                for try await response in responses.messages {
                    handle(response)
                }
            }
        }
    } catch {
        print("Stream failed: \(error)")
    }
}

The two halves run concurrently. As the user toggles the leaderboard on and off, the client writes new request messages updating its subscription, and the server adjusts what it streams back in real time. The handle(response) helper switches over the oneof payload and updates the view, drawing kart positions on a map or refreshing the standings.

This is the core of a real-time experience: a single long-lived connection carrying a live, two-way conversation, with strongly typed messages on both ends.

Implementing the server side

The same .proto contract generates the server code too. Implementing a service means conforming to a generated protocol, with one method per RPC. For a unary RPC, that is just an async function:

import GRPCCore
import GRPCNIOTransportHTTP2

struct SwiftKartService: SwiftKart.SimpleServiceProtocol {
    func listRaces(
        request: ListRacesRequest,
        context: ServerContext
    ) async throws -> ListRacesResponse {
        let races = try await database.races(limit: Int(request.limit))
        return ListRacesResponse.with { $0.races = races }
    }
}

Starting the server is a matter of creating one with a transport and the services it should offer, then calling serve():

let server = GRPCServer(
    transport: .http2NIOPosix(
        address: .ipv4(host: "0.0.0.0", port: 8080),
        transportSecurity: .plaintext
    ),
    services: [SwiftKartService()]
)
try await server.serve()

Streaming RPCs on the server look a little different. The request parameter becomes an async sequence of incoming messages, and the response becomes a writer you push messages into. Handling two streams at once is a natural fit for a Swift task group: one task reads the client's evolving subscription, another follows the live race data and writes matching events back. When the request stream ends, you treat that as the signal to cancel the work and stop sending.

Deploying to the cloud

Because gRPC Swift runs on Linux, deploying a service is the standard container workflow. Most cloud providers (Google Cloud Run, AWS, Fly.io, and others) follow a similar pattern even if the exact commands differ.

The typical steps:

Write a Containerfile that builds the server in release mode. Use a multi-stage build: compile with the full swift:latest image, then copy just the resulting binary into a smaller swift:slim runtime image. This keeps the final image from carrying the entire Swift toolchain.
Publish the image to your provider's container registry.
Create a deployment. Make sure to enable HTTP/2, since gRPC depends on it.
Update the app to point at the deployed service's DNS name, and switch the transport security from plaintext to TLS.

That last change on the client is small but essential:

.http2NIOPosix(
    target: .dns(host: "your-service.example.run.app", port: 443),
    transportSecurity: .tls   // was .plaintext for local development
)

With TLS enabled and the host pointed at the cloud, the same app that talked to your Mac now talks to a service available to everyone.

Where to go next

gRPC Swift has plenty built in to take an app from prototype to production:

Integration with other Swift server packages like Swift OTel (for distributed tracing via OpenTelemetry) and Swift Service Lifecycle.
Advanced connection management, including custom transports, name resolvers, and client-side load balancing.
A reflection service, health checks, and interceptors via the grpc-swift-extras package.

The fastest way to get comfortable is to prototype one slice of your app-to-server communication with gRPC and feel how the generated code removes the boilerplate. From there:

Browse the tutorials and examples in the grpc-swift-2 repository.
Since the project is open source, you can ask questions, improve docs, or propose features.

NVIDIA SkillSpector: Should You Scan Your AI Agent Skills Before Installing Them?

ArshTechPro — Sun, 21 Jun 2026 04:29:05 +0000

If you have been using Claude Code, Codex CLI, Gemini CLI, or any agent framework that supports "skills," you have probably installed a few skills from a marketplace or a random GitHub repo without reading every line of code inside them. Most people do. The skill promises to help with PDF generation, data analysis, or some other task, you drop it into your project, and you move on.

NVIDIA's new open source tool, SkillSpector, exists because that habit is riskier than it looks. This article walks through what SkillSpector does, how to set it up, and whether it is worth adding to your workflow.

What SkillSpector actually does

SkillSpector is a security scanner purpose-built for AI agent skills rather than general source code. It runs a two-stage pipeline:

Static analysis — fast, regex and AST-based pattern matching that looks for dangerous code patterns (exec, eval, subprocess, obfuscated payloads), taint flows from sensitive sources to network or execution sinks, YARA signature matches for known malware/webshell/cryptominer patterns, and dependency checks against the OSV.dev vulnerability database.
Optional LLM semantic analysis — a second pass where a language model evaluates context and intent, filters out false positives from the static stage, and explains findings in plain language. The prompt used for this step includes anti-jailbreak protections so a malicious skill cannot talk its way out of being flagged.

The static stage alone covers a wide net (prompt injection, data exfiltration, privilege escalation, supply chain issues, excessive agency, output handling, system prompt leakage, memory poisoning, tool misuse, rogue-agent behavior, trigger abuse, dangerous code execution, taint tracking, and MCP-specific issues like tool poisoning and least-privilege violations). Adding the LLM pass is what pushes precision up meaningfully, since static pattern matching alone tends to over-flag.

Every scan ends with a risk score from 0–100 and a severity label, so instead of reading a wall of findings you get a clear signal: safe, use caution, or do not install.

Setting it up

You do not need an NVIDIA account or any paid API to get value out of this. Here is the fastest path.

1. Clone and install

git clone https://github.com/NVIDIA/skillspector.git
cd skillspector

# Create and activate a virtual environment
uv venv .venv && source .venv/bin/activate
# or, without uv:
# python3 -m venv .venv && source .venv/bin/activate

# Install
make install
# or, if you want to contribute / run tests:
make install-dev

The project targets Python 3.12+ and is Apache 2.0 licensed, so there is no licensing friction for commercial use.

2. Run your first scan

# A local skill folder
skillspector scan ./my-skill/

# A single SKILL.md file
skillspector scan ./SKILL.md

# A skill hosted on GitHub
skillspector scan https://github.com/some-user/some-skill

# A zipped skill package
skillspector scan ./my-skill.zip

That is the whole entry point. No config file is required for a basic static scan.

3. Prefer Docker? Skip Python entirely

If you would rather not set up a Python environment, the repo ships a Dockerfile based on the official python:3.12-slim-bookworm image:

docker run --rm -v "$PWD:/scan" skillspector scan ./my-skill/ --no-llm

4. Turn on LLM-powered analysis (optional but recommended)

Static analysis alone is fast but can be noisy. Adding an LLM pass improves accuracy and gives you readable explanations for each finding. SkillSpector supports three providers out of the box, plus anything OpenAI-compatible (including local models via Ollama or vLLM):

Provider	Env var for the key	Where it runs
OpenAI	`OPENAI_API_KEY`	api.openai.com or any compatible endpoint
Anthropic	`ANTHROPIC_API_KEY`	api.anthropic.com
NVIDIA build.nvidia.com	`NVIDIA_INFERENCE_KEY`	build.nvidia.com

Example with Anthropic:

export SKILLSPECTOR_PROVIDER=anthropic
export ANTHROPIC_API_KEY=sk-ant-...
skillspector scan ./my-skill/

Or point it at a local model with no API key at all:

export SKILLSPECTOR_PROVIDER=openai
export OPENAI_API_KEY=ollama
export OPENAI_BASE_URL=http://localhost:11434/v1
export SKILLSPECTOR_MODEL=llama3.1:8b
skillspector scan ./my-skill/

If you just want the fast static pass without any model calls, add --no-llm to any command.

5. Pick an output format that fits your workflow

skillspector scan ./my-skill/ --format json --output report.json       # automation
skillspector scan ./my-skill/ --format markdown --output report.md     # review docs
skillspector scan ./my-skill/ --format sarif --output report.sarif     # CI/CD and IDE tooling

The SARIF output is worth calling out specifically: it plugs straight into GitHub code scanning, VS Code, and most CI pipelines that already understand SARIF from other security tools, which makes it realistic to wire this into a pull request check rather than running it manually every time.

6. Use it from Python directly

If you want to embed scanning inside your own tooling rather than shelling out to the CLI, the workflow is exposed as a LangGraph graph:

from skillspector import graph

result = graph.invoke({
    "input_path": "/path/to/skill",
    "output_format": "json",
    "use_llm": True,
})

print(f"Risk Score: {result['risk_score']}/100")
print(f"Severity: {result['risk_severity']}")

Reading the results

Scores map to four bands:

0–20 (LOW) — Safe
21–50 (MEDIUM) — Caution
51–80 (HIGH) — Do not install
81–100 (CRITICAL) — Do not install

Each finding in the report points to the exact file and line, names the pattern that triggered it, and (when LLM analysis is enabled) explains why it matters in a sentence or two. That last part is what makes the tool usable by people who are not security specialists — you do not need to know what a taint-flow chain is to understand "this code reads your environment variables and sends them to an external server."

Where it falls short

The project is upfront about its limitations, and they are worth knowing before you rely on it as your only line of defense:

It is static analysis at its core, so it does not execute the skill to observe runtime behavior.
Non-English content can slip past pattern matching.
Anything hidden inside an image cannot be inspected.
Encrypted or compiled code is opaque to the scanner.
The live CVE lookup (via OSV.dev) needs outbound network access; offline environments fall back to a much smaller built-in list.

None of this is unusual for a static scanner, but it means SkillSpector is a strong filter, not a guarantee.

What others are saying

This tool has been getting attention quickly since release. Developer Jacob Bennett, writing on his blog, described the gap NVIDIA addressed as a significant security blind spot for agent skills, and suggested the scanner is a good candidate to wire into CI for organizations that share skills internally. That lines up with how the tool is actually designed to be used: not as a one-time check, but as a recurring gate before a skill gets trusted.

Is it worth a try?

For a few specific situations, yes, clearly:

You install skills from public marketplaces or random repos and have never audited what is inside them.
Your team shares internal skills and you want a lightweight gate before something gets merged or distributed.
You already use SARIF-based scanning in CI and want this to slot in alongside your existing security tooling.
You want a quick second opinion before running a skill that asks for broad tool access or touches credentials.

The setup cost is low. A static scan needs nothing beyond a Python virtual environment, runs in seconds, and requires no API keys. Adding the LLM pass takes one extra environment variable and a key for whichever provider you already use, including a fully local option through Ollama if you would rather not send any code to an external API. The license is permissive, the CLI is simple enough to run once and forget, and the output formats mean it fits into an existing pipeline instead of becoming a new manual chore.

The honest caveat is that this is a young project (the GitHub repository is only a few weeks old at the time of writing), so expect the pattern set and accuracy to keep evolving. It is also not a replacement for actually reading a skill's code if it is going to run with elevated privileges. But as a first-pass filter that takes a few minutes to set up and catches a meaningful share of real issues, it is a reasonable addition to any workflow where you are installing code you did not write and trusting it with system access.

Quick reference

git clone https://github.com/NVIDIA/skillspector.git
cd skillspector
uv venv .venv && source .venv/bin/activate
make install

skillspector scan ./my-skill/ --no-llm        # fast static check
skillspector patterns                          # list all 64 detection patterns

If you try it on a skill you already have installed, it might be worth checking what comes back before you run that skill again.

Turso: A Rust Rewrite of SQLite. Setup Guide and Whether It's Worth Your Time

ArshTechPro — Sun, 21 Jun 2026 04:24:46 +0000

If you have spent any time in the SQLite-adjacent corner of GitHub lately, you have probably seen the name Turso pop up. The project Turso describes itself as an in-process SQL database written in Rust that is compatible with SQLite.

This post walks through what the project actually is, how to get it running locally and in the cloud, and an honest take on whether you should bother adopting it right now.

First, clear up the naming confusion

Before touching any code, it helps to know there are three related but different things, and mixing them up is the most common source of confusion in the community:

libSQL: Turso's original project, a fork of SQLite written in C. It is production ready today and currently powers Turso Cloud.
Turso (the database engine): The project at the GitHub link above. A clean-room rewrite of SQLite in Rust, started as a side project called "Limbo." It is currently in beta and is explicitly positioned as the successor to libSQL, not a side experiment.
Turso Cloud: The managed, hosted database-as-a-service product built by the same company. It currently runs on libSQL, with the Rust engine gradually being rolled into it.

If you just want a managed SQLite-compatible database in production today, libSQL plus Turso Cloud is the safer starting point. If you want to try the next-generation engine itself, that is the tursodatabase/turso repo this article focuses on.

What's actually in it for developers

This is the part most setup tutorials skip, so here is the practical pitch:

It still talks SQLite. Same SQL dialect, same file format, same C API surface where practical. If you know SQLite, you already mostly know Turso.
Concurrent writes. SQLite's biggest historical complaint is its single-writer lock. Turso ships an experimental MVCC engine with BEGIN CONCURRENT, letting multiple writers commit without blocking each other on simple cases.
Async by design. The engine is built around asynchronous I/O (including Linux io_uring), instead of bolting async behavior on top of a synchronous core the way most SQLite drivers have to.
Native vector search. Built-in approximate vector search for embeddings and RAG-style workloads, no extension required.
Change Data Capture (CDC). Real-time tracking of every change made to the database, which is the backbone of Turso's newer sync story.
Full-text search, powered by the tantivy library, again without an extension.
Encryption at rest and incremental view maintenance (via DBSP), both still marked experimental.
Multi-language support out of the box: official packages for Rust, JavaScript/TypeScript, Python, Go, with more community drivers (PHP/Laravel, .NET) appearing in the ecosystem.
A genuinely open contribution model. Unlike SQLite's core, which uses a closed test suite, Turso is built with public deterministic simulation testing and fuzzing against SQLite's own bytecode output, specifically so outside contributors can verify their changes.

In short: if you have ever wanted SQLite with safer memory handling, real concurrent writes, and vector search baked in, this project is aimed squarely at you.

Setting it up locally

1. Install the CLI

curl --proto '=https' --tlsv1.2 -LsSf \
  https://github.com/tursodatabase/turso/releases/latest/download/turso_cli-installer.sh | sh

Windows users can use the PowerShell installer linked from the releases page instead.

2. Launch the shell

tursodb

This drops you into an interactive shell connected to a transient in-memory database:

turso> CREATE TABLE users (id INT, username TEXT);
turso> INSERT INTO users VALUES (1, 'alice');
turso> INSERT INTO users VALUES (2, 'bob');
turso> SELECT * FROM users;
1|alice
2|bob

Use .open FILENAME inside the shell if you want a persistent file instead of an in-memory database.

3. Prefer Docker or building from source?

# build and run the dev version
cargo run

# or with Docker
make docker-cli-build && make docker-cli-run

4. Pick a language binding

Rust:

cargo add turso

let db = Builder::new_local("sqlite.db").build().await?;
let conn = db.connect()?;
let res = conn.query("SELECT * FROM users", ()).await?;

JavaScript/TypeScript:

npm install @tursodatabase/database

import { connect } from '@tursodatabase/database';
const db = await connect('sqlite.db');
const stmt = db.prepare('SELECT * FROM users');
const users = stmt.all();

Python:

uv pip install pyturso

import turso
con = turso.connect("sqlite.db")
cur = con.cursor()
res = cur.execute("SELECT * FROM users")
print(res.fetchone())

Go:

go get turso.tech/database/tursogo

conn, _ := sql.Open("turso", "sqlite.db")
defer conn.Close()

That's the entire local setup. No server, no daemon, no config file: it runs in-process exactly like SQLite always has.

Setting up sync to the cloud

If you want a local-first app that stays in sync with a remote primary, Turso's newer sync package is the relevant piece:

npm install @tursodatabase/sync

import { connect } from "@tursodatabase/sync";

const db = await connect({
  path: "./my-app.db",
  url: "libsql://your-db.turso.io",
  authToken: "your-token",
});

You will need a Turso Cloud database and auth token for the url and authToken fields, both available through the turso CLI or the Turso dashboard. This sync layer is what replaces libSQL's older "embedded replicas" feature, and the project's own team now recommends it over the legacy approach for any new sync work, citing faster replica bootstrap and lower bandwidth use thanks to the async, page-level sync protocol.

The honest caveats

The repository itself is upfront about this, and it is worth repeating rather than glossing over: this software is in beta. The maintainers explicitly warn that it may contain bugs and unexpected behavior, and they recommend caution with production data and proper backups.

A few specifics worth knowing before you commit to it:

MVCC has real limitations today. Indexes cannot currently be created on MVCC-enabled databases, and the entire dataset is eagerly loaded into memory on first access, so very large databases can be slow to start and memory-hungry.
Query result ordering isn't guaranteed to match SQLite in every case, which can matter if your tests or application logic implicitly depend on row order.
Several headline features are explicitly experimental: encryption at rest, incremental computation, and multi-process WAL coordination all carry that label in the project's own documentation.
libSQL is still the production recommendation for most things. The maintainers say plainly that libSQL is production ready while the Rust engine is not, even though it is evolving quickly.

None of this is a knock against the project. It is a young, fast-moving rewrite being built in the open, with public fuzzing against SQLite's own bytecode output as a compatibility check. That is a genuinely rigorous approach. It just means "beta" is not a formality here.

Is it worth a try?

For side projects, prototypes, and anything where you can tolerate some rough edges, yes, it is worth trying. The setup cost is close to zero: one shell script, no servers, and your existing SQLite knowledge mostly transfers directly. If your workload involves frequent concurrent writes, embeddings and vector search, or you simply want to watch where SQLite is heading next, this is a good time to kick the tires.

A reasonable way to think about it: Turso is not trying to be "yet another database." It is trying to answer a fairly specific question, whether SQLite's simplicity can be carried forward into a memory-safe, async-native, concurrent-write world without losing what made SQLite SQLite.

Stop Making Your AI Coding Agent Grep Your Whole Repo — Try codebase-memory-mcp

ArshTechPro — Sat, 20 Jun 2026 22:01:23 +0000

If you use an AI coding agent — Claude Code, Codex CLI, Gemini CLI, Cursor, Zed, Aider, whatever — you've probably watched it burn through tens of thousands of tokens just trying to figure out who calls a function or where a route is defined. It greps, it reads files, it greps again, it reads more files. Eventually it answers your question, but it took a small forest of tokens and several tool calls to do it.

codebase-memory-mcp is an open-source MCP server built to fix exactly that. It indexes your codebase into a persistent knowledge graph — functions, classes, call chains, HTTP routes, cross-service links — and lets your agent ask structural questions directly instead of reading its way through the filesystem.

Here's what's actually in it for you.

The pitch in one paragraph

You install a single static binary. You tell your agent "index this project." A few seconds to a few minutes later (yes, even the Linux kernel — 28 million lines of code — takes about 3 minutes), your agent can ask things like "what calls ProcessOrder?" or "show me the architecture of this service" and get an answer in under a millisecond, instead of grepping and reading dozens of files. No Docker, no API keys, no separate database to run. It's just a binary that talks MCP.

Why this matters: the token math

This is the number that should get your attention. According to the project's own benchmarks, five typical structural queries cost roughly 3,400 tokens through codebase-memory-mcp, versus about 412,000 tokens doing the equivalent file-by-file grep-and-read exploration. That's a 99 percent reduction. Less context burned on exploration means more budget left for the agent to actually reason about your problem — and a noticeably faster, cheaper session.

What it actually does

At its core, codebase-memory-mcp is a structural analysis backend, not another LLM wrapper. It parses your code with tree-sitter, builds a graph of how everything connects, and exposes that graph through 14 MCP tools. Your agent is still the brain — it just stops having to rediscover your codebase from scratch every session.

A typical interaction looks like this:

You: "what calls ProcessOrder?"
Agent calls: trace_call_path(function_name="ProcessOrder", direction="inbound")
codebase-memory-mcp: executes the graph query, returns structured results
Agent: presents the call chain in plain English

No extra LLM, no extra API key, no extra cost layer — the agent you're already paying for does the translation from natural language to graph query.

The features that actually matter day to day

It's fast, even on huge repos. RAM-first indexing pipeline (LZ4 compression, in-memory SQLite, single dump at the end). Benchmarked on an Apple M3 Pro, the Linux kernel indexes in about 3 minutes; a mid-sized project like Django takes around 6 seconds. Memory is released back to the OS once indexing finishes.

It speaks 155 languages. Tree-sitter grammars for all of them are vendored directly into the binary, so there's nothing extra to install. Go, C, C++, and the TypeScript/JavaScript/JSX/TSX family additionally get LSP-style hybrid type resolution — proper parameter binding, return-type inference, generic substitution, and JSDoc inference for plain JS files.

It plugs into 11 coding agents automatically. Running the installer auto-detects Claude Code, Codex CLI, Gemini CLI, Zed, OpenCode, Antigravity, Aider, KiloCode, VS Code, OpenClaw, and Kiro, and configures MCP entries, instruction files, and hooks for whichever ones you have installed.

It understands more than just application code. Dockerfiles, Kubernetes manifests, and Kustomize overlays get indexed as graph nodes too, with cross-references between them — useful if your agent needs to reason about infrastructure as well as application logic.

It finds dead code, traces blast radius, and detects near-duplicates. Beyond simple search, there's Louvain community detection for discovering functional modules, git-diff impact mapping that classifies risk for uncommitted changes, dead code detection (excluding entry points), and MinHash-based near-clone detection.

It can visualize the graph. An optional UI binary variant ships a built-in 3D graph visualization you can open in a browser at localhost:9749, running alongside the MCP server as a background thread.

Your team doesn't all have to reindex separately. A .codebase-memory/graph.db.zst artifact can be committed alongside your source — a zstd-compressed snapshot of the graph. When a teammate clones the repo and runs the indexer for the first time, it imports that snapshot and only does an incremental diff locally, instead of a full reindex. It's entirely optional and gitignore-friendly if you'd rather everyone start fresh.

Getting started

The one-line install on macOS or Linux:

curl -fsSL https://raw.githubusercontent.com/DeusData/codebase-memory-mcp/main/install.sh | bash

Add -s -- --ui on the end if you want the graph visualization included.

On Windows, download install.ps1 and run it from PowerShell. There's also a manual route if you'd rather inspect everything first: download the platform-specific archive from the latest release, extract it, and run the bundled install script.

Once installed, restart your coding agent and just say:

"Index this project"

That's the entire setup. If you want indexing to happen automatically whenever you open a new project, turn on auto-index:

codebase-memory-mcp config set auto_index true

After the initial index, a background watcher keeps the graph in sync with your git changes, so you're not manually re-indexing every time you commit.

What you get to ask it

Once a project is indexed, here's a sample of what's available through the 14 MCP tools:

search_graph — structured search by label, name pattern, file pattern, or degree filters
trace_call_path — BFS traversal showing what calls a function and what it calls, up to depth 5
get_architecture — a one-call overview of languages, packages, entry points, routes, hotspots, and clusters
detect_changes — maps your current git diff to the symbols it affects, with risk classification
query_graph — Cypher-like queries, e.g. MATCH (f:Function)-[:CALLS]->(g) WHERE f.name = 'main' RETURN g.name
semantic_query — vector search over the whole graph using bundled embeddings, no API key required
manage_adr — CRUD operations for Architecture Decision Records, so design decisions persist across sessions
get_code_snippet, search_code, ingest_traces, and several more

Everything is also callable directly from the command line if you want to script against it:

codebase-memory-mcp cli search_graph '{"name_pattern": ".*Handler.*", "label": "Function"}'
codebase-memory-mcp cli trace_call_path '{"function_name": "Search", "direction": "both"}'

On trust and security

Reasonable question to ask of any tool that reads your entire codebase: every release binary is scanned by 70+ antivirus engines on VirusTotal before publishing, carries SLSA Level 3 build provenance you can verify with gh attestation verify, is signed with Sigstore cosign, and ships SHA-256 checksums. There are zero runtime dependencies — every library is vendored at compile time, so there's no transitive supply chain to worry about. All processing happens locally; your code doesn't leave your machine.

Should you use it?

If your agent sessions are eating context on repetitive file exploration, or you work in a large monorepo where "where is this used" is a constant question, this is a low-effort, high-leverage addition to your setup. It's a single binary, the install is one command, and the worst case is you uninstall it and you're back where you started — codebase-memory-mcp uninstall cleanly removes configs, hooks, and instructions without touching your binary or databases.

Repo's here if you want to dig in further or check the source before running it: github.com/DeusData/codebase-memory-mcp

WWDC 2026 - WidgetKit Foundations: A Practical Guide for Developers

ArshTechPro — Thu, 18 Jun 2026 21:42:52 +0000

What makes a widget worth building

Apple frames good widgets around three qualities, and they're worth keeping in your head as design constraints, not just slogans:

Glanceable — someone should understand it in a fraction of a second. Think Weather showing you just enough of today's forecast.
Relevant — content should match the moment, the place, and the person's patterns. Calendar surfacing your next event is the canonical example.
Personalizable — it should be configurable with the content that matters to that specific user.

These three map directly onto the technical decisions you'll make: glanceable drives your view design, relevant drives your timeline strategy, and personalizable drives whether you reach for a configurable (App Intent) widget.

The mental model: how a widget actually runs

This is the part most newcomers get wrong, so it's worth being precise.

Your widgets are delivered to the system from a widget extension, which is a separate process from your app. That separation has a real consequence: your app can't just hand data to the extension in memory. You share data through an app group container — a shared database, or UserDefaults backed by the group. Wire this up early; it's the thing people forget.

Whether your app is UIKit or SwiftUI, the widgets themselves are always built in SwiftUI.

The data flow is:

WidgetKit asks your extension for content.
That content is a timeline — a series of timeline entries.
Each entry carries the data needed to render your view at a specific point in time.
The rendered views are archived, and the system displays each one at its relevant time.

The key insight hiding in step 4: your code is not running while the widget is on screen. The system renders archived views. This explains a lot of WidgetKit's API design, including why interactive elements use App Intents rather than closures.

Building your first widget

When you add a widget extension target, Xcode scaffolds most of what you need. The body returns a WidgetConfiguration, and you pick one of two types:

StaticConfiguration — the widget configures itself. Simplest option.
AppIntentConfiguration — the user configures it (more on this below).

For a widget that always shows "the book I'm currently reading," static configuration is the right call. It needs three things: a kind (a unique string identifier), a timeline provider, and a closure that turns an entry into a view.

struct DailyReadingGoalWidget: Widget {
    let kind = "DailyReadingGoalWidget"

    var body: some WidgetConfiguration {
        StaticConfiguration(
            kind: kind,
            provider: DailyReadingGoalProvider()
        ) { entry in
            DailyReadingGoalView(book: entry.book,
                                 message: entry.message,
                                 timeOfDay: entry.timeOfDay)
            .environment(\.colorScheme, .dark)
            .containerBackground(for: .widget) {
                Background()
            }
        }
    }
}

Two things to call out here:

You reuse your app's existing SwiftUI views. If your app is already SwiftUI, the view you pass to the closure is often a view you already have.
containerBackground(for: .widget) is not optional polish. It tells the system which view is your background. When someone applies a colored or clear tint to their Home Screen, the system swaps that background for an adaptive glass material. Skip it and your widget will look broken in tinted environments.

The timeline provider: three states you must handle

Your provider supplies three distinct things, and conflating them is a common bug source:

Snapshot — a realistic preview shown in the widget gallery. This is your first impression, and crucially, your app may have zero user data at this point. Don't show an empty shell. Feature representative sample content (the session uses a popular book with a default message) so people can imagine the widget at its best before adding it.

Placeholder — the stand-in the system shows while your real timeline loads for the first time. It must appear instantly, so fetching a placeholder is synchronous — no disk reads, no network. The clean trick here is SwiftUI's .redacted(reason:) modifier to render a skeleton version of your real view.

Timeline entry — what your widget shows at a specific moment, now or in the future. Your provider returns a collection of these, and the system renders each at its time. Each entry should carry everything the view needs (message, progress, title, cover, etc.).

Reload policies: keeping content fresh without burning battery

Timelines eventually run out of entries and need refreshing — that's a reload. You declare reload behavior with one of three policies, and choosing correctly is most of the skill here.

.atEnd — reload once all entries are exhausted. Use it when there's no single known "refresh at" time but the timeline will run dry. A widget cycling motivational messages at varied times throughout the day fits this: reload when the last entry has been shown.

.afterDate — reload at a specific date you name. Use it when you know the moment things change. A daily schedule that recalculates at end of day is the textbook case: hand the system "today" and "tomorrow," set the reload for end of day, and provide a fresh schedule when you're asked again.

.never — the widget won't reload on its own. Use it when automatic reloads make no sense and updates are driven entirely by interaction. You then trigger refreshes explicitly via WidgetCenter's reload APIs or a push notification. A log that only changes when the user logs something fits here.

A few battery-and-budget realities worth internalizing:

Provide multiple entries whenever possible so the system always has something to show.
WidgetKit gives each widget an update budget, heavily influenced by how often the user actually looks at the widget. Frequent reloads while your app is in the foreground may be throttled.
A good habit: if your data may have changed, fire one reload when your app enters the background.
If your content is genuinely ephemeral — a defined start/end, frequent updates, alerting (think live sports) — that's not a widget, that's a Live Activity.

One widget, many sizes — and a new family

Once your extension and provider are wired up, supporting additional families is mostly view work. You list what you support with .supportedFamilies, reuse the same provider, and build a SwiftUI view that suits each shape.

struct DailyReadingGoalWidget: Widget {
    let kind = "DailyReadingGoalWidget"

    var body: some WidgetConfiguration {
        StaticConfiguration(
            kind: kind,
            provider: DailyReadingGoalProvider()
        ) { entry in
            DailyReadingGoalView(book: entry.book,
                                 message: entry.message,
                                 timeOfDay: entry.timeOfDay)
            .environment(\.colorScheme, .dark)
            .containerBackground(for: .widget) {
                Background()
            }
        }
        .supportedFamilies([.systemMedium])
    }
}

Apple's guidance is to support as many sizes as make sense so people have placement choices — but starting with one or two families is perfectly fine. Notably, the system extra large portrait family (originally introduced on visionOS 26) is now coming to macOS, iOS, and iPadOS, giving large content a lot more room to breathe.

Also worth knowing: an iOS widget isn't confined to iOS. It can show up on CarPlay and as a remote widget on macOS without extra work — which is exactly why testing across environments matters later.

Integrating the widget with your app

A widget is an extension of your app, and there are three levers to tie them together.

Deep links

By default, tapping a widget opens your app. If the widget shows specific content, send people straight to it with .widgetURL. Encode whatever you need (here, a book ID) so the app launches directly to the right screen.

struct DailyReadingGoalWidget: Widget {
    let kind = "DailyReadingGoalWidget"

    var body: some WidgetConfiguration {
        StaticConfiguration(
            kind: kind,
            provider: DailyReadingGoalProvider()
        ) { entry in
            DailyReadingGoalView(book: entry.book,
                                 message: entry.message,
                                 timeOfDay: entry.timeOfDay)
            .environment(\.colorScheme, .dark)
            .containerBackground(for: .widget) {
                Background()
            }
            .widgetURL(URL(string: "bookclub://reading/\(book.bookID)"))
        }
        .supportedFamilies([.systemMedium])
    }
}

Configurable widgets

This is where AppIntentConfiguration earns its place. Let people pick the content the widget tracks — a location for weather, a specific book to log, and so on. Configurable widgets also let users add several copies with different settings (three widgets, three books).

Apple's practical rules for configuration are good ones:

Ask whether content should differ per user before adding configuration at all.
Keep it fast — one or two parameters is usually enough.
Don't require configuration up front. Provide a sensible default (the most recently read book, for instance) so the widget is useful immediately and tweakable later.

If you're going down this road, the relevant deep dive is Explore enhancements to App Intents (WWDC23).

Interactive elements

Buttons and toggles let people act directly from the widget — checking off a task, completing a chapter. Remember the archived-view reality: your code isn't running on screen, so buttons and toggles take an App Intent the system executes on your behalf. Pick the single most important action in your app and surface that one. For the full treatment, see Bring widgets to life (WWDC23).

Adapting to tinted and clear environments (don't skip this)

On iOS the Home Screen can be tinted with a color or set to a clear style. In those modes the system renders your widget through a glass material — tinting your content and replacing your background with adaptive glass. SwiftUI handles most of it (this is also why containerBackground matters), but you still have to verify.

The session walks through a real bug: in clear mode, a book cover image rendered as a plain white rectangle because the system couldn't accent it correctly. The fix is to tell the system how that image should render:

struct BookCoverImage: View {
    let imageName: String

    var body: some View {
        Image(imageName: bundle: .main)
            .widgetAccentedRenderingMode(.fullColor)
    }
}

Using .fullColor keeps the cover art in its original colors even in accented rendering mode. The broader lesson: imagery especially needs an explicit rendering decision, because the system's default accenting can mangle photographic or full-color assets.

A testing checklist before you ship

Pulling the session's testing advice into a list you can actually run through:

Test on real devices in full color, tinted, and clear modes.
Remember iOS widgets appear as remote widgets on macOS — verify interactions still feel right from a Mac.
Lean on SwiftUI previews: the Xcode canvas lets you flip through families, color schemes, and rendering modes without leaving the editor.
Turn on WidgetKit developer mode during testing to lift constraints like reload budgets so you can iterate quickly.

The takeaways

If you remember nothing else:

A widget extension is a separate process; share data through an app group.
Content is a timeline of entries; handle snapshot, placeholder, and timeline distinctly, and keep placeholders synchronous.
Pick a reload policy that matches reality — .atEnd, .afterDate, or .never — and respect the update budget.
Use containerBackground and widgetAccentedRenderingMode so the widget survives tinted and clear Home Screens.
Tie it to your app with deep links, configuration, and interactive App Intents — and test everywhere the widget can appear, including macOS.

Widgets remain one of the highest-leverage surfaces you can add to an app: small to build, and a genuine extension of your app's reach across the system. This session is a clean foundation to build on.

WWDC 2026 - Migrate to Swift Testing: What Actually Means for Your Test Suite

ArshTechPro — Tue, 16 Jun 2026 03:42:57 +0000

Swift Testing shipped with Xcode 16 back in 2024.

Swift Testing was built from the ground up for Swift. That means Swift concurrency is a first-class citizen, test cases run in parallel by default, and the API surface is dramatically smaller than XCTest's forty-plus assertion functions. One macro, #expect, replaces most of them.

If you are still on XCTest, you have probably felt the friction: class inheritance for every test suite, function names that must start with test, assertion messages that tell you what the values were but not where the expression came from. Swift Testing fixes all of this.

That said, you do not need to migrate everything at once, and WWDC 2026 is emphatic about this.

The Migration Strategy: Small Chunks, No Big Bang

The session opens with something refreshing: permission to be slow about this.

The recommended approach is to leave your existing XCTests where they are and start using Swift Testing only for new tests. Both frameworks can coexist in the same target and even the same file. You do not need a separate test target, and you do not need a migration sprint.

The one rule: Swift Testing tests cannot live inside XCTestCase subclasses. Everything else is fair game.

Raw Identifiers for Readable Test Names

One small quality-of-life improvement worth knowing about from the start: Swift supports raw identifiers using backticks, and Swift Testing takes full advantage of this.

import Testing

@testable import DemoApp

@Test func `Default climate: tropical`() async throws {
    let fruit = Fruit(name: "Coconut")
    #expect(fruit.climate == .tropical)
}

No more testDefaultClimateTropical or dealing with camelCase names in test output. The test name is the test name.

Interoperability: The Key to Reusing Your Helper Code

This is the main new story in WWDC 2026 and the feature that makes incremental migration actually work.

The problem: you have test helper functions that wrap XCTFail. You want to call them from new Swift Testing tests. Previously, this was messy. Now, it works by design.

Interoperability is a feature that lets you safely call API from one test framework inside a test written in the other. So a Swift Testing test can call a helper that internally uses XCTFail, and XCTest tests can use Swift Testing's Issue.record and expectation macros.

Three Interoperability Modes

The session introduces three modes, and understanding them is important for knowing what level of strictness you want:

Limited mode -- Cross-framework issues from XCTest become warnings, not errors. Tests still pass. This is the default for test plans created before Xcode 27.

Complete mode -- Those same warnings become errors. The test will fail. This is the default for new projects in Xcode 27.

Strict mode -- Cross-framework issues from XCTest cause a fatal error and stop the test immediately at the point of the bad call. This is useful when you want to systematically find every place you need to replace XCTest API.

You can change modes in your Test Plan settings under "Test Execution," or for Swift Package projects using an environment variable:

SWIFT_TESTING_XCTEST_INTEROP_MODE=strict swift test

For SPM projects, complete mode requires bumping to swift-tools-version: 6.4 or newer.

Migrating a Helper Function

Here is a typical helper before migration:

func assertUnique(_ fruits: [Fruit], file: StaticString = #filePath, line: UInt = #line) {
    var uniqueNames = Set<String>()
    for name in fruits.map(\.name) {
        if !uniqueNames.insert(name).inserted {
            XCTFail("Duplicate name: \(name)", file: file, line: line)
        }
    }
}

After migrating to Swift Testing:

import Testing

func assertUnique(_ fruits: [Fruit], sourceLocation: SourceLocation = #sourceLocation) {
    var uniqueNames = Set<String>()
    for name in fruits.map(\.name) {
        if !uniqueNames.insert(name).inserted {
            Issue.record("Duplicate name: \(name)", sourceLocation: sourceLocation)
        }
    }
}

XCTFail becomes Issue.record. The file and line parameters become a single SourceLocation parameter. The helper can now be called cleanly from both Swift Testing tests and existing XCTests.

Common Migration Patterns

The session walks through two patterns that come up in almost every migration.

Skipping Tests

XCTest uses XCTSkipIf. In Swift Testing, the direct replacement is Test.cancel, but the preferred approach is a trait:

let isFall = false

// XCTest
func testSwallowFallMigration() async throws {
    try XCTSkipIf(!isFall, "Wrong season for migration")
}

// Swift Testing via Test.cancel (works but not ideal)
func testSwallowFallMigration() async throws {
    if !isFall {
        try Test.cancel("Wrong season for migration")
    }
}

// Preferred: use a trait
@Test(.enabled(if: isFall, "Wrong season for migration"))
func `Swallow fall migration`() async throws {
    // ...
}

Moving the condition into a trait keeps the test body clean and makes the enablement logic visible at a glance.

Halting After Failures

In XCTest, you set continueAfterFailure = false to stop on the first failure. In Swift Testing, you use #require instead of #expect for the assertions where failure should halt the test:

func testExample() async throws {
    #expect(Fruit.banana.climate == .temperate)

    // If this fails, the test stops here
    try #require(Fruit.banana == Fruit.plantain)

    // This line is only reached if #require passed
}

The benefit over XCTest's approach: you get fine-grained control over which expectations are fatal and which are not, rather than a single global flag.

What You Unlock After Migrating

The second half of the session is about capabilities that simply do not exist in XCTest.

Parameterized Tests

This is one of the most impactful changes for test suites that have grown unwieldy with repetitive test methods.

Before, you might write a nested loop inside a single test:

@Test func `Birds flap wings successfully`() async throws {
    for bird in Aviary.birds {
        for count in (40...100) {
            try await bird.flapWings(count: count)
        }
    }
}

The problem: when it fails, you do not know which bird or which count triggered the failure. The whole loop is one test case.

After converting to a parameterized test:

@Test(arguments: Aviary.birds, 40...100)
func `Birds flap wings successfully`(bird: Bird, count: Int) async throws {
    try await bird.flapWings(count: count)
}

Swift Testing generates a separate test case for every combination of bird and count. All cases run in parallel. When something fails, the Test navigator shows you exactly which inputs caused the failure. In the session's demo, the refactored test also finished significantly faster because of parallel execution.

Exit Tests

Exit tests let you write coverage for code that is expected to crash -- preconditionFailure, fatalError, and similar calls that have historically been impossible to test without crashing your entire test process.

Given this code in a Bird initializer:

if name.isEmpty {
    preconditionFailure("Bird name cannot be empty")
}

You can now write:

@Test func `Bird with empty name crashes`() async throws {
    await #expect(processExitsWith: .failure) {
        _ = Bird(name: "")
    }
}

Swift Testing runs the body of the exit test in a child process. If that process exits with the expected condition, the test passes. The crash is isolated, so it cannot affect any other test. Exit tests are supported on macOS, Linux, FreeBSD, and Windows.

This finally gives you a way to get code coverage on defensive guards that were previously invisible to your test suite.

What Stays in XCTest

The session is clear about what not to migrate:

UI automation tests using XCUIApplication
Performance tests using XCTMetric
Tests that catch Objective-C exceptions (only Objective-C code can handle these safely)

For everything else, Swift Testing is the better home.

Xcode's Migration Assistance

One practical note from the session: Xcode 27's Coding Assistant is aware of the migration documentation and can help formulate a strategy, review your work, and automate parts of the migration. If you are staring at a large test suite and not sure where to start, that is worth exploring.

The Summary

The path forward is clear and low-risk:

Keep your existing XCTests where they are. Do not touch them until you are ready.
Write all new tests using Swift Testing.
Enable interoperability and start with limited mode. Gradually move to complete or strict as you migrate individual helpers.
When you update a helper, replace XCTFail with Issue.record and update the source location parameter.
Look for nested loops in your tests -- those are candidates for parameterized tests.
Add exit tests anywhere you have preconditionFailure or fatalError with no coverage.

The migration is not a one-time event. It is a gradual shift that Xcode 27 is explicitly designed to support.

WWDC 2026 - What's New in SwiftData: Sectioned Queries, Codable Attributes, and Observers

ArshTechPro — Mon, 15 Jun 2026 10:38:35 +0000

WWDC 2026's "What's new in SwiftData" session is a tight, practical one. There's no sweeping redesign here, just four targeted additions that fill gaps developers have been working around for a while. If you've ever fought SwiftData to group a list, store a type you don't own, or react to data changes outside a SwiftUI view, this release is for you.

Here's everything that's new and how to use it.

1. Sectioned fetching with @Query

Grouping a list by some property used to mean fetching everything flat and then partitioning it yourself in the view. Now @Query does it for you.

You pass a key path to the new sectionBy: parameter. The key path starts at the model root and points to the property you want to group on:

struct TripListView: View {
    @Query(sort: \Trip.startDate,
           sectionBy: \.destination)
    var trips: [Trip]

    var body: some View {
        List(selection: $selection) {
            ForEach(_trips.sections) { section in
                Section(section.id) {
                    ForEach(section) { trip in
                        TripListItem(trip: trip)
                    }
                }
            }
        }
    }
}

A few things to notice:

The wrapped value (trips) is still a plain [Trip], so existing code that reads it keeps working unchanged.
To reach the sections, you use the underscore-prefixed projected value _trips, which exposes a sections property.
Each section has an id (the value from your sectionBy key path, in this case the destination string) and is itself a collection of models you can iterate.

So adding sections is additive: keep your flat array where you had it, and reach for _trips.sections only where you actually want the grouping. Sorting still applies across the whole result set, which keeps section ordering predictable.

2. Storing custom types with @Attribute(.codable)

SwiftData builds a schema by inspecting your models at launch. That works automatically for its supported value types and for anything you mark @Model. It falls apart the moment you try to persist a class you don't control.

The session's example is MKMapItem.Identifier from MapKit. Add it to a model as-is and the app crashes at launch with:

Class property within Persisted Struct/Enum is not supported

The reason: SwiftData can't inspect a non-@Model class to generate a schema, and you can't go annotate a type that lives inside MapKit.

The fix in this release is a new attribute option. If the type conforms to Codable, mark the property @Attribute(.codable) and SwiftData stores the encoded representation instead of trying to model it:

import SwiftData

@Model
class Trip {
    struct Location: Codable {
        var latitude: Double
        var longitude: Double
    }

    var name: String
    var destination: String

    var startDate: Date
    var endDate: Date

    var location: Location?

    @Attribute(.codable)
    var mapItemIdentifier: MKMapItem.Identifier?
}

This is genuinely useful, but treat it as an escape hatch, not a default. The trade-offs matter:

Opaque to SwiftData. A codable attribute is stored as a serialized blob, so you can't use it in predicates to filter or in sort descriptors to sort.
No migration awareness. If the shape of the codable type changes (you add or remove a property), it won't trigger a migration. Your Codable implementation has to encode and decode in a forward- and backward-compatible way on its own.

The rule of thumb from the session: use .codable for types you don't own (framework or third-party types). For types you define, model them as @Model or use supported value types so you keep filtering, sorting, indexing, and migrations.

3. Observing query results anywhere with ResultsObserver

@Query is great, but it only lives inside SwiftUI views. It fetches when the view appears and keeps watching the store, re-rendering when results change. The problem: plenty of code isn't a SwiftUI view. A state object that derives values from your store, or an app with no SwiftUI at all (think a SceneKit game), had no clean equivalent.

ResultsObserver is that equivalent. It fetches from your store and observes for changes using Swift Observation, and it works anywhere. It supports the same primitives you already know from @Query: filtering, sorting, and the sectioning above.

The session uses it to drive a map camera that should always frame all your trips:

@Observable @MainActor
final class MapCameraController {
    private let resultsObserver: ResultsObserver<Trip>
    var bounds: MapCameraBounds?
    private var token: ObservationTracking.Token?

    init(modelContext: ModelContext) throws {
        resultsObserver = try ResultsObserver<Trip>(modelContext: modelContext)

        token = withContinuousObservation(options: [.didSet]) { [weak self] event in
            guard let self else { return }
            self.bounds = self.calculateBounds(trips: self.resultsObserver.results)
        }
    }

    private func calculateBounds(trips: [Trip]) -> MapCameraBounds? { /* ... */ }
}

How it fits together:

You create a ResultsObserver for the model. No predicate and no section key path here means "give me everything."
withContinuousObservation(options: [.didSet]) gives you a callback whenever the results change. Read resultsObserver.results inside the closure to get the current set.
The call returns an ObservationTracking.Token. That token defines the lifetime of the observation, so store it on the object to keep updates flowing for as long as the object lives. Drop the token and observation stops.

In the demo, deleting a trip fires the observation, recalculates the bounds, and the map re-frames. The mental model is "@Query, but for non-view code."

A naming note: the session and Apple's chapter summaries call this ResultsObserver, while Apple's published sample snippet writes ModelResultsObserver<Trip>. Check the final SwiftData headers in your SDK for the exact spelling when you adopt it.

4. Reacting to store changes with HistoryObserver

The second observer targets a different problem: syncing and reacting to changes rather than reading current results.

Quick refresher on SwiftData history. Every time your store is saved, SwiftData records a history transaction describing what changed, where the change came from (the author), and a token that uniquely identifies it. You fetch newer transactions with ModelContext.fetchHistory. (The WWDC 2024 session "Track model changes with SwiftData history" covers the foundations.)

HistoryObserver makes reacting to that history easy. It exposes a single observable property, eventCounter, which increments whenever new transactions land. You observe the counter, and when it ticks, you fetch and process the new history. You can also filter by model type and by transaction author, which is what makes server sync clean:

@SyncActor
final class ServerSync {
    private var observer: HistoryObserver?
    private var token: ObservationTracking.Token?

    func start() throws {
        let observer = try HistoryObserver(
            authors: ["App"],
            modelContainer: modelContainer
        )
        self.observer = observer

        token = withContinuousObservation(options: .didSet) { [weak self] _ in
            // Touch eventCounter so Swift Observation tracks it
            _ = self?.observer?.eventCounter
            self?.processChanges()
        }
    }

    private func processChanges() {
        // Use ModelContext.fetchHistory to fetch and upload changes
    }
}

The important details:

Filtering by authors: ["App"] means you only see changes your app made. That's how you avoid replaying server-originated changes back to the server in an infinite loop.
You must actually read eventCounter inside the observation closure. Swift Observation only tracks what you touch, so reading the property is what registers the dependency.
Same lifetime rule as ResultsObserver: hold onto the ObservationTracking.Token for as long as you want to keep observing.

This is the tool for keeping a server, an app extension, or any external system in sync with what's happening in your store.

When to reach for which

A quick way to keep the two observers straight:

Use ResultsObserver when you need the current set of models outside a SwiftUI view and want to recompute when they change (state objects, non-SwiftUI apps, derived values).
Use HistoryObserver when you care about the stream of changes themselves, especially for syncing with something outside your app.

Inside a SwiftUI view, @Query is still your first choice; the observers are for everywhere else.

Wrapping up

This year's SwiftData is about filling gaps rather than reinventing anything:

Sectioned fetching moves grouping into @Query with sectionBy:.
@Attribute(.codable) is an explicit escape hatch for persisting types you don't own, at the cost of querying, sorting, and migration awareness.
ResultsObserver brings @Query-style fetching and observation to non-SwiftUI code.
HistoryObserver gives you a simple, observable signal for reacting to persistent-history changes.

None of these are flashy, but each removes a real workaround. If you've been dropping into manual fetches or hand-rolled grouping, this release lets you delete some code.

WWDC 2026 - Apple's new server LLM on Private Cloud Compute: what's in it for developers

ArshTechPro — Sat, 13 Jun 2026 20:48:40 +0000

Last year Apple gave us an on-device LLM through the Foundation Models framework. This year that on-device model gets better, and Apple adds something many of us asked for: a larger server model you can call directly from your app, running on Private Cloud Compute (PCC).

TL;DR

A new server-class model is now reachable from the same Foundation Models API you already use.
Switching from on-device to server is a one-line change.
You get a 32K context window (vs 4K on-device), reasoning support, and image input.
No API keys, no auth, no token costs to you. Requests are metered against the user's iCloud account, with a daily per-user limit.
Eligible for apps with fewer than 2M downloads. You apply on the developer site.
It works across platforms, including watchOS.

Why a server model when we already have on-device

The on-device model is great for fast, private, offline tasks, and this year it improved: it now supports image input, follows instructions more reliably, and is better at calling your custom tools.

But some features just need more headroom. Think:

Assistants that reason over a large chunk of user input.
Workflows that make many tool calls and produce large outputs.
Tasks where a bigger context window and deeper reasoning materially change quality.

That's where PCC comes in. You get a frontier-class model while keeping Apple's privacy posture intact.

The privacy and pricing story (the part that's genuinely different)

Most server LLMs mean: provision an account, manage API keys, eat token costs, and ship a privacy policy that accounts for it. PCC removes most of that:

Privacy by design. Data is used only for the request and is never stored, and Apple has had this independently verified by researchers.
No keys or auth. PCC is integrated into the OS and iCloud. Your user just needs a device that supports Apple Intelligence.
No token bill for you. Each user gets a daily limit tied to their iCloud account. Users on iCloud+ get higher limits.

The trade-off you're accepting: a network connection is required, and there's a per-user daily cap you need to design around (more on that below).

Integrating it: one line to switch models

If you've used Foundation Models before, prompting the on-device model is three lines:

import FoundationModels

let session = LanguageModelSession()
let response = try await session.respond(to: "Summarize this article: \(article)")

Switching to the PCC server model is a single line, you just hand the session a different model:

import FoundationModels

let session = LanguageModelSession(
    model: PrivateCloudComputeLanguageModel()
)
let response = try await session.respond(to: "Summarize this article: \(article)")

That's the headline ergonomic win. Same unified Swift API, larger model behind it.

Structured output and tools work identically

@Generable structured output and Tool calling behave the same whether you're on-device or on PCC. You don't rewrite anything to move between them:

import FoundationModels

@Generable
struct ArticleSummary {
    let oneLineSummary: String
    let keyPoints: [String]
}

struct FindRelatedArticlesTool: Tool {
    // ...
}

let session = LanguageModelSession(
    model: PrivateCloudComputeLanguageModel(),
    tools: [FindRelatedArticlesTool.self]
)

let response = try await session.respond(
    to: "Summarize this article: \(article)",
    generating: ArticleSummary.self
)

Always check availability

PCC, like the on-device model, only runs on Apple Intelligence devices. Check availability and provide a graceful fallback:

import FoundationModels

struct ArticleSummarizationView: View {
    private var model = PrivateCloudComputeLanguageModel()

    var body: some View {
        if model.isAvailable {
            // Show UI for making request
        } else {
            // Fall back
        }
    }
}

On-device vs PCC: how to choose

Both are private. The rest is a set of trade-offs:

Factor	On-device	PCC server
Privacy	Yes	Yes
Works offline	Yes	No (needs connection)
Request limits	None	Daily per-user limit
Context size	4K	32K
Reasoning	No	Yes

The session's advice is worth repeating: pick the model based on data, not vibes. The updated on-device model may handle more than you'd expect, and it has no request limits. The only way to know is to evaluate your specific feature (Apple's new Evaluations framework, covered in "Meet the Evaluations framework," is built for exactly this).

Reasoning levels

PCC supports reasoning, where the model generates extra "thinking" text in a separate transcript segment before producing the final answer. There are three levels:

.light gathers a bit of extra context.
.moderate reasons a little deeper.
.deep can produce a reasoning segment longer than the answer itself.

You set it per request:

let response = try await session.respond(
    to: prompt,
    contextOptions: ContextOptions(reasoningLevel: .light)
)
// Reasoning levels: .light, .moderate, .deep

Two things to keep in mind:

Reasoning is generated text, so it consumes tokens and counts against your context limit.
The reasoning lives in the session transcript, so you can observe the transcript to show progress. This matters most with .deep, which can take a while.

Reading context size programmatically

You can now query context size directly instead of hardcoding it:

SystemLanguageModel().contextSize
// 4096 on 26.0
// 8192 on 27.0 (newer devices)

PrivateCloudComputeLanguageModel().contextSize
// 32768

Handling usage limits (don't skip this)

Because requests are metered against the user's iCloud account, your app will eventually hit a user who's at their daily cap. If the only thing that happens is a thrown error surfaced in the UI, that's a poor, non-actionable experience.

Instead, inspect quotaUsage and render persistent, actionable UI:

struct ArticleSummarizationView: View {
    private var model = PrivateCloudComputeLanguageModel()

    var body: some View {
        if case .belowLimit(let info) = model.quotaUsage.status {
            if info.isApproachingLimit {
                Text("Nearing usage limit.")
                    .foregroundStyle(Color.orange)
            }
        }
        if model.quotaUsage.isLimitReached {
            Text("Usage limit exceeded.")
                .foregroundStyle(Color.red)
        }
        if let suggestion = model.quotaUsage.limitIncreaseSuggestion {
            Button("Show options") {
                suggestion.show()
            }
        }
    }
}

Design guidance from the session:

Avoid alerts. Use UI that persists and isn't dismissed, for example a disabled request button with a subtle label beneath it.
Offer the upgrade path. limitIncreaseSuggestion lets the user manage or raise their limit (such as upgrading their iCloud account).
Handle the "approaching limit" case too, so users can make informed decisions about which requests are worth spending on.

Testing limit states in Xcode

You don't need to burn real quota to test this. In your scheme, go to Debug > Options and use Simulate Apple Foundation Models Availability. You can select Quota Usage Limit Reached and Nearing Usage Limit to exercise both code paths.

Combining on-device and server models

You're not forced to pick one. A common pattern is to route simple work to the on-device model and escalate harder tasks to PCC. The session points to "Build agentic app experiences with Foundation Models" for that workflow.

Getting access

The server model is available for apps with fewer than 2M downloads, and you apply on the Apple Developer website. If your feature genuinely needs the larger context or reasoning, it's worth applying early.

--
Summary
If you already use Foundation Models, reaching for a bigger model is now a one-line decision, with privacy handled and no token bill to manage. Evaluate, choose the right tier for each task, and design for the daily limit up front.

WWDC 2026 - What's New in Swift

ArshTechPro — Thu, 11 Jun 2026 16:04:12 +0000

Swift 6.3 and 6.4 landed at WWDC 2026 with a strong theme running through them: less boilerplate, fewer surprises, and more control. The session covers four broad areas — language improvements, library updates, cross-platform support, and performance. This article also folds in what shipped in Swift 6.3 earlier this year that the session touched on but did not fully detail.

Language

Better Swift Concurrency diagnostics
Improved Sendable conformances — weak let support, ~Sendable opt-out
More accessible memberwise initializers
anyAppleOS availability shorthand
@diagnose for per-declaration warning control
Module selectors (:: syntax) for disambiguating name conflicts
@c attribute for exposing Swift functions to C code

Library

withTaskCancellationShield for protecting critical work from cancellation
Safe Continuation<Success, Failure> type with compile-time misuse detection
Ref<T> and MutableRef<T> — safe first-class references without unsafe pointers
Dictionary.mapKeyedValues
New FilePath type in Foundation
Swift Testing: issue severity, test cancellation, image attachments, and XCTest interoperability
Subprocess output streaming
ProgressManager for structured async progress reporting
DocC: Markdown output, static HTML content, code block annotations

Performance

@inline(never) / @inline(always) for explicit inlining control
@specialized for pre-compiled generic specializations
@export(implementation) for ABI-stable library optimization
~Copyable and ~Escapable in protocol associated types
borrow and mutate accessors for non-copyable types
MutableRef for hoisting repeated subscript accesses

Cross-Platform

Official Swift SDK for Android
Embedded Swift improvements
Swift Build preview in Swift Package Manager

Language Improvements

Better Swift Concurrency Diagnostics

The compiler now catches more concurrency mistakes and gives you clearer guidance when it does. Two patterns that previously slipped through are now properly diagnosed: catching errors inside a Task block, and saving a task reference for later rendezvous.

// Catching inside a Task
Task {
    do {
        try lander.fly(to: moon)
    } catch {
        lander.abort()
    }
}

// Saving a Task for later
let landingTask = Task {
    try lander.fly(to: moon)
}

defer {
    await orbiter.rendezvous(with: lander)
}

try await orbiter.justHangOut(waitingFor: landingTask)

Improved `Sendable` Conformances

Working with Sendable in class hierarchies just got more expressive. You can now mark a class as ~Sendable to opt out, and weak let properties are supported in Sendable types.

final class Spacecraft: Sendable {
    weak let dockedAt: SpaceStation?  // weak let now works in Sendable types
}

class Mission: ~Sendable { ... }

class CrewedMission: Mission, @unchecked Sendable { ... }

More Accessible Memberwise Initializers

Swift now generates multiple memberwise initializers at different access levels based on property visibility. If a struct has a mix of internal and private properties, you get both an internal initializer (without the private properties) and a private one (with everything). No more hand-writing boilerplate initializers just to work around access control.

struct Briefing {
    internal var topic: String
    internal var scheduledAt: Date
    private  var attendees: [Person] = []
}

// Swift generates both:
// internal init(topic:scheduledAt:)
// private  init(topic:scheduledAt:attendees:)

`anyAppleOS` Availability

Tired of spelling out every Apple platform in availability annotations? Swift 6.4 introduces anyAppleOS as a shorthand that covers iOS, macOS, watchOS, tvOS, and visionOS in one shot. Works in both @available attributes and #if conditions.

// Before
@available(macOS 27, iOS 27, watchOS 27, tvOS 27, visionOS 27, *)
func showStatus() { ... }

// After
@available(anyAppleOS 27, *)
func showStatus() { ... }

#if os(anyAppleOS)
func makeLiveActivityWidget() -> some Widget { ... }
#endif

You can still layer platform-specific exclusions on top:

@available(anyAppleOS 27, *)
@available(tvOS, unavailable)
func launch() { ... }

`@diagnose` — Fine-Grained Warning Control

The new @diagnose attribute lets you control how the compiler treats specific diagnostics on a per-declaration basis. You can silence a deprecation warning, promote a warning to an error, or demote a future error to a warning — all scoped to a single function.

// Silence a deprecation warning with a reason
@diagnose(DeprecatedDeclaration, as: ignored, reason: "Flying with surplus hardware")
func makeApolloSoyuzMission() -> Mission { ... }

// Treat strict memory safety as a warning instead of the default
@diagnose(StrictMemorySafety, as: warning)
func uplinkCommand(from receiver: inout Receiver, to computer: inout Computer) { ... }

// Treat a future Swift error as an error now, ahead of the version bump
@diagnose(ErrorInFutureSwiftVersion, as: error)
func fetchPosition() -> (x: Double, y: Double, z: Double) { ... }

Module Selectors (`::` Syntax)

When two imported modules export the same name, Swift 6.3 gives you a clean way to be explicit: the double-colon module selector. It works on both types and members.

import Rocket
import GiftShopToys

let rocket2 = Rocket.SaturnV()   // ambiguous — prefers Rocket module's Rocket.SaturnV
let rocket3 = Rocket::SaturnV()  // unambiguous — definitely Rocket module's SaturnV

It also resolves method name conflicts from protocol extensions:

// Calls the HumanResources version of fire(), not Chemistry's
launchPadTechnician.HumanResources::fire()

Module selectors also work with the Swift module itself, which is useful when a local name shadows a standard library type:

let task = Swift::Task {
    // async work
}

`@c` Attribute for C Interoperability

Swift 6.3 introduces the @c attribute, which lets you expose Swift functions and enums to C code. Annotating a function with @c causes Swift to include a matching declaration in the generated C header — no manual bridging header edits required.

@c
func callFromC() { ... }

// Generated C header:
// void callFromC(void);

You can provide a custom name for the generated C declaration:

@c(MyLibrary_callFromC)
func callFromC() { ... }

// Generated C header:
// void MyLibrary_callFromC(void);

@c also pairs with @implementation, letting you write a Swift implementation for a function that is already declared in a C header. Swift validates that the signatures match rather than generating a new declaration.

// C header
void callFromC(void);

// Swift implementation
@c @implementation
func callFromC() { ... }

Library Updates

`withTaskCancellationShield`

Sometimes a piece of work must complete even if the parent task is cancelled — like sending an emergency signal. The new withTaskCancellationShield wrapper protects a block of code from task cancellation, letting it run to completion regardless.

extension EmergencyTransponder {
    func sendSOS() {
        withTaskCancellationShield {
            radio.send(makeSOSPacket())
        }
    }
}

Safe Continuations with `Continuation`

Bridging callback-based APIs to Swift concurrency has always required a tradeoff: UnsafeContinuation is fast but silent on misuse, while CheckedContinuation catches mistakes at the cost of extra allocations. Swift 6.3 adds a third option, Continuation<Success, Failure>, that makes double-resume a compile-time error and a missing resume a runtime trap — with no overhead on the fast path.

let value = try await withContinuation { continuation in
    someCallbackAPI { result in
        continuation.resume(returning: result)
    }
}

`Ref<T>` and `MutableRef<T>`

Storing a reference to part of a data structure previously required either a class (heap allocation, reference counting) or UnsafePointer (all the unsafe caveats). Swift 6.3 adds Ref<T> and MutableRef<T> to the standard library: safe types that hold shared and exclusive references to a value respectively, usable as local variables, struct members, and generic type parameters.

`Dictionary.mapKeyedValues`

A small but welcome addition. When you need to transform dictionary values while keeping access to the key, you previously had to construct the result manually. Now there is a purpose-built method for it.

// Before
let new: [Mission: String] = .init(
    uniqueKeysWithValues: missions.lazy.map { mission, launchWindow in
        (mission, makeDisplayName(for: mission, in: launchWindow))
    }
)

// After
missions.mapKeyedValues { mission, launchWindow in
    makeDisplayName(for: mission, in: launchWindow)
}

New `FilePath` Type

Foundation gains a new FilePath type that correctly handles macOS resource forks and named resources (the ..namedresource/rsrc path suffix). When iterating path components, it strips these platform-specific suffixes automatically.

var path: FilePath = "/var/www/static/..namedresource/rsrc"
print(path.components)
// [ "var", "www", "static" ]

Swift Testing: Issue Severity, Test Cancellation, and Image Attachments

Swift Testing picks up three improvements. First, you can record an issue with a .warning severity — useful for soft failures that do not warrant stopping the test.

Issue.record(
    "\(rocket.name) remaining fuel is below 10% reserve target",
    severity: .warning
)

Second, Test.cancel lets a test stop itself early with a message, which is cleaner than a conditional return and more expressive than skipping.

if rocket.engineType == .solid {
    try Test.cancel("\(rocket.name) has solid fuel")
}

Third, you can now attach images to test results on Apple and Windows platforms via new cross-import overlay modules with UIKit and other UI frameworks. Useful for snapshot-style tests where seeing what was rendered matters as much as whether the assertion passed.

XCTest Interoperability

You can now freely mix XCTest assertions and Swift Testing expectations in the same codebase — calling XCTAssertEqual from a Swift Testing test, or using #expect inside an XCTestCase. Migration from XCTest no longer has to be all-or-nothing.

Subprocess Output Streaming

Subprocess now supports streaming output via .sequence, so you can process command output lazily as it arrives instead of waiting for the process to finish.

let result = try await Subprocess.run(.name("ls"),
                                      input: .none,
                                      output: .sequence,
                                      error: .string(limit: 4096)) { execution in
    execution.standardOutput.strings().filter { $0.hasSuffix(".obj") }
}

for try await objectFiles in result.closureOutput {
    print("Object file: \(objectFiles)")
}

Progress Reporting

A new ProgressManager API brings structured progress reporting with Swift concurrency support. Progress can be composed hierarchically using subprogress objects, and updates can be observed with Observations.

let manager = ProgressManager(totalCount: 100)
try await rocket.launch(mission.subprogress(assigningCount: 100))

Task {
    for await update in Observations({ mission.fractionCompleted }) {
        print("Mission \(Int(update * 100))%")
    }
}

DocC Improvements

Swift 6.3 adds three experimental capabilities to DocC worth knowing about if you maintain a library:

Markdown output. Generate Markdown versions of documentation pages alongside the standard rendered JSON using --enable-experimental-markdown-output.

Static HTML content per page. Embed a lightweight HTML summary of each page — title, description, availability, declarations — directly in index.html inside a <noscript> tag. Improves search engine discoverability and screen reader accessibility without requiring JavaScript. Pass --transform-for-static-hosting --experimental-transform-for-static-hosting-with-content to enable it.

Code block annotations. New formatting options for fenced code blocks: nocopy disables the copy-to-clipboard button, highlight highlights specific line numbers, showLineNumbers shows line numbers, and wrap wraps long lines at a column width.

```swift, highlight=[1, 3]
let name = "World"              // highlighted
let greeting = "Hello"
print("\(greeting), \(name)!")  // highlighted
```

Enable with --enable-experimental-code-block-annotations.

Performance

Inlining Control: `@inline(never)` and `@inline(always)`

Swift now exposes explicit inlining attributes for when the optimizer needs a nudge. @inline(never) prevents a function from being inlined — useful for controlling code size or isolating a function during profiling. @inline(always) forces inlining where the performance gain is known and worth the code size cost.

@inline(never)
func makeInts(randomized: Bool) -> [256 of Int] { ... }

@inline(always)
func makeInts(randomized: Bool) -> [256 of Int] { ... }

`@specialized` for Generic Functions

Generic functions generate a single implementation that works for all types. When a specific concrete type is used frequently, @specialized tells the compiler to emit a dedicated, fully optimized version for that type — getting the performance of a non-generic function without giving up the generic API.

@specialized(where Values == [UInt8])
func histogram<Values>(of values: Values) -> [256 of Int] where Values: Sequence<UInt8> {
    // Compiler emits a specialized version for [UInt8]
}

`@export(implementation)` for ABI-Stable Libraries

Library authors building ABI-stable frameworks can now use @export(implementation) to expose a function's implementation to clients, allowing it to participate in more compiler optimizations across module boundaries — without breaking ABI.

`~Copyable` and `~Escapable` in Protocol Associated Types

Protocols can now express that their associated types do not need to be copyable or escapable, enabling more expressive and efficient protocol designs — particularly for iterator and span-based APIs that need to avoid unnecessary copies.

`borrow` and `mutate` Accessors

A new pair of accessors replaces the old get/set pattern for types that wrap unsafe pointers. borrow provides a read-only reference without copying; mutate provides a mutable reference. Together they allow non-copyable types to expose stored properties cleanly and safely.

public var value: Value {
    borrow { valuePointer.pointee }
    mutate { &valuePointer.pointee }
}

`MutableRef` for Hoisted Accesses

Subscript accesses inside loops — like updating a dictionary value — can result in repeated redundant lookups. MutableRef lets you hoist that access out of the loop manually, holding a stable mutable reference to the element for the duration of the operation.

var countRef = MutableRef(&counts[key, default: 0])

for set in sets {
    if set.contains(key) {
        countRef.value += 1
    }
}

Cross-Platform

Official Swift SDK for Android

Swift 6.3 ships the first official Swift SDK for Android. You can now build native Android programs in Swift, add Android as a target in your Swift packages, and integrate Swift code into existing Kotlin/Java Android apps using Swift Java and Swift Java JNI Core. This is a meaningful milestone — the Android target has existed as a grassroots community effort for years and is now a first-class, officially supported platform.

To get started: Getting Started with the Swift SDK for Android.

Embedded Swift

Embedded Swift continues to mature in Swift 6.3, with enhanced C interoperability, better debugging support, and meaningful progress toward a complete linkage model. If you are targeting microcontrollers or bare-metal environments, the Embedded Swift improvements post covers the details.

Swift Build Preview in Swift Package Manager

Swift 6.3 integrates a preview of Swift Build — a unified build engine across all supported platforms — into Swift Package Manager. The goal is a more consistent cross-platform build experience. Try it in your packages and report issues; it is opt-in for now.

SPM also gains swift package show-traits to discover the traits a package supports, and better support for prebuilt Swift Syntax binaries in shared macro libraries.

Summary

Swift 6.3 and 6.4 together tell a clear story: the language is maturing and the team knows it. The ergonomics work — anyAppleOS, improved memberwise initializers, better concurrency diagnostics — removes friction that has been accumulating for years. The cross-platform push, with an official Android SDK and continued Embedded Swift investment, reflects a genuine commitment to Swift outside the Apple ecosystem.

WWDC 2026 - Apple Just Opened the Foundation Models Framework to Any LLM Provider

ArshTechPro — Thu, 11 Jun 2026 11:07:49 +0000

Until WWDC 2026, the Foundation Models framework had one rule: Apple's on-device model or nothing. That rule is gone.

Session 339 introduces a public protocol layer that any LLM — a cloud API, an open-source local model, a fine-tune you host yourself — can implement. Once a provider ships a conforming Swift package, your existing LanguageModelSession code works with it unchanged. No rewrites. No new session abstractions. One line swap.

This article is not a transcript summary. It explains the decisions you now have to make as a developer building on Foundation Models in iOS 27 / macOS 27.

The Situation Before This

The Foundation Models framework launched in iOS 26 and was genuinely useful: free, private, offline, no API key, structured output via @Generable. But it had a hard ceiling. The on-device model is about 3B parameters, not designed for general world knowledge, and has no long-context mode worth speaking of. If your feature needed anything beyond what that model handled, you were stitching together a completely separate SDK — URLSession calls, your own message history management, your own error handling, duplicated everything.

The new protocol layer closes that gap. You write your session logic once against the Foundation Models API, and the model behind it becomes a deployment decision rather than an architectural one.

What Is Actually Available Now

Four model sources, one session API:

// The existing on-device model — free, private, offline
let model = SystemLanguageModel()

// Apple's cloud model — 32K context, reasoning, Private Cloud Compute privacy guarantees
// let model = PrivateCloudComputeLanguageModel()

// A model you package and distribute via Swift Package Manager
// let model = try await CoreAILanguageModel(resourcesAt: modelURL)

// Any MLX-format model from HuggingFace
// let model = MLXLanguageModel(modelID: "mlx-community/my-model")

let session = LanguageModelSession(model: model)
let response = try await session.respond(to: "Summarize this contract.")

And first-party partners are already here. Gemini models are available through the Firebase Apple SDK, plugging directly into the Foundation Models framework using the same API — so the on-device Apple model and cloud-hosted Gemini sit behind the same interface. Anthropic is also listed as a launch partner.

The practical upshot: you can build your feature against SystemLanguageModel for dev and testing, then swap to Claude or Gemini for production without touching your session code.

The Decision You Now Have to Make

Before writing any protocol conformance, figure out which tier your use case actually belongs to.

The on-device model is good at focused tasks: summarization, extraction, classification, short-form generation, anything where you control the prompt tightly and the output is bounded. A 20B sparse model on a phone is enough to handle a meaningful slice of in-app AI tasks — structured extraction, classification, embedded summarization, tool routing. Apps that previously paid for cloud calls to do this can stop.

The cloud tier is for everything else: long context, open-ended reasoning, conversations that run for many turns, tasks that need current world knowledge. Frontier reasoning, agentic loops, vision-language across many images — all still cheaper, more capable, or both via a cloud LLM. The build decision becomes "what can't run on-device" rather than "how big a model do I need."

That framing matters because implementing a custom LanguageModelExecutor is real work. Do not do it if the existing models cover your use case.

If You Are Building a Provider Integration

This is the engineering meat of session 339. Two protocols to implement, one Swift package to ship.

The Two Protocols

LanguageModel describes what your model can do. LanguageModelExecutor is where generation actually happens.

// LanguageModel: declare capabilities and hand the session a configuration
public struct MyLanguageModel: LanguageModel {
    typealias Executor = MyLanguageModelExecutor

    public var capabilities: LanguageModelCapabilities {
        LanguageModelCapabilities(capabilities: [.toolCalling, .guidedGeneration, .reasoning])
    }

    public var executorConfiguration: Executor.Configuration {
        Executor.Configuration(/* API endpoint, auth, model variant, etc. */)
    }
}

// LanguageModelExecutor: translate the framework's request into your model's wire format
public struct MyLanguageModelExecutor: LanguageModelExecutor {
    public typealias Model = MyLanguageModel

    public init(configuration: Configuration) throws { }

    public func respond(
        to request: LanguageModelExecutorGenerationRequest,
        model: MyLanguageModel,
        streamingInto channel: LanguageModelExecutorGenerationChannel
    ) async throws { }
}

The LanguageModel / LanguageModelExecutor split is deliberate. A single model type can have multiple executor configurations — for example, a fast tier and a quality tier backed by the same model family. The session caches executor instances per configuration, so if a developer creates two sessions with identical configurations, they share an executor.

Prewarm

prewarm is called before the first request arrives. For a local model that loads weights from disk, use it to get weights into memory so the user does not wait on the first generation. For a remote API, you might warm a connection pool here or do nothing at all.

func prewarm(transcript: Transcript) {
    loadedModel = try? loadWeights()
}

func respond(to request: ..., streamingInto channel: ...) async throws {
    let weights = try loadedModel ?? loadWeights()
    // generate
}

Reading the Transcript

The framework passes conversation history as a typed Transcript, not a raw array of role/content strings. Your executor maps these to whatever your model expects.

// Transcript.Entry cases you will encounter:
// .instructions  → system prompt
// .prompt        → user message
// .toolCalls     → model-initiated tool invocations
// .toolOutput    → results from those tool calls
// .response      → assistant turn

This typed representation is cleaner than raw JSON message arrays and makes multi-turn context, tool call history, and system instructions all unambiguous. If your model's API uses OpenAI-compatible message formats, the mapping is mechanical.

Streaming Output Back

The channel is how your executor sends generation back to the session. Three phases: metadata, token usage, then text deltas.

func respond(to request: ..., streamingInto channel: ...) async throws {
    // Tell the framework what model/request handled this
    await channel.send(.response(action: .updateMetadata([
        "modelID": "my-model-2026",
        "requestID": request.id.uuidString
    ])))

    // Report input token count before generating
    await channel.send(.response(action: .updateUsage(
        input: .init(totalTokenCount: promptTokens, cachedTokenCount: cachedTokens),
        output: .init(totalTokenCount: 0, reasoningTokenCount: 0)
    )))

    // Stream tokens as they arrive
    for try await token in modelStream {
        await channel.send(.response(action: .appendText(token)))
    }
}

Handling Options You Do Not Support

The session caller can request things your model might not support — greedy sampling, guided generation with a JSON schema, a specific reasoning level. The rule is: approximate where you can, throw where you cannot.

// Caller requested greedy sampling, your API only takes temperature — close enough
if request.generationOptions.sampling?.kind == .greedy {
    apiRequest.temperature = 0
}

// Schema + tiny token budget is genuinely unsatisfiable — throw
if let schema = request.schema,
   let budget = request.generationOptions.maximumResponseTokens,
   budget < minimumTokensNeeded(for: schema) {
    throw LanguageModelError.unsupportedCapability(
        .init(capability: .guidedGeneration,
              debugDescription: "Token budget too small for this schema.")
    )
}

The framework ships typed errors for every common failure: contextSizeExceeded, rateLimited, refusal, guardrailViolation, timeout, and more. Use them. Callers know how to handle them, and apps already built on Foundation Models will degrade gracefully when they see these errors from your model.

Your own provider-specific errors — subscription limits, suspended accounts, model variants not yet provisioned — can be thrown as custom Error types. Give them a proper errorDescription; that string surfaces in developer-facing tooling.

Custom Segments: When Text Is Not Enough

Some models produce or consume things that are not text. The framework has a Transcript.CustomSegment protocol for this.

Define a type, use it in prompts, emit it from your executor:

public struct AudioSegment: Transcript.CustomSegment {
    public var id: String
    public var content: URL
}

// In a session
let recording = AudioSegment(id: UUID().uuidString, content: audioFileURL)
let response = try await session.respond {
    "Transcribe the key decisions from this meeting."
    recording
}

// In the executor, emit back
await channel.send(.response(action: .updateCustomSegment(
    AudioSegment(id: outputFile.id, content: outputFile.url)
)))

Same mechanism works for web search citations, image outputs, retrieval chunks — anything that should live in the transcript with type information preserved.

Server-Side Tools

If your model runs tools on the server side (web search is the common case), you do not expose them as client-side Tool conformances. Instead, declare them on your model type and surface their output through the channel as custom segments.

public struct MyLanguageModel: LanguageModel {
    public struct ServerTool: Sendable {
        public static let webSearch: ServerTool = ...
    }
    public init(serverTools: [ServerTool] = []) { }
}

// Executor routes server events to the channel
for try await chunk in apiResponse {
    switch chunk {
    case .webSearch(let result):
        await channel.send(.response(action: .updateCustomSegment(
            WebSearchSegment(url: result.url, content: result.html)
        )))
    case .textDelta(let delta):
        await channel.send(.response(action: .appendText(delta.text, tokenCount: delta.tokenCount)))
    }
}

The developer using your model sees a coherent transcript that includes both the response text and the search results, typed and inspectable, without the server-side mechanics leaking through.

Packaging Your Provider

The session is specific about how to ship this:

// Package.swift structure Apple recommends
targets: [
    .target(name: "MyModelRuntime"),          // inference engine, weights loader
    .target(name: "MyModel", dependencies: ["MyModelRuntime"]),  // public LanguageModel conformance
    .testTarget(name: "MyModelTests", dependencies: ["MyModel"])
]

A few things worth noting from the session's packaging guidance:

Platform targets. Foundation Models supports iOS, macOS, visionOS, and watchOS. The Foundation Models framework is being released as open source, so your package could also be useful to developers who deploy Swift on Linux servers — consider supporting Linux too.

Dependencies. Every dependency translates to bytes that a developer ships to their users. Be deliberate about what is linked by your package. A bloated transitive dependency graph is a fast way to get your package rejected from app codebases.

Credentials. Design initializers that guide developers toward secure usage rather than plain API key strings — persist tokens via Keychain rather than accepting them as plain strings.

Summary

Foundation Models has always been Apple's model or nothing. That changes in iOS 27. What Apple has built here is less a feature and more a distribution channel. Any LLM provider that ships a conforming Swift package can be dropped into apps that already use Foundation Models — apps that collectively handle session management, tool call loops, and error handling in a consistent way.

WWDC 2026 - What's New in SwiftUI - A Developer's Breakdown

ArshTechPro — Thu, 11 Jun 2026 09:53:35 +0000

WWDC26 brought a substantial round of updates to SwiftUI — not a ground-up redesign, but a lot of small limitations removed, new APIs that were clearly driven by real-world pain points, and meaningful performance improvements. This post walks through every major announcement so you know exactly what's available and when to reach for it.

Look and Feel: Liquid Glass and the 2027 Releases

The most immediately visible change costs you zero code. Apps built with SwiftUI automatically pick up the updated Liquid Glass appearance on the 2027 OS releases. The glass tint responds to the new system-level Liquid Glass slider without any changes on your part.

On iPad, windows now dim when inactive, reinforcing which window has focus — again, automatic. On Mac, custom interactive Liquid Glass elements respond more fluidly to the mouse pointer.

There are a few opt-in refinements available when you want tighter control:

Responding to active state — use the appearsActive environment value to reduce opacity on custom elements when the window is inactive:

struct SidebarFooterView: View {
    @Environment(\.appearsActive) private var appearsActive

    var body: some View {
        MyAccountView()
            .opacity(appearsActive ? 1 : 0.5)
    }
}

Menu bar icons — the menu bar now shows a minimal set of icons by default. Add .labelStyle(.titleAndIcon) to a specific menu item to make its icon visible:

CommandMenu("Stickers") {
    Button { openStore() } label: {
        Label("Store", systemImage: "bag.fill")
            .labelStyle(.titleAndIcon)
    }
}

Resizability on iPhone

iPhone apps become resizable on iOS 27, which matters for iPhone Mirroring and running iPhone apps on iPad. Xcode 27's Live Previews now include resize handles so you can test this interactively without running on a device.

If your app mixes UIKit and SwiftUI, check the session "Modernize your UIKit app" for specifics around screen geometry, size classes, and orientation handling.

Toolbar APIs

The toolbar has been a source of friction on smaller screens for a while. Three new APIs address this directly.

Visibility priority — mark a toolbar group as high-priority so it stays visible when space is tight:

ToolbarItemGroup {
    UndoButton()
    RedoButton()
}
.visibilityPriority(.high)

Overflow menu — explicitly put secondary actions into the overflow menu rather than letting the system decide:

ToolbarOverflowMenu {
    ChoosePhotoButton()
    ExportAsImageButton()
    ClearAllStickersButton()
}

Pinned trailing item — guarantee a button always appears in the trailing position, never hidden:

ToolbarItem(placement: .topBarPinnedTrailing) {
    ShareButton()
}

Minimize on scroll — hide the navigation bar when the user scrolls down, maximizing content space:

ScrollView {
    StickerListView()
}
.toolbarMinimizeBehavior(.onScrollDown, for: .navigationBar)

Prominent Tab Role

Tabs can now be visually distinguished from the main tab row using the new .prominent role. This is useful for actions like a shopping cart or a creation button that should stand apart from content navigation tabs:

TabView {
    Tab { EventsTab() }
    Tab { HolidaysTab() }

    Tab(role: .prominent) {
        CartTab()
    }
}

Document API Overhaul

This is the most substantial new API surface in this release. The existing FileDocument and ReferenceFileDocument protocols are still there, but the 2027 releases introduce a new, more capable layer on top.

Document creation context

You can now define named creation sources and branch your initialization logic based on which one was selected:

extension DocumentCreationSource {
    static let blank = Self(id: "blank")
    static let photo = Self(id: "photo")
}

@main
struct Stickers: App {
    var body: some Scene {
        DocumentGroupLaunchScene("Create a Sticker Page") {
            NewDocumentButton("New Sticker Page", source: .blank)
            NewDocumentButton("Sticker Page from Photo…", source: .photo)
        }

        DocumentGroup { document in
            StickerPageDocumentView(document)
        } { configuration, context in
            StickerPageDocument(configuration: configuration, context: context)
        }
    }
}

WritableDocument and DocumentWriter

The new WritableDocument protocol separates the document model from the disk-writing logic. You provide a snapshot() method that captures the current state, and a Writer that knows how to serialize it.

The writer's write method is nonisolated and async, so heavy I/O stays off the main actor. You can compare current and previous snapshots to write only what changed, and report progress using Foundation's Subprogress API:

struct Writer: DocumentWriter {
    typealias Snapshot = PageSnapshot

    let contentType: UTType

    nonisolated func write(
        snapshot: sending PageSnapshot, to destination: URL,
        previous: sending PageSnapshot?, progress: consuming Subprogress
    ) async throws {
        if contentType.conforms(to: .stickerDocument) {
            // write custom format
        } else if contentType.conforms(to: .png) {
            let context = CGContext(/* ... */)
            context.draw(/* ... */)
        }
    }
}

Supporting multiple export formats is a matter of adding types to writableContentTypes and adding branches in write. The ReadableDocument and DocumentReader protocols mirror this structure for reading.

This API works with the @Observable macro, so views update only when the specific properties they depend on actually change.

Reorderable Containers

Drag-to-reorder is now available on any container, not just List. Apply .reorderable() to your ForEach and .reorderContainer to the parent, and SwiftUI handles the drag interaction and animation:

List {
    ForEach(stickers) { sticker in
        StickerListItemView(sticker: sticker)
    }
    .reorderable()
}
.reorderContainer(for: Sticker.self) { difference in
    difference.apply(to: &stickers)
}

The same code works on LazyVGrid — you don't need to rewrite anything when switching container types. Reordering also comes to watchOS for the first time this release.

For applying the ReorderDifference back to your array, the recommended approach uses the swift-collections package from swift.org:

import OrderedCollections

extension ReorderDifference where CollectionID == ReorderableSingleCollectionIdentifier {
    func apply(to values: inout [some Identifiable<ItemID>]) {
        var dictionary = OrderedDictionary(
            uniqueKeys: values.map { $0.id }, values: values)
        // resolve destination and move keys
        values = dictionary.values.elements
    }
}

Swipe Actions on Any View

Previously, .swipeActions only worked inside List. Now it works on any view inside a scroll container. Add .swipeActionsContainer() to the scroll view to coordinate the interactions:

ScrollView {
    LazyVStack {
        ForEach(stickers) { sticker in
            StickerListItemView(sticker: sticker)
                .swipeActions {
                    DeleteButton(sticker: sticker)
                }
        }
    }
}
.swipeActionsContainer()

Confirmation Dialogs and Alerts with Item Binding

Both .confirmationDialog and .alert now accept the same item-binding pattern that sheets use. Pass a binding to an optional item; when the item is set, the dialog appears with that item in scope:

.confirmationDialog("Delete?", item: $stickerToDelete) { sticker in
    DeleteStickerButton(sticker)
}

This replaces the pattern of managing a separate isPresented Bool alongside a selected-item variable.

AsyncImage Caching

AsyncImage now respects standard HTTP cache headers by default, so images loaded from the network are cached without any code changes. When scrolling back to previously loaded content, images appear immediately from cache.

When you need more control, you can provide a custom URLRequest per image and attach a custom URLSession with a configured URLCache:

@Observable class StickerStore {
    static let imageSession: URLSession = {
        let config = URLSessionConfiguration.default
        config.urlCache = URLCache(
            memoryCapacity: 64 * 1024 * 1024,
            diskCapacity: 256 * 1024 * 1024)
        return URLSession(configuration: config)
    }()
}

ForEach(pets) { pet in
    AsyncImage(request: URLRequest(
        url: pet.imageURL,
        cachePolicy: .returnCacheDataElseLoad)
    )
}
.asyncImageURLSession(StickerStore.imageSession)

@State Is Now a Macro — With Lazy Initialization

This is a subtle but impactful change. @State has been converted from a Dynamic Property to a macro. The practical effect: @Observable classes stored in @State are now initialized lazily — only once for the lifetime of the view, not on every reinitialization of the parent.

Previously, if a parent view reinitializes StickerStoreView, a new StickerStore() would be created each time (and immediately discarded). Now, the class is only ever created once. This behavior is back-ported to iOS 17, macOS 14, and aligned releases.

One source-breaking edge case to watch for: if you assign a default value in the property declaration and assign a different value in init, Xcode 27 will show a "variable used before being initialized" error. The fix is to remove the default value from the declaration:

// Before — causes error
@State private var page = StickerPage()

init(title: String) {
    self.page = StickerPage(title: title) // error
    self.title = title
}

// After — correct
@State private var page: StickerPage

init(title: String) {
    self.page = StickerPage(title: title)
    self.title = title
}

ContentBuilder: Better Compiler Performance

If your app has complex, deeply nested SwiftUI views, you may have seen "The compiler is unable to type-check this expression in reasonable time." This happens because Section, Group, ForEach, and similar containers each have multiple overloads, and the compiler has to explore every combination.

The 2027 releases introduce ContentBuilder, a unified builder type that replaces the per-container overloads. This reduces type-checking to a single path through the decision tree, which translates to meaningfully faster compile times. ContentBuilder is available for any deployment target because it's built on top of the existing ViewBuilder.

You can use it directly when needed:

@ContentBuilder
func stickerLibraryView() -> some View {
    // ...
}

The improvement applies when building with Xcode 27 regardless of your minimum deployment target.

SwiftUI Agent Skills in Xcode 27

Xcode 27 ships two new agent skills for the Coding Assistant:

SwiftUI Specialist — enforces SwiftUI best practices as you write code
What's New in SwiftUI — guides adoption of the new 2027 APIs

Both are available inside Xcode 27's Coding Assistant. If you use other tools, you can export them as markdown files with xcrun agent skills export.

Where to Start

If you want to work through these APIs systematically:

Build your existing app in Xcode 27 and check the updated Liquid Glass appearance — it requires no code changes.
If you have a document-based app, the new WritableDocument / ReadableDocument protocols are worth evaluating for the performance and multi-format benefits.
Audit your toolbar setup, especially on compact screens, using the three new toolbar APIs.
If you have complex views with compiler performance issues, upgrading to Xcode 27 alone should help due to ContentBuilder.
Switch any @State-managed @Observable classes over and verify the lazy initialization behavior works as expected in your initialization paths.