DEV Community: ArshTechPro

Years of Apple's Best Security Work, Cracked in Five Days — Here's What Developers Should Know

ArshTechPro — Fri, 15 May 2026 10:03:07 +0000

There's a stat buried in a recent security disclosure that should stop every developer in their tracks:

Apple spent five years and likely billions of dollars building Memory Integrity Enforcement (MIE) for the M5 chip. A small team at Calif, working with an AI model called Mythos Preview, built a working kernel exploit against it in five days.

This isn't a story about Apple failing. It's a story about the state of modern security — and it has real lessons for every developer writing software today.

What Exactly Is Memory Integrity Enforcement?

Before we get to the exploit, you need to understand what was bypassed.

Memory corruption bugs — things like buffer overflows, use-after-free errors, and heap sprays — have been the backbone of software exploits for decades. The reason they keep working is simple: most languages let you do unsafe things with memory, and hardware traditionally didn't care.

ARM's Memory Tagging Extension (MTE), introduced in 2019, was the first serious hardware-level attempt to change that. The idea is elegant:

Every 16-byte chunk of memory gets a secret 4-bit tag
Every pointer to that memory carries the same tag
When your code accesses memory, the CPU hardware checks the tags match
If they don't? Immediate exception — no exploit, no arbitrary write

Apple didn't just ship MTE as-is. They spent years hardening it into something they call EMTE (Enhanced MTE) and wrapped it in a system-wide defense called MIE:

Synchronous checking only — no async mode where an attacker could slip past the check
Tag Confidentiality Enforcement — protects tags from being leaked via side channels (like the TikTag attack that broke standard MTE with 95% success rate in under 4 seconds)
Non-tagged memory protection — plugs a hole in standard MTE where attackers could bypass tags by targeting global variables instead
Applied kernel-wide, hardware-accelerated, and always on

Apple claimed — with evidence — that MIE disrupts every known public exploit chain against modern iOS, including recently leaked commercial exploit kits.

Then came May 2025.

The Exploit: A Data-Only Kernel LPE

The Calif team disclosed that they built the first public macOS kernel exploit on M5 hardware with MIE enabled. Here are the key technical facts they shared:

Type: Data-only kernel local privilege escalation (LPE)
Target: macOS 26.4.1 on bare-metal M5
Starting point: Unprivileged local user, using only normal system calls
End result: Root shell
Bugs used: Two vulnerabilities chained together
Time to build: ~5 days (bugs found April 25th, working exploit by May 1st)

The term data-only is significant. It means the exploit doesn't inject executable code — it manipulates data structures inside the kernel to hijack control flow. Traditional memory safety defenses often focus on code injection; data-only attacks are harder to catch because from the CPU's perspective, you're just... reading and writing memory normally.

They haven't published the full technical report yet — that comes after Apple ships a fix. But the core insight is already visible: with the right vulnerabilities, MIE can be evaded. The tags can still be worked around if an attacker has primitives to reason about memory layout and tag values.

The AI Angle Is the Part That Should Keep You Up at Night

Here's what's genuinely new about this disclosure: the exploit wasn't found by a single legendary hacker working alone for months. It was found by a small team working with an AI system.

Mythos Preview identified the bugs because they belong to known vulnerability classes — patterns that, once an AI system has learned them, generalize across a huge surface area of code. The human experts on the team then applied judgment for the parts that required novel reasoning: specifically, figuring out how to bypass MIE, which is new enough that AI had no prior examples to draw from.

This human-AI pairing dynamic is important. The AI handled breadth — scanning for known patterns at scale. The humans handled depth — the novel, creative problem of defeating a new mitigation. Together they landed a kernel exploit against Apple's best hardware in a week.

The implication: the old security model of "this is too obscure/complex for anyone to bother" is accelerating toward irrelevance. AI systems are getting better at the breadth problem. The cost of finding known bug classes in new codebases is dropping fast.

What Developers Can Actually Learn From This

1. Memory safety in your language matters more than ever

If you're still writing systems-level code in C or C++, this is a reminder that hardware mitigations like MIE are playing defense on your behalf — and that defense can be beaten. The industry push toward Rust, Swift, and memory-safe languages isn't hype.

If you can't switch languages, use sanitizers (ASan, MSan, UBSan) in your CI pipeline. At minimum they'll catch bugs before attackers do.

2. Mitigations buy time — they don't buy safety

MIE is an extraordinary engineering achievement. It dramatically raises the cost of exploitation. But the Calif research illustrates a principle that security engineers know well: mitigations are not fixes. They change the economics of exploitation without eliminating the underlying bugs.

Every security control you add to your application — rate limiting, WAFs, sandboxing, ASLR — buys you time and raises attacker cost. None of them substitute for writing correct, safe code in the first place.

3. "Data-only" attacks are underappreciated in web and app security too

The kernel exploit here avoided code injection entirely and instead manipulated kernel data structures. The web equivalent of this thinking pattern shows up in logic bugs, IDOR vulnerabilities, and race conditions — attacks that don't inject code but manipulate the state your application trusts.

These are notoriously hard to catch with static analysis or fuzzing alone because they often require understanding semantic intent, not just memory layout. Your threat model should account for attackers who want to corrupt your application's state without ever triggering a traditional "input validation" check.

4. AI-assisted vulnerability discovery is already here

The security landscape is changing. Bug bounty hunters, red teams, and — unfortunately — malicious actors are all beginning to pair AI with human expertise the same way Calif did here.

5. Responsible disclosure still works — and matters

Calif walked into Apple Park and handed over a laser-printed report in person rather than submitting via the usual bug bounty flood. Theatrical? Maybe. But they also chose to withhold technical details until Apple ships a fix.

The Bigger Picture

The Calif team ended their post with a Vietnamese proverb: nhỏ mà có võ — small but mighty. It's a fitting note for an era where a handful of researchers with the right AI tooling can do what used to require nation-state resources.

For developers, the takeaway isn't panic. It's clarity: write memory-safe code where you can, layer your defenses, treat mitigations as speed bumps not walls, and take vulnerability reports seriously. The tools attackers have access to are improving. So should yours.

Full technical details of the exploit will be published by Calif after Apple releases a patch. Apple's MIE blog post is worth reading regardless — it's one of the best public explanations of hardware-assisted memory safety ever written.

Xcode 26.5 — What Developers Actually Need to Know

ArshTechPro — Tue, 12 May 2026 15:59:52 +0000

Xcode 26.5 RC is out. It is not a landmark release, but if you ship subscription apps or work across Swift, SwiftUI, or web views, there is enough here to warrant attention before you push your next build.

Here is what matters.

The App Store Deadline You Cannot Miss

Before getting into features — if you have not already done this, stop and do it now.

Starting April 28, 2026, all new apps and app updates uploaded to App Store Connect must be built with the iOS 26 SDK or later (and the equivalent SDKs for tvOS, visionOS, and watchOS). If your CI/CD pipeline is still on Xcode 16, it will start rejecting your submissions. Update your build environment to Xcode 26 immediately.

StoreKit: The Headlining Addition

The most substantive developer-facing change in 26.5 is a set of new StoreKit APIs built around monthly subscriptions with a 12-month commitment billing plan — a billing configuration Apple introduced in App Store Connect.

If your app monetizes via subscriptions, this is the update for you.

What is new

SubscriptionInfo.pricingTerms (PricingTerms model)
You can now read pricing information for subscriptions with a monthly-with-12-month-commitment plan directly from StoreKit. No more hardcoding pricing strings in your UI. Pull them live.

billingPlanType PurchaseOption
Specify the billing plan type at the point of purchase for subscriptions using the new commitment configuration. This gives you programmatic control over which billing path the customer follows.

CommitmentInfo on Transaction and SubscriptionRenewalInfo
Read customer entitlement metadata for subscriptions purchased on a monthly billing plan type. This belongs in your transaction verification and renewal logic.

preferredSubscriptionPricingTerms(_:) — SwiftUI merchandising
Import both StoreKit and SwiftUI and you get a new view modifier that handles merchandising monthly commitment plans using Apple's built-in styles. If you are building a subscription paywall, this is the fastest path to a design that follows Apple's conventions without rolling your own layout.

Availability note

These new billing plans will be available worldwide — except the United States and Singapore — on iOS 26.4 and later, with iOS 26.5's release in May.

Known issue to flag

There is one active bug worth noting before upgrading your test pipeline:

SKTestSession cannot use the selected StoreKit configuration during unit tests, causing test actions to fail. The workaround is to add a small delay before running the test so the configuration has time to persist on-device. Document this in your test setup code so no one wastes time debugging it later. The feedback number is FB22237318 if you want to follow along.

Debugger Fixes Worth Knowing

Swift Task stepping across threads
The debugger can now correctly follow a Swift Task when a step operation causes the task to be migrated to a different thread. If you have hit confusing debugger behavior during async/await step-throughs, this should resolve it.

SwiftUI Previews duplicate launch bug fixed
A run action was incorrectly launching a duplicate app instance when using SwiftUI Previews, or when running a command-line app that opens windows via SDL, GLFW, or NSApplication APIs without an app bundle. That is now resolved.

Swift enum Optional SBValue representation
The payload of a Swift enum or Optional SBValue is now represented as a synthetic child rather than a direct child. If you have custom Python data formatters that unwrap Optional values, they will continue to work as long as you have not disabled SetPreferSyntheticValue().

Editor and Source Control Fixes

Syntax highlighting performance
Several major performance issues with syntax highlighting in Swift files have been resolved. Large files should feel noticeably more responsive.

Git performance for large repositories
An issue where workspaces touching git repositories with many tags or branches would experience sudden hangs and spins has been fixed.

Documentation viewer
Missing documentation for PhotoKit and some SwiftUI symbols in the documentation viewer and Quick Help has been restored.

Interface Builder

Two additions worth noting if you still use IB:

The "Show Library" button (+) has moved from the main toolbar to the bar at the bottom of the canvas.
A new "Control Metrics" property in the File inspector for Mac XIB and Storyboard documents allows you to design for environments where prefersCompactControlSizeMetrics will be set at runtime.

Instruments

The SceneKit template has been removed. SceneKit Instrument remains available in the library, and SceneKit itself is now deprecated across all Apple platforms. If you have not started migrating to RealityKit, now is the time.

The previous SwiftUI template containing View Body and View Properties instruments has been replaced — both instruments are deprecated but remain accessible in the library.

Summary

Xcode 26.5 is a focused update, not a feature drop. The StoreKit subscription billing APIs are the reason to prioritize testing against this SDK if you run a monetized app. The debugger and source editor fixes improve everyday reliability. And if you have not already migrated your build pipeline to Xcode 26, the April 28 App Store deadline makes that non-negotiable.

