# Swift Radio Pro: an iOS radio station app template built in Swift

> Swift Radio Pro is an MIT-licensed Xcode project for shipping a branded live radio app on iOS, with CarPlay, lock screen controls and iTunes album art. It is a starting point for developers, not a finished product, and the README leaves several production questions open.

**analogcode/Swift-Radio-Pro** — Professional Radio Station App for iOS!

- Repository: https://github.com/analogcode/Swift-Radio-Pro
- Stars: 2,942 · Forks: 710
- Language: Swift
- License: MIT
- Published: 2026-09-24 · Updated: 2026-09-24 · Language: en
- Canonical page: https://hysenlabs.com/projects/analogcode-swift-radio-pro

## What Swift Radio Pro actually ships

Swift Radio Pro is an Xcode project, not a downloadable app. The README describes it as an "Open-source radio station app built entirely in Swift" and says it is used by 80+ apps on the App Store. The repository contains SwiftRadio.xcodeproj, a SwiftRadio source folder, a SwiftRadioUITests target, a LICENSE file and a preview image. There is no server component, no backend and no admin interface. The product is the client.

The intended user is an iOS developer or a small studio that has a stream URL and wants a store-ready shell around it. The README points to a paid single-station version on Payhip for people who want to skip the station list and launch straight into the player, which tells you the free repository is aimed at multi-station builds. If you are a radio station operator with no Swift developer on hand, this repository will not get you to the App Store on its own. If you are a developer who has shipped an iOS app before, the setup is short.

## How streaming, metadata and album art fit together

The README states the app is "Built on FRadioPlayer for streaming, metadata parsing, and iTunes album art fetching." That single sentence carries most of the architecture. FRadioPlayer owns the audio session and the stream, parses ICY metadata from the stream, and queries the iTunes API for cover art when the stream does not supply it. Swift Radio Pro supplies the screens, the station list and the configuration around it.

Three other packages sit alongside it, all managed with Swift Package Manager: LNPopupController for the now playing popup bar, NVActivityIndicatorView for loading indicators, and MarqueeLabel for scrolling text. Each maps to a visible piece of the UI. That is the whole dependency graph, and it is small enough to audit in an afternoon.

Station data comes from a local or remote JSON file. The README gives the shape of each entry, with name, streamURL, imageURL, desc, longDesc and website. Images can be a local asset name or a full URL, which the README distinguishes by the presence of http. The app also supports pull to refresh and an optional search bar, so a remote stations file can be updated without shipping a new binary. That is the main operational lever: change the JSON, and every installed copy picks up the new station list on the next refresh.

## Installing it and playing your first station

The README gives four steps: open SwiftRadio.xcodeproj in Xcode, edit SwiftRadio/Config/Config.swift, update the stations in SwiftRadio/Data/stations.json or host the file remotely, then build and run. There is no package manager install step for the app itself; the dependencies resolve through Swift Package Manager when Xcode opens the project.

The station file is the first thing to edit. The README shows this entry format:

```json
{
  "name": "Station Name",
  "streamURL": "https://stream.example.com/live",
  "imageURL": "station-image",
  "desc": "Short tagline",
  "longDesc": "Longer description for the detail screen",
  "website": "https://example.com"
}
```

Replace the values with your own. If imageURL has no http prefix, the app treats it as a local asset name, so the image has to exist in the asset catalog under that exact name. A full URL is fetched at runtime instead.

App-wide settings live in SwiftRadio/Config/Config.swift, which the README describes as holding your stations URL, contact email, website and other app-wide settings. Point the stations URL at a hosted copy of the same JSON if you want to update stations without a release. Then build and run from Xcode. You should see the station list, and tapping an entry should start playback with the now playing bar appearing at the bottom.

User-facing text is handled separately. The README says all strings are managed through Localizable.xcstrings, the Xcode String Catalog, and that you can change the default English text or add languages there without touching code.

## Where the project stops short

The README is a getting-started guide, not operational documentation. It does not document rollback, error handling for a dead stream URL, or what happens when the remote stations file is unreachable. It also does not describe how the app behaves when a station supplies neither stream metadata nor an iTunes match. If your station plays unsigned or local artists, the album art path through the iTunes API will often return nothing, and the README does not say what the UI falls back to. You would need to read the source to find out.

The dependency on FRadioPlayer is the other boundary. Streaming, metadata parsing and album art all live in that package, so a bug in ICY metadata handling or in the iTunes lookup is not something you fix inside this repository. You inherit that project's release cadence and its issue tracker.

