DEV Community: ArshTechPro

Strix: Give Your App a Free AI Pentester Before It Ships

ArshTechPro — Thu, 02 Jul 2026 17:13:58 +0000

If you have ever pushed code to production and quietly hoped nobody probes it too hard, this project is for you.

Strix is an open-source tool that runs autonomous AI agents against your application the way a real attacker would: it spins up your app, pokes at it, tries to break in, and proves whether a vulnerability is real before it tells you about it. No SaaS lock-in required, no waiting weeks for a pentest firm to get back to you.

In this article I will walk through what Strix actually does, how it is different from the static analysis tools you already have, and how to run your first scan.

The Problem With Most "Security Scanning"

Most security tooling developers use day to day falls into two buckets:

Static analysis (SAST) — scans your source code for risky patterns. Fast, but full of false positives, and it has no idea how your app actually behaves at runtime.
Dependency scanners — flag known CVEs in your packages. Useful, but they say nothing about the business logic bugs you wrote yourself.

Neither of these actually runs your application and tries to exploit it. That's traditionally been the job of a human penetration tester, and hiring one is slow and expensive.

Strix tries to close that gap by giving AI agents an actual hacker's toolkit and letting them attack a running instance of your app, the same way a person would.

What Strix Actually Does

Strix agents come with:

A full HTTP proxy for inspecting and manipulating requests and responses
Browser automation for testing things like XSS, CSRF, and auth flows across multiple tabs
Terminal access for running commands and testing interactively
A Python runtime for writing custom exploits on the fly
Reconnaissance tooling for mapping out the attack surface
Static and dynamic code analysis

Instead of one agent doing everything, Strix uses a "graph of agents" model, so multiple specialized agents can work in parallel on different parts of your app and share what they find with each other.

Critically, when Strix reports a vulnerability, it comes with an actual proof-of-concept demonstrating that the exploit works, not just a pattern match that says "this line looks suspicious." That is the main thing that separates it from a linter with a security label on it.

It can detect things like:

Access control issues — IDOR, privilege escalation, auth bypass
Injection attacks — SQL, NoSQL, command injection
Server-side flaws — SSRF, XXE, insecure deserialization
Client-side flaws — XSS, prototype pollution, DOM issues
Business logic bugs — race conditions, workflow abuse
Auth issues — JWT vulnerabilities, broken session management
Infrastructure misconfigurations and exposed services

Installing and Running Your First Scan

You need two things before you start:

Docker, running locally (Strix's agents operate inside a sandbox container)
An API key from a supported LLM provider — OpenAI, Anthropic, Google, or a local model via Ollama/LMStudio

Install it:

curl -sSL https://strix.ai/install | bash

Configure which model powers the agents:

export STRIX_LLM="openai/gpt-5.4"
export LLM_API_KEY="your-api-key"

Then point it at a target:

strix --target ./app-directory

That's it. On first run it will pull the sandbox Docker image, then start testing. Results land in strix_runs/<run-name>.

Strix will also remember your config after the first run, saving it to ~/.strix/cli-config.json so you don't have to set environment variables every time.

Beyond a Local Folder

Strix isn't limited to scanning a directory on your machine. A few other ways to point it at something:

# Review a GitHub repo directly
strix --target https://github.com/org/repo

# Black-box test a live deployed app
strix --target https://your-app.com

# Test both the source code and the deployed app together
strix -t https://github.com/org/app -t https://your-app.com

If your app needs a login, you can hand Strix credentials and let it test authenticated flows:

strix --target https://your-app.com \
  --instruction "Perform authenticated testing using credentials: user:pass"

You can also steer it toward specific concerns instead of a generic sweep:

strix --target api.your-app.com \
  --instruction "Focus on business logic flaws and IDOR vulnerabilities"

For more detailed rules of engagement, scope, or exclusions, hand it a file instead of a one-liner:

strix --target api.your-app.com --instruction-file ./instruction.md

Running It Headless

If you want to run Strix as part of an automated job rather than interactively, use non-interactive mode:

strix -n --target https://your-app.com

It prints findings in real time and exits with a non-zero status code if it finds vulnerabilities, which makes it straightforward to fail a build on real findings.

Wiring It Into CI/CD

This is where Strix gets genuinely useful for a team: instead of running a security scan occasionally, you run it on every pull request and block insecure code before it merges.

A minimal GitHub Actions setup:

name: strix-penetration-test

on:
  pull_request:

jobs:
  security-scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v6
        with:
          fetch-depth: 0

      - name: Install Strix
        run: curl -sSL https://strix.ai/install | bash

      - name: Run Strix
        env:
          STRIX_LLM: ${{ secrets.STRIX_LLM }}
          LLM_API_KEY: ${{ secrets.LLM_API_KEY }}
        run: strix -n -t ./ --scan-mode quick

A couple of practical notes if you're setting this up:

Use fetch-depth: 0 in the checkout step. On PR runs, Strix automatically scopes a quick review to just the changed files, and it needs full git history to resolve that diff correctly. If it can't, pass --diff-base explicitly.
Store your LLM credentials as GitHub secrets, not plain environment variables.

Configuration Options Worth Knowing

export STRIX_LLM="openai/gpt-5.4"
export LLM_API_KEY="your-api-key"

# Optional: point at a local model instead
export LLM_API_BASE="your-api-base-url"

# Optional: enables search capability for the agents
export PERPLEXITY_API_KEY="your-api-key"

# Optional: control how much the model "thinks"
export STRIX_REASONING_EFFORT="high"  # default is high; quick scans use medium

As for which model to run it with, the project currently recommends:

OpenAI GPT-5.4 (openai/gpt-5.4)
Anthropic Claude Sonnet 4.6 (anthropic/claude-sonnet-4-6)
Google Gemini 3 Pro Preview (vertex_ai/gemini-3-pro-preview)

It also supports Vertex AI, Bedrock, Azure, and local models — worth checking the LLM providers docs if you want to run something self-hosted.

Where This Fits in Your Workflow

A reasonable way to think about where Strix fits alongside what you probably already run:

Tool type	What it catches	What it misses
SAST / linters	Risky code patterns	Runtime behavior, business logic
Dependency scanners	Known CVEs in packages	Bugs in your own code
Strix	Exploitable, validated vulnerabilities with a working PoC	Anything outside the scope you give it

Strix is not a replacement for code review or a full professional pentest on a critical system, but as a fast, repeatable layer that actually tries to exploit your app before an attacker does, it fills a gap that static tooling structurally can't.

Trying It Out

If you want to run this against something disposable first rather than your production app, that's a reasonable way to get a feel for it — spin up a small local project, point Strix at it, and see what it turns up.

One important note directly from the maintainers: only test applications you own or have explicit permission to test. You are responsible for using it ethically and legally.

Repo: github.com/usestrix/strix

WWDC 2026 - Build Intelligent Siri Experiences with App Schemas

ArshTechPro — Thu, 02 Jul 2026 09:28:07 +0000

In the iOS 27 release, Siri takes a real step forward. It can now reach into the actual content inside your app, take actions on your behalf, and understand what is on screen right now. The way you plug into all of that as a developer is the App Intents framework, and the piece that makes it click is App Schemas.

This guide walks through the core ideas from Apple's session Build intelligent Siri experiences and turns them into something you can act on.

If App Intents is completely new to you, it is worth watching "Get to know App Intents" first, since everything below builds on that foundation.

The big picture: three new powers for Siri

There are three ways Siri gets more capable this year, and it helps to hold all three in your head before diving into code.

First, Siri can access your app's entities, meaning the real content inside your app. Someone can ask "When and where is my next meeting?" and Siri answers directly, because it understands what a meeting is, which one is relevant, and which properties to return.

Second, Siri can take actions using your app's intents. A request like "Send my latest report to Mary" works because your intent describes the action, its parameters, and when it is safe to run. Siri handles the language understanding; your app just does the work.

Third, Siri can understand on-screen context. When you annotate your views with entities, someone can say "Explain this text" or "Forward the last one" and Siri knows exactly what content they mean.

Everything below is built on one central concept, so let us start there.

App Entities: describing the content you already have

An App Entity is a structured description of the content inside your app. You are not building a new data model. You are describing content you already have in a way the system can reason about.

Think about the nouns in your app. A calendar app has events. A mail app has messages. A photos app has photos and albums. UnicornChat has Contacts, Conversations, and Messages. Each of these is an App Entity.

An entity describes three things: what the thing is, how it is identified, and which properties matter (a title, a date, some text). That is it.

Modeling an entity is step one, but on its own it is not enough for Siri to find it or talk about it. For that, your entity needs to conform to an App Schema.

App Schemas: giving Siri a shared vocabulary

An App Schema gives Siri a predefined understanding of a common concept, such as a message, a contact, or a document. When your entity conforms to a schema, Siri already knows how to reason about it. Instead of treating your app as a black box, it understands that a UnicornChat message is a message.

This is the key mental shift. You do not teach Siri your app's vocabulary or define training phrases. You declare your data against a shape Siri already knows, and the language understanding comes for free. Because schemas are system-defined, your integration automatically benefits as Siri improves and expands to new languages and dialects.

Here is how UnicornChat contributes a message's text content to Apple Intelligence by conforming to the messages message schema:

// Contributing message content to Apple Intelligence

@AppEntity(schema: .messages.message)
struct MessageEntity: IndexedEntity {

    // The text content of the message
    @Property(indexingKey: \.textContent)
    var body: AttributedString?
}

That single schema: .messages.message is what lets Siri understand a request like "Show my last message from Flare."

Entity resolution: turning words into real objects

Once your content is modeled, the next question is how Siri finds the right one. That process is called entity resolution. When someone says "Open UnicornChat with Glow," Siri resolves that "Glow" refers to a specific contact, finds the match, and fills in the entity with its properties.

But people do not always name things exactly. They describe them. Someone might say "the best windsurfing in Carmel," which is a meaning, not a text match. To support that, Siri needs semantic search, and there are two ways to power resolution.

Option 1: IndexedEntity (the best experience)

The primary path is adopting IndexedEntity. When you do, your entities are added to the system's semantic index in Spotlight. That lets Siri match on meaning rather than exact text, understand relationships between entities, and answer questions over your content.

For example, "Show the messages with Flare about movies" is not a string match. Siri can find messages that reference movie titles because it is running a semantic query over UnicornChat's indexed messages.

Notice the indexingKey in the earlier code sample. That is how you tell Spotlight which properties, like the message body, should be searchable. IndexedEntity gives you semantic matching, fewer follow-up questions, and the most natural language understanding.

Option 2: EntityStringQuery (when indexing is not feasible)

Not everything can be indexed ahead of time. Your dataset might be huge, live on a server, or change too frequently. In those cases you use EntityStringQuery. Siri hands you the person's raw input string, and your app is responsible for finding and returning the matches.

// An interface that locates entities using arbitrary string input

struct ContactQuery: EntityStringQuery {
    func entities(matching string: String) async throws -> [ContactEntity] {
        let predicate = #Predicate<Person> { person in
            person.name.localizedStandardContains(string)
        }
        let descriptor = FetchDescriptor<Person>(predicate: predicate)
        let matches = try modelContext.fetch(descriptor)
        return matches.map(\.entity)
    }
}