React Doctor: Is This the Missing Health Check for Your React Codebase?

ArshTechPro — Mon, 11 May 2026 21:09:29 +0000

If you have ever inherited a messy React codebase, or simply wondered whether your own project has drifted into bad patterns over time, React Doctor is a tool worth knowing about. One command, a score between 0 and 100, and a list of problems to fix. That is the pitch. Let us dig into whether it lives up to it.

What Is React Doctor?

React Doctor is an open-source CLI tool from the team behind Million.js. It scans your React project and produces a health score alongside a structured list of issues. Think of it as a linter on steroids — one that understands React patterns specifically, rather than just generic JavaScript rules.

npx -y react-doctor@latest .

That is all it takes to run it. No installation, no config file required to get started.

How It Works Under the Hood

When you run React Doctor against your project, it does two things in parallel.

1. Lint pass

It checks 60+ rules organized into categories: state and effects, performance, architecture, bundle size, security, correctness, accessibility, and framework-specific concerns (Next.js, React Native). Importantly, it detects your framework, React version, and compiler setup automatically, and toggles rules accordingly. So if you are on Next.js, it will apply Next.js-specific rules without you having to configure anything.

2. Dead code detection

It runs a separate pass to find unused files, unused exports, unused types, and duplicates across your codebase.

After both passes, it filters the results through any config you have set, then computes a score weighted by severity:

75 and above: Great
50 to 74: Needs work
Below 50: Critical

Errors weigh more than warnings, so a single serious issue pulls the score down more than a pile of minor ones.

Getting Verbose Output

By default you get a summary. Add --verbose and you see the exact files and line numbers involved:

npx -y react-doctor@latest . --verbose

This is the mode you actually want when fixing things, since the summary alone does not tell you where to look.

Real-World Scores on Popular Projects

The repo includes a leaderboard of scans against well-known open-source React projects. Here is a snapshot:

Project	Score
tldraw	84
excalidraw	84
twenty	78
plane	78
formbricks	75
posthog	72
supabase	69
payload	68
sentry	64
cal.com	63
dub	62

Even tldraw and excalidraw — projects maintained by experienced teams — score in the mid-80s, not 100. This is a useful calibration. Do not expect to hit a perfect score; the goal is identifying what actually matters in your specific project.

Plugging It Into CI With GitHub Actions

React Doctor ships a GitHub Action you can drop into any workflow:

- uses: actions/checkout@v5
  with:
    fetch-depth: 0
- uses: millionco/react-doctor@main
  with:
    diff: main
    github-token: ${{ secrets.GITHUB_TOKEN }}

The diff option is particularly useful — it tells the action to only scan files that changed relative to your base branch. This means in a pull request, it only flags new problems introduced by that PR, not pre-existing issues across the whole repo. The action also posts findings as a PR comment when github-token is set.

The action outputs a score value you can use in subsequent steps — for example, failing the build if a PR drops the score below a threshold you define.

Config File

You can suppress specific rules or exclude files via a react-doctor.config.json at the project root:

{
  "ignore": {
    "rules": ["react/no-danger", "jsx-a11y/no-autofocus"],
    "files": ["src/generated/**"]
  }
}

Or, if you prefer not to add another config file, you can put the same config under a "reactDoctor" key in your package.json.

Using It Programmatically

If you want to integrate React Doctor into a custom script or tooling pipeline, there is a Node.js API:

import { diagnose } from "react-doctor/api";

const result = await diagnose("./path/to/your/react-project");

console.log(result.score);       // { score: 82, label: "Good" }
console.log(result.diagnostics); // Array of Diagnostic objects
console.log(result.project);     // Framework, React version, compiler info

Each diagnostic object tells you the file, plugin, rule, severity, message, help text, line, and column. Clean enough to build your own reporting on top of.

Teaching Your AI Coding Agent React Best Practices

One underrated feature: React Doctor can install a "skill" into your coding agent — Cursor, Claude Code, Windsurf, Copilot, and others are supported:

curl -fsSL https://react.doctor/install-skill.sh | bash

This teaches the agent 47+ React best practice rules so it can catch issues proactively while you write code, not just after the fact.

Is It Worth Adding to Your Project?

Here is an honest assessment.

Where it genuinely helps:

Onboarding onto a legacy codebase. Run it once and you immediately get a map of the biggest problems, organized by category.
Enforcing standards across a team. The CI integration with diff mode means new PRs cannot silently introduce new antipatterns without someone noticing.
Dead code. Most linters do not catch unused files and exports across the entire project. React Doctor does this out of the box.
Framework-specific rules. If you are on Next.js, generic linters miss a lot. React Doctor knows about Next.js patterns and flags them appropriately.

Where you should temper expectations:

It is not a replacement for a well-configured ESLint setup. It is a complement. If you already have strict ESLint rules, some overlap is inevitable.
The score is a rough guide, not a precise metric. A score of 72 versus 75 does not mean much. Focus on the specific diagnostics, not the number.
It is relatively new (still under active development with open issues and PRs). Some rules may be noisy or context-dependent, which is why the config ignore list exists.
The --fix flag hands off to an AI agent (Ami) to auto-fix issues. This part is more experimental and depends on external tooling.

Bottom line: if you run npx -y react-doctor@latest . --verbose on your project right now and nothing surprises you, you probably did not need it. But if it surfaces 50 unused exports, three components with missing keys in lists, and a handful of useEffect dependency issues you forgot about, that is a morning of tech debt cleanup you would not have found otherwise.

For the CI use case alone — automatically flagging React-specific regressions in PRs with zero config — it earns its place in a frontend workflow.

Getting Started in 60 Seconds

# Run against your project
npx -y react-doctor@latest . --verbose

# If you use workspaces, select specific packages
npx -y react-doctor@latest . --project my-app

# Only scan changed files vs main
npx -y react-doctor@latest . --diff main

# Output just the score (useful in scripts)
npx -y react-doctor@latest . --score

The GitHub repo is at github.com/millionco/react-doctor.

RTK: Cut Your AI Coding Bill by 80% With One CLI Tool

ArshTechPro — Fri, 08 May 2026 21:08:33 +0000

If you use Claude Code, Cursor, Copilot, or any other AI coding assistant in your terminal, you are probably spending way more on tokens than you need to. RTK (Rust Token Killer) is an open-source CLI proxy that sits between your shell and your LLM and silently compresses what gets sent to the model — without changing how you work.

It has 39.5k stars on GitHub. It is worth understanding why.

The Problem It Solves

When an AI coding agent runs git status, the raw output can be 2,000 tokens. When it runs cargo test on a mid-sized project and a few tests fail, you are looking at 200+ lines of output — most of it passing tests you do not care about.

The agent reads all of it. You pay for all of it.

This happens dozens of times in a single session. A 30-minute Claude Code session on a TypeScript or Rust project can easily burn through 118,000 tokens just from routine shell commands — file reads, test runs, git operations, lint checks.

RTK intercepts those commands, applies smart filtering, and hands the model a compressed version that contains the same useful signal. According to the project's benchmarks, the same 30-minute session drops to around 23,900 tokens — an 80% reduction.

How It Actually Works

RTK is a CLI proxy. You prefix your commands with rtk, or you install a hook that does it transparently.

# Without RTK: git push outputs 15 lines (~200 tokens)
Enumerating objects: 5, done.
Counting objects: 100% (5/5), done.
Delta compression using up to 8 threads
...

# With RTK: git push outputs 1 line (~10 tokens)
ok main

Four strategies are applied depending on the command type:

Smart filtering — strips comments, whitespace, and boilerplate
Grouping — aggregates similar items, like files grouped by directory or errors grouped by type
Truncation — keeps the signal, drops the redundancy
Deduplication — collapses repeated log lines into a count

For test output specifically, RTK is particularly aggressive. cargo test on a failure goes from 200+ lines to roughly 20. You see which tests failed and why. The agent does not need to read the 13 passing tests to understand what went wrong.

Installation

RTK is a single Rust binary with no dependencies.

macOS (Homebrew):

brew install rtk

Linux / macOS (curl):

curl -fsSL https://raw.githubusercontent.com/rtk-ai/rtk/refs/heads/master/install.sh | sh

Via Cargo:

cargo install --git https://github.com/rtk-ai/rtk

One gotcha: there is another project called "rtk" (Rust Type Kit) on crates.io. If rtk gain fails after install, you got the wrong one. Use the --git flag above.

After install, connect it to your AI tool:

rtk init -g                    # Claude Code / Copilot
rtk init -g --agent cursor     # Cursor
rtk init -g --gemini           # Gemini CLI
rtk init --agent windsurf      # Windsurf
rtk init --agent cline         # Cline / Roo Code

Restart your AI tool and that is it. Commands are automatically rewritten from git status to rtk git status before the model ever sees the output.

What Commands Are Supported

The coverage is broad. Here is a quick scan of what RTK knows how to compress:

Git:

rtk git status      # compact status
rtk git log -n 10   # one-line commits
rtk git diff        # condensed diff
rtk git push        # -> "ok main"
rtk git pull        # -> "ok 3 files +10 -2"

Test runners (failures only — this is where the big savings come from):

rtk cargo test
rtk pytest
rtk go test
rtk jest
rtk vitest
rtk playwright test
rtk rspec

Build and lint:

rtk tsc             # TypeScript errors grouped by file
rtk ruff check      # Python linting
rtk cargo clippy    # Rust lints
rtk golangci-lint run

File operations:

rtk ls .            # token-optimized directory tree
rtk read file.rs    # smart file reading
rtk grep "pattern" .

AWS, Docker, Kubernetes are also covered. The project lists 100+ supported commands.

The Auto-Rewrite Hook

The most useful feature is the hook. Once you run rtk init -g, a PreToolUse hook is installed in Claude Code (or your chosen agent) that transparently rewrites Bash commands before execution. The model never knows RTK is involved — it just receives smaller, cleaner output.

One thing worth knowing: the hook only intercepts Bash tool calls. Claude Code's built-in Read, Grep, and Glob tools bypass it. If you want RTK filtering for those workflows, use the shell equivalents (cat, rg, find) or call rtk read, rtk grep, rtk find directly.

Token Savings in Practice

Here is the table from the project's README, representing a 30-minute session on a medium-sized project:

Command	Frequency	Standard	RTK	Savings
`ls` / `tree`	10x	2,000	400	-80%
`cat` / `read`	20x	40,000	12,000	-70%
`grep` / `rg`	8x	16,000	3,200	-80%
`git status`	10x	3,000	600	-80%
`git diff`	5x	10,000	2,500	-75%
`cargo test` / `npm test`	5x	25,000	2,500	-90%
`pytest`	4x	8,000	800	-90%
Total		~118,000	~23,900	-80%

