At the latest WWDC, Apple introduced a new framework called PaperKit, described in the documentation as:

PaperKit builds on top of PencilKit and PDFKit to provide a consistent way to add drawing and shapes in your app.

Having recently bought an iPad and being curious about how to make the most of the Apple Pencil, I immediately followed the session video to start testing what this new framework had to offer.

WWDC25: Meet PaperKit | Apple

However, I quickly noticed a problem: there was no demo project provided along with the presentation, and the code shown in the video was rather ambiguous. On top of that, Apple’s documentation was not particularly clear. Overall, the introduction of this new framework felt a bit rushed and under-documented.

So, I decided to spend some time building demo projects for both UIKit and SwiftUI, so developers can have a proper starting point for experimenting with PaperKit.

Issues in the Video

The main issue with the UIKit implementation shown in the session was making the tool picker appear correctly. Using Apple’s suggested code, the toolkit wouldn’t show up, making it impossible to use the Pencil effectively.

To work around this, I used an implementation based on PencilKit, while waiting for Apple to release more details on this part of the API:

let toolpicker = PKToolPicker()
toolpicker.colorMaximumLinearExposure = 4
toolpicker.setVisible(true, forFirstResponder: paperVC)
toolpicker.addObserver(paperVC)
paperVC.pencilKitResponderState.activeToolPicker = toolpicker
paperVC.pencilKitResponderState.toolPickerVisibility = .visible
paperVC.becomeFirstResponder()

By combining PaperKit with PencilKit, I was able to achieve the desired result.

You can check out the UIKit demo project on GitHub:

GitHub - Longo97/PaperKit-UIKit-Demo: A demo project that follows what was presented in Apple's video.

SwiftUI Implementation

As for the SwiftUI implementation, the video completely skipped over the details, leaving developers on their own to come up with a working demo.

Once I had a stable UIKit version, I ported the implementation to SwiftUI using a UIViewControllerRepresentable with a Coordinator, acting as a bridge between the two frameworks.

The code is not perfectly polished yet, but it works and lets you start experimenting with PaperKit.

You can find the SwiftUI demo project here:

GitHub - Longo97/PaperKit-Demo-SwftUI

Conclusions

Despite the rough start, PaperKit looks like a very promising framework. For now, we’ll just have to wait and see what updates Apple will release in the coming months.

In the previous article, I introduced SwiftNetworking, a lightweight and reusable networking package built with Swift and distributed via Swift Package Manager (SPM).

GitHub - Longo97/SwiftNetworking: A lightweight and testable asynchronous REST client built with Swift and `async/await`

We explored how to modularize networking code, structure a Swift package, and publish it for other projects.

But building a package is just the beginning.

To make it truly reliable and production-ready, we need to ensure:

• Functionality is covered by automated unit tests;
• Contributions go through a pull request review process;
• Every commit to main is validated automatically using GitHub Actions.

In this follow-up article, I’ll walk you through how I:

• Added unit tests to validate the core networking logic;
• Created a custom mock protocol for controlled network simulation;
• Set up CI workflows using GitHub Actions to automate testing.

Whether you’re building your first Swift package or maintaining an open-source library, these steps will help ensure quality and maintainability.

Unit Testing in Swift: A Quick Overview

Swift provides a built-in testing framework called XCTest, which supports unit, integration, and UI testing. When working with Swift Packages, testing becomes even simpler thanks to native support from the Swift Package Manager (SPM).

A basic test target looks like this:

Sources/
└── SwiftNetworking/
    └── NetworkProvider.swift

Tests/
└── SwiftNetworkingTests/
    ├── NetworkProviderTests.swift
    └── MockURLProtocol.swift

Your test classes subclass XCTestCase, and use assertions like XCTAssertEqual and XCTAssertThrowsError to validate outcomes. You can run tests via Xcode or by using swift test in the terminal.

Writing Unit Tests for SwiftNetworking

Once the package was ready, I added a set of unit tests to validate the most critical features. One such test verifies that a valid JSON response is correctly decoded into a Swift model:

