Bottom line: choose by platform first, then check config compatibility
On Apple Silicon Macs, prioritize clients with arm64 builds and clearly documented core versions. On iPhone and iPad, check subscription format and Network Extension support first. If you want to keep Clash-style proxy groups and rules, start by evaluating mihomo-based desktop clients such as Clash Verge Rev and FlClash on Mac, and Stash on iOS. Shadowrocket and Surge are also popular proxy tools for Apple devices, but that doesn’t mean they can run an entire Clash YAML file unchanged.
“Clash for Apple” is a search term for a use case, not the name of one official app for both Mac and iPhone. A graphical client, proxy core, and subscription config are three separate layers: the client manages settings and configs, the core handles protocols and rules, and the subscription provides nodes and may include proxy groups. Keep these layers distinct when troubleshooting to identify whether the failure occurred during import, parsing, or connection.
- For browsers and everyday desktop apps: First check whether the macOS system proxy is enough. There’s no need to enable TUN just to get more features.
- For terminals, games, and apps that ignore system proxy settings: Check TUN, UDP, DNS, and routing controls—not just whether there’s a toggle in the interface.
- For shared rules on Mac and iPhone: Start with the config features supported by both platforms, then decide whether to maintain separate override files.
Compare popular clients: cores, configs, and controls
This comparison covers each project’s focus and limitations; it isn’t a permanent verdict based on one download’s version. Check the release notes or app listing for the specific build you plan to install to confirm minimum OS requirements, bundled core version, and regional availability.
| Client | Platform and core | Config and traffic handling | Best suited for |
|---|---|---|---|
| Clash Verge Rev | Desktop platforms including macOS; uses mihomo | Clash-style YAML; system proxy and TUN | Managing subscriptions, checking rules, and inspecting connections |
| FlClash | Cross-platform graphical client based on mihomo | Clash-style configs; verify traffic-handling features for the specific desktop build | Using a similar interface across devices |
| ClashX Meta | macOS menu bar client; Meta-based | Clash-style configs; check enhanced traffic handling in each release | Preferring menu bar controls and willing to check maintenance status |
| Stash | iOS and iPadOS proxy app; independent implementation | Supports Clash-style YAML and routes traffic through the system Network Extension | Keeping Clash-style proxy groups and rule structures |
| Shadowrocket | iOS and iPadOS proxy app; not a mihomo client | Supports multiple node subscription formats, with its own config and rule system | Importing nodes and managing mobile rules separately |
| Surge | macOS and iOS networking tool; independent implementation | Uses its own config format, with proxy group and network diagnostics features | Detailed diagnostics and willingness to migrate config syntax |
Check the App Store or product pages for how Stash, Shadowrocket, and Surge are sold, where they’re available, and what each license covers. Don’t assume a macOS license also covers iOS. Clash Verge Rev and FlClash are open source, so their implementation and issue history can be reviewed—but open source alone doesn’t replace testing compatibility with the current release.
Apple Silicon arm64: check the installer and core versions separately
Two ways to check your Mac’s architecture
Open the Apple menu → About This Mac. If it shows an Apple M-series chip, choose a build marked arm64, aarch64, or Apple Silicon. If it shows an Intel processor, choose x86_64 or x64. A Universal build may include both architectures, but you should still check the release notes for compatible macOS versions.
You can also open Terminal from Applications → Utilities and run this command. Terminal running natively on Apple Silicon will usually report arm64. If Terminal is running through Rosetta, the result may reflect the translation environment, so use About This Mac to confirm your hardware.
uname -m
After installation, open Activity Monitor and check the client process’s “Kind” to help confirm that it’s running natively on Apple Silicon. The graphical interface and core are usually separate processes, so check both when troubleshooting. Don’t assume the core has the right architecture just because the interface launches.
Record both GUI and core versions—not just the app name
The original Clash, the legacy Premium branch, and Clash Meta/mihomo aren’t a single set of features that stays in sync. Clash Meta continued development under the mihomo name. Legacy builds of the original Clash and Premium shouldn’t be treated as the default choice for newer protocol support. An old core may not recognize new config fields, even if the client still launches.
- Record the GUI’s full version number and build identifier from the About or version information screen.
- Record the core name and full version number from the core manager, runtime logs, or core information screen. The menu labels vary between clients.
- Check the documentation for that core version to confirm support for
rule-providers,proxy-providers, DNS, and the protocols you need. Don’t infer support from the app icon.
This guide doesn’t list an unverified “latest version.” GUI and core updates may not arrive together. Before updating, keep a working installer and a copy of your config; that’s more useful than comparing version numbers alone.
TUN vs. system proxy: choose how to route app traffic
Start with the macOS system proxy for a minimal test
The system proxy gives apps that follow system settings an HTTP, HTTPS, or SOCKS proxy endpoint; it doesn’t route every process through the same connection. On macOS 13 and later, check the current settings under System Settings → Network → your active network service → Details → Proxies. The connection type and macOS version can affect the menu labels.
If the client is configured with mixed-port: 7890, use this command to test the local HTTP proxy. 7890 is an example port, not a universal default; replace it with the listening port shown in the app.
curl --proxy http://127.0.0.1:7890 --connect-timeout 10 --head https://example.com
This test only shows that the request could attempt to use the specified proxy. It doesn’t prove that every app is routed through it or that traffic exits where expected. If the command works but your browser doesn’t, check the browser’s own proxy settings, extensions, and DNS behavior before reinstalling the client.
TUN can capture more traffic, but it doesn’t mean every connection goes through a remote proxy
TUN uses a virtual network interface and routes to pass matching traffic to the core, making it useful for apps that ignore system proxy settings. The core still routes each intercepted connection according to the rules: through a proxy, directly, or not at all. LAN access, excluded routes, and system restrictions also affect coverage. UDP support depends on the node protocol, server, and network path.
- How it’s implemented: A macOS client may use a privileged helper or a Network Extension. Don’t assume every TUN toggle requires approval for the same system extension.
- DNS behavior: Check the client’s DNS settings and TUN DNS interception options. Encrypted DNS in the browser, other VPNs, and security software can also change how DNS requests are routed.
- Network conflicts: Quit other tools that modify routes or DNS before testing TUN. Verify split-tunneling behavior separately if you use a work VPN.
On iOS, proxy apps typically create a VPN configuration through Network Extension. The system prompt to add a VPN configuration the first time you connect is part of this routing method; it’s different from entering a proxy port manually on Mac. For typical personal use, avoid running two apps that compete for the same VPN connection. Managed devices may have additional restrictions.
Subscription and rule compatibility: check configs for Mac and iPhone in order
A subscription link may return a complete YAML file or just an encoded list of proxy nodes. A full config may include proxies, proxy-groups, and rules; a node list usually won’t include a complete routing policy. Both may be labeled “subscription” in the app, so the link’s file extension alone won’t tell you what you’ll import.
Check the config structure first, then client-specific features
- Check proxy groups: Make sure every group referenced in the config exists, especially the targets used in
rules. Importing nodes successfully won’t help if the proxy groups are missing. - Check remote resources: Confirm support for
rule-providersandproxy-providers, and make sure their URLs are reachable. The rule-set format and behavior type must also match. - Check platform-specific fields: Don’t copy Mac-specific
tunsettings, listening ports, controller endpoints, or local file paths directly into an iOS config. - Check where local edits are saved: Updating a remote subscription may overwrite direct edits. Prefer the client’s override, merge, or separate local config features.
The snippet below illustrates how the fields relate; it isn’t a complete, working config. DIRECT is a built-in direct-connection policy. Even with TUN enabled, this final rule sends matching traffic directly rather than through a remote proxy.
mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
rules:
- MATCH,DIRECT
When moving to Shadowrocket or Surge, review and rewrite rules and proxy groups for the target app’s format. Converting nodes isn’t the same as migrating a complete config. Stash’s support for Clash-style structures doesn’t guarantee compatibility with every mihomo extension field; check the docs for the version you’re using.
Interface and update cadence: compare clients using the same tasks
You don’t have to judge an interface by looks alone. Run the same test config through these tasks to see whether the workflow suits you: import a subscription, select a proxy group, check which rule matched a connection, track down a DNS error, and restore a previous config. Menu bar apps work well for frequent status changes, while a full window is better for checking connections and logs side by side.
| Test | What to record | What it tells you |
|---|---|---|
| Update a subscription | Whether proxy group selections and local overrides are retained | Whether you have to redo settings after every update |
| Switch between Wi-Fi and a phone hotspot | Whether connections recover and whether DNS errors appear in the logs | Whether the client recovers when the network changes |
| Close the Mac lid, then wake it | Whether the system proxy or TUN comes back | How it handles everyday sleep and wake |
| Restart the client | Whether proxy status, rule mode, and ports remain consistent | Whether settings persist |
| Roll back after an upgrade | Whether the previous config can still be read | Whether you can recover if config migration fails |
Look at the notes for the last few releases to assess update cadence: Do they explain core changes, fix known OS compatibility issues, provide builds for the right architecture, and call out breaking config changes? Frequent releases don’t mean every version is worth installing immediately. Test an update before replacing a stable setup, especially on a device you rely on.
Node latency tests aren’t a reliable way to rank clients. The test URL, connection reuse, DNS cache, and selected protocol can all vary for the same node. For a meaningful comparison, use the same network, node, test target, and traffic-handling mode, and record latency, connection success, and download performance separately. This guide doesn’t include untested performance figures.
Choose by use case: three practical setups
Apple Silicon Mac, mostly for browsing
Start with a mihomo-based graphical client that offers an arm64 build, import your subscription, and enable the system proxy. Once you’ve confirmed the rule mode, proxy groups, and exit route are correct, decide whether you need TUN. Clash Verge Rev and FlClash are both worth trying. Choose based on how clear the logs are, how easy subscription overrides are, and whether the current build supports your macOS version.
Use the same proxy group structure on Mac and iPhone
Build on YAML fields supported by both devices. Use a suitable mihomo client on Mac and check Stash’s compatibility on iPhone. Keep nodes and shared rules in the remote config; set ports, TUN, and device paths locally on each platform. Start with a few rules, then add remote rule sets gradually to make differences easier to pinpoint.
For network diagnostics or managing phone nodes only
If you need a more complete diagnostics workflow, consider Surge, factoring config migration and licensing costs into your decision. If you mainly use node subscriptions on iPhone and are happy to maintain rules separately, consider Shadowrocket. Whichever app you choose, test subscription import, rule matching, network switching, and recovery after disconnecting before committing to it long term.
Choose in this order: OS and architecture compatibility → config parses correctly → traffic is routed as intended → updates and rollbacks are manageable. Similar app names don’t guarantee similar behavior. Keep a tested config and clear version records to make ongoing maintenance predictable across Mac, iPhone, and iPad.