You can see your own savings with:

rtk gain              # summary stats
rtk gain --graph      # ASCII graph of the last 30 days
rtk gain --history    # recent command history

Is It Worth It?

The honest case for trying it:

Zero friction to install and zero changes to your workflow after the hook is set up.
The savings are real and verifiable — you can check them yourself with rtk gain.
39.5k stars and active development (141 releases, v0.38.0 as of late April 2026) suggest this is not an abandoned project.
It is open-source (MIT), written in Rust, and ships as a single binary with no dependencies. The attack surface is minimal.

The honest caveats:

The benchmark numbers (60-90% savings) are estimates based on medium-sized projects. Real savings depend heavily on how you work and what you are building.
The hook only works on Bash calls. If your agent leans heavily on its native file-reading tools, a portion of your token usage is unaffected.
On Windows, you get full filter support but no auto-rewrite hook unless you use WSL. Native Windows gets a CLAUDE.md fallback mode instead.
When a command fails, RTK saves the full unfiltered output to disk so the model can read it — a thoughtful design, but worth being aware of if you are working with sensitive output.
If RTK's filter for a specific command is overly aggressive, it could in theory strip context the agent needed. The rtk discover command helps you find cases where savings were unexpectedly low, which can be a signal that something went wrong.

Quick Summary

RTK is a thin, fast CLI proxy that compresses the output of 100+ common dev commands before they reach your LLM. It installs in one command, hooks into your agent transparently, and saves you a measurable amount on token usage — particularly for test runners and git operations.

GitHub: github.com/rtk-ai/rtk

Local Deep Research: Run Your Own AI Research Assistant, Fully Private

ArshTechPro — Wed, 06 May 2026 20:56:52 +0000

If you have ever wished you could throw a complex question at an AI and get back a proper cited report — not a hallucinated paragraph, but something that actually searched the web, read papers, and synthesized sources — that is what Local Deep Research (LDR) does. And it runs entirely on your machine.

The project sits at about 4,000 GitHub stars at the time of writing, has 124 releases, and is actively maintained. It is worth understanding what it actually does before you decide whether to spin it up.

What Is It?

Local Deep Research is a self-hosted AI research assistant. You give it a question. It searches across multiple sources — web, arXiv, PubMed, Wikipedia, GitHub, your own local documents — iterates on what it finds, and produces a structured report with citations.

It supports both local models (via Ollama) and cloud models (OpenAI, Anthropic, Google). The "local" in the name means your data never has to leave your machine if you choose the fully-local setup.

Benchmark-wise, the project claims roughly 95% accuracy on the SimpleQA benchmark when tested with GPT-4.1-mini and SearXNG. That puts it in the range of commercial deep research tools.

Who This Is For

This tool is genuinely useful if you fall into one of these categories:

You do research-heavy work (technical writing, literature reviews, competitive analysis) and are tired of manually stitching together sources.
You want to search across your own document library with AI — think internal wikis, PDFs, notes.
You work with sensitive topics and cannot send queries to a third-party API.
You want to build a compounding knowledge base over time where each research session adds to a searchable library.

If you just want quick answers and are fine with ChatGPT, LDR is probably overkill. But if you want something you own and control, it is a serious option.

How It Works

The core loop is straightforward:

You submit a research question.
LDR picks a research strategy (quick summary, deep analysis, academic, etc.) and breaks the question into sub-queries.
It searches across configured sources, pulling results from the web, academic databases, or your local documents.
It synthesizes the results iteratively, discarding low-quality content and expanding on promising threads.
It produces a final report with citations and optionally stores sources in your encrypted local library.

Each session can download sources (arXiv papers, web pages, PubMed articles) directly into your library, which gets indexed and made searchable. Over time your knowledge base grows and future research queries can search across both live web results and everything you have already collected.

Getting Started

Option 1: Docker (Recommended for most people)

This is the fastest path. It handles dependencies, encryption, and all service wiring automatically.

Standard setup (CPU, works on Mac, Windows, Linux):

curl -O https://raw.githubusercontent.com/LearningCircuit/local-deep-research/main/docker-compose.yml
docker compose up -d

Wait about 30 seconds, then open http://localhost:5000.

With NVIDIA GPU acceleration (Linux only):

First install the NVIDIA Container Toolkit:

curl -fsSL https://nvidia.github.io/libnvidia-container/gpgkey | sudo gpg --dearmor \
  -o /usr/share/keyrings/nvidia-container-toolkit-keyring.gpg

curl -s -L https://nvidia.github.io/libnvidia-container/stable/deb/nvidia-container-toolkit.list | \
  sed 's#deb https://#deb [signed-by=/usr/share/keyrings/nvidia-container-toolkit-keyring.gpg] https://#g' | \
  sudo tee /etc/apt/sources.list.d/nvidia-container-toolkit.list

sudo apt-get update && sudo apt-get install nvidia-container-toolkit -y
sudo systemctl restart docker
nvidia-smi  # verify it worked

Then bring up the stack with GPU support:

curl -O https://raw.githubusercontent.com/LearningCircuit/local-deep-research/main/docker-compose.yml
curl -O https://raw.githubusercontent.com/LearningCircuit/local-deep-research/main/docker-compose.gpu.override.yml
docker compose -f docker-compose.yml -f docker-compose.gpu.override.yml up -d

The Docker Compose setup bundles Ollama (local LLM runner) and SearXNG (self-hosted meta-search engine) together with LDR. Everything runs locally.

Option 2: pip (For developers / Python integration)

If you want to embed LDR in a Python project or prefer to manage dependencies yourself:

# Install the package
pip install local-deep-research

# Run SearXNG in Docker for search
docker run -d -p 8080:8080 --name searxng searxng/searxng

# Install Ollama from https://ollama.ai, then pull a model
ollama pull gemma3:12b

# Start the web UI
python -m local_deep_research.web.app

Important note on encryption: The pip install does not automatically set up SQLCipher (the AES-256 encrypted database LDR uses for storing your data and API keys). If you hit errors during setup, bypass it for now with:

export LDR_ALLOW_UNENCRYPTED=true

This stores data in plain SQLite. Fine for local dev, not recommended for production or shared setups. Docker handles encryption out of the box.

Using the Python API

Once running, you can drive LDR programmatically:

from local_deep_research.api import LDRClient, quick_query

# One-liner research
summary = quick_query("username", "password", "What is the current state of Rust async runtimes?")
print(summary)

# Client for more control
client = LDRClient()
client.login("username", "password")
result = client.quick_research("Compare FAISS vs Hnswlib for vector search at scale")
print(result["summary"])

Using the HTTP API

LDR exposes a REST API with session-based authentication and CSRF protection. The auth flow is a bit verbose but works reliably:

import requests
from bs4 import BeautifulSoup

session = requests.Session()

# Get CSRF token from login page
login_page = session.get("http://localhost:5000/auth/login")
soup = BeautifulSoup(login_page.text, "html.parser")
csrf = soup.find("input", {"name": "csrf_token"}).get("value")

# Authenticate
session.post("http://localhost:5000/auth/login", data={
    "username": "user",
    "password": "pass",
    "csrf_token": csrf
})

# Get API CSRF token
api_csrf = session.get("http://localhost:5000/auth/csrf-token").json()["csrf_token"]

# Submit a research query
response = session.post(
    "http://localhost:5000/api/start_research",
    json={"query": "What are the tradeoffs between gRPC and REST for internal microservices?"},
    headers={"X-CSRF-Token": api_csrf}
)
print(response.json())

The repository includes ready-to-run HTTP examples under examples/api_usage/http/ that handle authentication, retry logic, and progress polling.

Enterprise / RAG Integration

If you already have a vector store or internal knowledge base, LDR can search it as one of its sources via LangChain retrievers:

from local_deep_research.api import quick_summary

result = quick_summary(
    query="What are our current deployment procedures for the payments service?",
    retrievers={"internal_kb": your_langchain_retriever},
    search_tool="internal_kb"
)

It supports FAISS, Chroma, Pinecone, Weaviate, Elasticsearch, and anything LangChain-compatible. This is where the tool gets interesting for teams — you can combine live web search with your own internal documents in a single research pass.

Search Sources Available

Free (no API key needed):

arXiv, PubMed, Semantic Scholar (academic)
Wikipedia, SearXNG (general web)
GitHub (technical)
The Guardian, Wikinews (news)
Wayback Machine (historical)

Premium (API key required):

Tavily (AI-optimized search)
Google (via SerpAPI or Programmable Search Engine)
Brave Search

Custom:

Your local documents
Any LangChain-compatible retriever

Supported LLMs

Local via Ollama: Llama 3, Mistral, Gemma, DeepSeek, and anything Ollama supports. No API costs, processing stays on your machine. Search queries will still hit the web if you are using web search engines.

Cloud: OpenAI (GPT-4, GPT-4.1-mini), Anthropic (Claude 3), Google (Gemini), and 100+ models via OpenRouter.

The README benchmarks show GPT-4.1-mini + SearXNG hitting 90-95% on SimpleQA. Gemini 2.0 Flash reached 82% in a single test run. Results vary by query type and configuration.

Security Model

For a self-hosted tool that holds API keys and research data, the security story matters.

Each user gets an isolated SQLCipher database encrypted with AES-256. The project uses a zero-knowledge design — there is no password recovery mechanism, which means even server admins cannot read user data. Docker images are signed with Cosign and include SLSA provenance attestations. The CI pipeline runs CodeQL, Semgrep, OWASP ZAP, Trivy, Gitleaks, and OSV-Scanner on every release.

If you are running this fully locally with Ollama and SearXNG, nothing leaves your machine.

Is It Worth Trying?

Yes, if:

You regularly do research that requires synthesizing multiple sources.
You need to search across private documents alongside the web.
Privacy matters — you cannot send queries to commercial APIs.
You want to build up a searchable knowledge base over time.
You are building a research-augmented application and want a local-first backend.

Maybe not, if:

You need simple Q&A. This is heavyweight for that.
You are on limited hardware. Running a local LLM plus SearXNG plus the app itself adds up. A GPU helps significantly.
You want a zero-config experience. The Docker path is smooth, but getting the full setup — GPU passthrough, encryption, custom models — takes some tinkering.

The SQLCipher setup is the roughest edge. Docker sidesteps it cleanly, but the pip path has caught people out. The project documents it well, but plan for some back-and-forth if you go that route.

Quick Reference


Repo	github.com/LearningCircuit/local-deep-research
License	MIT
Language	Python (80%), JavaScript (14%)
Install	Docker (recommended) or pip
Local LLM	Ollama
Local Search	SearXNG
Database	SQLCipher (AES-256)
API	REST + Python client
WebSocket	Yes (live progress)
Benchmark	~95% SimpleQA (GPT-4.1-mini)