/// ## testSuccessfulDecoding
/// Tests that the `NetworkProvider` correctly decodes a valid JSON response into a Decodable model.
///
/// The test ensures:
/// - The mocked JSON is returned and decoded properly.
/// - The decoded value matches the expected model.
  func testSuccessfulDecoding() async throws {
        let json = """
        {
          "message": "Hello world"
        }
        """.data(using: .utf8)!
        
        MockURLProtocol.stubResponseData = json
        
        let config = URLSessionConfiguration.ephemeral
        config.protocolClasses = [MockURLProtocol.self]
        let session = URLSession(configuration: config)
        
        let baseURL = URL(string: "https://api.example.com")!
        let network = NetworkProvider<DefaultNetworkError>(
            configuration: .init(baseURL: baseURL, session: session)
        )
        
        let endpoint = Endpoint(path: "/greeting", method: .get)
        
        struct Response: Decodable {
            let message: String
        }
        
        let result: Response = try await network.send(endpoint, as: Response.self)
        XCTAssertEqual(result.message, "Hello world")
    }

What This Test Verifies

• A fake JSON is returned by a mocked session;
• The network layer successfully decodes it into a Swift model;
• No real API call is made;
• The decoded value matches the expected content.

Using MockURLProtocol for Isolated Network Testing

To simulate different network conditions without hitting a real API, I created a custom subclass of URLProtocol called MockURLProtocol.

Here’s its core implementation:

final class MockURLProtocol: URLProtocol {
    static var stubResponseData: Data?
    static var error: Error?
    static var responseStatusCode: Int = 200

    override class func canInit(with request: URLRequest) -> Bool { true }
    override class func canonicalRequest(for request: URLRequest) -> URLRequest { request }

    override func startLoading() {
        if let error = Self.error {
            client?.urlProtocol(self, didFailWithError: error)
            return
        }

        if let data = Self.stubResponseData {
            client?.urlProtocol(self, didLoad: data)
        }

        let response = HTTPURLResponse(
            url: request.url!,
            statusCode: Self.responseStatusCode,
            httpVersion: nil,
            headerFields: nil
        )!
        client?.urlProtocol(self, didReceive: response, cacheStoragePolicy: .notAllowed)
        client?.urlProtocolDidFinishLoading(self)
    }

    override func stopLoading() {}
}

How to Use It

During test setup, inject the mock protocol into a custom URLSession:

let config = URLSessionConfiguration.ephemeral
config.protocolClasses = [MockURLProtocol.self]
let session = URLSession(configuration: config)

This technique allows you to simulate:

• Successful responses;
• Network errors (e.g., URLError.notConnectedToInternet);
• Server-side failures like 500 Internal Server Error.

All without touching the network.

Setting Up GitHub Actions for CI

To validate code on every commit or pull request, I configured GitHub Actions with a workflow like this:

name: CI

on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

jobs:
  test:
    runs-on: macos-13

    steps:
      - uses: actions/checkout@v3

      - name: Set up Xcode
        uses: maxim-lobanov/setup-xcode@v1
        with:
          xcode-version: '15.2'

      - name: Setup Swift
        uses: fwal/setup-swift@v1
        with:
          swift-version: '5.8'

      - name: Run tests
        run: xcodebuild test -scheme SwiftNetworking -destination 'platform=iOS Simulator,name=iPhone 14,OS=17.0' -enableCodeCoverage YES -parallel-testing-enabled YES

This workflow runs on macOS 13 with Xcode 15.2 and simulates an iOS 17 environment using an iPhone 14 simulator. It ensures all tests pass before merging any change into the main branch.

Protecting the main Branch

To enforce CI and code quality, I added branch protection rules on GitHub:

1. Go to Settings > Branches > Branch Protection Rules;
2. Select main;
3. Enable:

• ✅ Require a pull request before merging;
• ✅ Require status checks to pass (CI must succeed);
• ✅ Optionally, require code review.

Now, contributors must go through a proper review and testing pipeline — improving reliability and trust for all users.

Wrapping Up

In this article, I showed how to test the networking layer of your Swift package using XCTest and a custom MockURLProtocol. These tools allow you to simulate real-world network conditions in a fast and safe way — no actual API calls needed.

I also configured GitHub Actions to automatically run unit tests for every push and pull request on the main branch. This ensures the package stays stable and production-ready as it evolves.

Introduction

As an iOS Engineer, I’ve often worked with external frameworks and packages. After some time, driven by curiosity, I decided to explore this topic more deeply, especially in the context of Swift. My main motivation was to move beyond the theoretical knowledge I had about package creation and get hands-on experience building one myself.

To make the process more concrete, I chose to use one of my personal projects — a football widget app Versus — and extract one of its core components that could be generalized and benefit from a more solid and testable structure: the Network Manager.