CarPlay is the sharpest constraint. The README lists Apple CarPlay support as a feature, and the repository includes a separate carplay.yml workflow alongside ios.yml, which suggests CarPlay is built as a distinct target or configuration. CarPlay audio entitlements are granted by Apple per app, not by a library, so the repository can give you the code but not the permission. Treat CarPlay as a feature you must qualify for separately before you promise it to anyone.

## How it compares with a general audio player library

The obvious alternative is to build on AVPlayer directly, or on a general-purpose Swift audio library, and write the station list, metadata parsing and album art lookup yourself. The difference is where the work sits. A general player gives you transport control and leaves the radio-specific parts to you: ICY metadata parsing, the iTunes fallback for cover art, the station list model, the now playing popup, the CarPlay scene.

Swift Radio Pro takes the opposite position. It assumes the domain is radio, ships the station JSON schema, wires FRadioPlayer for stream metadata and iTunes art, and hands you a project to rebrand. You trade flexibility for a working starting point. If your app is a podcast player, a music library browser or anything that is not a list of live streams, the station model and the metadata assumptions will fight you, and a general player library is the better base.

The README also points to Swift Radio Android, described as the same station format in native Kotlin and Jetpack Compose. That is a real consideration if you need both platforms: the station JSON is the shared contract, but the two codebases are separate and neither is a cross-platform framework.

## Licence, maintenance and upgrade cost

Swift Radio Pro is released under the MIT License, and the LICENSE file sits at the repository root. MIT is permissive: you can ship modified versions in a closed-source App Store app. The repository does not include a NOTICE file or any additional terms in the README, but the bundled dependencies carry their own licences, and the README does not list them. Check FRadioPlayer, LNPopupController, NVActivityIndicatorView and MarqueeLabel individually before you ship, since their terms are not stated here.

Maintenance activity is visible in the release history. v3.1.0 was tagged on 2026-07-04, v3.0.0 on 2026-02-08, and the prior release, 2.0.8, on 2020-04-11. The last push to the repository was on 2026-09-23. The gap between 2020 and 2026 is worth noting: this is a project that went quiet for years and then returned with two major versions. The README directs contributions to the dev branch and explicitly asks contributors not to commit directly to master, so master should be treated as the release line.

Upgrade cost is dominated by Xcode and iOS SDK churn rather than by this project's own releases. A project that has been through a six-year gap will likely need attention on deprecated APIs and current signing requirements when you open it. Budget for that before you plan a release date.

## Conclusion

Swift Radio Pro suits an iOS developer who already has a stream URL and wants an App Store-ready shell with CarPlay, lock screen controls and album art, and who is comfortable editing Swift and a JSON station file. It is the wrong choice if you need a cross-platform build, a server-side metadata pipeline, or a project you can adopt without reading Xcode settings. Before committing, verify three things in the repository: what the Xcode project sets for its bundle identifier and signing team, how a station with no imageURL renders in the list, and whether the CarPlay workflow file matches the entitlements your Apple account can actually provision.

## FAQ

### What is pro radio?

In this repository, Swift Radio Pro is an open-source iOS radio station app built in Swift, released under the MIT License. The README describes it as an Xcode project you configure with your own stations rather than a finished app.

### Where do I change the stations in Swift Radio Pro?

Edit SwiftRadio/Data/stations.json, or host that file remotely and point the stations URL in SwiftRadio/Config/Config.swift at it. The README shows the field format for each station entry.

### Does Swift Radio Pro support CarPlay?

The README lists Apple CarPlay support as a feature, and the repository includes a separate CarPlay build workflow. The README does not describe the entitlement process, which Apple grants per app.

### How do I translate the interface in Swift Radio Pro?

All user-facing strings are managed through Localizable.xcstrings, the Xcode String Catalog. The README states you can change the default English text or add new languages there without any code changes.

## Sources

- [analogcode/Swift-Radio-Pro on GitHub](https://github.com/analogcode/Swift-Radio-Pro)
- [Issues](https://github.com/analogcode/Swift-Radio-Pro/issues)
- [License: MIT](https://github.com/analogcode/Swift-Radio-Pro/blob/master/LICENSE)
- [README](https://github.com/analogcode/Swift-Radio-Pro/blob/master/README.md)
- [Releases](https://github.com/analogcode/Swift-Radio-Pro/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/analogcode-swift-radio-pro