DeepSeek-TUI: Run a DeepSeek Coding Agent Directly in Your Terminal

ArshTechPro — Wed, 06 May 2026 16:11:06 +0000

If you have spent time using AI coding tools through a browser or GUI, you already know the friction. You switch windows, lose context, and your workflow gets interrupted. DeepSeek-TUI removes that friction by bringing a full DeepSeek coding agent into your terminal.

This article walks you through what DeepSeek-TUI is, what you can do with it, and exactly how to get it running.

What is DeepSeek-TUI

DeepSeek-TUI is an open-source terminal user interface that connects to DeepSeek's language models and acts as an agentic coding assistant. It is written in Rust and installable via npm, which means you do not need a Rust toolchain to get started.

The key thing to understand is that this is not just a chat interface. It is an agent — meaning it can take actions on your behalf: edit files, run shell commands, make git commits, search the web, and interact with external services through MCP (Model Context Protocol) servers.

Everything runs inside your terminal. No browser tab. No electron app. Your existing workflow stays intact.

Three Modes of Operation

DeepSeek-TUI has three visible modes you can cycle through with Tab or Shift+Tab:

Plan mode — Before the agent starts making changes, it shows you a plan. You review and approve before anything happens. Good for unfamiliar or risky tasks.

Agent mode — The default. The agent works interactively, uses tools step by step, and asks for approval on sensitive actions like running shell commands.

YOLO mode — Auto-approves all tool use. Useful in isolated, trusted environments where you want fully autonomous operation without confirmation prompts.

You can also set a default mode in your config, or launch straight into YOLO with deepseek-tui --yolo.

Installation

Prerequisites

You need Node.js installed. That is it for the npm path.

Step 1 — Install via npm

npm install -g deepseek-tui

This is the quickest way and works on macOS, Linux, and Windows.

Step 2 — Get a DeepSeek API Key

Go to platform.deepseek.com and create an account. Generate an API key from the dashboard. DeepSeek's API pricing is notably low compared to other providers, which makes this tool cost-effective even for heavy use.

Step 3 — Set Your API Key

You have two options:

Option A — Interactive login (recommended for first-time setup)

deepseek-tui login

This prompts you for your API key and saves it to ~/.deepseek/config.toml.

Option B — Environment variable (useful for CI or scripting)

DEEPSEEK_API_KEY="your_key_here" deepseek-tui

Step 4 — Launch

deepseek-tui

On first launch, if no API key is configured, it will prompt you for one automatically.

Verify Your Setup

deepseek-tui doctor

This runs a diagnostics check: API key presence, model configuration, MCP status, shell tool availability, and API connectivity. If something is off, it tells you exactly what.

Alternative Installation Methods

If you prefer to install from source or via Rust's package manager:

Via cargo (requires Rust 1.85 or newer):

cargo install deepseek-tui --locked
cargo install deepseek-tui-cli --locked

Build from source:

git clone https://github.com/Hmbown/DeepSeek-TUI.git
cd DeepSeek-TUI
cargo install --path crates/tui --locked

Basic Usage

Once running, you interact with the agent through the TUI. Here are the most useful commands to know:

deepseek-tui                                   # start the interactive TUI
deepseek-tui -p "explain this codebase"        # one-shot prompt, no interactive UI
deepseek-tui --yolo                            # start in YOLO (auto-approve) mode
deepseek-tui models                            # list available DeepSeek models
deepseek-tui serve --http                      # run as an HTTP/SSE API server

Inside the TUI:

F1 opens help
Ctrl+K opens the command palette
Esc backs out of the current action
Tab / Shift+Tab cycles between Plan, Agent, and YOLO modes
/config opens the interactive config editor
/compact manually compresses session history when context gets long

To add local files as context, type @path/to/file in the composer. To attach an image from the clipboard, use Ctrl+V.

Configuration

The config file lives at ~/.deepseek/config.toml. A minimal working config looks like this:

api_key = "your_deepseek_api_key"
default_text_model = "deepseek-v4-pro"

Profiles

If you work with multiple providers or API keys, profiles let you switch between them:

api_key = "personal_key"
default_text_model = "deepseek-v4-pro"

[profiles.work]
api_key = "work_key"
base_url = "https://api.deepseek.com"

Switch profiles on launch:

deepseek-tui --profile work
# or
DEEPSEEK_PROFILE=work deepseek-tui

Key Environment Variables

Variable	Purpose
`DEEPSEEK_API_KEY`	Your API key
`DEEPSEEK_MODEL`	Override the default model for one run
`DEEPSEEK_BASE_URL`	Point to a custom endpoint
`DEEPSEEK_PROFILE`	Select a named profile
`DEEPSEEK_SANDBOX_MODE`	Control file access: `read-only`, `workspace-write`, `danger-full-access`
`DEEPSEEK_APPROVAL_POLICY`	Tool approval behavior: `on-request`, `untrusted`, `never`

Supported Providers

Beyond DeepSeek's own API, you can point the tool at other providers that host DeepSeek models:

deepseek — Default, uses https://api.deepseek.com
nvidia-nim — NVIDIA's hosted NIM endpoints
fireworks — Fireworks AI
sglang — Self-hosted, defaults to http://localhost:30000/v1
openrouter — OpenRouter
novita — Novita AI

Set the provider in your config or via DEEPSEEK_PROVIDER.

MCP Server Integration

MCP (Model Context Protocol) lets you connect external tools and services to the agent. DeepSeek-TUI reads MCP configuration from ~/.deepseek/mcp.json.

To scaffold the MCP directory:

deepseek-tui mcp init

Once configured, any MCP server listed in that file becomes available as a tool the agent can call. This is how you would connect databases, custom APIs, or other external systems to the agent's toolset.

Feature Flags

You can enable or disable individual capabilities:

[features]
shell_tool = true
subagents = true
web_search = true
apply_patch = true
mcp = true

Or override for a single session:

deepseek-tui --enable web_search
deepseek-tui --disable subagents

To see the current state of all flags:

deepseek-tui features list

Current Models

DeepSeek-TUI defaults to deepseek-v4-pro. Both current public models have 1M context windows and support thinking mode:

deepseek-v4-pro — Full capability model, default
deepseek-v4-flash — Faster, lighter variant

The legacy aliases deepseek-chat and deepseek-reasoner still work but map to deepseek-v4-flash. Run deepseek-tui models to see live model IDs from your configured endpoint.

Practical Tips

Use Plan mode for anything that touches production. It forces a review step before the agent starts modifying files. Five seconds of reading a plan is worth it.

Run doctor after any config change. It catches misconfiguration before you need it to work.

Use @file references liberally. The more context you give the agent up front, the fewer clarification rounds you need.

Set sandbox_mode = "workspace-write" for normal development. This restricts the agent to your project directory, which is a sensible default. Use danger-full-access only when you explicitly need broader access.

Check deepseek-tui --no-alt-screen if you want scrollback. By default the TUI uses an alternate screen. Running with --no-alt-screen keeps output in your normal terminal buffer so you can scroll through it.

Zig: The Honest Systems Language You Have Been Ignoring

ArshTechPro — Thu, 30 Apr 2026 12:10:34 +0000

A practical introduction for developers who want control without chaos

What Is Zig?

If you have been writing C for years and quietly resenting it, or if you tried Rust and got intimidated by the borrow checker on day two, Zig might be the language you have been waiting for.

Zig is a general-purpose systems programming language created by Andrew Kelley in 2016. It is free, open-source (MIT licensed), and designed with one clear ambition: be a better C. Not a replacement for Rust, not a competitor to Go -- a sharper, more honest version of C.

The official tagline from the Zig team sums it up well: Zig is built for "robustness, optimality and maintainability." It does not introduce new paradigms. It does not hide things from you. It just removes the parts of C that have been quietly ruining your week for decades.

As of April 2026, Zig sits at position 39 on the TIOBE Index with a 0.31% rating -- small but growing, with real production usage. Bun, the popular JavaScript runtime, is written in Zig. So is a Sega Dreamcast emulator called Deecy, and a Wayland compositor called River. The community is small and focused, and that is part of its appeal.

The Core Philosophy: No Hidden Anything

The most important thing to understand about Zig is its stance on transparency.

Zig has:

No hidden control flow
No hidden memory allocations
No preprocessor
No macros
No operator overloading
No exceptions

If a line of Zig code does not look like it calls a function, it does not call a function. That sounds obvious until you spend a morning debugging a C++ program where a + b secretly calls an overloaded operator that allocates memory.

In Zig, if you write foo() and then bar(), those two functions are called, in that order, guaranteed. No exceptions swallowing control flow, no hidden allocations, no surprises.

The entire Zig syntax is defined in a 580-line PEG grammar file. That is the whole language. For comparison, the C++ grammar is notoriously enormous and context-dependent. Zig is designed so that a maintainer who does not know Zig deeply can still read and debug Zig code.

Merits: What Zig Does Well

1. Explicit Error Handling (No Exceptions)

Zig does not have exceptions. Instead, functions that can fail return error union types. You handle errors at the call site, explicitly, every time.

const result = try readFile("data.txt");

The try keyword means: if this fails, propagate the error up. If you want to handle it yourself, use catch:

const result = readFile("data.txt") catch |err| {
    std.debug.print("Error: {}\n", .{err});
    return;
};

There are no silent failures. Every error path is visible in the code. This is one of the most frequently praised features by developers coming from C.

2. Manual Memory Management Without the Foot-guns

Zig requires you to manage memory yourself -- there is no garbage collector, no runtime, and no automatic cleanup. But unlike C, Zig gives you allocators as first-class objects.

Instead of calling malloc directly, you pass an allocator into your functions:

const std = @import("std");

pub fn main() !void {
    var gpa = std.heap.GeneralPurposeAllocator(.{}){};
    defer _ = gpa.deinit();
    const allocator = gpa.allocator();

    const buffer = try allocator.alloc(u8, 1024);
    defer allocator.free(buffer);

    // use buffer...
}

This pattern makes testing much easier -- you can swap in a testing allocator that detects leaks automatically. The defer keyword ensures cleanup happens when the scope exits, which removes the classic C problem of forgetting to free memory before every return path.

3. `comptime`: Compile-Time Execution

This is Zig's most unusual and powerful feature. Instead of macros or templates, Zig uses comptime -- a directive that runs arbitrary Zig code at compile time.

fn max(comptime T: type, a: T, b: T) T {
    return if (a > b) a else b;
}

// Works for any numeric type
const a = max(i32, 10, 20);
const b = max(f64, 3.14, 2.71);

You are not writing a macro. You are writing normal Zig code that the compiler evaluates during compilation. You can inspect types, loop over struct fields, generate code -- all in plain Zig syntax. No template metaprogramming arcana required.