You lose semantic understanding here, but you gain full control over how you search. The rule of thumb: index when you can, use a string query when you cannot.

App Intents and action schemas: letting Siri do things

Entities on their own are just information. Things get interesting when you combine them with actions, and actions come from App Intents.

When you define an App Intent, that action can appear across the system: in Shortcuts, Spotlight, Widgets, and more. People can discover and trigger it even without Siri. You describe what the action does, define its parameters, and implement the behavior. The system handles surfacing and suggesting it.

To bring an action to Siri specifically, you adopt an action schema. Just as entities use schemas to be understood, actions use schemas to become executable by Siri. Think of a schema as a specialized App Intent, shaped so Siri knows how to process it. The schema defines the kind of action, the structure Siri expects, and how it maps to natural language. That is what lets Siri confidently handle "Send a message to Mary" or "Play my focus playlist."

Domains: grouping schemas into complete experiences

A single schema defines a single action, but apps usually need a set of them. That is why schemas are grouped into domains such as mail, photos, and messages. A domain is a category of contract between your app and Siri. When you adopt a domain, you implement its predefined schemas, map them to your app's functionality, and Siri immediately knows how to talk about your app in that category.

In UnicornChat, sending a message means adopting the sendMessage schema from the messages domain. In Xcode you start typing the schema name, autocomplete shows the available schemas grouped by domain, and you pick the one you want. Your job is then to map the schema's parameters (the recipient, the message content) onto your existing messaging flow: process the parameters, pass them into your send logic, and return the sent message back to the system as an entity.

