Hi,

One of our dependency (CometChatPro) has a namespace conflict in the compile run time. This happens in XCode 12.

The affected class object is

'User' has different definitions in different modules; first difference is definition in module 'CometChatPro.Swift' found super class with type 'AppEntity' User: App

Additionally, there are many developers facing this issue with other pods as well.
https://developer.apple.com/forums/thread/658012

Could you look into this issue as it does not give us confidence in integrating ConfigCat SDK with our project.

Thanks

Describe the bug

When using carthage to build ConfigCat as an XCFramework, the simulator framework's Info.plist is missing a CFBundleIdentifier.

This causes Xcode to fail installing an app to the simulator with the following error.

Bundle at path ~/Users/neo~/Library/Developer/CoreSimulator/Devices/9DDC0094-839D-45A5-86FC-3E1A6AFFC881/data/Library/Caches/com.apple.mobile.installd.staging/temp.MKcv1j/extracted/Payload/App/Frameworks/ConfigCat.framework did not have a CFBundleIdentifier in its Info.plist
Domain: MIInstallerErrorDomain
Code: 12
User Info: {
    FunctionName = "-[MIBundle _validateWithError:]";
    LegacyErrorString = MissingBundleIdentifier;
    SourceFileLine = 54;
}

To reproduce

carthage build swift-sdk --platform ios --use-xcframeworks
/usr/libexec/PlistBuddy -c "Print :CFBundleIdentifier" Carthage/Build/ConfigCat.xcframework/ios-arm64_armv7/ConfigCat.framework/Info.plist
/usr/libexec/PlistBuddy -c "Print :CFBundleIdentifier" Carthage/Build/ConfigCat.xcframework/ios-arm64_i386_x86_64-simulator/ConfigCat.framework/Info.plist

Expected behavior

After building the XCFramework with carthage, the following two lines should print out the CFBundleIdentifier from the iOS and iOS Simulator framework. They should both have a value but the second one fails with

Print: Entry, ":CFBundleIdentifier", Does Not Exist

Describe the bug

Using Xcode 14.0.1 (14A400) it does appear this compilation error
'let' property 'major' may not be initialized directly; use "self.init(...)" or "self = ..." instead onto Version.swift.

To reproduce

Use ConfigCat as Pod in a project and try to build with Xcode Version 14.0.1 (14A400)

Expected behavior

Build successfully without any errors.

Screenshots

I see it is using OSLog() for most of the logging, which is good. But it logs too many things like Evaluating rule: or Returning User object: {...}, which clutters up our console log. Is there a way to disable logging to Xcode debug console?

Hi! I think I have found a potential issue related to Async and AsyncResult in the code base. As Async executes submitted completion handlers on its own private queue, there is a potential for data races when manipulating shared resources.

To reproduce

Consider the following test:

import XCTest
@testable import ConfigCat

class CrashAsyncTests: XCTestCase {
    
    func testNotCrashing() {
        let numberOfAttempts = 10
        let expectation = self.expectation(description: "wait for all attempts to mutate dictionary")
        expectation.assertForOverFulfill = true
        expectation.expectedFulfillmentCount = numberOfAttempts
        for i in 0..<numberOfAttempts {
            var sharedResource = ["": ""]
            let async = Async()
            async.apply {
                sharedResource["\(i)"] = "blargh"
                expectation.fulfill()
            }
            async.complete()
        }
        wait(for: [expectation], timeout: .pi)
    }
    
    func testCrashing() {
        let numberOfAttempts = 10
        let expectation = self.expectation(description: "wait for all attempts to mutate dictionary")
        expectation.assertForOverFulfill = true
        expectation.expectedFulfillmentCount = numberOfAttempts
        var sharedResource = ["": ""]
        for i in 0..<numberOfAttempts {
            let async = Async()
            async.apply {
                sharedResource["\(i)"] = "blargh"
                expectation.fulfill()
            }
            async.complete()
        }
        wait(for: [expectation], timeout: .pi)
    }

}