4. Built-In Cross-Compilation

Cross-compiling in C typically means fighting with toolchains, sysroots, and autoconf scripts. In Zig, it is a flag:

zig build-exe main.zig -target aarch64-linux-gnu
zig build-exe main.zig -target x86_64-windows-gnu
zig build-exe main.zig -target wasm32-wasi

Zig ships with its own cross-compilation toolchain. This is a genuine killer feature for embedded, IoT, WebAssembly, and server-side work where you need to build for multiple targets from a single machine.

5. C Interoperability

Zig can include C headers directly, with no bindings, no glue code:

const c = @cImport({
    @cInclude("stdio.h");
});

pub fn main() void {
    _ = c.printf("Hello from C\n");
}

You can also compile Zig code as a C library and call it from C. This makes Zig a practical incremental migration path for projects with large existing C codebases.

6. Four Build Modes

Zig separates safety from performance explicitly, giving you four build modes:

Debug -- safety checks on, slow, verbose panics
ReleaseSafe -- safety checks on, optimized
ReleaseFast -- safety checks off, maximum performance
ReleaseSmall -- optimized for binary size

You pick the trade-off consciously. There is no magic mode that guesses for you.

7. `defer` for Guaranteed Cleanup

The defer keyword runs a statement when the current scope exits, regardless of how it exits:

const file = try std.fs.openFileAbsolute("/etc/hosts", .{});
defer file.close();
// file.close() is called here no matter what

This removes entire categories of resource leak bugs common in C.

Demerits: Where Zig Falls Short

Being fair is important. Zig is a young language and it comes with real limitations.

1. Not at 1.0 Yet

As of 2026, Zig is still pre-1.0. The language itself changes between versions. Code written for 0.11 may need updates to compile on 0.13. If you are building production software that needs to stay stable for five years, this is a real concern. The core team is actively working toward a stable release, but it is not there yet.

2. Small Ecosystem

The standard library is usable but not comprehensive. There is no official package repository -- packages are URLs pointing to compressed archives.

3. No Async (For Now)

Async support existed in earlier versions but was removed. The team found it needed to be redesigned from the ground up to work correctly with the native backend. It is coming back, but it is not in the current stable releases. If your project depends heavily on async I/O, this matters.

5. Smaller Community

A smaller community means fewer Stack Overflow answers, fewer tutorials, fewer examples to copy from.

How to Get Started

Installation

# On macOS with Homebrew
brew install zig

# On Linux (download from ziglang.org)
wget https://ziglang.org/download/0.13.0/zig-linux-x86_64-0.13.0.tar.xz
tar xf zig-linux-x86_64-0.13.0.tar.xz
export PATH=$PATH:$(pwd)/zig-linux-x86_64-0.13.0

# Verify
zig version

Hello World

const std = @import("std");

pub fn main() void {
    std.debug.print("Hello, Zig!\n", .{});
}

Run it:

zig run hello.zig

Compile it:

zig build-exe hello.zig
./hello

A More Realistic Example: Reading a File

const std = @import("std");

pub fn main() !void {
    var gpa = std.heap.GeneralPurposeAllocator(.{}){};
    defer _ = gpa.deinit();
    const allocator = gpa.allocator();

    const file = try std.fs.cwd().openFile("notes.txt", .{});
    defer file.close();

    const contents = try file.readToEndAlloc(allocator, 1024 * 1024);
    defer allocator.free(contents);

    std.debug.print("{s}\n", .{contents});
}

Notice: every operation that can fail uses try. Every allocation has a matching defer to free it. Every resource has a matching defer to close it. The flow is explicit from top to bottom.

Writing a Test

Zig has a built-in test runner, no external library required:

const std = @import("std");

fn add(a: i32, b: i32) i32 {
    return a + b;
}

test "add works correctly" {
    try std.testing.expectEqual(@as(i32, 5), add(2, 3));
}

Run it:

zig test math.zig

How Zig Compares to Its Neighbors

Feature	C	Rust	Zig
Memory management	Manual	Ownership/borrow	Manual with allocators
Error handling	errno / return codes	Result type	Error unions
Generics	Macros / void*	Traits	comptime
Cross-compilation	Painful	Moderate	First-class
C interop	Native	Requires FFI	Direct (cImport)
Learning curve	Moderate	Steep	Moderate
Ecosystem maturity	Extensive	Growing	Early
Stability	Stable	Stable	Pre-1.0

Zig sits between C and Rust. It gives you C's performance and directness without C's preprocessor mess, and it avoids Rust's complexity without pretending the safety tradeoffs don't exist. You still have to think carefully about memory. You just have better tools to do it.

Who Should Use Zig Today

Zig is a good choice right now if you are:

Writing embedded or low-level systems software and tired of C's preprocessor and opaque error handling
Building tools or runtimes where cross-compilation matters (WebAssembly, IoT, CLI tools)
Incrementally migrating a C codebase and want a language that interoperates directly
Exploring language design and compilers -- Zig's internals are genuinely instructive
The kind of developer who reads source code instead of waiting for Stack Overflow answers

It is probably not the right choice today if you need a stable production language for a team unfamiliar with systems programming, or if you need a rich ecosystem of third-party libraries out of the box.

Final Thought

Zig's design philosophy can be summarized in one sentence: if it isn't written, it doesn't happen. No hidden allocations, no hidden control flow, no hidden anything. That philosophy resonates with a specific kind of developer -- the one who wants to know exactly what the machine is doing.

It is not the flashiest language. It does not have a mascot with a marketing team behind it. But the developers who try it tend to keep using it, and the projects built with it -- Bun being the most visible example -- demonstrate that it can produce fast, real software.

If you have ever thought "I wish C just worked better," give Zig an afternoon. You might not put it down.

Standard library reference: ziglang.org/documentation

Claude Code Routines: Put Your AI Agent on Autopilot

ArshTechPro — Thu, 30 Apr 2026 04:39:20 +0000

If you have been using Claude Code interactively, you already know what it can do in a session. Routines take that further: you define a prompt once, wire up a trigger, and Claude Code runs autonomously on Anthropic-managed cloud infrastructure whenever that trigger fires. Your laptop can be off. The job still runs.

This article walks through what routines are, how to set them up, and where the rough edges are during the current research preview.

What Is a Routine?

A routine is a saved Claude Code configuration. It packages three things:

A prompt (the instructions Claude runs each time)
One or more GitHub repositories to work in
A set of connectors (MCP servers for external services like Slack, Linear, etc.)

You attach one or more triggers to it. Each trigger type determines when a run starts:

Schedule - recurring on a cron cadence, or a one-off at a specific timestamp
API - an HTTP POST to a per-routine endpoint with a bearer token
GitHub event - reactions to pull requests, releases, and similar repository events

A single routine can combine all three. A PR review routine could run nightly, also fire when your CD pipeline calls the endpoint, and also react to every new pull request.

Routines are available on Pro, Max, Team, and Enterprise plans with Claude Code on the web enabled. You manage them at claude.ai/code/routines or from the CLI using /schedule.

Why This Matters

The key property is that routines run without you present. A regular Claude Code session expects you to review, approve, and guide. A routine is designed for unattended, repeatable work tied to a clear outcome.

That changes the use cases you can build:

Backlog maintenance. A schedule trigger runs every weeknight. The routine reads issues opened since the last run, applies labels, assigns owners based on the area of code referenced, and posts a summary to Slack. Your team starts the day with a groomed queue.

Alert triage. Your monitoring tool POSTs to the routine's API endpoint when an error threshold crosses. The routine pulls the stack trace, correlates it with recent commits, and opens a draft PR with a proposed fix. On-call reviews the PR instead of starting from a blank terminal.

Bespoke code review. A GitHub trigger fires on pull_request.opened. The routine applies your team's review checklist and leaves inline comments covering security, performance, and style issues. Human reviewers focus on design decisions.

Library porting. A trigger fires on merged PRs in one SDK repository. The routine ports the change to a parallel SDK in another language and opens a matching PR. Two libraries stay in sync without a human re-implementing each change.

Creating a Routine

You can create routines from the web UI, the Claude Desktop app, or the CLI.

From the Web

Go to claude.ai/code/routines and click New routine.
Name it and write the prompt. The prompt is the most important part. Since the routine runs autonomously, the prompt must be self-contained and explicit about what to do and what success looks like.
Select one or more GitHub repositories. Each is cloned fresh at the start of every run from the default branch.
Pick a cloud environment (controls network access, environment variables, and setup scripts). A Default environment is provided.
Add triggers (Schedule, GitHub event, or API).
Review connectors. All your connected MCP connectors are included by default. Remove any the routine does not need.
Click Create.

After creation, click Run now on the detail page to start an immediate run without waiting for a trigger.

From the CLI

/schedule daily PR review at 9am

/schedule in 2 weeks, open a cleanup PR that removes the feature flag

Claude walks through the same information the web form collects and saves the routine. The CLI supports scheduled triggers only. To add API or GitHub triggers, edit the routine on the web afterward.

Useful CLI management commands:

/schedule list        # see all routines
/schedule update      # change a routine
/schedule run         # trigger a routine immediately

Configuring Triggers

Schedule Triggers

Pick a preset: hourly, daily, weekdays, or weekly. Times are entered in your local timezone and converted automatically. Runs may start a few minutes after the scheduled time due to stagger, but the offset is consistent for each routine.

For custom intervals (every two hours, first of each month), pick the closest preset in the form and then use /schedule update in the CLI to set a specific cron expression. The minimum interval is one hour.

One-off runs fire the routine a single time at a specific timestamp, then auto-disable. Useful for cleanup after a rollout, follow-ups when an upstream change lands, or end-of-week summaries.

One-off runs do not count against the daily routine run cap. They draw down your regular subscription usage like any other session.

API Triggers

An API trigger gives the routine a dedicated HTTP endpoint. POSTing to it with the bearer token starts a new session and returns a session URL.

To set one up:

Open the routine for editing.
Click Add another trigger and choose API.
Copy the URL and click Generate token. Store the token immediately - it is shown once and cannot be retrieved later.

Here is how to call the endpoint:

curl -X POST https://api.anthropic.com/v1/claude_code/routines/trig_01ABCDEFGHJKLMNOPQRSTUVW/fire \
  -H "Authorization: Bearer sk-ant-oat01-xxxxx" \
  -H "anthropic-beta: experimental-cc-routine-2026-04-01" \
  -H "anthropic-version: 2023-06-01" \
  -H "Content-Type: application/json" \
  -d '{"text": "Sentry alert SEN-4521 fired in prod. Stack trace attached."}'

