Context

Recently, a client approached us to integrate a banking app SDK into their existing mobile banking application. While I can’t share all the details due to NDA restrictions, the challenge was straightforward on the surface: integrate an SDK. Easy! I thought to myself. However, the client’s requirements demanded a level of control and security that went beyond our standard CocoaPods integration.

Most banking apps follow tight security standards to prevent any data breaches and compromise. So they tend to integrate external libraries differently. Instead of CocoaPods, they use frameworks, which provide more control over the code they “inject” into their applications.

So, a new challenge on our hands. Enter the world of XCFrameworks: a modern approach to packaging code for multiple platforms, ensuring a single, self-contained binary that’s robust and future-proof (According to Apple).

So a few terminologies as we begin:

  1. Library 📚: Collection of compiled code(functions, classes, etc.) you can link to your app. Think of it like a toolbox - you copy tools from it into your app (static) or your app borrows tools from it while running(dynamic)
  2. Framework 🧰: A library plus extras(Headers, Resources like images, Metadata like the info.plist) packaged neatly into a single folder. UIKit.Framework is a really good example.
  3. XCFramework 📦: A bundle of frameworks for different platforms(iOS Device, iOS Simulator, Mac). Think of it as a big shipping box containing multiple toolboxes, each designed for different machines.

So how did we settle for an xcframework?

  1. Multi-Architecture Support: Well a normal framework only supports once architecture at a time. So I’d have to build two frameworks manually for the client to be able to test it on a physical device and on a simulator. Not sure about you but that just feels like a hustle each time I have to build my project.
  2. Modern Standard: Apple has really been pushing it since Xcode 11 as a modern standard. So we kinda have to comply 😅.
  3. Future proofing:, if we later want to add support for visionOS, macOS, tvOS, it's way easier to add that support than building out entire frameworks for each architecture.

A Quick Preview of the Demo Project

For starters, we'll be working with a brand new project that loosely mirrors what we built for the banking app SDK. It’s a simple iOS app that subscribes to an MQTT topic to receive and display seismic activity messages in real-time — built using UIKit and the CocoaMQTT client library.

The main app has a Subscribe button that initializes the library and presents a chat-like modal screen where incoming seismic activity messages appear live as they are published. Along the way, we’ll also dive a little into how MQTT works and how you can set up a broker to test the project yourself.

You can check out the demo project here:

  1. Demo App 🤳🏾: https://github.com/Sianwa/SeismicDemo.git
  2. Framework 🧰: https://github.com/Sianwa/SeismicLib.git

Seismic App Demo
Seismic Lib Modal

What’s Coming Next?

  1. Demo App Walkthrough

    A quick introduction to the project — how to clone it, set it up, and what to expect as you start playing around.

  2. Getting Started with XCFrameworks:

    A detailed walkthrough of building and packaging your first XCFramework.

  3. Embedding Dependencies:

    How to integrate third-party libraries directly into your framework.

  4. Distribution Options:

    Exploring different methods to distribute your self-contained SDK, including GitHub Releases and Swift Package Manager.

  5. Reflecting on the Journey:

    A candid look at the challenges, trade-offs, and future improvements for our SDK.