Derived Data

How to Use OpenCode in Xcode 27

Tue, 09 Jun 2026 13:00:00 GMT

One of the most exciting announcements out of WWDC this year is support for third-party coding agents, or harnesses, in Xcode 27. Over the past couple of years, I've used a lot of GUIs and TUIs for coding agents, but the Xcode Intelligence team has knocked it out of the park with the UI and animations, so much so that I feel, for the first time, incentivized to use it.

Xcode 27 achieves this through first-class support for ACP-compatible coding harnesses[^1], which makes it possible to use any agent even if not officially supported by Apple. This guide uses OpenCode as an example, but the same steps apply to any ACP-compatible harness.

First, we need the path to the executable. For OpenCode installed via Homebrew, that's /opt/homebrew/bin/opencode. You can find it using the which command:

which opencode

In Xcode Settings, go to the Intelligence tab and click Add an Agent… in the Agents section.

Fill in the Name (anything goes) and Executable fields. Leave Interpreter blank unless the executable is a script.

Some agents require additional arguments to enter ACP mode. For OpenCode, add acp to the Arguments list. See Finding the Right Arguments below if you're unsure what to put here.

Click Add. The first time Xcode launches the agent during that session, it will ask for permission. Click Allow.

That's it. The agent is now ready to use in Xcode. In the Intelligence sidebar, click New Conversation and select your freshly added harness from the dropdown.

Finding the Right Arguments

Not all ACP-compatible harnesses need arguments, and many listen for ACP by default. Others, like OpenCode, require a subcommand to switch into protocol mode.

The ACP registry lists all compliant agents. Each entry's agent.json tells you exactly how to launch it. Here's OpenCode's:

{
  "id": "opencode",
  "name": "OpenCode",
  "distribution": {
    "binary": {
      "darwin-aarch64": {
        "cmd": "./opencode",
        "args": ["acp"]
      }
    }
  }
}

Find your agent's folder in the registry and open agent.json. If there's an args field under your platform, add those values to the Arguments list in Xcode, one per line. If there's no args field, leave it empty. Some agents are more finicky to set up than others, but the most popular ones are straightforward.

P.S. I still haven't figured out a way to change models, but I will update this guide if I do.

[^1]: A harness is a program that wraps an LLM and exposes it as a controllable coding assistant. It handles things like context, file access, shell execution, and tool calling. The combination of a harness and an LLM is what is we often call an autonomous agent.

Using Xcode 27 Skills with Any Harness

Tue, 09 Jun 2026 12:00:00 GMT

Beside new MCP tools, the Xcode 27 beta comes with a half dozen agent skills covering topics such as SwiftUI, security, and testing. These are all available to agents used from within Xcode, but even if you use an external agent like I do, you're in for a treat as these can be exported as skill folders and used by any AI coding harness such as Claude Code, OpenCode, or anything else that supports the skills format.

How to

Before exporting these skills you need to point xcode-select at Xcode 27:

sudo xcode-select -s <beta-location>/Contents/Developer # Example: /Applications/Xcode-27.0.0-Beta.app/Contents/Developer

Then run from wherever you want the output to land:

xcrun agent skills export

This creates an xcode-skills/ folder containing all the skill folders, but if you want to save these in a different folder, either global or repo-specific, use the following command:

xcrun agent skills export --output-dir ~/.claude/skills

Once exported, feel free to revert xcode-select to the stable version, as skills stay put regardless of which Xcode version is active afterward.

The Skills

swiftui-whats-new-27: Xcode 27 SwiftUI changes such as the @State macro migration, reorderable containers, and the new document model.
swiftui-specialist: Provides broader SwiftUI guidance, including soft-deprecated patterns.
uikit-app-modernization: Replaces UIScreen.main, interfaceOrientation, and other legacy shared-state APIs with multi-window-aware alternatives, in both Swift and Objective-C.
c-bounds-safety: Adopting C bounds-safety attributes and removing unsafe pointer usage.
test-modernizer: Migrating test suites to current testing APIs.
audit-xcode-security-settings: Checks project security settings against current best practices.
device-interaction: Device-specific interaction patterns.

What's New in Xcode 27 MCP Bridge

Tue, 09 Jun 2026 00:00:00 GMT

WWDC 2026 kicked off yesterday with the usual keynote, State of the Union, and beta software for those who like to live life dangerously. Xcode 27 beta is also out, and it includes a significant expansion of the mcpbridge toolset. I have been using the bridge for a while in my agentic coding workflow, and this beta goes from 21 tools to 48, adding deep device interaction, live debugging, crash analytics, localization, and more. This will solve a lot of the problems I've been patching around in my workflow, inlcuding interacting with the simulator and debugging.