The result is SwiftNetworking: a Swift Package designed to provide a minimal, type-safe, asynchronous networking layer that is compatible with older iOS/macOS versions. I’ve made it open source so that others can dive into the topic, use it, or contribute improvements.

GitHub - Longo97/SwiftNetworking: A lightweight and testable asynchronous REST client built with Swift and `async/await`

What Is a Package?

Before diving into how to build a Swift package, let’s clarify some key terms often encountered when dealing with code modularization:

• Module: All iOS and macOS projects are composed of modules — reusable, isolated units of code. Swift Packages and Frameworks are examples of modules;
• Library: A type of module that contains a set of related classes. Libraries can be static (linked at build time) or dynamic (linked at runtime);
• Framework: A type of module that typically bundles resources, compiled code, and dependencies. It’s commonly used in Apple platforms;
• Swift Package: Similar to a library, but with built-in dependency and versioning support, making it easier to manage via Swift Package Manager (SPM).

Creating a Package in Xcode

Thanks to Xcode, creating a package is quite simple. Just go to File > New > Package:

In the next window, you’ll choose whether to create a library, select the test framework, and define the name and location for the package.

Package Structure

This is the basic file structure you’ll see once the package is created:

The Package.swift file is the manifest of the project and contains metadata about the package. Here's what you’ll typically find:

• swift-tools-version: Defines the minimum version of Swift tools required;
• Products and Targets: A target is a module that can be imported. In the file system, it corresponds to a folder with source files;
• Platforms: Lists the minimum supported platform versions;
• Dependencies: Lists other packages this one depends on.

Package Content: The NetworkProvider

Without going into every file in the repository, let’s focus on the core of SwiftNetworking: the NetworkProvider.

This class provides a generic, asynchronous network layer built on top of URLSession. It supports custom error mapping via a NetworkErrorConvertible protocol and is compatible with macOS 10.15 / iOS 13 and later.

📌 You can find the full implementation in the GitHub repository.

Here is the class definition:

import Foundation

/// # NetworkProvider
/// A generic, asynchronous network client that sends requests using `URLSession` and decodes responses into strongly-typed models.
///
/// `NetworkProvider` supports:
/// - Custom decoding error mapping via a user-defined `NetworkErrorConvertible`
/// - Asynchronous networking with backward compatibility to macOS 10.15 / iOS 13
/// - Customizable configuration including base URL, session, and decoder
///
/// ## Generics
/// - `ErrorType`: A type conforming to `NetworkErrorConvertible`, used to map decoding and unknown errors into app-specific error cases.
///
/// ## Initialization
/// Create an instance by providing a `NetworkConfiguration`:
///
/// ```swift
/// let config = NetworkConfiguration(baseURL: URL(string: "https://api.example.com")!)
/// let provider = NetworkProvider<MyCustomError>(configuration: config)
/// ```
///
/// ## Conforms to
/// - `NetworkClientProtocol`
///
/// ## Usage
/// Use the `send(_:as:)` method to make a network request and decode the response:
///
/// ```swift
/// struct Response: Decodable {
///     let message: String
/// }
///
/// let endpoint = Endpoint(path: "/hello", method: .get)
/// let response: Response = try await provider.send(endpoint, as: Response.self)
/// print(response.message)
/// ```
///
/// ## Error Handling
/// - If the server returns an invalid status code, `HTTPResponseValidator` throws a validation error.
/// - If decoding fails, the error is mapped using `ErrorType.fromDecodingError(_:)`.
/// - Any unknown errors are mapped to `ErrorType.unknown`.
@available(iOS 13.0.0, *)
public final class NetworkProvider<ErrorType: NetworkErrorConvertible>: NetworkClientProtocol {
    private let configuration: NetworkConfiguration

    /// Initializes the `NetworkProvider` with a given network configuration.
    ///
    /// - Parameter configuration: The configuration that includes base URL, session, and decoder.
    public init(configuration: NetworkConfiguration) {
        self.configuration = configuration
    }