The text field is optional freeform context passed alongside the saved prompt. It is not parsed - if you send JSON, the routine receives it as a literal string.

A successful response looks like this:

{
  "type": "routine_fire",
  "claude_code_session_id": "session_01HJKLMNOPQRSTUVWXYZ",
  "claude_code_session_url": "https://claude.ai/code/session_01HJKLMNOPQRSTUVWXYZ"
}

Open the session URL to watch the run in real time, review changes, or continue the conversation manually.

Note: The /fire endpoint ships under the experimental-cc-routine-2026-04-01 beta header. Request and response shapes, rate limits, and token semantics may change. Breaking changes ship behind new dated beta header versions, with the two most recent previous versions remaining active during migration.

Each routine gets its own token scoped to that routine only. To rotate or revoke it, return to the same modal and use Regenerate or Revoke.

GitHub Triggers

GitHub triggers start a new session automatically on matching repository events. Each matching event starts its own independent session - there is no session reuse across events.

Supported events:

Event	Triggers when
Pull request	A PR is opened, closed, assigned, labeled, synchronized, or otherwise updated
Release	A release is created, published, edited, or deleted

You can subscribe to a specific action (like pull_request.opened) or to all actions in the category.

Filters let you narrow which events actually start a session:

Filter	Matches
Author	PR author's GitHub username
Title	PR title text
Body	PR description text
Base branch	Branch the PR targets
Head branch	Branch the PR comes from
Labels	Labels applied to the PR
Is draft	Whether the PR is in draft state
Is merged	Whether the PR has been merged

Operators: equals, contains, starts with, is one of, is not one of, matches regex.

One thing to watch with regex: the matches regex operator tests the entire field value, not a substring. To match any PR title containing hotfix, write .*hotfix.*. Without the surrounding .*, it only matches a title that is exactly hotfix and nothing else. For substring matching without regex syntax, use the contains operator.

Example filter combinations:

Auth module review: base branch main, head branch contains auth-provider
Ready-for-review only: is draft is false
Label-gated backport: labels include needs-backport

The Claude GitHub App must be installed on the repository. The trigger setup prompts you if it is not already. Note that running /web-setup in the CLI grants repository access for cloning but does not install the GitHub App and does not enable webhook delivery. GitHub triggers require the App specifically.

During the research preview, GitHub webhook events are subject to per-routine and per-account hourly caps. Events beyond the limit are dropped until the window resets.

Branch Behavior and Safety

By default, Claude can only push to branches prefixed with claude/. This prevents routines from accidentally modifying protected or long-lived branches.

To allow pushing to any branch (for example, if you need Claude to push directly to main or a release branch), enable Allow unrestricted branch pushes for that repository when creating or editing the routine. Scope this permission carefully.

Connectors

Routines can use your connected MCP connectors to read from and write to external services during each run. A backlog routine might read from a Slack channel and create issues in Linear. An alert triage routine might read from PagerDuty and push to GitHub.

All connectors are included by default when you create a routine. Remove any the routine does not actually need. During a run, Claude can use every tool from an included connector, including writes, without asking for permission.

Usage and Limits

Routines draw down subscription usage the same way interactive sessions do. There is also a daily cap on how many routine runs can start per account.

You can check your current consumption and remaining daily routine runs at claude.ai/code/routines or claude.ai/settings/usage.

When a routine hits the daily cap or your subscription usage limit, organizations with extra usage enabled can keep running routines on metered overage. Without extra usage, additional runs are rejected until the window resets. Enable extra usage from Settings > Billing.

One-off runs are exempt from the daily routine run allowance. They still consume your regular subscription usage.

There is no per-run token count displayed directly in the routine detail view. Usage is reflected in your overall account consumption at the settings page rather than being itemized per routine run.

Managing Runs

Click a routine in the list to open its detail page. From there you can view past runs, see what Claude did in each run, review changes, create a pull request, or continue the conversation.

You can also:

Click Run now to start an immediate run
Toggle the schedule on and off to pause or resume
Edit the name, prompt, repositories, environment, connectors, or triggers
Delete the routine (past sessions created by it remain in your session list)

Things to Know Before You Ship

Routines run as you. Anything a routine does through your connected GitHub identity or connectors appears as your account. Commits and pull requests carry your GitHub user. Slack messages and Linear tickets use your linked accounts.

Routines belong to your individual account. They are not shared with teammates and count against your account's daily run allowance.

The prompt is everything. The routine runs autonomously with no approval prompts. There is no permission-mode picker. Write prompts that are self-contained, explicit about the goal, and explicit about what success looks like.

This is research preview. Behavior, limits, and the API surface may change. The /fire endpoint ships under a dated beta header for exactly this reason.

Related Resources

Lemonade v10.3: Run Local LLMs, Image Gen, and Speech on Your Own GPU for Free

ArshTechPro — Wed, 29 Apr 2026 20:09:26 +0000

If you are building AI-powered apps and feeling the cost of cloud API bills — or the anxiety of sending user data off-device — Lemonade is worth your time.

Lemonade is an open-source local AI server (3.7k stars, sponsored by AMD) that runs LLMs, image generation, speech-to-text, and text-to-speech entirely on your own hardware. It exposes a standard OpenAI-compatible API, so switching from a cloud provider means changing one URL. The project just shipped v10.3, its biggest release yet.

What is Lemonade?

Lemonade installs as a system service and manages everything: model downloads, backend selection, and a unified REST endpoint at http://localhost:13305/v1. Under the hood it wires together proven inference engines:

llama.cpp for GGUF LLMs (Vulkan, ROCm, CPU, Metal)
OnnxRuntime GenAI / FastFlowLM for NPU-accelerated FLM models
whisper.cpp for speech-to-text
stable-diffusion.cpp for image generation
Kokoro for text-to-speech

Apps like n8n, VS Code GitHub Copilot, Open WebUI, Continue, OpenHands, and Dify already integrate with it out of the box via the standard OpenAI API.

What is new in v10.3 (Latest Release)

v10.3 is a landmark release with three headline changes.

Desktop app is now 10x smaller. The app migrated from Electron to Tauri, a Rust-based cross-platform framework that uses the system's native webview instead of bundling Chromium. macOS and Windows binaries dropped from ~101-107 MB to ~7-9 MB.

OmniRouter for true omni-modal chat. The new OmniRouter unifies all backends — text, image, speech, vision — into a single OpenAI-compatible endpoint. You can interact with these modalities as tools in an agentic loop, making natural-language requests like "generate an image of X and then describe it" without gluing separate API calls together.

ROCm 7 support with multiple channels. ROCm 7.2 stable, 7.12 preview, and TheRock nightly builds are all supported. The 7.12 preview is now the default.

Other notable changes in v10.3:

Light mode theme added to the GUI
Easy llama.cpp version pinning and auto-update
AppImage removed for Linux; use the web app or Snap instead
lemonade-server-minimal.msi deprecated (will be removed in a future release)
amd_igpu and amd_dgpu consolidated to amd_gpu in the system-info endpoint
nvidia_dgpu renamed to nvidia_gpu for consistency

Recent release history at a glance

Version	Key headline
v10.3 (latest)	OmniRouter, Tauri app (10x smaller), ROCm 7
v10.2	Embeddable Lemonade binary, Qwen Image models, OpenCode integration
v10.1	Gemma 4 on GPU, super-resolution (Real-ESRGAN), new `lemonade` CLI, default port changed to 13305
v10.0	Claude Code integration, Fedora RPM installer, NPU on Linux, FLM multi-modal
v9.4	Qwen 3.5 on ROCm/Vulkan, redesigned app, image editing endpoint

Install

Windows

Download lemonade.msi from the releases page. This installs both the server and the Tauri desktop app.

Ubuntu / Debian (PPA)

sudo add-apt-repository ppa:lemonade-team/stable
sudo apt install lemonade-server

Snap

sudo snap install lemonade-server

macOS (beta)

Download the .pkg from the releases page.

Docker

docker run -p 13305:13305 lemonade-sdk/lemonade-server

RPM (Fedora)

# Download the .rpm from the releases page
sudo rpm -i lemonade-server-10.3.0.x86_64.rpm

Your first model in 3 commands

Note: as of v10.1, the CLI command is lemonade (the old lemonade-server CLI is deprecated).

# See which backends your hardware supports
lemonade recipes

# Download a model
lemonade pull Gemma-3-4b-it-GGUF

# Run it
lemonade run Gemma-3-4b-it-GGUF

Other modalities work the same way:

# Image generation
lemonade run SDXL-Turbo

# Text-to-speech
lemonade run kokoro-v1

# Speech-to-text
lemonade run Whisper-Large-v3-Turbo

Integrating with your app

Because Lemonade exposes an OpenAI-compatible API, you swap it in with a single config change. The base URL as of v10.1 is http://localhost:13305/v1.

Python

from openai import OpenAI

client = OpenAI(
    base_url="http://localhost:13305/v1",
    api_key="lemonade"  # required by the library, but unused by Lemonade
)

response = client.chat.completions.create(
    model="Gemma-3-4b-it-GGUF",
    messages=[
        {"role": "system", "content": "You are a helpful assistant."},
        {"role": "user", "content": "Summarize the benefits of running AI locally."}
    ]
)

print(response.choices[0].message.content)

Node.js

import OpenAI from "openai";

const client = new OpenAI({
    baseURL: "http://localhost:13305/v1",
    apiKey: "lemonade",
});

const response = await client.chat.completions.create({
    model: "Gemma-3-4b-it-GGUF",
    messages: [{ role: "user", content: "Hello from Node.js" }],
});

console.log(response.choices[0].message.content);

Lemonade also supports the Ollama API and the Anthropic API for apps that use those clients natively.

Supported hardware

Hardware	Backend	Notes
AMD Radeon RDNA3 / RDNA4 GPU	ROCm	RX 7000/9000 series, Radeon PRO
Ryzen AI MAX (Strix Halo)	ROCm (gfx1151)	Windows and Ubuntu
Any Vulkan-capable GPU	Vulkan (llamacpp)	Broad compatibility
AMD Ryzen AI NPU (XDNA2)	FLM / FastFlowLM	Windows and Linux (beta)
Any x86_64 CPU	CPU	Universally available, slower
Apple Silicon	Metal	macOS beta

Not sure what your machine supports? Run:

lemonade recipes

It auto-detects your hardware and lists exactly which backends are available.

Embeddable Lemonade

Since v10.2, you can bundle Lemonade as a portable binary inside your own application. Your users get local multi-modal AI without ever seeing a Lemonade installer or any Lemonade branding.

# Run lemond as a subprocess from your app
lemond ./

Full guide: lemonade-server.ai/docs/embeddable/

This is particularly useful for desktop app developers who want to ship local AI features without taking on the complexity of packaging inference engines themselves.