The payoff looks like this in practice. You say "Send a message to Glow in UnicornChat, saying 'What movies do you recommend?'" Siri resolves Glow through your entity query, invokes your intent, and sends the message, all without opening the app.

Working across apps: on-screen awareness and content transfer

Many real requests span multiple apps. "Email my wife this reply from Bubbles" starts in one app and finishes in another. That combines two capabilities: understanding what the person is looking at, and moving that content elsewhere.

On-screen awareness

To let Siri understand references like "this message" or "that conversation," you connect what is visible to your entities. There are two APIs, for two situations.

Use UserActivity when there is one primary thing on screen, like a single document or a compose view. Use view annotations when several meaningful items are visible at once, like rows in a conversation. Here is the view annotation approach in UnicornChat, attaching each message row to its entity:

// Working across apps - View annotations

List {
    ForEach(messages) { message in
        MessageRow(message: message)
            .appEntityIdentifier(
                EntityIdentifier(
                    for: MessageEntity.self,
                    identifier: message.id
                )
            )
    }
}

With that in place, someone can say "Edit this message" or "Forward the last one" and Siri resolves the entity straight from the view.

Exporting content to another app

Content transfer is what lets other apps act on your entities. You enable it by conforming your entity to Transferable and providing an IntentValueRepresentation. UnicornChat exports a ContactEntity as a system IntentPerson, which powers requests like "Call this contact." Your app does not need to know what happens next; it just describes its content accurately.

// Working across apps - Exporting content to another app

extension ContactEntity: Transferable {

    static var transferRepresentation: some TransferRepresentation {
        IntentValueRepresentation(
            exporting: \.person
        )
    }
}

Receiving content: resolve or import

When content comes into your app, it either refers to something that already exists or represents something new. You decide which path to take.

If the incoming content should match an existing entity, use IntentValueQuery. This is conceptually like an entity query, but scoped to an intent parameter. Here UnicornChat receives an IntentPerson from another app and matches it to an existing contact:

// Working across apps - IntentValueQuery

struct ContactEntityQuery: IntentValueQuery {

    func values(for input: [IntentPerson]) async throws -> [ContactEntity] {
        let names = input.map(\.displayName)
        let descriptor = FetchDescriptor<Contact>()
        let contacts = try model.mainContext.fetch(descriptor)
        let matches = contacts.filter { contact in
            names.contains(where: { name in
                contact.name.localizedStandardContains(name)
            })
        }
        return matches.map(\.entity)
    }
}

If the incoming content should create something new, add an importing closure to your IntentValueRepresentation. This converts the incoming value into a brand new entity, such as creating a new unicorn from an IntentPerson. Your app stays in control of how that content is stored.

// Working across apps - IntentValueRepresentation

extension ContactEntity: Transferable {

    static var transferRepresentation: some TransferRepresentation {
        IntentValueRepresentation(exporting: \.person, importing: { intentPerson in
            let contact = Contact(importing: intentPerson)
            ContactManager.shared.contacts.append(contact)
            return contact.entity
        })
    }
}

Many apps use both: resolve when the content already exists, import when it does not.

Best practices and tooling