    /// Sends a request to the provided `Endpoint` and decodes the response into the expected type.
    ///
    /// - Parameters:
    ///   - endpoint: The `Endpoint` describing the path, method, headers, query, and body.
    ///   - type: The expected `Decodable` type for the response.
    /// - Returns: A decoded object of type `T`.
    /// - Throws:
    ///   - A `URLError` if networking fails.
    ///   - An error thrown by `HTTPResponseValidator` if status code is invalid.
    ///   - A mapped decoding error using `ErrorType.fromDecodingError`.
    ///   - `ErrorType.unknown` for unexpected decoding failures.
    @available(macOS 10.15, *)
    public func send<T>(_ endpoint: Endpoint, as type: T.Type) async throws -> T where T: Decodable {
        let request = try endpoint.asURLRequest(baseURL: configuration.baseURL)
        let (data, response): (Data, URLResponse)

        if #available(macOS 12.0, *) {
            (data, response) = try await configuration.session.data(for: request)
        } else {
            // Fallback for macOS < 12
            (data, response) = try await withCheckedThrowingContinuation { continuation in
                configuration.session.dataTask(with: request) { data, response, error in
                    if let error = error {
                        continuation.resume(throwing: error)
                    } else if let data = data, let response = response {
                        continuation.resume(returning: (data, response))
                    } else {
                        continuation.resume(throwing: URLError(.badServerResponse))
                    }
                }.resume()
            }
        }

        try HTTPResponseValidator.validate(response)

        LogUtilities.log("RESPONSE: \(String(data: data, encoding: .utf8) ?? "Unable to decode data to string")")

        do {
            return try configuration.decoder.decode(T.self, from: data)
        } catch let decodingError as DecodingError {
            throw ErrorType.fromDecodingError(decodingError)
        } catch {
            throw ErrorType.unknown
        }
    }
}

The goal of this package was to provide a networking layer that requires minimal setup to use. As it stands, the NetworkProvider only needs a configuration at initialization to be ready for use. Each call then takes an Endpointinstance to define the request.

Defining an Endpoint

The Endpoint struct encapsulates all the information needed to create a URLRequest: path, HTTP method, query parameters, headers, and body.

import Foundation

/// Represents a REST API endpoint, encapsulating the URL path, HTTP method,
/// query parameters, headers, and optional body data.
///
/// This struct simplifies the creation of `URLRequest` objects by
/// constructing the full URL and encoding the request body if provided.
///
/// # Properties
/// - `path`: The URL path component appended to the base URL.
/// - `method`: The HTTP method to use (e.g., GET, POST). Defaults to `.get`.
/// - `query`: Optional query parameters as an array of `URLQueryItem`.
/// - `headers`: Optional HTTP headers as a dictionary `[String: String]`.
/// - `body`: Optional request body conforming to `Encodable`.
///
/// # Usage Example
/// ```swift
/// let endpoint = Endpoint(
///     path: "/teams",
///     method: .post,
///     query: [URLQueryItem(name: "season", value: "2024")],
///     headers: ["Authorization": "Bearer TOKEN"],
///     body: Team(name: "Napoli", year: 1926)
/// )
/// ```
///
/// # Errors
/// Throws `DefaultNetworkError.cannotBuildURL` if the composed URL is invalid.
public struct Endpoint {
    /// The path component appended to the base URL.
    public let path: String
    
    /// The HTTP method used for the request.
    public let method: HTTPMethod
    
    /// Query parameters included in the URL.
    public let query: [URLQueryItem]?
    
    /// HTTP headers included in the request.
    public let headers: [String:String]?
    
    /// The body payload encoded as JSON, if provided.
    public let body: Encodable?
    
    /// Creates a new `Endpoint` instance.
    ///
    /// - Parameters:
    ///   - path: The URL path component (e.g., "/teams").
    ///   - method: The HTTP method to use (default is `.get`).
    ///   - query: Optional query parameters to append to the URL.
    ///   - headers: Optional HTTP headers to include in the request.
    ///   - body: Optional request body conforming to `Encodable`.
    public init(path: String,
                method: HTTPMethod = .get,
                query: [URLQueryItem]? = nil,
                headers: [String: String]? = nil,
                body: Encodable? = nil) {
        self.path = path
        self.method = method
        self.query = query
        self.headers = headers
        self.body = body
    }
    
    /// Constructs a `URLRequest` from the endpoint and a base URL.
    ///
    /// - Parameter baseURL: The base URL to which the endpoint path and query are appended.
    /// - Returns: A configured `URLRequest` with method, headers, and body set.
    /// - Throws: `DefaultNetworkError.cannotBuildURL` if URL construction fails.
    internal func asURLRequest(baseURL: URL) throws -> URLRequest {
        var components: URLComponents? = nil
        if #available(iOS 16.0, macOS 13.0, *) {
            components = URLComponents(url: baseURL.appending(path: path),
                                       resolvingAgainstBaseURL: false)
        } else {
            components = URLComponents(url: baseURL.appendingPathComponent(path),
                                       resolvingAgainstBaseURL: false)
        }
        
