Tuist & Revenue Cat, Part 2

This blog post series is done in conjunction with the Ship-a-thon/Melting-hacks
In part 1, I have already explained the basics surrounding these tools.
For part 2, I will go deeper into how to utilize & integrate these tools into your project.

Configurations

If you have read part 1 and followed along with the code, you have probably setup Revenue Cat successfully (hopefully). However, in order to actually use the SDK, you need to setup the public key inside your source code.

As you are well aware, committing the key directly to your version control backend is highly frowned upon. Similar to other languages, you can setup a xcconfig file to setup value that you don’t want to commit to version control.

You can simply create a xcconfig file and add a definition like below.

Base.xcconfig
Naming is entirely up to you, also it is not an actual key if you are wondering

RC_PUBLIC_KEY=rc_test_key

How do you inject this value into the actual source code? With Tuist, it’s rather simple. You just need to setup a build configuration that reference the value. You can do it like below.

// You can name the config freely as well, I usually go with Debug, Staging, Release

let settings: Settings = .settings(
    base: [
        "PROJECT_BASE": "PROJECT_BASE",
    ],
    configurations: [
        .debug(name: "Debug", xcconfig: "Base.xcconfig"),
    ]
)

Now, whenever you build & run your project, the value will be injected into your source code.

Development setup

After you have completed the configuration setup, you are pretty much ready to monetize your application. However, you are still reliant on Revenue Cat backend to test your purchase or paywall setup. That’s where the StoreKit config comes in.

Assuming you have already setup your subscription on App Store Connect, you can easily create a StoreKit config directly from Xcode. It will retrieve and create a StoreKit config without you doing much.

However, since the file is created with Xcode. It is not actually registered within our project since it is all generated by Tuist. There is some extra work in getting it to work with Tuist.

Let’s create a build config that will be using our StoreKit file instead of retrieving from the server.

let debugScheme: Scheme = .scheme(
    name: "Debug", shared: true,
    buildAction: .buildAction(targets: ["Artomo"]),
    testAction: .targets(["Artomo"]),
    runAction: .runAction(
        executable: "Artomo",
        options: .options(storeKitConfigurationPath: "Debug.storekit")
    )
)

Now, you can easily test and make changes to your subscription offerings locally without needing to fetch from the servers

Closing

I hope I had done a good job introducing Tuist & Revenue Cat. Both are wonderful tools on their own but can be use together to make your experience developing iOS app all the more better!