Here's every new tool and what it does.

Running & Debugging

RunProject: The biggest new addition, builds and runs the current scheme, the equivalent of pressing Cmd+R. Returns once the app has launched. Pair it with InvokeDebuggerCommand and GetConsoleOutput to drive a full debug session.
StopProject: Stops the running app, the equivalent of Cmd+. Returns immediately if nothing is running.
InvokeDebuggerCommand: Sends any lldb command to Xcode's active debug session and returns the output. The process must already be running with the debugger attached. Supports the full lldb surface: bt, po, breakpoint set, thread step-over, frame variable, etc. The agent and Xcode UI share the same lldb session, so state is consistent on both sides.
GetConsoleOutput: Retrieves stdout, stderr, and OSLog output from a running or completed app session. Supports regex filtering, severity filtering, and context extraction.
RunCodeSnippet (replaces ExecuteSnippet): Builds and runs a code snippet in the context of a specific source file and waits for results. Returns the output of any print statements in the snippet. Works for app, framework, library, and command-line targets.

Device Interaction

DeviceInteractionStartSession: Prepares a simulator or physical device for interaction and boots it if needed. Designed to be called early so the device is ready in parallel with other work. Keeping a session open is expensive, so always close it when done.
DeviceInteractionEndSession: Closes an open device session. Must be called when interaction is finished.
DeviceInteractionInstallAndRun: Builds, installs, and launches the app on the currently targeted device. Should be called every time the project changes, the target device changes, or the previous debug session has disconnected.
DeviceInteractionSynthesize: Synthesizes device events: taps, swipes, text input, hardware button presses, orientation changes, etc. then captures the resulting state as a screenshot and UI hierarchy. Always base coordinates on the latest hierarchy dump, not a screenshot.

Crash Reporting & Field Performance

GetTopCrashIssues: Pulls the top crash signatures for an app from Apple's crash reporting service, sorted by number of affected devices over the last 14 days. Supports filtering by platform, version, and release channel (App Store vs. TestFlight).
GetCrashIssueLogs: Drills into a specific crash signature to retrieve raw crash logs plus expert triage analysis and actionable recommendations. Use after GetTopCrashIssues.
GetTopFieldPerformanceIssues: Surfaces the top performance regressions from Apple's field report APIs. Covers four diagnostic types: launches, hangs, diskwrites, and energy.
GetFieldPerformanceIssueLogs: Retrieves detailed diagnostics for a specific performance issue: stack traces, timeline data, and expert triage guidance. Use after GetTopFieldPerformanceIssues.

Build Settings & Compiler Flags

GetTargetBuildSettings: Returns all build settings for a given target. The canonical way to inspect build settings instead of parsing project.pbxproj directly.
UpdateTargetBuildSetting: Updates, appends, or deletes a named build setting for a target. Same caveat: always use this tool instead of editing project.pbxproj directly.
GetFileCompilerFlags: Gets the per-file compiler flags for a single source file in a target: the value shown in the Compiler Flags column of Build Phases > Compile Sources.
UpdateFileCompilerFlags: Updates, appends, or deletes per-file compiler flags for a single source file.

Schemes & Run Destinations

XcodeListSchemes: Lists all schemes in the current workspace with their sharing status and container. Active scheme is listed first. Full list is written to a file for grep-friendly access.
XcodeSwitchScheme: Switches the active scheme by name or disambiguated name.
XcodeListRunDestinations: Lists available run destinations for the active scheme, grouped the same way the Xcode picker does (Devices, Simulators, Build, Incompatible). Identifies the active destination. Incompatible destinations are omitted by default.
XcodeSwitchRunDestination: Changes the active run destination for the current scheme. Pass the destination's displayTitle from XcodeListRunDestinations. Refuses destinations that aren't eligible for the active scheme.

Project Configuration

AddEntitlement: Adds a new entitlement to the project's entitlements file for a given target. Only for restricted system capabilities gated by code signing—push notifications, app groups, iCloud, hardware access, etc. Not for standard frameworks, privacy descriptions, or general feature flags. Use AddInfoPlist for privacy descriptions.
AddInfoPlist: Adds or updates an Info.plist key (privacy usage descriptions, URL schemes, background modes, orientation settings, app metadata, etc.) Not for entitlements.

Localization