A few things separate a working integration from a great one.

Some Siri scenarios need more than one schema. If you adopt sendMessage, Xcode may raise a build error telling you that you also need draftMessage, because a complete send flow requires a way to draft and confirm. This is a design hint delivered at build time rather than a silent runtime failure. Xcode even offers a fix-it that generates a stub adoption for you to fill in. If your app mutates UI state in an intent, remember to run that work on the main actor.

When it comes to testing, work outward in layers. Start with AppIntentsTesting, a framework that lets you exercise your intents in isolation with no Siri involved, so you can validate business logic fast. Then use the Shortcuts app to inspect how your intent's parameters are shaped and exposed. Next check Spotlight to confirm your entities are indexed, discoverable, and linkable. Finally test end to end with Siri, where natural language, entity resolution, on-screen context, and cross-app workflows all come together.

WWDC 2026 - Craft Clear Names for Features and Labels in Your App

ArshTechPro — Thu, 02 Jul 2026 09:24:53 +0000

You've probably opened an app and instantly known where to tap. No hunting, no second-guessing. That feeling isn't luck — it's designed. And one of the biggest contributors to it is something most of us treat as an afterthought: the names we give things.

Naming isn't just for products like iPhone or iCloud. It happens at every level of your app — menus, tab bars, buttons, settings, plan tiers. Each of those small choices adds up to how someone feels about what you built. This article walks through a framework from Apple's session Craft clear names in your app, aimed at helping you make those choices deliberately instead of by default.

Three criteria for a name that works

Before you judge any name, it helps to have something to judge it against. There are three qualities to look for.

It belongs. A name that belongs fits your app at every level — it matches what users expect to find, and it sits comfortably alongside everything else you've already named. A Balance label belongs in a payments app because that's the word that ecosystem already speaks.

It sets the right expectation. When someone reads a name, they're already predicting what they'll find behind it. A good name delivers on that prediction. When the prediction and the reality match, trust builds. When they don't, the user feels tricked — even if the feature is great.

It works everywhere. A strong name travels. It holds up across languages, markets, platforms, and the different contexts where your app lives. A clever pun that dies in translation is a liability at scale.

One important caveat: names won't always check every box, and that's fine. You may have your own constraints too — trademark availability, industry regulations, brand voice. Treat these three criteria as a guide, not a rulebook. The trade-offs are yours to make.

Clarity vs. cleverness: a worked example

Consider Apple Cash. When you send money, the one thing you need to know immediately is how much you have. That value sits right next to the send button, and it needs a label.

Walk through some candidates:

Spending Power sounds compelling but isn't concrete. Is it a credit limit? A score? In a financial context, ambiguity is exactly what you don't want. Worse, if the value is low or zero, the label stops describing and starts judging — and payment services run entirely on trust.
Current Funds is accurate but stiff. Say it out loud: "let me check my Current Funds." Nobody talks like that. That gut check alone tells you it doesn't belong in a service people use conversationally.
Balance wins. It's the industry-standard term — well understood, clear, and neutral. It belongs, it sets the right expectation, and it translates without friction.

The lesson: sometimes the most obvious word is the right one, precisely because it's already doing the job. Here, clarity and trust matter more than brand expression.

But the pull toward something more branded is real, and sometimes justified. Picture a gym app with two subscription tiers: Basic Access and All Access. Clear, easy to choose between. Now imagine renaming them Lightweight and Heavyweight. Fun, on-brand — but there's a learning curve. What do those tiers actually include? That friction makes choosing harder.

So which do you pick? It depends on what matters most where that name lives. Sometimes you lean into clarity. Sometimes you lean into brand. The criteria don't tell you the answer; they tell you what you're trading off.

An exercise for arriving at a name

When you're building something, it's natural to name it after what it does, the technology behind it, or its internal function. But your users don't see it that way. They want to know what it does for them. So the exercise starts with a question: who is this for? New parents? Marathon trainees? Get clear on the audience first.

Then, with that person in mind, ask what they should think, feel, and do when they encounter the feature.

