Tower (塔台): a native SwiftUI app that turns subscriptions and self-hosted nodes into client configs

The problem Tower addresses: subscription sprawl and one-off config edits

Anyone who pays for more than one proxy subscription ends up maintaining the same information in several places. The nodes arrive as a subscription URL, the rules live in a client-specific config file, and the policy groups have to be rewritten every time a client changes its syntax. Tower's README frames the workflow as three steps: add subscriptions, choose rules, export. That ordering is the whole product argument. The app keeps subscriptions and self-hosted nodes in one place, tracks traffic information and expiry reminders, and then produces a configuration in the dialect of whichever client you use. The target user is someone who already has nodes and a preferred client, not someone shopping for either. The README lists Surge Mac, Clash Verge, ClashMac, FlClash and Mihomo Party on the desktop side, and Shadowrocket, Surge, Stash, Loon, Quantumult X, Egern, sing-box, Hiddify, V2Box, Clash, Anywhere, Clash Mi and Karing on mobile. That is a broad export surface, and it is the main reason to look at the project at all.

On-device parsing, offline rulesets and client-specific export

The architecture described in the README is deliberately local. Subscription parsing, rule matching and config generation all happen on the device and do not pass through a third-party conversion service. The repository layout matches that description: there are Config/, Rulesets/ and Scripts/ directories at the top level, alongside the Tower/ source tree, TowerTests/ and TowerUITests/. Rulesets/ is where the bundled ACL4SSR material lives, which explains the README's claim that rules are available offline and that you can import your own rules and customize policy groups. Region identification is also offline, with manual region tagging available when the automatic guess is wrong. A map view and latency testing round out the node side. iCloud sync exists but is off by default, and the README is explicit that you opt in. The important boundary is stated twice in the README: Tower provides no nodes and establishes no proxy connections. Export is the end of the pipeline. Anywhere is handled slightly differently, with node-only subscriptions and local one-click import, and rules configured inside Anywhere itself.

Installing Tower on macOS via Homebrew and a first export

The README gives two distribution paths. On iOS the app is on the App Store under id6797458927, and on macOS there is a universal DMG attached to the v1.0.20 release, Tower-1.0.20-58-macOS-universal.dmg. Homebrew is the other route, and the README shows the cask command directly:

brew install --cask pengchujin/tap/tower

That taps pengchujin/tap and installs the tower cask, so a later brew upgrade picks up new versions through the same tap.

Once the app is open, the documented flow starts with adding a subscription URL. Tower fetches and parses it locally, then shows the parsed nodes on the map and in a list, with region labels that you can correct by hand. The next step is rules: the built-in ACL4SSR set is available offline, and the README says imported rules and custom policy groups are supported. The final step is export. You pick a client, filter by protocol if needed, and then use whichever of the three delivery methods that client supports: one-click import, copying the subscription, or exporting a file. The README points to docs/CLIENT-COMPATIBILITY.md for the per-client detail, and that file is the one to read before assuming a given client will accept the output. The README does not document a rollback path for an export that a client rejects, so keep the previous working config until the new one is confirmed.

What Tower does not do, and where it is the wrong tool

The most consequential limitation is stated plainly in the README: Tower is not a proxy. It supplies no nodes and opens no connections. If you want to browse through a proxy, you still need Surge, Clash, Shadowrocket or another client running the exported configuration. That makes Tower a companion app, not a replacement, and anyone who installs it expecting a working tunnel will be disappointed. The second constraint is platform. This is a native SwiftUI project, and the README's install options are an App Store listing and a macOS DMG or Homebrew cask. There is no documented Linux or Windows build, no headless mode and no server component, so it does not fit a workflow that generates configs on a build machine. Third, the export is only as good as the client compatibility matrix. The README distinguishes clients that support one-click import from those where you copy a subscription and from those where you export a file, and it notes that Anywhere takes node-only subscriptions with rules set inside Anywhere. Expect per-client friction rather than a uniform result. Finally, the licence facts are mixed: the README says the source is MIT, the repository metadata reports NOASSERTION, and THIRD-PARTY-NOTICES.md covers the bundled third-party resources under their own licences. Treat the README statement as the project's position and read the LICENSE file before you depend on it.

How Tower differs from Sub-Store and from editing a client config by hand

The obvious comparison is Sub-Store, which also converts subscriptions into client configurations. The difference is where the work happens. Sub-Store is a script-oriented tool that typically runs as a hosted or self-hosted service, with conversion logic written as scripts you can inspect and extend, and its output is usually consumed through a subscription URL that the client refreshes. Tower inverts that: it is a native app with a graphical workflow, the parsing and generation run on the iPhone or Mac itself, and delivery is one-click import, a copied subscription or an exported file rather than a service endpoint. That trade-off cuts both ways. Tower gives you a visible interface, offline rulesets and no third-party conversion service in the path, which is the property the README leads with. In exchange you get less scriptability, no headless pipeline, and a workflow tied to Apple platforms. The other alternative is simply editing the client config by hand. That is viable for one client and a handful of nodes, and it stays fully under your control. It stops being viable once you maintain several clients, several subscriptions and expiry reminders, which is exactly the point at which Tower's central inventory starts to pay for itself.

Maintenance cadence, upgrade cost and licence implications

The repository is not archived, and the last push was on 2026-09-16, which is recent. The release list is dense: v1.0.18 on 2026-09-13, v1.0.19 on 2026-09-15 and v1.0.20 on 2026-09-16, with build numbers 56, 57 and 58. That cadence has a practical consequence. The Mac DMG is versioned per release, so a pinned download goes stale quickly, and Homebrew is the lower-effort upgrade path because brew upgrade follows the tap. On iOS the App Store handles updates. The real upgrade cost is not the binary, it is the exported configuration. Each client parses rules and policy groups in its own way, so a Tower update that changes generation logic can produce a file your client rejects, and the README does not document a rollback or a config diff. Keep the last known-good export. On licensing, the README states the source uses the MIT licence, while the repository metadata reports NOASSERTION, and THIRD-PARTY-NOTICES.md lists bundled third-party resources under their own licences. That distinction matters if you redistribute the app or its bundled rulesets, and it is worth reading both files rather than assuming MIT covers everything in the tree. This is a description of what the files say, not legal advice.

Editorial conclusion

Adopt Tower if you already own subscriptions or self-hosted nodes and want one place to edit rules and emit configs for several clients, especially if you prefer that parsing happen on your own device. Do not adopt it expecting a proxy: the README states Tower provides no nodes and makes no connections, so a client such as Surge or Clash still has to run the exported file. Before relying on it, verify that your client appears in docs/CLIENT-COMPATIBILITY.md and that the one-click import path works for your setup, then check the LICENSE and THIRD-PARTY-NOTICES.md files for the terms that actually apply to your use.

Frequently asked questions

Official sources

1. Issues
2. pengchujin/tower on GitHub
3. README
4. Releases