App integrations

Lemonade has a growing marketplace of first-class integrations. Highlights include:

VS Code GitHub Copilot — use local models for code completions
Claude Code — lemonade launch claude wires it up natively (added in v10.0)
Open WebUI — a polished ChatGPT-style UI, running locally
Continue — local AI coding assistant for VS Code and JetBrains
n8n — automate workflows with local AI nodes
OpenHands — local AI agent for software engineering tasks
Dify — LLM app building platform
AnythingLLM — local knowledge base with RAG

OmniRouter: the key new API concept in v10.3

OmniRouter is worth calling out separately because it changes how you think about the API surface. Previously you would call separate endpoints for text, image, and speech. With OmniRouter, you interact through a single multi-modal endpoint and Lemonade routes each request to the correct backend engine automatically.

This means you can build agentic pipelines — for example, a loop that generates text, converts it to speech, and produces an image — all through one unified client without managing multiple base URLs or backend configurations.

How it compares to Ollama and LM Studio

These tools all solve similar problems. Where Lemonade stands out:

NPU support — one of the very few tools that accelerates inference on the AMD XDNA2 NPU in Ryzen AI laptops
True multi-modal in one server — text, images, speech-to-text, and TTS from a single API endpoint
OmniRouter — automatic multi-modal routing without manual backend wiring
Embeddable binary — package it inside your own app with no Lemonade branding
Multiple API standards — OpenAI, Anthropic, and Ollama APIs simultaneously
AMD-first optimizations — deep ROCm integration and NPU tooling maintained by AMD engineers

If you are on NVIDIA with a mainstream GPU and only need text generation, Ollama is slightly simpler to get started. For AMD hardware, AI PCs with NPUs, or multi-modal workloads, Lemonade covers more ground.

Quick reference

Resource	Link
GitHub	github.com/lemonade-sdk/lemonade

Claude Connectors Explained: How to Give Claude Access to Your Tools

ArshTechPro — Mon, 27 Apr 2026 11:10:44 +0000

Claude is no longer just a chat window. With Connectors, you can wire it up to the tools your team actually uses. Google Drive, Gmail, GitHub, Slack, Notion, Asana, Spotify, Uber, and over 200 others.

This post covers what Connectors are, how they work under the hood, and how to build your own.

What Are Connectors?

Connectors extend Claude's capabilities by giving it access to external tools, data sources, and services. They are powered by the Model Context Protocol (MCP), an open standard created by Anthropic.

Think of it this way: Claude has a conversation with you, but mid-conversation it can reach into your Google Drive, pull a document, summarize it, and drop the result into a Slack message — all without you leaving the thread.

A real workflow example: a product manager pulls a query from Amplitude, turns it into a Canva deck, and drops the link into Asana. One conversation. Three connected apps.

How It Works: MCP in Plain English

MCP is a protocol that defines how Claude (the client) communicates with external services (the servers). The spec is open, which means anyone can build a connector for any service.

There are two things a connector can do:

1. Provide tools and data
This gives Claude the ability to take actions — read files, send emails, create issues, query databases, etc.

2. Surface UI components (MCP Apps)
Instead of just returning text, an MCP server can render interactive UI elements directly in the conversation: charts, maps, forms, booking flows, and more.

Types of Connectors

Prebuilt First-Party Integrations

Anthropic ships ready-to-use connectors for the most common services. No setup beyond logging in:

Google Drive, Gmail, Google Calendar
GitHub
Slack
Microsoft 365

These work across all Claude products immediately.

Remote MCP Servers

Third-party developers can host their own MCP servers in the cloud. Claude connects to them over HTTPS. These are what you find in the Connectors Directory — verified by Anthropic and available to all users.

MCP Apps

These are MCP servers that go a step further and render UI inside the conversation. A booking flow, an interactive chart, a filled-out form — all rendered in the chat thread.

MCP Bundles (Desktop Extensions)

For enterprise or local use cases, you can package an MCP server with all its dependencies into a desktop extension (.mcpb format). This handles cross-platform compatibility, code signing, and centralized version updates.

Local MCP via Plugins

If you want to distribute a local MCP server through npm or PyPI, you bundle it in a Plugin using .mcp.json and submit it to the plugin directory.

Where Connectors Work

Platform	Remote MCP	MCP Apps	Local Extensions
Claude.ai (web)	Yes	Yes	No
Claude Desktop	Yes	Yes	Yes
Claude Mobile	Yes	Beta	No
Claude Code	Yes	No	Via plugins
Claude Cowork	Yes	Yes	Via plugins

How Claude Discovers and Uses Connectors

This is the part that feels almost magical once it clicks.

When you connect a service, Claude does not just wait for you to explicitly invoke it. It dynamically surfaces the right connector based on what you are doing. Ask Claude to recommend a weekend hike and AllTrails will appear automatically. Ask for grocery help and Instacart shows up.

When multiple connectors could help, Claude shows all of them and lets you choose. There is no hidden ranking by paid placement. The directory is ad-free.

Privacy and Data Boundaries

Your data from connected apps is not used to train Claude's models.
A connected app cannot see your other conversations with Claude.
Before Claude books or purchases something on your behalf, it confirms with you first.
You can disconnect any connector at any time from Settings.

Building Your Own Connector

If you have an internal tool or a service you want Claude to access, you can build a connector. Here is the path:

Step 1: Build an MCP Server

Your MCP server is a standard HTTPS service that implements the MCP protocol. It exposes a set of tools — each tool has a name, description, and input schema.

A minimal Node.js example:

import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
import { z } from "zod";

const server = new McpServer({
  name: "my-tool-server",
  version: "1.0.0"
});

server.tool(
  "get_user_data",
  { userId: z.string() },
  async ({ userId }) => {
    const data = await fetchFromYourDB(userId);
    return {
      content: [{ type: "text", text: JSON.stringify(data) }]
    };
  }
);

const transport = new StdioServerTransport();
await server.connect(transport);

For a remote server, you swap StdioServerTransport for an HTTP/SSE transport and deploy it like any other API.

Step 2: Connect it in Claude Desktop

In your claude_desktop_config.json:

{
  "mcpServers": {
    "my-tool-server": {
      "command": "node",
      "args": ["/path/to/your/server.js"]
    }
  }
}

For a remote server:

{
  "mcpServers": {
    "my-remote-server": {
      "url": "https://your-mcp-server.com/sse"
    }
  }
}

Restart Claude Desktop and your tools are immediately available.

Step 3 (Optional): Add UI with MCP Apps

If you want to render interactive UI inside the conversation, your MCP server can return HTML-based components that Claude will render inline. See the MCP Apps design guidelines for what you can render and how.

Step 4 (Optional): Submit to the Directory

If your connector would be useful to other Claude users, you can submit it to the Connectors Directory. Anthropic reviews submissions and, if approved, your connector becomes available to all users across Claude products.

Submit at: claude.com/docs/connectors/building/submission

Using Connectors in the Anthropic API (for Artifact Builders)

If you are building Claude-powered apps via the API, you can pass MCP servers directly in your API call. Claude will use them during the conversation to take actions on behalf of the user.

const response = await fetch("https://api.anthropic.com/v1/messages", {
  method: "POST",
  headers: { "Content-Type": "application/json" },
  body: JSON.stringify({
    model: "claude-sonnet-4-20250514",
    max_tokens: 1000,
    messages: [
      { role: "user", content: "Create a task in Asana for reviewing the Q3 report" }
    ],
    mcp_servers: [
      {
        type: "url",
        url: "https://mcp.asana.com/sse",
        name: "asana-mcp"
      }
    ]
  })
});

Claude will discover the tools exposed by that MCP server and use them automatically to complete the task.

You can combine multiple MCP servers in a single call:

mcp_servers: [
  { type: "url", url: "https://mcp.asana.com/sse", name: "asana-mcp" },
  { type: "url", url: "https://gmailmcp.googleapis.com/mcp/v1", name: "gmail-mcp" }
]

You can also add web search alongside MCP:

tools: [
  { type: "web_search_20250305", name: "web_search" }
],
mcp_servers: [
  { type: "url", url: "https://mcp.asana.com/sse", name: "asana-mcp" }
]

Handling MCP Responses in Your Code

When Claude uses an MCP tool, the response content array contains multiple block types. Do not assume ordering — filter by type:

const data = await response.json();

// Get tool results (the actual data returned from your MCP server)
const toolResults = data.content
  .filter(item => item.type === "mcp_tool_result")
  .map(item => item.content?.[0]?.text || "")
  .join("\n");

// Get Claude's natural language response
const claudeText = data.content
  .filter(item => item.type === "text")
  .map(item => item.text)
  .join("\n");

// See what tools were called and with what inputs
const toolCalls = data.content
  .filter(item => item.type === "mcp_tool_use")
  .map(item => ({ name: item.name, input: item.input }));

Quick Reference

What you want	How to do it
Use a prebuilt connector	Go to claude.ai Settings, connect the service
Browse available connectors	claude.ai/directory/connectors
Connect a remote MCP server	Add URL to claude_desktop_config.json or Settings
Build your own MCP server	Use the MCP SDK, implement tools, expose via HTTPS
Submit to the directory	claude.com/docs/connectors/building/submission
Use MCP in the API	Pass `mcp_servers` array in your API request
Add UI to your connector	Implement MCP Apps using the design guidelines

Resources

MCP Apps: https://claude.com/docs/connectors/building/mcp-apps/getting-started
Anthropic Blog Post: https://claude.com/blog/connectors-for-everyday-life

The Connectors Directory launched in July 2025 and already has over 200 integrations. The new consumer connectors (Uber, Spotify, Instacart, TripAdvisor, Resy, Audible, AllTrails, and others) were added in April 2026 and are available on all plans, with mobile in beta.

If you build something useful, submit it. The protocol is open and the directory is growing.

iOS 26 SDK Is Now Mandatory — Here Is What Actually Changes for Your App

ArshTechPro — Mon, 27 Apr 2026 10:08:23 +0000

Starting April 28, 2026, Apple will reject any app or update submitted to App Store Connect unless it is built with the iOS 26 SDK. If you have not migrated yet, this article walks you through exactly what changed, what breaks, and what you need to do before you submit your next build.

What the Requirement Actually Means

Apple has updated its minimum SDK policy. From tomorrow onward, every app and game uploaded to App Store Connect must meet these requirements:

iOS and iPadOS apps must be built with the iOS 26 and iPadOS 26 SDK or later
tvOS apps must use the tvOS 26 SDK or later
visionOS apps must use the visionOS 26 SDK or later
watchOS apps must use the watchOS 26 SDK or later (64-bit support is also now required)

