Fix name-space collision bug

[justinvallely]

• [x] All new/changed/fixed functionality is covered by tests (or N/A)
• [x] I have added documentation for all new/changed functionality (or N/A)

📋 Changes

1. Adds support for using with Swift 5.7 (Xcode 14)
2. Fixes name-space collisions that prevent integrating in some scenarios.

The compile-time errors due to this bug are preventing us from updating Auth0 to the latest version. This PR adds a "SK" prefix to two items to fix the bug. This could be changed to anything, even reverting back to "A0". Another option is to rename the module to something like "SimpleKeychainKit" instead of renaming the struct and enum that was done in this PR.

📎 References

In SimpleKeychain v1.0.0 a struct and an enum were renamed to drop the "A0" prefix. This causes namespace confusion for Swift. This is due to a known Swift bug: https://github.com/apple/swift/issues/56573

Warnings in SimpleKeychain

Errors in End User project

🎯 Testing

This is a simple name change so the framework should compile as it does currently. Unit tests were updated with the new names and all pass successfully.

[Widcket]

Hi @justinvallely, thanks for the PR. Unfortunately this would be a breaking change, so we can't merge it. Could you please provide more detail about the specific scenarios you're encountering this issue in?

[justinvallely]

Hi @Widcket! The Swift bug has been around for a couple of years but has only affected us starting with Xcode 14. I'm not sure what changed there, we're still investigating on our end.

If you build a sample cocoapods app, incorporating the SimpleKeychain app, you'll see compiler warnings that match our issue (see screenshot in description). Then, when SimpleKeychain is compiled as a XCFramework, those warnings become errors (screenshot above).

Yes, merging these changes would be breaking and would require a version bump release similar to when the A0 name prefix was dropped in the conversion from ObjC to Swift. 😅

[Widcket]

@justinvallely I just tried building a Cocoapods app with the latest version of Auth0.swift (which depends on SimpleKeychain) and the build succeeded, so I couldn't reproduce this.

Did you try the workaround mentioned in https://github.com/apple/swift/issues/56573?

[justinvallely]

@Widcket thanks for checking. I'll try that work around next. Were you able to see these warnings in a fresh project? They should show up as long as inhibit_all_warnings! is not added to the podfile.

[Widcket]

No, I just did the following and was unable to reproduce:

• Created a new app with Xcode 14.0.1 (14A400)
• Ran pod init
• Added SimpleKeychain to the Podfile
• Ran pod install
• Opened the workspace
• Inside ContentView.swift, imported SimpleKeychain and created an instance
• Ran the app

The Podfile

# Uncomment the next line to define a global platform for your project
# platform :ios, '9.0'

target 'CocoapodsTest' do
  # Comment the next line if you don't want to use dynamic frameworks
  use_frameworks!

  # Pods for CocoapodsTest
  pod 'SimpleKeychain', '~> 1.0'

end

ContentView.swift

import SwiftUI
import SimpleKeychain

let sk = SimpleKeychain()

struct ContentView: View {
    var body: some View {
        VStack {
            Image(systemName: "globe")
                .imageScale(.large)
                .foregroundColor(.accentColor)
            Text("Hello, world!")
        }
        .padding()
    }
}

struct ContentView_Previews: PreviewProvider {
    static var previews: some View {
        ContentView()
    }
}

[justinvallely]

@Widcket I followed your steps above and I as well wasn't able to recreate the warnings. However, as soon as I added Auth0 to the pod file (and ran pod install) the warnings showed up. Would you mind checking that as well at your convenience please? Thanks again for all your help with this!

Xcode 14.0.1 Cocoapods 1.11.3 MacBook Pro (2021) with Apple M1 Pro chip

[Widcket]

Hi @justinvallely, I just tried with Auth0.swift in two different ways and got no warnings:

1. Replacing SimpleKeychain in the Podfile with Auth0.swift

2. Adding Auth0.swift to the Podfile

I'm using Cocoapods 1.11.3, on an Intel MacBook Pro. Could you please try on an Intel machine?

[Widcket]

Also, in both cases I cleared Xcode's build cache before building.

[justinvallely]

Ok, we're getting somewhere. I tried on an Intel MBP and I can't reproduce on that machine so these warnings/errors look to be related to Apple Silicon.

[Widcket]

@poovamraj can you try and reproduce this on your M1 mac?

[Widcket]

Hi @justinvallely we just tested this on a M1 MBP using Xcode 13, and we were unable to reproduce. Make sure you're not using Library Evolution. We don't recommend building SimpleKeychain with Library Evolution enabled.

[justinvallely]

We didn't have any issues with Xcode 13 either. Could you please try with Xcode 14 on an M1 machine?

[Widcket]

Unfortunately we don't have one available.

[justinvallely]

Hi Rita, is there anything preventing you from installing Xcode 14 on the M1 MBP you mentioned above? We often have 2 version of Xcode installed (13 and 14 in this case) during transition times with no issues.

[Widcket]

We cannot because it's running an older macOS version that Xcode 14 does not support.

[Widcket]

Closing this as we don't recommend building the library with Library Evolution enabled. FWIW, we've had Lock.swift expose a Lock class for years, with the framework being called Lock as well.