When running the test above with thread sanitizer enabled, one can indeed observe a data race:

In and of itself, one can stipulate that Async inherently is not thread safe, which is not necessarily problematic. The issue arises when one is manipulating a shared resources via different instances of Async or AsyncResult.

One example of this, can be found in the way AutoPollingPolicy.writeConfigCache|readConfigCache are called in closures passed to instances of AsyncResult. See AutoPollingPolicy:59:

timer.setEventHandler(handler: { [weak self] in
            guard let `self` = self else {
                return
            }

            if self.fetcher.isFetching() {
                self.log.debug(message: "Config fetching is skipped because there is an ongoing fetch request")
                return;
            }

            self.fetcher.getConfiguration()
                .apply(completion: { response in
                    let cached = self.readConfigCache()
                    if let config = response.config, response.isFetched() && config.jsonString != cached.jsonString {
                        self.writeConfigCache(value: config) // <- writing to property on Async's private queue
                        self.onConfigChanged?()
                    }
                    
                    if !self.initialized.getAndSet(new: true) {
                        self.initResult.complete()
                    }
                })
        })

and in AutoPollingPolicy:95:

public override func getConfiguration() -> AsyncResult<Config> {
        if self.initResult.completed {
            return self.readCacheAsync()
        }
        
        return self.initResult.apply(completion: {
            return self.readConfigCache() // <- reading from property on Async's private queue
        })
    }

While access to properties are enforced some places in the code base with Synced, in the said examples the code is inherently not thread safe. It is perhaps unfortunate that a by-effect of Async's implementation leads to dispatching code on otherwise inaccessible queues to code from the outside, such that synchronization is needed.

Another issue is that AsyncResult itself is not thread safe. In AsyncResult:96:

public func complete(result: Value) {
        self.result = result // <- assignment on the caller's queue
        super.complete()
    }

we can see that self.result is assigned the argument of complete(result:). As it is not private, the method will be called on the caller's queue. In AsyncResult:122:

@discardableResult
    public func apply(completion: @escaping (Value) -> Void) -> AsyncResult<Value> {
        self.queue.async {
            if self.state.get().isCompleted() {
                guard let result = self.result else { // <- reading self.result on private queue
                    assert(false, "completion handlers executed on an incomplete AsyncResult")
                    return
                }
                
                completion(result)
            } else {
                self.completions.append({
                    guard let result = self.result else {
                        assert(false, "completion handlers executed on an incomplete AsyncResult")
                        return
                    }
                    
                    completion(result)
                })
            }
        }
        
        return self
    }

Thus, it is evident there is a potential for accessing self.result on different queues.

Conversely, the property Async.state is wrapped in a thread safe container / actor. However, since this is a private property, and it is seemingly only accessed on Async.queue, it never had to be wrapped in synchronization code in the first place.

Describe the bug

Xcode 14.3 started warning about this possible hang risk:

Thread running at QOS_CLASS_USER_INTERACTIVE waiting on a lower QoS thread running at QOS_CLASS_DEFAULT. Investigate ways to avoid priority inversions.

It happens in ConfigCatClient.getValueSync(for:defaultValue:user:):167, in the semaphore.wait() call.

To reproduce

Compile the app using Xcode 14.3 and run it.

Expected behavior

No warnings about possible thread hangs.

Screenshots

Describe the bug

Run app on simulator with ConfigCat pod and building fails. Missing architecture arm64-simulator

To reproduce

Using the latest version of Xcode (12.5.1) on most recent's Apple MacBook Pro (processor Apple M1), install ConfigCat (7.2.0) install using Cocoapods (1.11.0)

1. Attempt to Build
2. Observe error: Framework not found ConfigCat

Expected behavior

Builds successfully with no errors or warnings

SDK version

ConfigCat (7.2.0)

Platform

MacBook Pro (13-inch, M1, 2020)
macOS Big Sur 11.5.2 (20G95)