Let's run it on a real example: an Apple Maps feature that remembers places you've been — that café you found last week, the park with the accessible trails.

Think. Grab sticky notes (or the digital equivalent) and write one idea per note. What do you want people to think when they use this? Easy. Helpful. Clever. Don't filter yet — you're hunting for recurring themes, not the perfect word.

Feel. What should the emotion be? Finding a place whose name you'd forgotten feels like a small, fun win. Knowing your data is private and encrypted feels secure. Both matter here.

Do. What action should follow? Find the feature, use it, share places with the people they choose.

Once the ideas are down, step back and group them by theme. For this feature, three themes emerged:

Ease — finding what you want without effort
Excitement — the fun of rediscovering a place you loved
Security — because it was built with privacy in mind, that has to come through

Now generate names against those themes and start cutting. Some candidates won't fit the app's tone. Some feel vague. Some won't translate. Cross them off.

For the survivors, run a quick real-world test: drop each name into a sentence you'd actually say. "Hey, check out Private Memories." "Just search for Private Memories." If it reads and sounds natural, it's worth exploring. If it makes you wince, that's your answer.

The Maps team landed on Visited Places — descriptive, clear, and already at home in an interface that uses "places" throughout. It signals ownership (these are your places, not something Apple reads) and it holds up across languages. It honors the themes and tests well against the criteria. It doesn't have to hit all three, but it's great when it does.

Clear doesn't have to mean literal

The examples so far lean descriptive, but that's not the only path to clarity.

The Photos app has a feature that scans your library and surfaces moments that matter — a birthday, a trip, an ordinary Tuesday that turned out to be worth remembering. Technically, it's algorithmic photo grouping. But the person who just rediscovered a five-year-old video of a laugh they hadn't heard in years isn't thinking about algorithms. They're looking for a memory.

That's why Memories works. It meets people where they are emotionally, in a way a technical label never could. It fits the app's tone and the relationship people have with their photos. It's still clear — but the clarity comes from emotion, not explanation.

Knowing when a name lands: verbs, control, and context

Here's a case that shows the reasoning in motion. Apple Podcasts has a feature that isolates voices and reduces background noise. It lives in a menu alongside playback speed. What do you call it?

Vocal Isolation comes to mind first — but for a control the user toggles, a verb works better. This is something you do, not something you have.
Isolate Vocals fixes the grammar but it's an audio-engineering term. It describes the technology, not the experience.
Clarify Speech gets closer, but it only tells half the story — there's more going on than clarity.
Enhance Playback puts the feature before the person. Enhanced how? For whom?
Enhance Dialogue answers both questions — what's being enhanced, and for whom — before you even tap.

That's the one they shipped. It fits the context, sets the right expectation, and delivers exactly what it promises when you turn it on. All three criteria, working together. As a bonus, the same name already appears on Apple TV for a similar feature — more evidence that it belongs.

When the right word doesn't exist yet

Naming with intention doesn't mean you're limited to words that already exist.

AutoMix in Apple Music does what a good DJ does — it handles transitions between songs so playback never stops. Auto: it happens without you doing anything. Mix: it blends songs together. Put together, they form a word that doesn't exist, yet you understand it instantly. AutoMix earns its clarity from its parts, so the invented word doesn't have to explain itself.

Descriptive like Enhance Dialogue, emotional like Memories, invented like AutoMix — the criteria don't change. Only how you weigh them does.

Three things to take with you

Naming is fundamental, not cosmetic. It shapes how someone experiences your app just as much as layout, interactions, and visual design do. Next time you name something, come back to the criteria: Does it belong? Does it set the right expectation? Will it hold up everywhere your app lives?

The best names speak to the person, not just the feature. When what the product is aligns with what the person needs, the name feels like it truly belongs.

Names compound. Every good name makes the next one easier, because names build on each other and over time become the shared language of your app. The clarity, the trust, and the sense of feeling at home all accumulate.

Naming can feel like a small decision in the moment. It isn't. Next time you're wondering what to call something, you have a way to work through it — and your app or game will be better for it.

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.