In practice, this means you must build using Xcode 26 or later. The current latest SDK is version 26.2, so that is what you should be targeting.

One thing to clarify upfront: this requirement applies to the SDK you build with, not the iOS version your users must run. You can still set your deployment target to iOS 16 or 17. Your existing users on older iOS versions are not affected.

What Changes When You Build With the iOS 26 SDK

1. Liquid Glass UI Is Applied by Default

This is the change that will visually affect most apps immediately.

Liquid Glass is Apple's new design language — it applies translucent, fluid materials to native UI components. When you build with the iOS 26 SDK, standard UIKit and SwiftUI components like navigation bars, tab bars, buttons, and sheets will automatically pick up this new look on devices running iOS 26.

You do not need to write a single line of code for this to happen. It applies automatically.

What this means for you:

Run your app on an iOS 26 device or simulator after rebuilding
Check every screen for layout regressions or contrast issues
Pay close attention to custom UI elements — they will not automatically adopt Liquid Glass and may look inconsistent next to system components

If you want to opt out of the Liquid Glass appearance for specific components, you can do so explicitly. But be aware that Apple's design direction is clearly moving toward this system, and opting out across your entire app may increasingly feel out of place over time.

Basic example of applying Liquid Glass manually in SwiftUI:

import SwiftUI

struct CardView: View {
    var body: some View {
        VStack(alignment: .leading, spacing: 12) {
            Text("Account Summary")
                .font(.headline)
            Text("Balance: $4,200.00")
                .font(.body)
                .foregroundStyle(.secondary)
        }
        .padding()
        .background(.regularMaterial) // This picks up the Liquid Glass material
        .clipShape(RoundedRectangle(cornerRadius: 16))
    }
}

Use .regularMaterial, .thickMaterial, or .ultraThinMaterial to match the system's visual depth.

2. Foundation Models Framework Is Now Available

iOS 26 introduces the Foundation Models framework, which lets you run on-device language models without sending any data to a server. This is separate from Core ML — it is designed for natural language tasks like summarization, classification, tagging, and contextual responses.

You do not have to use it immediately, but building with the iOS 26 SDK means you now have access to it.

A simple example — summarizing user notes on-device:

import FoundationModels

func summarize(note: String) async throws -> String {
    let model = LanguageModel.default
    let prompt = "Summarize this note in one sentence: \(note)"
    let response = try await model.generate(prompt: prompt)
    return response.text
}

On-device processing means no network call, no latency spike, and no privacy concern about user data leaving the device.

3. Deprecated APIs Will Block Compilation

This is the most common reason apps fail to build with a new SDK. Frameworks that Apple has been warning about for years — like UIWebView, legacy Core Data stacks, and older networking patterns — may now cause build failures.

What to do:

Open your project in Xcode 26 and do a clean build. Read every warning and error carefully. The compiler will tell you exactly where deprecated usage lives.

Run this in Terminal to quickly scan for common deprecated patterns:

grep -rn "UIWebView\|NSURLConnection\|ABAddressBook" ./YourProject/

Replace any matches with their modern equivalents:

UIWebView -> WKWebView
NSURLConnection -> URLSession
ABAddressBook -> Contacts framework

4. Third-Party SDKs May Not Be Ready

Your own code might be fine, but analytics libraries, ad networks, crash reporters, and feature flag SDKs may not have updated yet.

Check your dependencies before submitting:

# If you use CocoaPods
pod outdated

# If you use Swift Package Manager, check in Xcode:
# File > Packages > Update to Latest Package Versions

If a third-party SDK is not compatible with the iOS 26 SDK, you have three options:

Wait for the vendor to release an update
Remove the SDK temporarily to unblock your submission
Contact the vendor directly — most are aware and have updates in progress

5. Age Rating Questionnaire Update

Apple updated its age rating questions in App Store Connect. If you have not already done this, update the questionnaire for all your apps immediately. Stale ratings can cause submission issues independently of the SDK requirement.

Step-by-Step Migration Checklist

Work through these in order. Do not skip the simulator testing step.

Step 1 — Install Xcode 26

Download Xcode 26 from the Mac App Store or the Apple Developer portal. Ensure your Mac is running macOS Tahoe 26.2 or later, as Xcode 26 requires it.

Step 2 — Update your project settings

Open your project in Xcode 26. Set the build SDK to iOS 26. Do not change your deployment target unless you specifically want to drop support for older iOS versions.

Step 3 — Do a clean build

Product > Clean Build Folder (Shift + Command + K)
Product > Build (Command + B)

Read every warning. Treat deprecation warnings as tasks, not noise.

Step 4 — Run on an iOS 26 simulator

Go through every screen in your app. Look for:

Layout issues in navigation bars or tab bars due to Liquid Glass materials
Text readability problems against translucent backgrounds
Custom UI components that look visually disconnected from system components

Step 5 — Run on a physical iOS 26 device

Simulators do not fully replicate Metal rendering or ProMotion behavior. Test on a real device, especially if your app has custom animations or graphics-heavy screens.

Step 6 — Update or remove incompatible third-party SDKs

Run pod outdated or check Swift Package Manager for updates. Flag anything that does not have an iOS 26-compatible release.

Step 7 — Archive and validate before submitting

Use Xcode's Organizer to archive your build and run Validate App before uploading. This catches many issues before Apple's review team does.

Product > Archive
Window > Organizer > Distribute App > Validate App

Step 8 — Submit via TestFlight first

Upload to TestFlight before submitting for App Store review. This gives you a buffer to catch any runtime issues that do not show up in local testing.

The Bigger Picture

This is Apple's standard annual SDK bump, but iOS 26 is a larger change than most years. Liquid Glass is a system-wide visual overhaul. Foundation Models is a new category of capability. The unified versioning across all Apple platforms (iOS, macOS, watchOS, tvOS, and visionOS all sharing the "26" designation) signals Apple pushing harder on cross-platform consistency.

Developers who migrate now and begin adopting these APIs incrementally will be in a much stronger position when WWDC 2026 announcements add another layer of requirements to keep up with.

The deadline is tomorrow. The steps above are everything you need. Build with Xcode 26, test on iOS 26, fix what breaks, and submit.

iOS - On-Device AI vs. Cloud AI: Why Privacy Can Win Over Convenience

ArshTechPro — Thu, 09 Apr 2026 17:41:35 +0000

Most photo cleaner apps upload photos to the cloud for processing. Every selfie, every screenshot, every private moment — sent to a remote server before the app can identify which ones to delete.

The easy path: cloud AI

Cloud processing is the default for a reason. It's cheaper to develop, easier to scale, and provides access to the most powerful models available. For developers, it's the path of least resistance.

But it comes with a trade-off users pay for: their data leaves their device.

For a photo management app, that means intimate, personal content — family photos, medical documents, private conversations captured in screenshots — all passing through infrastructure that isn't fully under the user's control.

The harder path: on-device AI

CleanKit takes a different approach, running all of its intelligence directly on-device. Duplicate detection, blur analysis, screenshot grouping, smart categorization — none of it requires a network connection, and none of it ever leaves the phone.

On-device processing means working within real hardware constraints: memory limits, thermal throttling, battery impact. Every algorithm needs to be optimized not just for accuracy, but for efficiency on mobile silicon.

Apple's Core ML framework and the Neural Engine make this possible — but making it fast and reliable across thousands of different photo libraries requires significant engineering effort.

Why it matters

Privacy isn't a feature. It's a design decision that affects every layer of a product.

When data never leaves the device:

There's no server breach that can expose photos
There's no privacy policy users need to trust
There's no internet requirement — it works on a plane, in airplane mode, anywhere
There's no per-scan cost that forces aggressive monetization

Users shouldn't have to choose between a clean photo library and their privacy. They can have both.

The result

CleanKit scans thousands of photos in minutes, identifies duplicates, blurry shots, old screenshots, and large videos — all without a single byte leaving the phone. It reclaims gigabytes of storage while keeping data exactly where it belongs: with the user.

For anyone building products that handle personal data, it's worth asking: does this need to leave the device? More often than not, the answer is no — and users will notice the difference.

What trade-offs have others encountered between on-device and cloud processing? The comments are open for discussion.

Clean Kit – Storage Cleaner is available on the App Store. Free to try — photos stay on-device, always.

DEV Community: ArshTechPro

Years of Apple's Best Security Work, Cracked in Five Days — Here's What Developers Should Know

What Exactly Is Memory Integrity Enforcement?

The Exploit: A Data-Only Kernel LPE

The AI Angle Is the Part That Should Keep You Up at Night

What Developers Can Actually Learn From This

1. Memory safety in your language matters more than ever

2. Mitigations buy time — they don't buy safety

3. "Data-only" attacks are underappreciated in web and app security too

4. AI-assisted vulnerability discovery is already here

5. Responsible disclosure still works — and matters

The Bigger Picture

Xcode 26.5 — What Developers Actually Need to Know

The App Store Deadline You Cannot Miss

StoreKit: The Headlining Addition

What is new

Availability note

Known issue to flag

Debugger Fixes Worth Knowing

Editor and Source Control Fixes

Interface Builder

Instruments

Summary

React Doctor: Is This the Missing Health Check for Your React Codebase?

What Is React Doctor?

How It Works Under the Hood

Getting Verbose Output

Real-World Scores on Popular Projects

Plugging It Into CI With GitHub Actions

Config File

Using It Programmatically

Teaching Your AI Coding Agent React Best Practices

Is It Worth Adding to Your Project?

Getting Started in 60 Seconds

RTK: Cut Your AI Coding Bill by 80% With One CLI Tool

The Problem It Solves

How It Actually Works

Installation

What Commands Are Supported

The Auto-Rewrite Hook

Token Savings in Practice

Is It Worth It?

Quick Summary

Local Deep Research: Run Your Own AI Research Assistant, Fully Private

What Is It?

Who This Is For

How It Works

Getting Started

Option 1: Docker (Recommended for most people)

Option 2: pip (For developers / Python integration)

Using the Python API

Using the HTTP API

Enterprise / RAG Integration

Search Sources Available

Supported LLMs

Security Model

Is It Worth Trying?

Quick Reference

Further Reading

DeepSeek-TUI: Run a DeepSeek Coding Agent Directly in Your Terminal

What is DeepSeek-TUI

Three Modes of Operation

Installation

Prerequisites

Step 1 — Install via npm

Step 2 — Get a DeepSeek API Key

Step 3 — Set Your API Key

Step 4 — Launch

Verify Your Setup

Alternative Installation Methods

Basic Usage

Configuration

Profiles

Key Environment Variables

Supported Providers

MCP Server Integration

Feature Flags

Current Models

Practical Tips

Links

3. `comptime`: Compile-Time Execution

7. `defer` for Guaranteed Cleanup