scriptable.com

The to-do app from Build Your First SwiftUI App on macOS keeps its model inside the app target. That works for one app, but nothing else can use the code, and its unit tests can only run by building the whole app and booting an iPhone simulator. This article moves that model into a Swift package: a folder of Swift code described by a Package.swift file, which Swift Package Manager (SwiftPM, the build tool that ships with Swift) can build and test on its own. You will create a library package named TodoKit, move the TodoItem model and its five unit tests into it, and run those tests on your Mac with swift test in about a second, with no simulator. Then you will add the package to the Xcode project as a local dependency, so the app imports TodoKit instead of owning the model. The finished project runs the package tests and the UI test from one make test, and the app still shows the to-do you saved in the first article, read from the same database by code that now lives in the package. ...

Many first SwiftUI tutorials stop once the app appears in Xcode’s preview canvas. That leaves out the parts you need before an app is real: data that survives a relaunch, tests that prove it, and a way to build and run the whole thing without clicking through the IDE. This article builds a to-do list app for iPhone with SwiftUI, Apple’s declarative UI framework, and SwiftData, Apple’s framework for saving Swift objects to an on-device database. The result is an Xcode project that you build, test, and launch in the iOS Simulator with three make commands. Its test suite includes a UI test that adds a to-do, quits the app, relaunches it, and checks the to-do is still there. You will run that test, then open the app and see the saved item yourself. ...

Data rarely arrives in one format. Customer records come out of a spreadsheet as CSV, an analytics pipeline drops order history as Parquet, a compact binary format for tables, and the app logs events as JSON, one object per line. The usual Python answer is to load each file into pandas, fix up the types, and merge the frames by hand. DuckDB lets you skip the loading: you write SQL against the files themselves, and a single query can join a CSV to a Parquet file to a JSON log. ...

This tutorial ends with NVIDIA’s garak scanner attacking an open-weight model running on your own Mac, and with you able to answer a question most teams answer by guesswork: did this change to my prompt make the model easier or harder to hijack? You will scan Llama 3.2 3B (3 billion parameters), served locally by Ollama, with hundreds of prompt-injection attacks, read the individual attacks that worked, then write two defensive system prompts and measure each one against the same attacks. The first one makes the model more vulnerable. The second helps against one kind of injection and is indistinguishable from noise against the other. You will finish with a make gate target that fails a build when a prompt change pushes the attack success rate past a threshold you choose. Nothing leaves the machine: no API keys, no hosted model, no account. ...

This tutorial ends with an Apache Kafka broker running in Docker on your Mac, a topic named orders, and two Python programs that talk to it: a producer that publishes JSON order events and a consumer that reads them. You will then use those programs to show the property that makes Kafka different from a job queue. Reading a message does not remove it, so a consumer that restarts picks up where it stopped, and a second, independent consumer can replay the whole history from the beginning. You will see both happen, and measure how far behind a consumer is, with Kafka’s own tools. ...

Laya is an open-weights model from Convai Innovations that answers typed questions about a piece of text instead of writing prose. You hand it a state (a support thread, an email, a JSON record) and a set of questions, each of which declares the shape of its answer in advance: pick one option from a list, place the text on an ordered scale, or give the probability that a statement is true. Every answer comes back as a probability distribution over the options you declared. Laya is an encoder, a network that reads text and scores it rather than writing any. Each call is one forward pass (a single run of the network over the input), with no generated text to parse. ...

By the end of this article you will have trained a language model to do something it currently cannot do, on your own Mac, in about twenty seconds of compute. You will hand it a bug report in plain English and it will answer with exactly one line: severity=high component=auth summary=login fails after the token refresh runs The base model does not do this. Asked the same question it starts explaining token refresh and never reaches a parseable answer. You will measure that difference rather than eyeball it: twenty test reports held out of training so the model has never seen them, which the base model scores 0/20 on and your fine-tuned model scores 20/20 on, run by a script you write in Step 8. ...

vLLM is the inference server many production LLM deployments sit behind, and until recently it had no answer on a Mac beyond a source build of its CPU backend. The vllm-metal plugin changed that: it keeps vLLM’s engine, scheduler and OpenAI-compatible API, and swaps the compute layer for MLX, Apple’s array framework, running on the GPU through Metal. By the end of this article you will have that server running on your Mac, answering on the same OpenAI-compatible endpoint you would deploy on a CUDA box, sized so it leaves the machine usable. You will then measure the number that decides whether vLLM is the right server for your workload at all: how much aggregate throughput continuous batching buys you, and how much per-request latency it costs. Continuous batching is vLLM’s core trick, running many requests through the model together and admitting new ones as others finish. ...

A language model is a function from text to text. You send it a list of messages, it returns one message, and nothing else happens. It cannot read your disk, check the clock, remember your previous question, or run the tool it just asked for. Every capability an AI product appears to have belongs to the program wrapped around the model. That program is the harness: the code that builds each request, executes the tools the model asks for, and decides what the model is shown in the first place. ...

An MCP server that adds two numbers has no opinion about who is calling it. One that posts to a social account has to answer a question before it can do anything at all: whose account? There are two workable answers. You can build a multi-tenant server that authenticates every caller and looks up the account they own, which is the shape Add GitHub OAuth to a FastMCP Server builds. Or you can build one process that acts as exactly one account, reads that account out of its own environment, and runs on the same machine as the client calling it. ...