StringCatalogRead: Returns string keys grouped by translation state for a requested locale. Requires the xcode-integration:translation-coordinator skill to be active before calling.
StringCatalogContext: Returns the source language value and context for a given string in the String Catalog. Requires the xcode-integration:translation skill.
StringCatalogEdit: Inserts a translation for a given locale into the String Catalog. Requires the xcode-integration:translation skill.
LocalizationPlanner: Ensures the project is ready for translations to be added. Call this each time you're adding a new language or translating an entire project. Requires the xcode-integration:translation-coordinator skill.

Whether the agent runs standalone or inside Xcode through ACP, the new tools close the loop that previously required reaching out to simctl and friends just to run and poke at the app to verify their work. DeviceInteractionSynthesize alone eliminates a whole class of workarounds. GetConsoleOutput is similarly welcome, since pulling logs directly instead of switching windows and copy-pasting saves more time than it sounds once you're doing it dozens of times a session.

A Feel-Good Refactor

Sun, 21 Feb 2021 00:00:00 GMT

If you are using Combine's Just, Fail, or Result.publisher as much as I do to mock publishers for SwiftUI's previews and tests, chances are you have grown tired of manually setting either the output or the failure types, then erasing to AnyPublisher in every occurrence.

Today I decided that it was time to honor the rule of three (or thirty eight?) and come up with something better. For one, we can heavily lean on Swift's type inference to improve the API at the call site. And while we're at it, we can make it easier to remember by using a similar syntax to handle both success and failure scenarios.

Since the goal here is to create a type-erased publisher that emits either a value or an error then completes, we can call the helper "once". As for the implementation, we have a couple of options: define a static function on Publisher, or create a custom Publisher type. Since the latter would still require type-erasure at the call site, I chose to go with the former.

Let's start with the far more common value-emitting path.

public extension Publisher {
  static func once<T, U: Error>(
   _ value: T,
    failAs error: U.Type // 1
  ) -> AnyPublisher<T, U> {
    Just(value)
      .setFailureType(to: U.self)
      .eraseToAnyPublisher()
  }
}

This does the job, but having to specify the error type (1) every time takes away some of the feel-goodness of this solution. Luckily, Swift's type inference comes to the rescue. Time for take 2!

static func once<T, U: Error>(
  _ value: T
) -> AnyPublisher<T, U> {
  Just(value)
    .setFailureType(to: U.self)
    .eraseToAnyPublisher()
}

The type of the return value should be enough to identify the publisher's failure type. For cases where there isn't enough type information at the call site, we can keep the first iteration around to avoid the need for explicit types when assigning values—but that's purely a matter of preference.

With the happy path case behind us, let's do the same for the failure-emitting case.

static func once<T, U: Error>( // 1
  failing error: U // 2
) -> AnyPublisher<T, U> {
  Fail(
    outputType: T.self,
    failure: error
  )
  .eraseToAnyPublisher()
}

I chose to keep the same method name (1) to streamline the API at the call site. Unfortunately this means an additional keyword is needed to help the compiler tell them apart. I went with failing (2) on the spur of the moment, but anything would do the job. If call site uniformity is a non-goal, then using just/fail to match the Combine publishers would be preferable.

As a parting bonus, we can throw in an additional helper for publishers where the output value is Void; quite common for write operations and PUT/DELETE endpoints.

static func once<U: Error>() -> AnyPublisher<Void, U> {
  once((), failAs: U.self)
}

static func once<U: Error>(
  failing error: U
) -> AnyPublisher<Void, U> {
  once(Void.self, failing: error)
}

Armed with these new tools, mocking publishers is now as easy as calling once() and once(failing:) with the value or error respectively.

Here's an example from the codebase that prompted me to write this post:

let cache = Cache(
  upsert: { value in // -> AnyPublisher<Value, CachingError>
    Just(value)
      .setFailureType(to: CachingError.self)
      .eraseToAnyPublisher()
  },
  deleteOutdated: { // -> AnyPublisher<Int, CachingError>
    Just(2)
      .setFailureType(to: CachingError.self)
      .eraseToAnyPublisher()
  },
  deleteAll: { // -> AnyPublisher<Int, CachingError>
    Fail(
      outputType: Int.self,
      failure: CachingError.nothingToDelete
    )
  }
)

And here is the same section after the refactor:

let cache = Cache(
  upsert: { .once($0) }, // (Item) -> AnyPublisher<Value, Error>
  deleteOutdated: { .once(2) }, // () -> AnyPublisher<Int, Error>
  deleteAll: { .once(failing: .nothingToDelete) } // () -> AnyPublisher<Int, Error>
)

