YoutubeKit wraps the IFrame player and the Data API in Swift

Two APIs, one Swift library

YoutubeKit is a Swift library for the YouTube IFrame Player and the YouTube Data API, and its stated purpose is making it easy to create a YouTube app. The two halves are separate. The player side is YTSwiftyPlayer, a video player built on a WKWebView that speaks the IFrame API, with typed player parameters through a VideoEmbedParameter type. The data side is a set of typed request objects covering the YouTube Data API v3, with the available list endpoints enumerated in the documentation: Activity, Caption, Channel, ChannelSections, Comment, CommentThreads, PlaylistItems, Playlists, Search, Subscriptions, VideoAbuseReportReasons, VideoCategories and Videos. The README is careful about attribution, pointing readers to the official IFrame Player API and Data API v3 documents when they are unsure whether something is a bug or normal behaviour, which is a sensible default for a wrapper library.

Adding the package and writing the first player

The library ships as a Swift package, with a Package.swift at the root, a YoutubeKit.podspec and a Carthage topic, and the CocoaPods badge is marked deprecated, so Swift Package Manager is the route the project is steering people toward. The README does not spell out the install steps beyond that, but it does list the Swift version the package targets as Swift 5. Once the package is added, the import is the only thing between you and a player:

import UIKit
import YoutubeKit

The getting started sample shows the intended shape of an integration, and the configuration is where the typing pays off. A YTSwiftyPlayer is created with a frame and a list of player variables, each of them a typed option rather than a string key:

final class VideoPlayerController: UIViewController {

    private var player: YTSwiftyPlayer!

    override func viewDidLoad() {
        super.viewDidLoad()

        // Create a new player
        player = YTSwiftyPlayer(
            frame: .zero,
            playerVars: [
                .playsInline(false),
                .videoID("_6u6UrtXUEI"),
                .loopVideo(true),
                .showRelatedVideo(false),
                .autoplay(true)
            ])

        view = player
        player.delegate = self

        // Load video player
        player.loadDefaultPlayer()
    }
}

// Use the default implementations of the optional delegate callbacks.
extension VideoPlayerController: YTSwiftyPlayerDelegate {}

The delegate extension at the end is the detail that decides whether adopting this library is a small change or a large one. Because YTSwiftyPlayerDelegate provides default implementations of the optional callbacks, a conformer that wants nothing can write an empty extension, and a conformer that wants a few events implements only those.

The delegate surface covers state, errors and autoplay

The delegate callbacks are the API's real contract, and there are eleven of them. They cover the player becoming ready, the current time updating, the player state changing, the playback rate changing, an error arriving, a raw error code arriving, autoplay being blocked, the video quality changing, the API changing, the IFrame API becoming ready, and the IFrame API failing to load. Quality changes get their own callback and report a YTSwiftyVideoQuality value, and the autoplay case is called out separately because it is a normal outcome rather than a failure: autoplayBlocked reports blocked autoplay and the guidance is to let the user start playback with a tap. Two of the callbacks, the raw error code and the blocked autoplay report, were added later and both have default implementations, so existing delegates need no changes to keep compiling.

Client identity is derived from your bundle identifier

The most consequential detail in the documentation concerns the referer the player sends to YouTube. loadDefaultPlayer and loadPlayerHTML without an explicit URL derive the base URL from the host app's bundle ID, forming https://<bundle-id> for the YouTube Referer. Custom hosts can supply loadDefaultPlayer(baseURLString:) or the existing baseURLString argument, and Const.basePlayerURLString plus explicit base URLs remain supported. Without a valid bundle ID the legacy URL is used, and the instruction is to supply an explicit app identity URL in that case. This is the piece to understand before shipping, because YouTube's terms list a required minimum functionality and the library links straight to that page. The error callback that reports raw codes includes code 153 for a missing client identity, and the typed didReceiveError callback still runs first for known codes.

Calling into the player while it is running

Once playback has started, the player exposes commands that map directly onto the IFrame API. Pausing is a single call, seeking accepts a whole or fractional second with an allowSeekAhead flag, muting is a call, and loading a different video takes a video identifier:

// Pause the video.
player.pauseVideo()

// Seek to a whole or fractional second.
player.seek(to: 15, allowSeekAhead: true)
player.seek(to: 15.5, allowSeekAhead: true)

// Set a mute.
player.mute()

// Load another video.
player.loadVideo(videoID: "M7lc1UVf-VE")

Two compatibility notes come with those calls. Int values and method references remain supported, so older call sites keep working, and NaN and infinity values are ignored rather than passed through to the web view. The bundled HTML template uses the device viewport width, and custom HTML templates are expected to forward the onAutoplayBlocked callback the same way the bundled template does. The library ships an Example project demonstrating video playback and Data API requests, with animated examples covering a feed, comments, a floating player and a rotating view.

Data API requests are typed objects with a shared key

The data side needs an API key, obtained from the Google developer console, and it is set once on the shared instance in the app delegate:

func application(_ application: UIApplication, didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?) -> Bool {

    // Set your API key here
    YoutubeKit.shared.setAPIKey("Your API key")

    return true
}

Requests are then built as typed objects rather than dictionaries. A chart ranking uses VideoListRequest with a part list of id and statistics and a filter of chart:

// Get youtube chart ranking
let request = VideoListRequest(part: [.id, .statistics], filter: .chart)

// Send a request.
YoutubeAPI.shared.send(request) { result in
    switch result {
    case .success(let response):
        print(response)
    case .failure(let error):
        print(error)
    }
}

For iOS-restricted API keys, requests automatically include the host app's bundle ID, and a separate document covers API key restrictions and custom headers. That automatic inclusion is what lets a restricted key work without hand-adding an identifier to every request.

Pagination and authorization follow the Data API shape

Listing endpoints are paged, and the library models that with a nextPageToken carried on the response and passed back into the next request. The pattern is to keep the token from the previous response and construct the following request with it:

// Set nextPageToken
let request = VideoListRequest(part: [.id], filter: .chart, nextPageToken: nextPageToken)

The response type exposes nextPageToken directly, and the request type takes it as a parameter alongside the same part and filter arguments, so paging is a loop over two types rather than a manual URL edit. Authorized requests work the same way, with an access token set before sending. The documentation recommends GoogleSignIn to obtain the token and shows the CocoaPods line for adding it, which is the one place where the library expects you to pull in a third party dependency yourself. Note that the request is sent through a completion handler with a result switch rather than a throwing async call, so the callback style is the one to design your error handling around.

Editorial conclusion

YoutubeKit fits an iOS team that needs to embed YouTube playback and read YouTube metadata in the same app, and that wants typed request objects and a delegate with default implementations rather than raw web view scripting. It does not fit a team that needs Android, tvOS or macOS targets, since the README describes it as an iOS library, and it does not remove the need for a Google API key and for thinking about YouTube's client identity rules. Verify first that your API key is set and that its restrictions match the bundle identifier your app ships with, that your video identifiers play under the referer scheme the player derives, and that the YouTube Data API list endpoints you need are among the ones the library covers.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. Releases
5. rinov/YoutubeKit on GitHub