Circling back on the LocalLM Lab arc. With v0.7, we've moved from prompt experimentation into real app development on Apple's Foundation Models local AI. The LocalLM Lab SDK lets you build that same on-device model and MCP client this thread has covered directly into your own app, with real tool and data access (Slack, Todoist, GitHub, Notion, Linear, plus Calendar, Reminders, Contacts and Location). And you can ship your app including through the Mac App Store. This is a big improvement over version 0.6, where the localai-cli toolkit needed LocalLM Lab installed and running. On the other hand, the SDK (LocalLMLabSDKCore) doesn't relay through anything; it links FoundationModels and a real MCP client directly into your own binary and is totally self-contained. The example included in the SDK, Plate Today, has actually been built into a sandboxed test app and verified working, with a signed path to a Mac App Store .pkg (Apple Distribution signing + provisioning profile pipeline). That's "verified signable and sandbox-compatible," to be precise. Entitlements (from personal experience: always a complicated topic): com.apple.security.app-sandbox + com.apple.security.network.client for the app itself, plus the standard personal-information entitlements per connector used (com.apple.security.personal-information.calendars, .addressbook, .location) and matching NS*UsageDescription strings in Info.plist. The one worth flagging specifically: the network entitlement is easy to miss and fails silently rather than throwing. Without it, MCP connections and Weather calls just hang with no error surfaced. OAuth handling requires the app delegate callback (application(_:open:)), not SwiftUI's .onOpenURL. Worth knowing before wiring it up if you're SwiftUI-only. Full entitlements list + SDK guide: https://github.com/ancientcomputing/locallm/blob/main/docs/sdk-guide.md Feature page: thisbrain.ai/locallm/sdk.html I hope the availability of the SDK (free, Apache 2.0 license) will give folks further incentive to explore local AI-enabled applications on the Mac. What else would you want to do that the SDK doesn't currently support? File picker? Calendar/Reminders/Contacts edits & writes?

While building with Apple's Foundation Models, I kept running into a workflow problem before the app code itself. The hard part was not only calling LanguageModelSession. It was figuring out the shape of the interaction: What should be in the system prompt? What should stay in the user input? What output is actually usable by the app? How much instruction is too much? How do I test the same prompt repeatedly without creating another small Xcode project? I ended up building a small macOS tool for myself, LocalLM Lab, mainly to speed up that loop. The first use case was a Prompt Playground: system prompt, user input, model output, and a repeatable way to compare results before moving the workflow into app code. The current version also experiments with connector-style context, such as system clock, weather, reminders/calendar, contacts, and a scoped filesystem folder. That has made the prompt design problem more interesting, because the question becomes: what context should the model see, and how should the app frame that context so the output is useful? I am curious how other developers are handling this while building with Foundation Models. Are you mostly iterating inside Xcode playgrounds? Are you building small internal test harnesses? Are you separating system prompts and user inputs during testing? How are you evaluating whether the output is reliable enough for the app workflow? For reference, this is the tool I have been using for my own experiments: https://thisbrain.ai/locallm I would be especially interested in any patterns people have found for designing and testing prompts before committing them to app code.