Now, tell me which scores higher in the feel-good department?

Debugging SwiftUI: Trials and Tribulations

Fri, 30 Oct 2020 00:00:00 GMT

I have been using SwiftUI since day one, on both client and side projects. It's an incredibly refreshing way of coding interfaces for Apple devices, but it's far from being wrinkle-free. The framework's bold ambitions are sometimes hampered by subpar debugging tools and arcane, seemingly random limitations.

I previously wrote about a SwiftUI bug that gave me quite a run for my money:

The stack trace isn’t of much help and no amount of view hierarchy tweaks got rid of it entirely. Initially I was under the impression that either my code or one of my external dependencies were doing something horribly wrong, but this post from Peter Steinberger made me realize that it is a rather widespread issue.

Since I didn’t manage to reproduce it on a particular test device at the time, I assumed it’s yet another simulator quirk. But a little over a month later, the same bug reared its ugly head on a test device. Fun times!

The app in question uses tab navigation where the first tab is always accessible, while the second tab shows different content depending on whether the user is signed in to their account or not. The view code looked roughly like this:

TabView {
  Home()
    .tabItem { /* ... */ }
    .tag { /* ... */ }

  if isSignedIn {
    Profile()
      .tabItem { /* ... */ }
      .tag { /* ... */ }
  } else {
    SignIn()
      .tabItem { /* ... */ }
      .tag { /* ... */ }
  }
}

To avoid the isSignedIn boolean check in multiple modifiers, I opted for an if-else block with separate views and tabItem modifiers.[^1] Except that didn’t seem to sit right with SwiftUI for some reason. The app launches and displays the content of the first tab exactly as intended. But when I switch tabs—or god forbid, sign in or out—the app crashes with this cryptic error message:

[error] precondition failure: invalid size for indirect attribute: <number> vs <number>

The call stack points exclusively to SwiftUI internals, with the last call referring to a certain AG::Graph—responsible for holding the view tree and diffing it. As far as debugging goes, this is very, very little to work with.

With my hands tied, I briefly considered resurrecting the UITabBarController wrapper I used prior to WWDC, especially since I didn’t manage to make a reproducible test case or submit a feedback to Apple. At first, I spent an inordinate amount of time tweaking the view hierarchies of the profile and sign-in screens themselves, with varying—and rather inconsistent—levels of success. I ran out of both time and patience, so I moved on to other things to not stall the project any further. Weeks later, I came back to the problematic screen—pitchfork in hand—ready to gut the entire tab navigation and replace it with a custom-made solution. I had had enough.

But then came the proverbial aha moment: what if the conditional check took place inside the second tab, instead of around it?

TabView {
  Home()
    .tabItem { /* ... */ }
    .tag { /* ... */ }

  ProfileOrSignIn(isSignedIn: $isSignedIn)
    .tabItem { /* ... */ }
    .tag { /* ... */ }
}

And just like that, the crasher was gone. Squashed into oblivion.

If this sounds dumb, it’s because it is. At no point did the compiler chastise me for doing something I wasn't supposed to do. And to make matters worse, the documentation doesn't mention anything related to... wait, what documentation?

It’s a bittersweet feeling when you fix a bug in a non-deterministic, haphazard way. On one hand you are elated you’ve managed to fix it at all. On the other, you feel somewhat powerless and insecure about your ability to handle similar situations in the future. I adore SwiftUI, but moments like these give me a good dose of anticipatory anxiety—the kind that erodes trust and dampens the thrill of being at the bleeding edge.

[^1]: As an aside, apps that greet users with a sign up screen are generally trash. You don't ask prospective tenants to sign the contract at the door before they've even seen the apartment.

How I Use Document Tabs in Xcode 12

Thu, 03 Sep 2020 00:00:00 GMT

The new document tabs in Xcode 12 caught me off-guard more than once at first, but as soon as I figured out how they work, I started to enjoy using them.

For instance, in server-side projects I am typically dealing with half a dozen files related to the same area or feature; the model itself, the repository, migrations, tests, mocks, etc. Before, I used separate window tabs for each "topic", but now I rely heavily on document tabs to fill that need. My current setup is something roughly like this:

I usually keep 3 window tabs in every project: development, testing, and debugging. I occasionally create break-out window tabs for self-contained tasks like refactoring, reading the source code of a dependency, etc.
In the development window tab, I use vertical area splits for the different topics I am actively working on. Usually these correspond to a model file and its satellite types. I start with one then add or remove splits as needed.
Inside each area, I use the new document tabs to keep all the related files open, enabling quick tab switching using the keyboard shortcut <kbd>cmd</kbd> + <kbd>shift</kbd> + <kbd>[</kbd> or <kbd>]</kbd>.
I use horizontal splits when I need to look at different files in the same topic. An example would be the model and its migration file in server-side, or a view and its state object in SwiftUI.

I reason better about code when I can see several related files at the same time, and document tabs give me an even more effective way to achieve that.

Mattt on WWDC 2020

Sun, 28 Jun 2020 00:00:00 GMT

It's refreshing to see Mattt's reasoned take amidst all the attention-seeking headlines this week:

As it turns out, going fully remote wasn’t merely good enough — it was, in many ways, superior to the original thing. [...] Sessions are tight and well-paced. Rather than stretching or cramming content into a fixed time slot, they’re as long as they need to be.

This definitely echoes my impressions. As someone who mostly followed along from home in the past, not only did I not miss much this year, but I got treated to a much improved remote experience.

Mattt also brings up the topic of Excitement—or hype, as I often call it—and productivity:

Here’s the thing about excitement: It’s kryptonite to developers. Excitement messes with our ability to focus on one thing, which is already a big struggle for a lot of us (myself included). When you’re excited, it’s almost impossible to get anything done.

This is true for any endeavor, but especially so for software development.

There are plenty of voices in the community who are echoing this excitement. I can’t add anything to that discussion. And besides, that’s not really where my head’s at right now.

The official Apple content generates enough sense of <abbr title="Fear of Missing Out">FOMO</abbr> as it is. Combining that with a firehose of What's new in X blog posts, podcasts, YouTube videos, and tweets doesn't help much as far as I am concerned.

It’s been an exciting week, so take a moment to collect yourself. Go on a walk. Take a hike. (Be safe about it.) Do whatever you need to break free of the “reality distortion field”. Once you do, you’ll have the necessary distance to determine what new technologies you should pay attention to and what you can ignore for now.

Solid advice, WWDC or otherwise.

Early Lessons in Adopting SwiftUI

Fri, 02 Aug 2019 00:00:00 GMT

We've been using SwiftUI day in and day out since the first beta to build a non-trivial app at work---a bold move, but one that makes me like my job. Here are some lessons I've learned:

Stick to standard navigation. As unstable as the APIs are for the time being, this will spare you the layout and accessibility headaches that come with custom transitions.
Always investigate whether your UI can be implemented as a list view. It handles dynamic type, dark mode, and other accessibility features out of the box, and will likely look more polished as a result.
Make good use of section headers and footers in List. Unlike UITableView, these are much easier to set up in SwiftUI's declarative syntax. They can be used for empty states, search fields, sorting controls, etc.
Embrace the current limitations of the framework. If you have to fight it at every turn to get the result you want, consider taking a different route where you don't have to do that. You can revisit the same challenge later as the framework matures.
Don’t use hard coded colors, i.e. the RGB initializer. Use system tint colors or asset catalogs instead, and stay clear of white and black as they don't adapt to appearance modes.
Pay attention to the methods used to pass data down to and up from subviews. It’s easy to use the wrong method and the error won’t be very helpful. Spend some time to understand the difference between @State, @Binding, @ObservedObject, and @EnvironmentObject.
Speaking of compiler errors, split your view hierarchy using variables, methods, and separate view structs to make the wide of the mark error messages slightly more relevant and helpful.
Extract reoccurring view modifier chains into custom modifiers to DRY up the code. It's a bit more work that I anticipated, but it's worth it.
UIKit appearance helpers still work in SwiftUI. Call them from within the init() method of the view when needed. For instance, this is the only method to remove the opaque background from a List as of now.
SwiftUI is still very rough around the edges, so keep your cool and stay hydrated.🥤

Swift's Killer Feature

Tue, 18 Jun 2019 00:00:00 GMT

Since its release 5 years ago, Swift has matured a great deal as a programming language, both in terms of stability and expressive power. Its concise syntax and type safety have been largely celebrated within the Apple developer community, and increasingly noticed outside of it. But, as it is the case with similar transitions, not everything is hunky-dory.

In addition to the source breaking changes that soured the language earlier on, Swift is often criticized for lacking an indisputable selling point compared to what was there before it (Cocoa and Objective-C), and what came after it (JavaScript cross-platform frameworks).

