Package setup often creates compiler errors

[squarefrog]

SDK version: 3.13.1

Environment: Development and Production

Describe the bug
We often encounter an issue when switching branches, we're no longer able to build our project unless we do a full clean and rebuild. This is due to our conformance of CustomerIO to a shared protocol to allow mocking. We're only able to import the public packages, and CustomerIO is declared in CioInternalCommon which is not publicly exposed, or re-exported.

While cleaning and rebuilding doesn't sound like an issue, this takes a long time and drastically reduces our developers productivity.

To Reproduce

The file that generally emits this error is in it's own package, and simply contains the following.

// implicitly imports CioInternalCommon
import CioDataPipelines

protocol PushServiceProtocol {
    static func initialize(withConfig config: SDKConfigBuilderResult)
    func identify(userId: String, traits: [String: Any]?)
}

extension CustomerIO: PushServiceProtocol {}

Other source files within this package import all of the following. Each of these has a dependence on CioInternalCommon.

import CioDataPipelines
import CioMessagingInApp
import CioMessagingPushAPN

Expected behavior
We should be able to switch branches without a 3rd party dependency breaking our build pipeline.

Screenshots

Additional context
This has been an issue for us since the CioInternalCommon changes were merged into 2.10.2.

[squarefrog]

I'm going to close this as I think we can overcome this issue with a tiny adapter

struct CioPushService: PushServiceProtocol {
    static func initialize(withConfig config: SDKConfigBuilderResult) {
        CustomerIO.initialize(withConfig: config)
    }

    func identify(userId: String, traits: [String: Any]?) {
        CustomerIO.shared.identify(userId: userId, traits: traits)
    }

    // and so on...
}

[squarefrog]

I'm going to reopen this as we cannot resolve this, even with the adapter shown above. It is significantly worse with Xcode 26, and means we have to do a clean build every time we switch branches.

Do you have any suggestions for how others have overcome this? As far as I can tell it's caused by the typealias to an internal type that is not reexported by the public packages.

[Shahroz16]

Hey @squarefrog thanks for reaching out, Are you using any wrapper protocols around CustomerIO in your codebase, or directly using the type?

[squarefrog]

@Shahroz16 yes - please see the PushServiceProtocol example in the first post. Using a wrapper is a requirement for us to facilitate unit testing, and prevent coupling usage with third-party dependencies.

[Shahroz16]

Thank you for sharing more details. We’ll review how we can improve this and determine if we can prioritize it. If this is an immediate blocker on your side, please feel free to fork in the meantime.

[squarefrog]

If anyone else is struggling with this, here's what worked for us:

1. Fork this repo
2. Update Package.swift and expose the internal common package
3. Update Sources/DataPipeline/Type/Aliases.swift and comment out all the typealiases
4. In your Project or Package definition reference your fork and branch
5. In your codebase, anywhere you reference CustomerIO (to conform it to a protocol etc), import CioInternalCommon

We can now reliably switch branches without compiler errors each time we build for testing. Of course this comes at a cost that updating to the latest version is now very inconvenient, so if you could prioritise a first-party fix, that would be useful.

[Shahroz16]

@squarefrog If you're using Xcode 16.3 or later and encounter errors like not available due to missing import of defining module 'CioMessagingPush'" when building your NotificationServiceExtension, you need to adjust a build setting:

1. In Xcode, select your NotificationServiceExtension target.
2. Go to the Build Settings tab.
3. Search for Member Import Visibility.
4. Set the value to "Package" or disable the setting.

This resolves module visibility issues introduced in Xcode 16.3.

We will fix this in SDK too.

[squarefrog]

We already had that setting set to NO, but these errors were emanating from our main target, not the extension.