        components?.queryItems = query
        
        guard let components = components, let url = components.url else {
            throw DefaultNetworkError.cannotBuildURL
        }
        
        guard let scheme = url.scheme, let host = url.host, !scheme.isEmpty, !host.isEmpty else {
            LogUtilities.log("Invalid URL: \(url)")
            throw DefaultNetworkError.cannotBuildURL
        }
        
        var request = URLRequest(url: url)
        LogUtilities.log("Request URL: \(method.rawValue) \(url.absoluteString)")
        request.httpMethod = method.rawValue
        
        if let body = body {
            request.httpBody = try JSONEncoder().encode(body)
            request.setValue("application/json", forHTTPHeaderField: "Content-Type")
            if let data = request.httpBody {
                LogUtilities.log("Body: \n\(String(data: data, encoding: .utf8) ?? "Unable to convert body to string")")
            }
        }
        
        headers?.forEach { request.setValue($0.value, forHTTPHeaderField: $0.key) }
        
        return request
    }
}

This approach makes body, query, and headers configuration entirely transparent to the user.

Error Abstraction

To allow for customized error handling, the package introduces a protocol called NetworkErrorConvertible. By extending this protocol, each project can define and handle its own business logic errors.

For convenience, the package includes a default implementation (DefaultNetworkError) that you can use if you don’t need advanced error mapping.

Publishing the Package

Once your package is working and ready for integration, it’s time to make it available via Swift Package Manager (SPM). Here’s how:

1. Create a Git repository — I used GitHub;
2. Push your package code;
3. Navigate to the repository’s main page and click “Create a new release”;
4. Add a title and description for your release and — most importantly — create a tag (e.g., v1.0.0).

This tag is what SPM will use to identify which commit/version of your package to use during integration.

To add the package to an Xcode project, use:
File > Add Package Dependencies…,

then paste the repository URL:

You can also specify the exact version tag, helping you avoid potential breaking changes from future updates.

Conclusion

Building SwiftNetworking has been a valuable learning experience. It allowed me to deepen my understanding of Swift Package Manager, modular architecture, and asynchronous networking in a clean and testable way.

If you’re working on iOS/macOS apps and want a lightweight, customizable networking solution, feel free to explore and integrate the package — or contribute to its development.

🔗 GitHub Repository — SwiftNetworking

Coming soon: I’ll publish a follow-up article where I’ll cover how to add automated tests and set up GitHub workflows to validate all pushes to the main branch.

Happy coding! 🚀

A script that automates the creation of a local WordPress server based on a Duplicator backup using Docker

Have you ever found yourself in a situation where you wanted to test local changes for a website developed with WordPress? Or perhaps you had the desire to have a local backup of your site so that it’s always accessible? This process, especially when starting with a site that already has its own visual identity and structure, can become lengthy and complex. The script presented in this article aims to address this need by seeking to simplify this process as much as possible.

Prerequisites

The only prerequisite required to use the script is to have Docker installed on your system. Docker is a containerization platform that will be used to create the local server on which the site will be hosted. To install it, you can visit the following link.

Usage

Once you’ve downloaded the script’s repository, you’ll need the files generated by the Duplicator plugin, namely the zip file and ‘installer.php’. It’s essential for the script to function that the PHP file has the exact name ‘installer.php’. At this point, you just need to place these two files inside the ‘Source’ folder of the script’s directory and run it using the following shell command inside the script’s directory:

source docker_wp_create.sh

Now you only have to follow the prompts inside the terminal. Once the server is up and running the page to restore the Duplicator backup will open.

When you are asked to connect to the database, the values that you need to insert are:

• Host: db
• Database: wordpress
• User: The user you choose inside the terminal (Default is admin)
• Password: The password you choose inside the terminal (Default is admin)

You can see an example in the following image:

At the end of the restore process, the site will be up and running locally, and the server files can be found inside a folder with the name you specified in the ‘Projects’ directory within the script’s folder. To create new sites, you can simply replace the Duplicator files inside the ‘Source’ folder.

You can find the script in the following repository:

GitHub - Longo97/WP-Duplicator-Backup-Local-Restore: A script that automates the creation of a local WordPress server based on a Duplicator backup using Docker.

For any issues or ideas regarding future developments, feel free to reach out to me.