Unfair as it may sound, programming languages are often evaluated based on their ecosystem, not on their intrinsic merits. In the eyes of many, Swift is indissociable from Apple and their platform UI frameworks, for better or for worse. The mismatch between Cocoa APIs and Swift language features has been brought up again and again in discussions about its appeal as a replacement for Objective-C.

Expressiveness and type safety can certainly keep a handful of enthusiastic developers engaged, but it won’t be enough to sustain Swift’s momentum on the long run. As much as some of us hate to admit, the competition is colossal on the server and scripting side of things, and it’s getting uncomfortably stronger on the native platform front.

On top of that, the write-preview-debug development cycle that we’ve been dealt since the dawn of Cocoa is considered sluggish and tedious by today’s standards. A liability that’s long overdue for reconsideration. To make matters worse, Apple's UI frameworks haven’t converged fast enough to alleviate some of these issues---we are still required to implement half a dozen methods for each platform to display a plain table view.

This state of affairs has pushed many to adventure outside first-party fences in search of more exotic alternatives, while the holdouts stuck to their ~~guns~~ bows and arrows in the absence of a clear-cut perk of leaving their tried-and-true programming language behind[^1].

But all of this is bound to change.

During this past WWDC, Apple introduced SwiftUI---a modern, universal framework for building user interfaces across their platforms. And it’s packing quite a punch. SwiftUI is declarative, reactive, and ready to take us places; the killer feature that Swift deserved all along. Not only is it tightly integrated with the language, but it’s also pushing it forward by providing a use case for new additions such as function builders and property wrappers.

Even though we have barely scratched the surface of SwiftUI since its announcement, it’s already winning the hearts of large swaths of developers, myself included. I don't have a shred of doubt that this is the future of UI programming on Apple platforms, and I am thrilled to witness, and be part of, this transition.

[^1]: Part of me appreciates the prudent approach with regard to adopting new technology that’s yet to prove itself. Another part of me fails to see the point of swimming against the current in a predominantly closed platform where a single company gets to call the shots.

Units in Foundation

Sun, 04 Dec 2016 00:00:00 GMT

Starting iOS 10 and macOS 10.12, Foundation supports units and measurements out of the box, in the form of (NS)Unit and (NS)Measurement respectively. Let's take a look at how they work.

Note: All code snippets below are written in Swift 3.0.

To get started, let's define a measurement. To do that, you have to pass a value and a unit to the initializer:

import Foundation

let snorlaxWeight = Measurement(value: 460, unit: UnitMass.kilograms)
// -> 460.0 kg

You can then effortlessly convert the measurement to another unit:

let snorlaxWightInImperial = snorlaxWeight.converted(to: .pounds)
// -> 1014.12723328454 lb

You can also define your own unit by extending one of the default dimensions available:

extension UnitMass {
  static let snorlax = UnitMass(symbol: "snorlax", converter: UnitConverterLinear(coefficient: 460))
}

The converter is used to transform the measurement from any given unit to the base unit of the dimension; Kilograms in the case of UnitMass. You can inspect the base unit of any dimension by calling baseUnit() on it.

UnitMass.baseUnit()
// -> kg

Once defined, your custom unit can be used alongside the pre-defined ones:

let statueOfLibertyMass = Measurement(value: 225_000, unit: UnitMass.kilograms)
let statueOfLibertyMassInSnorlax = statueOfLibertyMass.converted(to: .snorlax)
// -> 489.130434782609 snorlax

You can also define a custom dimension of units by subclassing Dimension if necessary. Here is an example that defines a new UnitDataRate class for measuring data transfer rates, often used in Internet speed tests:

class UnitDataRate: Dimension {
  static let kilobitPerSecond = UnitDataRate(symbol: "kbps", converter: UnitConverterLinear(coefficient: 1))
  static let megabitPerSecond = UnitDataRate(symbol: "Mbps", converter: UnitConverterLinear(coefficient: 1_000))
  static let gigabitPerSecond = UnitDataRate(symbol: "Gbps", converter: UnitConverterLinear(coefficient: 1_000_000))

  override class func baseUnit() -> UnitDataRate {
    return .megabitPerSecond
  }
}

let speed = Measurement(value: 100, unit: UnitDataRate.megabitPerSecond)
let speedInKpbs = speed.converted(to: .kilobitPerSecond)

// -> 100000 kbps

Learn More

WWDC session 238
Measurements and Units in Foundation by Ole Begemann.
iOS 10: Measurements & Units Screencast by Sam Davies.