A storyboard is a graphical user interface (GUI) provided by Apple within the Xcode development environment. It’s a visual representation of an application’s user interface, allowing programmers to visually design and organize the various screens and views of the app. It provides a way to visually organize and connect different scenes, screens, and their respective elements such as buttons, labels, view controllers, and more. Its main features include:

• The ability to design individual scenes, representing specific screens or views of the app, and link these scenes to create the app’s flow;
• Segues define transitions between scenes based on specific actions;
• Links can be created between interface elements in the storyboard and Swift code using outlets and actions.

Everything that can be done within a storyboard can, of course, be replicated through code, but storyboards provide a simplified interface for creating them. However, this comes with disadvantages as the project complexity grows. These files tend to become larger and more complex, making it increasingly difficult to modify or add new parts. They also bring about challenges in resolving conflicts when multiple developers make simultaneous changes.

Given this, it’s not always certain that using storyboards in your project will lead to long-term benefits. Therefore, the steps to initialize a new Xcode project while removing the initial dependency on storyboards will now be listed.

1. Create a new Xcode project

When creating the new project, make sure to select Storyboard as Interface and Swift as Language.

2. Change project settings

Now, you have to remove the dependency onthe Main storyboard. First, inside your Project Target > Build Settings > Info.plist Values, remove the UIKit Main Storyboard File Base Name. By default, it contains a reference to the Main storyboard.

You are now free to delete the Main.storyboard file. The last thing to do inside the project settings is to update the info.plist file. You have to remove the Main.storyboard filename inside Information Property List > Application Scene Manifest > Scene Configuration > Window Application Session Role > Item 0 > Storyboard Name.

3. Update SceneDelegate

When working with a storyboard, the window property is automatically initialized and the root view controllers are set as the initial view controller in the storyboard. When removing the storyboard, you will have to do it by yourself. This can be done inside the SceneDelegate.swift file, modifying the scene function:

func scene(_ scene: UIScene, willConnectTo session: UISceneSession, options connectionOptions: UIScene.ConnectionOptions) {
        // Use this method to optionally configure and attach the UIWindow `window` to the provided UIWindowScene `scene`.
        // If using a storyboard, the `window` property will automatically be initialized and attached to the scene.
        // This delegate does not imply the connecting scene or session are new (see `application:configurationForConnectingSceneSession` instead).
        guard let windowScene = (scene as? UIWindowScene) else { return }
        let window = UIWindow(windowScene: windowScene)
        window.rootViewController = ViewController()
        window.makeKeyAndVisible()
        self.window = window
    }

Now your project is ready to go! As we conclude this guide, remember that the choice of whether to use storyboards or not ultimately depends on the specific needs and scale of your project. Each approach has its merits and considerations. Whether you choose to stick with a purely programmatic interface or leverage the convenience of storyboards for certain aspects, the key is to make an informed decision based on the requirements and goals of your application.

In recent months, there has been much talk about the latest updates to the GDPR and how these could affect the world of Open Source. If you’ve never heard this term before, the General Data Protection Regulation (GDPR) is a comprehensive and strict data privacy and protection law enacted by the European Union (EU). It is designed to strengthen and unify data protection for individuals within the EU and addresses the export of personal data outside the EU and EEA areas. GDPR regulates how organizations collect, use, process, and store personal data, imposing requirements to ensure individuals’ privacy rights and control over their data. Naturally, this regulation also impacts the world of app development, so it’s important to be well-prepared on the subject. Among the various things to consider to deem an app fully GDPR compliant is the necessity to display various information regarding all the third-party libraries that have been used for the development of our app. Collecting and displaying this data can be a long and tedious task, especially for iOS applications that use CocoaPods. To simplify your life, I’ve developed this small Python script, PodsAnalyzer, which will automate the collection of this information.

PodsAnalyzer allows you to analyze the installed CocoaPods in the project, providing a Property List (Plist) file as output containing information for each pod. To do this, it uses the CLI command pod spec, iterating through all the pods in the project and producing an output file containing the following information for each pod:

• Name
• Version
• License
• Git Source

This file can be easily imported into the project to then display the required information.

You can find the script in the following repository:

GitHub - Longo97/PodsAnalyzer: This script allows you to analyze the installed CocoaPods in the project, providing a Property List (Plist) file as output containing information for each pod.

In the README file, you’ll find a guide on how to use the script.

For any issues or ideas regarding future developments, feel free to reach out to me.